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 _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
