Messages in this thread | | | Date | Sun, 1 Oct 2023 19:46:25 +0200 | From | Simon Horman <> | Subject | Re: [PATCH] tipc: fix a potential deadlock on &tx->lock |
| |
On Wed, Sep 27, 2023 at 06:14:14PM +0000, Chengfeng Ye wrote: > It seems that tipc_crypto_key_revoke() could be be invoked by > wokequeue tipc_crypto_work_rx() under process context and > timer/rx callback under softirq context, thus the lock acquisition > on &tx->lock seems better use spin_lock_bh() to prevent possible > deadlock. > > This flaw was found by an experimental static analysis tool I am > developing for irq-related deadlock. > > tipc_crypto_work_rx() <workqueue> > --> tipc_crypto_key_distr() > --> tipc_bcast_xmit() > --> tipc_bcbase_xmit() > --> tipc_bearer_bc_xmit() > --> tipc_crypto_xmit() > --> tipc_ehdr_build() > --> tipc_crypto_key_revoke() > --> spin_lock(&tx->lock) > <timer interrupt> > --> tipc_disc_timeout() > --> tipc_bearer_xmit_skb() > --> tipc_crypto_xmit() > --> tipc_ehdr_build() > --> tipc_crypto_key_revoke() > --> spin_lock(&tx->lock) <deadlock here> > > Signed-off-by: Chengfeng Ye <dg573847474@gmail.com>
Hi Chengfeng Ye,
thanks for your patch.
As a fix for Networking this should probably be targeted at the 'net' tree. Which should be denoted in the subject.
Subject: [PATCH net] ...
And as a fix this patch should probably have a Fixes tag. This ones seem appropriate to me, but I could be wrong.
Fixes: fc1b6d6de220 ("tipc: introduce TIPC encryption & authentication")
I don't think it is necessary to repost just to address these issues, but the Networking maintainers may think otherwise.
The code change itself looks good to me.
| |