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 <[email protected]> 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/[email protected]/ -- Rgrds, legion
