Re: [mainline]Error while running make modules_install command

Re: [mainline]Error while running make modules_install command

[Omar Sandoval]

On Tue, Nov 04, 2025 at 04:54:38PM +0530, Venkat Rao Bagalkote wrote:
> 
> On 04/11/25 4:47 pm, Samir M wrote:
> > Hello,
> > 
> > 
> > I am observing below error while running the make modules_install
> > command on latest mainline kernel on IBM Power11 server.
> > 
> > 
> > Error:
> > DEPMOD  /lib/modules/6.18.0-rc4
depmod: ERROR: kmod_builtin_iter_next:
> > unexpected string without modname prefix
> > 
> 
> IBM CI has also reported this error.
> 
> 
> Error:
> 
> 
> depmod: ERROR: kmod_builtin_iter_next: unexpected string without modname
> prefix
>   INSTALL /boot
> depmod: ERROR: kmod_builtin_iter_next: unexpected string without modname
> prefix
> depmod: ERROR: kmod_builtin_iter_next: unexpected string without modname
> prefix
> 
> 
> Git bisect is pointing to below commit as first bad commit.
> 
> 
> d50f21091358b2b29dc06c2061106cdb0f030d03 is the first bad commit
> commit d50f21091358b2b29dc06c2061106cdb0f030d03
> Author: Dimitri John Ledkov <dimitri.ledkov@surgut.co.uk>
> Date:   Sun Oct 26 20:21:00 2025 +0000
> 
>     kbuild: align modinfo section for Secureboot Authenticode EDK2 compat
> 
>     Previously linker scripts would always generate vmlinuz that has
> sections
>     aligned. And thus padded (correct Authenticode calculation) and unpadded
>     calculation would be same. As in https://github.com/rhboot/pesign
> userspace
>     tool would produce the same authenticode digest for both of the
> following
>     commands:
> 
>         pesign --padding --hash --in ./arch/x86_64/boot/bzImage
>         pesign --nopadding --hash --in ./arch/x86_64/boot/bzImage
> 
>     The commit 3e86e4d74c04 ("kbuild: keep .modinfo section in
>     vmlinux.unstripped") added .modinfo section of variable length.
> Depending
>     on kernel configuration it may or may not be aligned.
> 
>     All userspace signing tooling correctly pads such section to calculation
>     spec compliant authenticode digest.
> 
>     However, if bzImage is not further processed and is attempted to be
> loaded
>     directly by EDK2 firmware, it calculates unpadded Authenticode digest
> and
>     fails to correct accept/reject such kernel builds even when propoer
>     Authenticode values are enrolled in db/dbx. One can say EDK2 requires
>     aligned/padded kernels in Secureboot.
> 
>     Thus add ALIGN(8) to the .modinfo section, to esure kernels irrespective
> of
>     modinfo contents can be loaded by all existing EDK2 firmware builds.
> 
>     Fixes: 3e86e4d74c04 ("kbuild: keep .modinfo section in
> vmlinux.unstripped")
>     Cc: stable@vger.kernel.org
>     Signed-off-by: Dimitri John Ledkov <dimitri.ledkov@surgut.co.uk>
>     Link:
> https://patch.msgid.link/20251026202100.679989-1-dimitri.ledkov@surgut.co.uk
>     Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> 
>  include/asm-generic/vmlinux.lds.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

drgn's CI hit this same failure. FWIW, the commit fixed by this bisected
commit, 3e86e4d74c04 ("kbuild: keep .modinfo section in
vmlinux.unstripped"), also results in ELF segments of size 0 in vmlinux
for some configurations, which confused drgn until I added a workaround
(https://github.com/osandov/drgn/commit/2a9053de8796af866fd720a3c8c23013595d391a).
So there's some funkiness in this area.

Thanks,
Omar

Re: [mainline]Error while running make modules_install command

[Dimitri John Ledkov]

On Tue, 4 Nov 2025 at 18:12, Omar Sandoval <osandov@osandov.com> wrote:
>
> On Tue, Nov 04, 2025 at 04:54:38PM +0530, Venkat Rao Bagalkote wrote:
> >
> > On 04/11/25 4:47 pm, Samir M wrote:
> > > Hello,
> > >
> > >
> > > I am observing below error while running the make modules_install
> > > command on latest mainline kernel on IBM Power11 server.
> > >
> > >
> > > Error:
> > > DEPMOD  /lib/modules/6.18.0-rc4
depmod: ERROR: kmod_builtin_iter_next:
> > > unexpected string without modname prefix
> > >
> >
> > IBM CI has also reported this error.
> >
> >
> > Error:
> >
> >
> > depmod: ERROR: kmod_builtin_iter_next: unexpected string without modname
> > prefix
> >   INSTALL /boot
> > depmod: ERROR: kmod_builtin_iter_next: unexpected string without modname
> > prefix
> > depmod: ERROR: kmod_builtin_iter_next: unexpected string without modname
> > prefix
> >
> >
> > Git bisect is pointing to below commit as first bad commit.
> >
> >
> > d50f21091358b2b29dc06c2061106cdb0f030d03 is the first bad commit
> > commit d50f21091358b2b29dc06c2061106cdb0f030d03
> > Author: Dimitri John Ledkov <dimitri.ledkov@surgut.co.uk>
> > Date:   Sun Oct 26 20:21:00 2025 +0000
> >
> >     kbuild: align modinfo section for Secureboot Authenticode EDK2 compat
> >
> >     Previously linker scripts would always generate vmlinuz that has
> > sections
> >     aligned. And thus padded (correct Authenticode calculation) and unpadded
> >     calculation would be same. As in https://github.com/rhboot/pesign
> > userspace
> >     tool would produce the same authenticode digest for both of the
> > following
> >     commands:
> >
> >         pesign --padding --hash --in ./arch/x86_64/boot/bzImage
> >         pesign --nopadding --hash --in ./arch/x86_64/boot/bzImage
> >
> >     The commit 3e86e4d74c04 ("kbuild: keep .modinfo section in
> >     vmlinux.unstripped") added .modinfo section of variable length.
> > Depending
> >     on kernel configuration it may or may not be aligned.
> >
> >     All userspace signing tooling correctly pads such section to calculation
> >     spec compliant authenticode digest.
> >
> >     However, if bzImage is not further processed and is attempted to be
> > loaded
> >     directly by EDK2 firmware, it calculates unpadded Authenticode digest
> > and
> >     fails to correct accept/reject such kernel builds even when propoer
> >     Authenticode values are enrolled in db/dbx. One can say EDK2 requires
> >     aligned/padded kernels in Secureboot.
> >
> >     Thus add ALIGN(8) to the .modinfo section, to esure kernels irrespective
> > of
> >     modinfo contents can be loaded by all existing EDK2 firmware builds.
> >
> >     Fixes: 3e86e4d74c04 ("kbuild: keep .modinfo section in
> > vmlinux.unstripped")
> >     Cc: stable@vger.kernel.org
> >     Signed-off-by: Dimitri John Ledkov <dimitri.ledkov@surgut.co.uk>
> >     Link:
> > https://patch.msgid.link/20251026202100.679989-1-dimitri.ledkov@surgut.co.uk
> >     Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> >
> >  include/asm-generic/vmlinux.lds.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
>
> drgn's CI hit this same failure. FWIW, the commit fixed by this bisected
> commit, 3e86e4d74c04 ("kbuild: keep .modinfo section in
> vmlinux.unstripped"), also results in ELF segments of size 0 in vmlinux
> for some configurations, which confused drgn until I added a workaround
> (https://github.com/osandov/drgn/commit/2a9053de8796af866fd720a3c8c23013595d391a).
> So there's some funkiness in this area.

The expectation is that said section is removed from the final binary.
But the fact that it is present with 0 length, indicates incorrect
linking. It also now makes sense why on x86/arm it is tripping up
section alignment.

As it is likely that it is the same underlying issue that such segment
exists in the first place.

I wonder if the original implementation of moving sections about and
when/where the builtin module info is kept is not as tidy as it was
intended to be.

I wonder if we should:
- rollback to the state of how things were before that feature was added
- keep the production / stripped / installed kernel build as is
- reshuffle of how modinfo is preserved in the unstripped kernel with
a bespoke linker script

Such that hopefully we have correct alignment, without any zero length segments.

Or possibly even link / split the built-in module info somewhere else entirely.

As in revert both:
- d50f21091358b (kbuild: align modinfo section for Secureboot
Authenticode EDK2 compat, 2025-10-26)
- 3e86e4d74c049 (kbuild: keep .modinfo section in vmlinux.unstripped,
2025-09-18)

And try implementing the keeping of .modinfo section again.

Better structure tests, after linking would be nice to catch such
issues, because linker scripts are hard and trying to understand how a
linker script change affects the result.

-- 
Regards,

Dimitri.

Re: [mainline]Error while running make modules_install command

[Nathan Chancellor]

On Tue, Nov 04, 2025 at 08:35:57PM +0000, Dimitri John Ledkov wrote:
> On Tue, 4 Nov 2025 at 18:12, Omar Sandoval <osandov@osandov.com> wrote:
> > drgn's CI hit this same failure. FWIW, the commit fixed by this bisected
> > commit, 3e86e4d74c04 ("kbuild: keep .modinfo section in
> > vmlinux.unstripped"), also results in ELF segments of size 0 in vmlinux
> > for some configurations, which confused drgn until I added a workaround
> > (https://github.com/osandov/drgn/commit/2a9053de8796af866fd720a3c8c23013595d391a).
> > So there's some funkiness in this area.

Omar, could you provide me with a configuration file that reproduces
this for you? Is there an easy way to check for this situation on the
command line?

> The expectation is that said section is removed from the final binary.
> But the fact that it is present with 0 length, indicates incorrect
> linking. It also now makes sense why on x86/arm it is tripping up
> section alignment.

If I diff the output of 'llvm-readelf -e' for vmlinux.unstripped and
vmlinux when building 'ARCH=arm64 defconfig' using my suggested diff on
top of 6.18-rc4, I do see .modinfo get removed and I am not sure I see
an empty segment as a result?

diff --git a/tmp/.psub.Rg1zsq b/tmp/.psub.nGpcxI
index 2f079cb57f58..dcca71062760 100644
--- a/tmp/.psub.Rg1zsq
+++ b/tmp/.psub.nGpcxI
@@ -10,15 +10,15 @@ ELF Header:
   Version:                           0x1
   Entry point address:               0xffff800080000000
   Start of program headers:          64 (bytes into file)
-  Start of section headers:          157810560 (bytes into file)
+  Start of section headers:          156417384 (bytes into file)
   Flags:                             0x0
   Size of this header:               64 (bytes)
   Size of program headers:           56 (bytes)
-  Number of program headers:         5
+  Number of program headers:         4
   Size of section headers:           64 (bytes)
-  Number of section headers:         47
-  Section header string table index: 46
-There are 47 section headers, starting at offset 0x967ff80:
+  Number of section headers:         46
+  Section header string table index: 45
+There are 46 section headers, starting at offset 0x952bd68:
 
 Section Headers:
   [Nr] Name              Type            Address          Off    Size   ES Flg Lk Inf Al
@@ -56,19 +56,18 @@ Section Headers:
   [31] .mmuoff.data.read PROGBITS        ffff80008270b800 271b800 000008 00  WA  0   0  8
   [32] .pecoff_edata_padding PROGBITS    ffff80008270b808 271b808 0001f8 00   A  0   0  1
   [33] .bss              NOBITS          ffff80008270c000 271ba00 0ac970 00  WA  0   0 4096
-  [34] .debug_aranges    PROGBITS        0000000000000000 27d09d0 047550 00      0   0 16
-  [35] .debug_info       PROGBITS        0000000000000000 2817f20 38fdcf1 00      0   0  1
-  [36] .debug_abbrev     PROGBITS        0000000000000000 6115c11 4845e1 00      0   0  1
-  [37] .debug_line       PROGBITS        0000000000000000 659a1f2 1848e28 00      0   0  1
-  [38] .debug_frame      PROGBITS        0000000000000000 7de3020 3e2858 00      0   0  8
-  [39] .debug_str        PROGBITS        0000000000000000 81c5878 58f8cc 01  MS  0   0  1
-  [40] .debug_line_str   PROGBITS        0000000000000000 8755144 057ff7 01  MS  0   0  1
-  [41] .debug_rnglists   PROGBITS        0000000000000000 87ad13b 4d3fc6 00      0   0  1
-  [42] .modinfo          PROGBITS        ffff8000827d0000 2720000 0b09c8 00   A  0   0  1
-  [43] .comment          PROGBITS        0000000000000000 8c81101 000012 01  MS  0   0  1
-  [44] .symtab           SYMTAB          0000000000000000 8c81118 671a60 18     45 250028  8
-  [45] .strtab           STRTAB          0000000000000000 92f2b78 38d1f3 00      0   0  1
-  [46] .shstrtab         STRTAB          0000000000000000 967fd6b 000215 00      0   0  1
+  [34] .debug_aranges    PROGBITS        0000000000000000 271ba00 047550 00      0   0 16
+  [35] .debug_info       PROGBITS        0000000000000000 2762f50 38fdcf1 00      0   0  1
+  [36] .debug_abbrev     PROGBITS        0000000000000000 6060c41 4845e1 00      0   0  1
+  [37] .debug_line       PROGBITS        0000000000000000 64e5222 1848e28 00      0   0  1
+  [38] .debug_frame      PROGBITS        0000000000000000 7d2e050 3e2858 00      0   0  8
+  [39] .debug_str        PROGBITS        0000000000000000 81108a8 58f8cc 01  MS  0   0  1
+  [40] .debug_line_str   PROGBITS        0000000000000000 86a0174 057ff7 01  MS  0   0  1
+  [41] .debug_rnglists   PROGBITS        0000000000000000 86f816b 4d3fc6 00      0   0  1
+  [42] .comment          PROGBITS        0000000000000000 8bcc131 000012 01  MS  0   0  1
+  [43] .symtab           SYMTAB          0000000000000000 8bcc148 612990 18     44 233806  8
+  [44] .strtab           STRTAB          0000000000000000 91dead8 34d07e 00      0   0  1
+  [45] .shstrtab         STRTAB          0000000000000000 952bb56 00020c 00      0   0  1
 Key to Flags:
   W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
   L (link order), O (extra OS processing required), G (group), T (TLS),
@@ -77,21 +76,19 @@ Key to Flags:
 
 Elf file type is DYN (Shared object file)
 Entry point 0xffff800080000000
-There are 5 program headers, starting at offset 64
+There are 4 program headers, starting at offset 64
 
 Program Headers:
   Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
   LOAD           0x010000 0xffff800080000000 0xffff800080000000 0x11cc000 0x11cc000 R E 0x10000
   LOAD           0x11e0000 0xffff8000811d0000 0xffff8000811d0000 0x153ba00 0x15e8970 RWE 0x10000
-  LOAD           0x2720000 0xffff8000827d0000 0xffff8000827d0000 0x0b09c8 0x0b09c8 R   0x10000
   NOTE           0x1e83cf4 0xffff800081e73cf4 0xffff800081e73cf4 0x000054 0x000054 R   0x4
-  GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW  0x10
+  GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW  0x8
 
  Section to Segment mapping:
   Segment Sections...
    00     .head.text .text 
    01     .rodata .pci_fixup __ksymtab __ksymtab_gpl __ksymtab_strings __param __modver __ex_table .notes .hyp.rodata .got .got.plt .rodata.text .init.text .exit.text .altinstructions .init.data runtime_shift_d_hash_shift runtime_ptr_dentry_hashtable .data..percpu .hyp.data..percpu .hyp.reloc .rela.dyn .relr.dyn .data __bug_table .hyp.data .mmuoff.data.write .mmuoff.data.read .pecoff_edata_padding .bss 
-   02     .modinfo 
-   03     .notes 
-   04     
+   02     .notes 
+   03     
    None   .debug_aranges .debug_info .debug_abbrev .debug_line .debug_frame .debug_str .debug_line_str .debug_rnglists .comment .symtab .strtab .shstrtab 

> As it is likely that it is the same underlying issue that such segment
> exists in the first place.
> 
> I wonder if the original implementation of moving sections about and
> when/where the builtin module info is kept is not as tidy as it was
> intended to be.

This is entirely possible. It would be helpful to know why exactly this
is happening to be certain.

> I wonder if we should:
> - rollback to the state of how things were before that feature was added
> - keep the production / stripped / installed kernel build as is
> - reshuffle of how modinfo is preserved in the unstripped kernel with
> a bespoke linker script
> 
> Such that hopefully we have correct alignment, without any zero length segments.
> 
> Or possibly even link / split the built-in module info somewhere else entirely.
> 
> As in revert both:
> - d50f21091358b (kbuild: align modinfo section for Secureboot
> Authenticode EDK2 compat, 2025-10-26)
> - 3e86e4d74c049 (kbuild: keep .modinfo section in vmlinux.unstripped,
> 2025-09-18)
> 
> And try implementing the keeping of .modinfo section again.
> 
> Better structure tests, after linking would be nice to catch such
> issues, because linker scripts are hard and trying to understand how a
> linker script change affects the result.

I think if we cannot figure out these issues by -rc6 timeframe, it may
be worth reverting the entire builtin .modinfo series and trying again
for 6.20 (it will probably be too late for 6.19 at that point) but I
would like to avoid doing that to Alexey if possible. I am not sure the
zero length segment issue is worth an entire back out at this point
alone, as I have proposed a fix for the original issue brought up by
this thread.

Cheers,
Nathan

Re: [mainline]Error while running make modules_install command

[Alexey Gladkov]

On Tue, Nov 04, 2025 at 06:15:48PM -0700, Nathan Chancellor wrote:
> On Tue, Nov 04, 2025 at 08:35:57PM +0000, Dimitri John Ledkov wrote:
> > On Tue, 4 Nov 2025 at 18:12, Omar Sandoval <osandov@osandov.com> wrote:
> > > drgn's CI hit this same failure. FWIW, the commit fixed by this bisected
> > > commit, 3e86e4d74c04 ("kbuild: keep .modinfo section in
> > > vmlinux.unstripped"), also results in ELF segments of size 0 in vmlinux
> > > for some configurations, which confused drgn until I added a workaround
> > > (https://github.com/osandov/drgn/commit/2a9053de8796af866fd720a3c8c23013595d391a).
> > > So there's some funkiness in this area.
> 
> Omar, could you provide me with a configuration file that reproduces
> this for you? Is there an easy way to check for this situation on the
> command line?
> 
> > The expectation is that said section is removed from the final binary.
> > But the fact that it is present with 0 length, indicates incorrect
> > linking. It also now makes sense why on x86/arm it is tripping up
> > section alignment.
> 
> If I diff the output of 'llvm-readelf -e' for vmlinux.unstripped and
> vmlinux when building 'ARCH=arm64 defconfig' using my suggested diff on
> top of 6.18-rc4, I do see .modinfo get removed and I am not sure I see
> an empty segment as a result?
> 
> diff --git a/tmp/.psub.Rg1zsq b/tmp/.psub.nGpcxI
> index 2f079cb57f58..dcca71062760 100644
> --- a/tmp/.psub.Rg1zsq
> +++ b/tmp/.psub.nGpcxI
> @@ -10,15 +10,15 @@ ELF Header:
>    Version:                           0x1
>    Entry point address:               0xffff800080000000
>    Start of program headers:          64 (bytes into file)
> -  Start of section headers:          157810560 (bytes into file)
> +  Start of section headers:          156417384 (bytes into file)
>    Flags:                             0x0
>    Size of this header:               64 (bytes)
>    Size of program headers:           56 (bytes)
> -  Number of program headers:         5
> +  Number of program headers:         4
>    Size of section headers:           64 (bytes)
> -  Number of section headers:         47
> -  Section header string table index: 46
> -There are 47 section headers, starting at offset 0x967ff80:
> +  Number of section headers:         46
> +  Section header string table index: 45
> +There are 46 section headers, starting at offset 0x952bd68:
>  
>  Section Headers:
>    [Nr] Name              Type            Address          Off    Size   ES Flg Lk Inf Al
> @@ -56,19 +56,18 @@ Section Headers:
>    [31] .mmuoff.data.read PROGBITS        ffff80008270b800 271b800 000008 00  WA  0   0  8
>    [32] .pecoff_edata_padding PROGBITS    ffff80008270b808 271b808 0001f8 00   A  0   0  1
>    [33] .bss              NOBITS          ffff80008270c000 271ba00 0ac970 00  WA  0   0 4096
> -  [34] .debug_aranges    PROGBITS        0000000000000000 27d09d0 047550 00      0   0 16
> -  [35] .debug_info       PROGBITS        0000000000000000 2817f20 38fdcf1 00      0   0  1
> -  [36] .debug_abbrev     PROGBITS        0000000000000000 6115c11 4845e1 00      0   0  1
> -  [37] .debug_line       PROGBITS        0000000000000000 659a1f2 1848e28 00      0   0  1
> -  [38] .debug_frame      PROGBITS        0000000000000000 7de3020 3e2858 00      0   0  8
> -  [39] .debug_str        PROGBITS        0000000000000000 81c5878 58f8cc 01  MS  0   0  1
> -  [40] .debug_line_str   PROGBITS        0000000000000000 8755144 057ff7 01  MS  0   0  1
> -  [41] .debug_rnglists   PROGBITS        0000000000000000 87ad13b 4d3fc6 00      0   0  1
> -  [42] .modinfo          PROGBITS        ffff8000827d0000 2720000 0b09c8 00   A  0   0  1
> -  [43] .comment          PROGBITS        0000000000000000 8c81101 000012 01  MS  0   0  1
> -  [44] .symtab           SYMTAB          0000000000000000 8c81118 671a60 18     45 250028  8
> -  [45] .strtab           STRTAB          0000000000000000 92f2b78 38d1f3 00      0   0  1
> -  [46] .shstrtab         STRTAB          0000000000000000 967fd6b 000215 00      0   0  1
> +  [34] .debug_aranges    PROGBITS        0000000000000000 271ba00 047550 00      0   0 16
> +  [35] .debug_info       PROGBITS        0000000000000000 2762f50 38fdcf1 00      0   0  1
> +  [36] .debug_abbrev     PROGBITS        0000000000000000 6060c41 4845e1 00      0   0  1
> +  [37] .debug_line       PROGBITS        0000000000000000 64e5222 1848e28 00      0   0  1
> +  [38] .debug_frame      PROGBITS        0000000000000000 7d2e050 3e2858 00      0   0  8
> +  [39] .debug_str        PROGBITS        0000000000000000 81108a8 58f8cc 01  MS  0   0  1
> +  [40] .debug_line_str   PROGBITS        0000000000000000 86a0174 057ff7 01  MS  0   0  1
> +  [41] .debug_rnglists   PROGBITS        0000000000000000 86f816b 4d3fc6 00      0   0  1
> +  [42] .comment          PROGBITS        0000000000000000 8bcc131 000012 01  MS  0   0  1
> +  [43] .symtab           SYMTAB          0000000000000000 8bcc148 612990 18     44 233806  8
> +  [44] .strtab           STRTAB          0000000000000000 91dead8 34d07e 00      0   0  1
> +  [45] .shstrtab         STRTAB          0000000000000000 952bb56 00020c 00      0   0  1
>  Key to Flags:
>    W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
>    L (link order), O (extra OS processing required), G (group), T (TLS),
> @@ -77,21 +76,19 @@ Key to Flags:
>  
>  Elf file type is DYN (Shared object file)
>  Entry point 0xffff800080000000
> -There are 5 program headers, starting at offset 64
> +There are 4 program headers, starting at offset 64
>  
>  Program Headers:
>    Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
>    LOAD           0x010000 0xffff800080000000 0xffff800080000000 0x11cc000 0x11cc000 R E 0x10000
>    LOAD           0x11e0000 0xffff8000811d0000 0xffff8000811d0000 0x153ba00 0x15e8970 RWE 0x10000
> -  LOAD           0x2720000 0xffff8000827d0000 0xffff8000827d0000 0x0b09c8 0x0b09c8 R   0x10000
>    NOTE           0x1e83cf4 0xffff800081e73cf4 0xffff800081e73cf4 0x000054 0x000054 R   0x4
> -  GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW  0x10
> +  GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW  0x8
>  
>   Section to Segment mapping:
>    Segment Sections...
>     00     .head.text .text 
>     01     .rodata .pci_fixup __ksymtab __ksymtab_gpl __ksymtab_strings __param __modver __ex_table .notes .hyp.rodata .got .got.plt .rodata.text .init.text .exit.text .altinstructions .init.data runtime_shift_d_hash_shift runtime_ptr_dentry_hashtable .data..percpu .hyp.data..percpu .hyp.reloc .rela.dyn .relr.dyn .data __bug_table .hyp.data .mmuoff.data.write .mmuoff.data.read .pecoff_edata_padding .bss 
> -   02     .modinfo 
> -   03     .notes 
> -   04     
> +   02     .notes 
> +   03     
>     None   .debug_aranges .debug_info .debug_abbrev .debug_line .debug_frame .debug_str .debug_line_str .debug_rnglists .comment .symtab .strtab .shstrtab 
> 
> > As it is likely that it is the same underlying issue that such segment
> > exists in the first place.
> > 
> > I wonder if the original implementation of moving sections about and
> > when/where the builtin module info is kept is not as tidy as it was
> > intended to be.
> 
> This is entirely possible. It would be helpful to know why exactly this
> is happening to be certain.
> 
> > I wonder if we should:
> > - rollback to the state of how things were before that feature was added
> > - keep the production / stripped / installed kernel build as is
> > - reshuffle of how modinfo is preserved in the unstripped kernel with
> > a bespoke linker script
> > 
> > Such that hopefully we have correct alignment, without any zero length segments.
> > 
> > Or possibly even link / split the built-in module info somewhere else entirely.
> > 
> > As in revert both:
> > - d50f21091358b (kbuild: align modinfo section for Secureboot
> > Authenticode EDK2 compat, 2025-10-26)
> > - 3e86e4d74c049 (kbuild: keep .modinfo section in vmlinux.unstripped,
> > 2025-09-18)
> > 
> > And try implementing the keeping of .modinfo section again.
> > 
> > Better structure tests, after linking would be nice to catch such
> > issues, because linker scripts are hard and trying to understand how a
> > linker script change affects the result.
> 
> I think if we cannot figure out these issues by -rc6 timeframe, it may
> be worth reverting the entire builtin .modinfo series and trying again
> for 6.20 (it will probably be too late for 6.19 at that point) but I
> would like to avoid doing that to Alexey if possible. I am not sure the
> zero length segment issue is worth an entire back out at this point
> alone, as I have proposed a fix for the original issue brought up by
> this thread.

Nathan, if you see that my changes are creating more problems than they
are solving, feel free to revert them.

My changes were based on Masahiro Yamada's patches. I didn't expect his
changes to cause many problems. Before his changes, I tried to use a
different approach. If you think it's worth it, we can return to
discussing it.

https://lore.kernel.org/all/cover.1748335606.git.legion@kernel.org/

-- 
Rgrds, legion

Re: [mainline]Error while running make modules_install command

[Nathan Chancellor]

On Wed, Nov 05, 2025 at 01:51:22PM +0100, Alexey Gladkov wrote:
> Nathan, if you see that my changes are creating more problems than they
> are solving, feel free to revert them.

Thanks for that permission! I will keep it in mind as we get closer to
the end of the release cycle if these problems are too much to overcome.

> My changes were based on Masahiro Yamada's patches. I didn't expect his
> changes to cause many problems. Before his changes, I tried to use a
> different approach. If you think it's worth it, we can return to
> discussing it.
> 
> https://lore.kernel.org/all/cover.1748335606.git.legion@kernel.org/

Right, I had noticed that in the development history and wondered if we
would want to revisit it. I will have to take a closer look at that
depending on how things go here.

Cheers,
Nathan

Re: [mainline]Error while running make modules_install command

[Omar Sandoval]

On Tue, Nov 04, 2025 at 06:15:48PM -0700, Nathan Chancellor wrote:
> On Tue, Nov 04, 2025 at 08:35:57PM +0000, Dimitri John Ledkov wrote:
> > On Tue, 4 Nov 2025 at 18:12, Omar Sandoval <osandov@osandov.com> wrote:
> > > drgn's CI hit this same failure. FWIW, the commit fixed by this bisected
> > > commit, 3e86e4d74c04 ("kbuild: keep .modinfo section in
> > > vmlinux.unstripped"), also results in ELF segments of size 0 in vmlinux
> > > for some configurations, which confused drgn until I added a workaround
> > > (https://github.com/osandov/drgn/commit/2a9053de8796af866fd720a3c8c23013595d391a).
> > > So there's some funkiness in this area.
> 
> Omar, could you provide me with a configuration file that reproduces
> this for you? Is there an easy way to check for this situation on the
> command line?

Here's a script that reproduces it:

```
#!/bin/sh

set -e

host_arch=x86_64
compiler_version="12.4.0"

compiler_dir="/tmp/arm64-gcc-$compiler_version"
if [ ! -e "$compiler_dir" ]; then
	rm -rf "$compiler_dir.tmp"
	mkdir "$compiler_dir.tmp"
	curl -L "https://mirrors.kernel.org/pub/tools/crosstool/files/bin/$host_arch/$compiler_version/$host_arch-gcc-$compiler_version-nolibc-aarch64-linux.tar.xz" | tar -C "$compiler_dir.tmp" -Jx
	mv "$compiler_dir.tmp" "$compiler_dir"
fi

export PATH="$compiler_dir/gcc-$compiler_version-nolibc/aarch64-linux/bin:$PATH"
make ARCH=arm64 CROSS_COMPILE=aarch64-linux- tinyconfig
make ARCH=arm64 CROSS_COMPILE=aarch64-linux- -j$(nproc) vmlinux
readelf -W -l vmlinux | awk '$1 == "LOAD" && $6 ~ /0x0+\>/'
```

It prints something like:

  LOAD           0x1ef008 0x0000000000000000 0xffff800080220000 0x000000 0x000000 R   0x10000

I.e., a segment with FileSiz and MemSiz 0.

Using a newer crosstool version fixes it, so maybe this was a GCC or
binutils bug.

Thanks,
Omar

Re: [mainline]Error while running make modules_install command

[Nathan Chancellor]

On Wed, Nov 05, 2025 at 01:53:13PM -0800, Omar Sandoval wrote:
> Here's a script that reproduces it:
> 
> ```
> #!/bin/sh
> 
> set -e
> 
> host_arch=x86_64
> compiler_version="12.4.0"
> 
> compiler_dir="/tmp/arm64-gcc-$compiler_version"
> if [ ! -e "$compiler_dir" ]; then
> 	rm -rf "$compiler_dir.tmp"
> 	mkdir "$compiler_dir.tmp"
> 	curl -L "https://mirrors.kernel.org/pub/tools/crosstool/files/bin/$host_arch/$compiler_version/$host_arch-gcc-$compiler_version-nolibc-aarch64-linux.tar.xz" | tar -C "$compiler_dir.tmp" -Jx
> 	mv "$compiler_dir.tmp" "$compiler_dir"
> fi
> 
> export PATH="$compiler_dir/gcc-$compiler_version-nolibc/aarch64-linux/bin:$PATH"
> make ARCH=arm64 CROSS_COMPILE=aarch64-linux- tinyconfig
> make ARCH=arm64 CROSS_COMPILE=aarch64-linux- -j$(nproc) vmlinux
> readelf -W -l vmlinux | awk '$1 == "LOAD" && $6 ~ /0x0+\>/'
> ```
> 
> It prints something like:
> 
>   LOAD           0x1ef008 0x0000000000000000 0xffff800080220000 0x000000 0x000000 R   0x10000
> 
> I.e., a segment with FileSiz and MemSiz 0.

Thank you, that was incredibly helpful.

> Using a newer crosstool version fixes it, so maybe this was a GCC or
> binutils bug.

Good observation, as this was reproducible with GCC 12.4.0 from
kernel.org but not GCC 12.5.0, which I noticed has a newer binutils
version. I was able to reproduce it with a self compiled copy of
binutils 2.42 but not with binutils 2.44 so I reverse bisected the fix
to [1], which certainly makes sense :)

The diff of 'readelf -lW' before that change:

diff --git a/tmp/.psub.9QY0ZO b/tmp/.psub.6lHG9T
index 7f7f4de7be8..ea3a9b4ffb0 100644
--- a/tmp/.psub.9QY0ZO
+++ b/tmp/.psub.6lHG9T
@@ -7,14 +7,14 @@ Program Headers:
   Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
   LOAD           0x010000 0xffff800080000000 0xffff800080000000 0x14f000 0x14f000 R E 0x10000
   LOAD           0x160000 0xffff800080150000 0xffff800080150000 0x08f008 0x0c4c40 RWE 0x10000
-  LOAD           0x1f0000 0xffff800080220000 0xffff800080220000 0x000d08 0x000d08 R   0x10000
+  LOAD           0x1ef008 0x0000000000000000 0xffff800080220000 0x000000 0x000000 R   0x10000
   NOTE           0x1860f8 0xffff8000801760f8 0xffff8000801760f8 0x000054 0x000054 R   0x4
-  GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW  0x10
+  GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW  0x8
 
  Section to Segment mapping:
   Segment Sections...
    00     .head.text .text 
    01     .rodata __param __ex_table .notes .rodata.text .init.text .exit.text .altinstructions .init.data runtime_shift_d_hash_shift runtime_ptr_dentry_hashtable .data..percpu .data .mmuoff.data.write .mmuoff.data.read .bss 
-   02     .modinfo 
+   02     
    03     .notes 
    04     

After:

diff --git a/tmp/.psub.x5uqM8 b/tmp/.psub.LHoP7d
index 7f7f4de7be8..27bda6ea7cc 100644
--- a/tmp/.psub.x5uqM8
+++ b/tmp/.psub.LHoP7d
@@ -1,20 +1,18 @@
 
 Elf file type is EXEC (Executable file)
 Entry point 0xffff800080000000
-There are 5 program headers, starting at offset 64
+There are 4 program headers, starting at offset 64
 
 Program Headers:
   Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
   LOAD           0x010000 0xffff800080000000 0xffff800080000000 0x14f000 0x14f000 R E 0x10000
   LOAD           0x160000 0xffff800080150000 0xffff800080150000 0x08f008 0x0c4c40 RWE 0x10000
-  LOAD           0x1f0000 0xffff800080220000 0xffff800080220000 0x000d08 0x000d08 R   0x10000
   NOTE           0x1860f8 0xffff8000801760f8 0xffff8000801760f8 0x000054 0x000054 R   0x4
-  GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW  0x10
+  GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW  0x8
 
  Section to Segment mapping:
   Segment Sections...
    00     .head.text .text 
    01     .rodata __param __ex_table .notes .rodata.text .init.text .exit.text .altinstructions .init.data runtime_shift_d_hash_shift runtime_ptr_dentry_hashtable .data..percpu .data .mmuoff.data.write .mmuoff.data.read .bss 
-   02     .modinfo 
-   03     .notes 
-   04     
+   02     .notes 
+   03     

I am not really sure how to workaround this in a concise way... at least
for arm64 since it does not seem to use PHDRS to describe ELF segments,
it just relies on the default linker heuristics? It also seems seems
like this is a generic problem not specific to .modinfo, we just so
happen to see it with this section since it is in its own segment and we
are removing it.

[1]: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=7f26d260ef76a4cb2873a7815bef187005528c19

Cheers,
Nathan