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

[Juerg Haefliger]

On Tue, 29 Jun 2021 11:49:56 +0200
Kleber Souza <kleber.souza at canonical.com> wrote:

> 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.

Ok. Thanks for the explanation.


> > 
> >     
> >> [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.

We should really try to keep debian/* consistent across all kernels. I'm
certain we're going to end up in a world of pain if we deviate and copy
stuff for new kernels and end up being different all over the place (which
I'm pretty sure we are already). debian/* needs to be flexible enough so that
kernel-specifics can be driven via settings/overrides in debian.<foo>/*.
Crazy thought: debian/* lives in kteam-tools (or somewhere) and gets cranky
fixed every time...

...Juerg



> Thanks for the review.
> 
> Kleber

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20210629/54d27b3c/attachment.sig>