[PATCH 0/4] Help to debug spinlocks
John Wood
john.wood at gmx.com
Mon Dec 21 13:02:02 EST 2020
On Sun, Dec 20, 2020 at 03:06:52PM -0500, Valdis Klētnieks wrote:
> On Sun, 20 Dec 2020 12:47:08 +0100, John Wood said:
>
> > disable interrupts. Then, the task_free hook was call from an IRQ context
> > and tried to acquire the same lock in a write state.
>
> OK, I'll bite.
>
> Why was task_free called from an IRQ context in the first place? That sounds
> awfully fishy.....
If I understand correctly is what the call trace says:
[ 200.483698] Call Trace:
[ 200.484481] <IRQ>
[ 200.485141] do_raw_write_lock+0xae/0xb0
[ 200.486265] _raw_write_lock+0x6c/0x70
[ 200.487366] brute_task_free+0x86/0xf0
[ 200.488477] security_task_free+0x27/0x50
[ 200.489657] __put_task_struct+0x6d/0x150
[ 200.490824] delayed_put_task_struct+0x9b/0x110
[ 200.492142] rcu_core+0x412/0x6d0
[ 200.493113] ? rcu_core+0x3de/0x6d0
[ 200.493864] rcu_core_si+0xe/0x10
[ 200.494568] __do_softirq+0xcf/0x428
[ 200.495325] asm_call_irq_on_stack+0x12/0x20
[ 200.496407] </IRQ>
[ 200.496969] do_softirq_own_stack+0x61/0x70
[ 200.498030] irq_exit_rcu+0xc1/0xd0
[ 200.498913] sysvec_apic_timer_interrupt+0x52/0xb0
[ 200.500179] asm_sysvec_apic_timer_interrupt+0x12/0x20
Thanks,
John Wood
More information about the Kernelnewbies
mailing list