Messages in this thread | | | From | Eric Dumazet <> | Date | Tue, 27 Jun 2023 15:55:11 +0200 | Subject | Re: [PATCH] net/802/garp: fix potential deadlock on &app->lock |
| |
On Tue, Jun 27, 2023 at 12:52 PM Chengfeng Ye <dg573847474@gmail.com> wrote: > > As &app->lock is also acquired by the timer garp_join_timer() which > which executes under soft-irq context, code executing under process > context should disable irq before acquiring the lock, otherwise > deadlock could happen if the process context hold the lock then > preempt by the interruption. > > garp_pdu_rcv() is one such function that acquires &app->lock, but I > am not sure whether it is called with irq disable outside thus the > patch could be false. > > Possible deadlock scenario: > garp_pdu_rcv() > -> spin_lock(&app->lock) > <timer interrupt>
This can not happen.
RX handlers are called from BH context, and rcu_read_lock()
See net/core/dev.c, deliver_skb() and netif_receive_skb()
> -> garp_join_timer() > -> spin_lock(&app->lock) > > This flaw was found using an experimental static analysis tool we are > developing for irq-related deadlock. > > The tentative patch fix the potential deadlock by spin_lock_irqsave(), > or it should be fixed with spin_lock_bh() if it is a real bug? I am > not very sure.
I guess more work is needed at your side :)
| |