On Tue, Nov 04, 2025 at 08:35:57PM +0000, Dimitri John Ledkov wrote:

quoted

On Tue, 4 Nov 2025 at 18:12, Omar Sandoval [off-list ref] wrote:

quoted

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?

quoted

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 

quoted

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.

quoted

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.