On Tue, 3 Dec 2024 at 15:56, James Bottomley
<James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote:
>
> On Tue, 2024-12-03 at 09:35 +0100, Ard Biesheuvel wrote:
> > On Mon, 2 Dec 2024 at 21:27, James Bottomley
> > <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote:
> > >
> > > I'm getting this in 6.13-rc1:
> > >
> > > /home/jejb/git/linux-tpm/lib/crypto/aesgcm.c:212:29: error: ptext1
> > > causes a section type conflict with aesgcm_tv
> > > static const u8 __initconst ptext1[16];
> > > ^~~~~~
> > > /home/jejb/git/linux-tpm/lib/crypto/aesgcm.c:570:9: note:
> > > ‘aesgcm_tv’ was declared here
> > > } const aesgcm_tv[] __initconst = {
> > > ^~~~~~~~~
> > > make[5]: *** [/home/jejb/git/linux-tpm/scripts/Makefile.build:194:
> > > lib/crypto/aesgcm.o] Error 1
> > > /home/jejb/git/linux-tpm/lib/crypto/aesgcm.c:212:29: error: ptext1
> > > causes a section type conflict with aesgcm_tv
> > > static const u8 __initconst ptext1[16];
> > > ^~~~~~
> > > /home/jejb/git/linux-tpm/lib/crypto/aesgcm.c:570:9: note:
> > > ‘aesgcm_tv’ was declared here
> > > } const aesgcm_tv[] __initconst = {
> > > ^~~~~~~~~
> > > make[5]: *** [/home/jejb/git/linux-tpm/scripts/Makefile.build:194:
> > > lib/crypto/aesgcm.o] Error 1
> > >
> > > I think it's way older than 6.13-rc1, but the inclusion of the
> > > sevguest
> > > driver in the merge window now means that something actually
> > > selects
> > > it. I can fix it simply by adding a zero initialization to the
> > > file:
> > >
> > > -static const u8 __initconst ptext1[16];
> > > +static const u8 __initconst ptext1[16] = { 0 };
> > >
> > > Which I think means that by default the traditional zero
> > > initialization
> > > of a static variable is in the wrong section (and actually likely
> > > is
> > > wrong for all our __initX variables as well).
> > >
> > > In case it matters, this is with gcc-7
> > >
> >
> > This also works
> >
> > static const u8 __section(".init.rodata,\"a\",@progbits #")
> > ptext1[16];
>
> That also works for me.
>
> > and so this suggests that without the @progbits annotations, the
> > compiler is placing ptext1 into a SHT_NOBITS section, causing a
> > conflict with the SHT_PROGBITS annotation of aesgcm_tv.
>
> I'm not so sure about that:
>
> static const u8 __section(".bss.init,\"a\",@nobits #") ptext1[16];
>
> Also works for me.
>
I'm not sure I get the point you are trying to make. .bss.init does
not exist otherwise, so there is no other section it might conflict
with.
> > Given how unusual it is to have a static const variable without an
> > initializer, I don't think this suggests that there is a wider issue
> > with __initconst/__initdata.
>
> What I meant was that uninitialized static __initX variables point to
> the bss section. We don't seem to have a discardable init bss section,
> so they remain allocated for the life of the kernel.
>
This is not about the section, but about the type annotation.
__initdata will be emitted into .init.data, and it will be discarded
after boot. Even if there is no initializer, the variable will still
end up in the correct section, and not point to the .bss section as
you claim.
> > We're about to bump the minimum GCC version to 8 for other reasons,
> > and I couldn't reproduce it with GCC 8.5.0. But the fix is
> > straight-forward and actually clarifies this rather odd occurrence,
> > so I think we should apply it nonetheless.
>
> Hm, that's going to cause some problems: I'm on openSUSE Leap.
> Although all gcc's up to gcc-13 can be installed, the default compiler
> is still gcc-7
>
I guess you will have to upgrade your compiler then.
