Backport request for fda024fb64769e9d6b3916d013c78d6b189129f8 to stable/6.18.y

Backport request for fda024fb64769e9d6b3916d013c78d6b189129f8 to stable/6.18.y

[Brett Mastbergen]

Please consider applying the following mainline commit to the 6.18.y
stable tree:

 commit fda024fb64769e9d6b3916d013c78d6b189129f8
 kallsyms: clean up modname and modbuildid initialization in
kallsyms_lookup_buildid()

The patch applies cleanly to 6.18.21

kallsyms_lookup_buildid() only initializes *modname and *modbuildid
inside the is_ksym_addr() branch, leaving them uninitialized for the
BPF/module/ftrace path.  When a backtrace entry resolves through the
BPF path, __sprint_symbol() passes the uninitialized modname pointer
to sprintf(" [%s", modname).  This consistently causes a kernel panic
on aarch64 when running the sched_ext:select_cpu_dispatch_dbl_dsp
kselftest.  Presumably any sched_ext workload that triggers a scheduler
error could hit this.

Reproducible by running:

    make -C tools/testing/selftests/sched_ext run_tests

on aarch64 (tested on QEMU running 6.18.19).

CCing the original commit author in case they have any
thoughts

Thanks,
Brett

[panic log follows]

[  7225.950942] sched_ext: select_cpu_dispatch_dbl_dsp:
kdamond.0[7189] already direct-dispatched
[  7225.951029]    scx_dsq_insert_commit+0x128/0x138
[  7225.951086]    scx_bpf_dsq_insert+0x74/0xc8
[  7225.951466] Unable to handle kernel paging request at virtual
address 007265736e695f71
[  7225.951493] Mem abort info:
[  7225.951506]   ESR = 0x0000000096000004
[  7225.951533]   EC = 0x25: DABT (current EL), IL = 32 bits
[  7225.951550]   SET = 0, FnV = 0
[  7225.951562]   EA = 0, S1PTW = 0
[  7225.951579]   FSC = 0x04: level 0 translation fault
[  7225.951613]   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
[  7225.951645]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[  7225.951662]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[  7225.951700] [007265736e695f71] address between user and kernel
address ranges
[  7225.951871] Internal error: Oops: 0000000096000004 [#1] SMP
[  7225.953839] Modules linked in: nft_tproxy nf_tproxy_ipv6
nf_tproxy_ipv4 nf_defrag_ipv6
nf_defrag_ipv4 nft_socket nf_socket_ipv4 nf_socket_ipv6 nf_tables
nfnetlink sch_netem
hsr can_raw can vcan can_dev xfs uhid gpio_sim dev_sync_probe loop
dummy cls_matchall
8021q garp mrp ipvlan macvlan esp4_offload esp4 nlmon act_gact
cls_flower sch_ingress
bridge stp llc bonding tls veth netconsole snd_timer snd soundcore virtio_net
net_failover failover fuse ext4 crc16 mbcache jbd2 ghash_ce virtio_blk
[last unloaded: ptp_mock]
[  7225.955788] CPU: 0 UID: 0 PID: 167908 Comm: sched_ext_helpe Not
tainted 6.18.19-_brett__ciq-6.18.y-cbbf63788+ #1
PREEMPT(voluntary)
[  7225.956092] Hardware name: QEMU QEMU Virtual Machine, BIOS
edk2-20250221-8.fc42 02/21/2025
[  7225.956481] Sched_ext: select_cpu_dispatch_dbl_dsp (disabling)
[  7225.956563] pstate: 004000c5 (nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[  7225.956908] pc : string+0x5c/0x118
[  7225.957055] lr : vsnprintf+0x1b0/0x5a8
[  7225.957198] sp : ffff80008dd0b460
[  7225.957299] x29: ffff80008dd0b460 x28: ffff80008177db6c x27:
0000000000000405
[  7225.957610] x26: ffff80008dd0b66a x25: ffff80008177db6c x24:
00000000ffffffd8
[  7225.957866] x23: ffff80008147a560 x22: ffff80008dd0b590 x21:
0000000000000004
[  7225.958143] x20: ffff80010dd0b667 x19: 0000000000000005 x18:
00000000ffffffff
[  7225.958336] x17: 2079646165726c61 x16: 205d393831375b30 x15:
ffff80010dd0b65d
[  7225.958580] x14: 0000000000000001 x13: ffff80008dd0b666 x12:
0101010101010101
[  7225.958783] x11: 7f7f7f7f7f7f7f7f x10: 000000000000005b x9 :
0000000000000002
[  7225.958947] x8 : 00000000ffffffff x7 : ffffffffffffffff x6 :
ffff80010dd0b667
[  7225.959148] x5 : 00000000ffffffff x4 : 0000000000000000 x3 :
ffffffffffff0a00
[  7225.959344] x2 : 747265736e695f71 x1 : 0000000000000000 x0 :
ffff80008dd0b66a
[  7225.959612] Call trace:
[  7225.959772]  string+0x5c/0x118 (P)
[  7225.959933]  vsnprintf+0x1b0/0x5a8
[  7225.960058]  sprintf+0x64/0x90
[  7225.960238]  __sprint_symbol.constprop.0+0x90/0x120
[  7225.960378]  sprint_symbol+0x20/0x38
[  7225.960998]  symbol_string+0x60/0x150
[  7225.961186]  pointer+0x84/0x4f8
[  7225.961319]  vsnprintf+0x2cc/0x5a8
[  7225.961443]  vprintk_store+0x180/0x4f0
[  7225.961575]  vprintk_emit+0xd8/0x3a8
[  7225.961697]  vprintk_default+0x40/0x58
[  7225.961869]  vprintk+0x3c/0x80
[  7225.961990]  _printk+0x68/0xa0
[  7225.962114]  stack_trace_print+0x54/0x88
[  7225.962280]  scx_disable_workfn+0x458/0x5d0
[  7225.962414]  kthread_worker_fn+0x100/0x2d0
[  7225.962534]  kthread+0x128/0x138
[  7225.962693]  ret_from_fork+0x10/0x20
[  7225.962905] Code: 91000400 110004e1 eb08009f 540000c0 (38646845)
[  7225.963431] ---[ end trace 0000000000000000 ]---
[  7225.963815] Kernel panic - not syncing: Oops: Fatal exception
[  7225.964126] SMP: stopping secondary CPUs
[  7225.964578] Kernel Offset: 0x140000 from 0xffff800080000000
[  7225.964724] PHYS_OFFSET: 0x40000000
[  7225.964822] CPU features: 0x100000,0000e000,40046280,0401720b
[  7225.964967] Memory Limit: none
[  7225.965217] Rebooting in 180 seconds..

Re: Backport request for fda024fb64769e9d6b3916d013c78d6b189129f8 to stable/6.18.y

[Greg KH]

On Fri, Apr 03, 2026 at 04:30:35PM -0400, Brett Mastbergen wrote:
> Please consider applying the following mainline commit to the 6.18.y
> stable tree:
> 
>  commit fda024fb64769e9d6b3916d013c78d6b189129f8
>  kallsyms: clean up modname and modbuildid initialization in
> kallsyms_lookup_buildid()
> 
> The patch applies cleanly to 6.18.21

What about 6.19.y?  You also need/want it there too, right?

thanks,

greg k-h

Re: Backport request for fda024fb64769e9d6b3916d013c78d6b189129f8 to stable/6.18.y

[Brett Mastbergen]

On Sat, Apr 4, 2026 at 2:24 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Fri, Apr 03, 2026 at 04:30:35PM -0400, Brett Mastbergen wrote:
> > Please consider applying the following mainline commit to the 6.18.y
> > stable tree:
> >
> >  commit fda024fb64769e9d6b3916d013c78d6b189129f8
> >  kallsyms: clean up modname and modbuildid initialization in
> > kallsyms_lookup_buildid()
> >
> > The patch applies cleanly to 6.18.21
>
> What about 6.19.y?  You also need/want it there too, right?

Yes please!  I was able to trigger the same panic with aarch64 running
6.19.11-rc1.
fda024fb6476 applies cleanly and gets rid of the panic there too.

Thanks!
Brett