Re: Track down hard lockup with smatch

Keeping it logged...

> On 18 Jun 2025, at 14:33, Miguel Luis <[email protected]> wrote:
>=20
> Hi!
>=20
> I'm trying to track down a hard lockup with smatch which produces the fol=
lowing
> stacktrace:
>=20
> [   43.028758] Kernel panic - not syncing: Hard LOCKUP
> [   43.029701] CPU: 92 UID: 0 PID: 0 Comm: swapper/92 Not tainted 6.15.0-=
rc4+ #11 VOLUNTARY
> [   43.031264] Hardware name: linux,dummy-virt (DT)
> [   43.032156] Call trace:
> [   43.032641]  show_stack+0x20/0x48 (C)
> [   43.033358]  dump_stack_lvl+0x38/0xf8
> [   43.034082]  dump_stack+0x18/0x30
> [   43.034740]  panic+0x3a8/0x408
> [   43.035349]  nmi_panic+0x48/0xc0
> [   43.035987]  watchdog_hardlockup_check+0x2dc/0x360
> [   43.036924]  watchdog_buddy_check_hardlockup+0x78/0xa8
> [   43.037924]  watchdog_timer_fn+0xa0/0x3b8
> [   43.038712]  __run_hrtimer+0x224/0x3b0
> [   43.039455]  __hrtimer_run_queues+0xb4/0x148
> [   43.040292]  hrtimer_interrupt+0x138/0x320
> [   43.040932]  arch_timer_handler_phys+0x4c/0x78
> [   43.041695]  handle_percpu_devid_irq+0xb0/0x2a0
> [   43.042584]  handle_irq_desc+0x54/0x90
> [   43.043328]  generic_handle_domain_irq+0x24/0x48
> [   43.044197]  gic_handle_irq+0x74/0x100
> [   43.044907]  call_on_irq_stack+0x24/0x30
> [   43.045653]  do_interrupt_handler+0xa8/0xb8
> [   43.046444]  el1_interrupt+0x34/0x60
> [   43.047126]  el1h_64_irq_handler+0x18/0x38
> [   43.047821]  el1h_64_irq+0x70/0x78
> [   43.048410]  default_idle_call+0xac/0x270 (P)
> [   43.049126]  cpuidle_idle_call+0x184/0x1e0
> [   43.049729]  do_idle+0xb8/0x108
> [   43.050195]  cpu_startup_entry+0x40/0x50
> [   43.050870]  secondary_start_kernel+0xe0/0x108
> [   43.051713]  __secondary_switched+0xc0/0xc8
> [   43.052480] SMP: stopping secondary CPUs
> [   43.053253] Kernel Offset: disabled
> [   43.053775] CPU features: 0x0000,080001c0,02138ca1,554ffea7
> [   43.054628] Memory Limit: none
> [   43.055234] ---[ end Kernel panic - not syncing: Hard LOCKUP ]---
>=20
> I was able to successfully ( I believe ) build all the requirements with:
>=20
> Setting CONFIG_DYNAMIC_DEBUG=3Dn per [1]
>=20
> And only build the kernel Image to reduce the build time with:
>=20
> make clean && make CHECK=3D"../smatch/smatch -p=3Dkernel --info --file-ou=
tput" C=3D1 -j $(nproc) Image || make -j $(nproc) Image
> export WLOG=3D"warns.txt"
> find -name *.c.smatch -exec cat {} \; -exec rm {} \; > $WLOG
> find -name *.c.smatch.sql -exec cat {} \; -exec rm {} \; > $WLOG.sql
> find -name *.c.smatch.caller_info -exec cat {} \; -exec rm {} \; > $WLOG.=
caller_info
>=20


s/>/>>

To append to file instead.

> Along with the DB:
>=20
> ../smatch/smatch_data/db/create_db.sh  -p=3Dkernel $WLOG.sql
>=20
> from [2].
>=20
> I'm wondering wether there's already a resource available that could guid=
e me
> through smdb.py based on a stack trace so I could get to the bottom of it=
 or
> otherwise let me know if these steps are missing something. As far as I k=
now
> smdb.py is used to query smatch's .sqlite but what exactly should I be lo=
oking
> for there or what's a good approach for tracking this down are all good a=
dvices
> and welcome.
>=20
>=20
> Thank you in advance for considering this message's concerns.
>=20
> Regards,
> Miguel
>=20
> [1]: https://smatch.sourceforge.net/
> [2]: https://github.com/error27/smatch/issues/17#issuecomment-2976435847