> On 23 Jun 2025, at 11:35, Miguel Luis <[email protected]> wrote:
>
> Hi Dan,
>
>> On 23 Jun 2025, at 11:13, Dan Carpenter <[email protected]> wrote:
>>
>> On Mon, Jun 23, 2025 at 10:36:46AM +0000, Miguel Luis wrote:
>>> Keeping it logged...
>>>
>>>> On 18 Jun 2025, at 14:33, Miguel Luis <[email protected]> wrote:
>>>>
>>>> Hi!
>>>>
>>>> I'm trying to track down a hard lockup with smatch which produces the
>>>> following
>>>> stacktrace:
>>>>
>>>> [ 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 ]---
>>>>
>>>> I was able to successfully ( I believe ) build all the requirements with:
>>>>
>>>> Setting CONFIG_DYNAMIC_DEBUG=n per [1]
>>>>
>>>> And only build the kernel Image to reduce the build time with:
>>>>
>>>> make clean && make CHECK="../smatch/smatch -p=kernel --info --file-output"
>>>> C=1 -j $(nproc) Image || make -j $(nproc) Image
>>>> export WLOG="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
>>>>
>>>
>>>
>>> s/>/>>
>>>
>>> To append to file instead.
>>>
>>
>> Those files are only used once... Keeping the old data seems like it
>> might cause a problem.
Now I get it, whether one removes $WLOG* or keep them and use ‘>’ will get the
same result.
>
> I agree and based on that this is the script I’m using:
.. however, I still get the same number of $((`cat smatch_warns.txt | wc -l` -
`cat smatch_warns.txt | uniq | wc -l`)) duplicates.
>
> ```
> # env
> export WLOG="smatch_warns.txt"
>
> # clear everything
> rm -rf $WLOG* smatch_db.sqlite
>
> # build
> make clean && time make CHECK="../smatch/smatch -p=kernel --info
> --file-output" C=1 -j $(nproc) Image || time make -j $(nproc) Image
>
> # squash
> 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
>
> #create DB
> ../smatch/smatch_data/db/create_db.sh -p=kernel $WLOG.sql
> ```
>
>> One thing you can do is:
>>
>> kchecker --info drivers/file.c | tee out
>> ~/smatch/smatch_data/db/reload_partial.sh out
>>
>> It will reload just the one file.
>
> Thanks for the tip!
>
>> It doesn't update everything,
>> but it updates the caller_info and return_states which is what we
>> mostly care about.
>>
>
> And thanks for the hint. :)
> I’m creating SQL views which I believe should simplify ‘smdb.py' a bit. Or at
> least for me or to use cases where would like to work on top of the db.
>
>> regards,
>> dan carpenter
>
> Regards
> Miguel
