Re: objtool crash processing drivers/gpu/drm/vmwgfx/vmwgfx_msg.o

[Ingo Molnar <mingo@kernel.org>]

* Arnd Bergmann <arnd@arndb.de> wrote:

> I saw this on one randconfig build failing today with yesterday's
> next-20250326 (with a couple of patches on top), using gcc-14.2
> and the attached config I assume this is a rare configuration:
> 
> ./tools/objtool/objtool --hacks=jump_label --hacks=noinstr --sls --stackval --static-call --uaccess   --module drivers/gpu/drm/vmwgfx/vmwgfx_msg.o
> Segmentation fault
> 
> I have not tried to analyze it any further, but I would guess that
> this is a rare configuration, not a recent regression.

I can reproduce this now too, not with a randconfig but with a distro 
DEB package build:

starship:~/tip.localinstall> tools/objtool/objtool --hacks=jump_label --hacks=noinstr --hacks=skylake --retpoline --rethunk --stackval --static-call --uaccess --prefix=16   --module drivers/gpu/drm/vmwgfx/vmwgfx_msg.o
Segmentation fault (core dumped)

Program received signal SIGSEGV, Segmentation fault.
check (file=file@entry=0x555555589b40 <file>) at check.c:4655
4655				w += validate_reachable_instructions(file);
(gdb) bt
#0  check (file=file@entry=0x555555589b40 <file>) at check.c:4655
#1  0x0000555555569fb2 in objtool_run (argc=<optimized out>, argv=0x7fffffffe1d8) at builtin-check.c:326
#2  0x00007ffff7c2a3b8 in __libc_start_call_main (main=main@entry=0x555555559d30 <main>, argc=argc@entry=12, argv=argv@entry=0x7fffffffe1d8) at ../sysdeps/nptl/libc_start_call_main.h:58
#3  0x00007ffff7c2a47b in __libc_start_main_impl (main=0x555555559d30 <main>, argc=12, argv=0x7fffffffe1d8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffe1c8) at ../csu/libc-start.c:360

(gdb) i r
rax            0x0                 0
rbx            0x555555d8ed70      93825000861040
rcx            0x61                97
rdx            0xff9bb000          4288393216
rsi            0x55555557e0f0      93824992403696
rdi            0x555555d918ad      93825000872109
rbp            0x0                 0x0
rsp            0x7fffffffe020      0x7fffffffe020
r8             0xfffffe90          4294966928
r9             0xff9c155c          4288419164
r10            0x63e934            6547764
r11            0x555555589b40      93824992451392
r12            0x555555dfa640      93825001301568
r13            0x11                17
r14            0x555555d988e0      93825000900832
r15            0x555555d8ed70      93825000861040
rip            0x555555559d14      0x555555559d14 <check[cold]>
eflags         0x10246             [ PF ZF IF RF ]
cs             0x33                51
ss             0x2b                43
ds             0x0                 0
es             0x0                 0
fs             0x0                 0
gs             0x0                 0
k0             0x400000            4194304
k1             0x80480001          2152202241
k2             0xdfffbfff          3758079999
k3             0x0                 0
k4             0x0                 0
k5             0x0                 0
k6             0x0                 0
k7             0x0                 0
fs_base        0x7ffff7e99ec0      140737352670912
gs_base        0x0                 0

The 'file' pointer got corrupted it appears:

(gdb) print file
$1 = (struct objtool_file *) 0x555555589b40 <file>
(gdb) print *file
value of type `objtool_file' requires 8388768 bytes, which is more than max-value-size
(gdb) 

(gdb) print opts
$3 = {dump_orc = false, hack_jump_label = true, hack_noinstr = true, hack_skylake = true, ibt = false, mcount = false, noinstr = false, orc = false, retpoline = true, rethunk = true, unret = false, sls = false, stackval = true, static_call = true, 
  uaccess = true, prefix = 16, cfi = false, backtrace = false, dryrun = false, link = false, mnop = false, module = true, no_unreachable = false, output = 0x0, sec_address = false, stats = false, verbose = false, werror = false}

It's fairly reproducible here. Sending object file separately.

Based on latest -tip.

Thanks,

	Ingo