ACK/cmt: [SRU][focal/linux-riscv-5.8][PATCH 0/1] gcc version used for kernel configs doesn't match the one used for builds

Kleber Souza kleber.souza at canonical.com
Tue Jun 29 09:49:56 UTC 2021


On 29.06.21 10:21, Juerg Haefliger wrote:
> On Mon, 28 Jun 2021 18:31:24 +0200
> Kleber Sacilotto de Souza <kleber.souza at canonical.com> wrote:
> 
>> BugLink: https://bugs.launchpad.net/bugs/1933856
>>
>> [Impact]
>> linux-riscv-5.8 needs to be built with gcc-10 in Focal otherwise it won't boot.
>> This was fixed by commit "UBUNTU: [Packaging] Use gcc-10 for riscv 5.8 kernel
>> build", which adds gcc-10 as "Build-Depends-Arch" and sets a variable "gcc" in
>> 'debian/rules', which is passed down to make by
>> 'debian/rules.d/2-binary-arch.mk'.
>>
>> The other gcc version dependency is when we generate locally the kernel configs
>> by running 'make syncconfig', which is called by
>> 'debian/scripts/misc/kernelconfig'. Currently, the syncconfig is called using
>> the chroot default compiler, which in Focal is gcc-9. So far there hasn't been
>> any major differences, however with the update of gcc-10 in Groovy and Focal
>> from 10.2.0 to 10.3.0 some KASAN related config options are not available
>> anymore, causing some changes on the configs generated. The problem with
>> non-matching gcc versions being used, is that there will be a mismatch between
>> the configs being generated during the preparation of the kernel and the ones
>> during the build.
> 
> Differences as in CC_VERSION is different or are there other config
> differences?

CONFIG_GCC_VERSION differences were not causing any issue, as they have always
been diverging until recently. With gcc 10.3.0, CC_HAS_KASAN_GENERIC is not
available as it depends on the following compiler flag:

config CC_HAS_KASAN_GENERIC
         def_bool $(cc-option, -fsanitize=kernel-address)

'cc-option' will do something similar to the following, which with gcc 10.2.0
riscv64 cross compiler would return success:

$ /usr/bin/riscv64-linux-gnu-gcc-10 -Werror -fsanitize=kernel-address -c -x c /dev/null
$ echo $?
0

But with 10.3.0 this doesn't seem to be supported anymore as a standalone flag, depending
now on '-fasan-shadow-offset=':

$ /usr/bin/riscv64-linux-gnu-gcc-10 -Werror -fsanitize=kernel-address -c -x c /dev/null
cc1: error: ‘-fsanitize=kernel-address’ with stack protection is not supported without
‘-fasan-shadow-offset=’ for this target [-Werror]

And all KASAN options get removed altogether.

This doesn't cause any real config change, as we disable CONFIG_KASAN anyway. But
for our annotations '-' != 'n', failing the config checks.


> 
>   
>> [Fix]
>> The proposed fix is to use the same variable defined for the build, passing it
>> down to 'debian/scripts/misc/kernelconfig' and using it to define the correct
>> cross-compiler to be used.
>>
>> [Where problems could occur]
>> If the environment variables are not set correctly the build can break in some
>> environment which was not tested.
>>
>> Kleber Sacilotto de Souza (1):
>>    UBUNTU: [Packaging] Use gcc-10 for riscv-5.8 kernel configs
>>
>>   debian/rules.d/1-maintainer.mk   | 4 ++--
>>   debian/scripts/misc/kernelconfig | 7 ++++---
>>   2 files changed, 6 insertions(+), 5 deletions(-)
>>
> 
> We're deviating from other kernels. Shouldn't this be a cranky fix of sorts
> or is there a reason why we can't put this in all kernels?

I agree this solution is not ideal, but this issue is still specific for riscv
in Focal which is already deviating from the other kernels. I didn't think it
was worth the effort to craft a cranky fix patch and have it more thoroughly
tested just to cover this specific case.

We'll need to backport more recent kernels to Focal, 5.13 being likely the next
one, and if those will need a more recent gcc as well then we'll need to pull
something as you are suggesting.

Thanks for the review.

Kleber



More information about the kernel-team mailing list