[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