[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231001174625.GR92317@kernel.org>
Date: Sun, 1 Oct 2023 19:46:25 +0200
From: Simon Horman <horms@...nel.org>
To: Chengfeng Ye <dg573847474@...il.com>
Cc: jmaloy@...hat.com, ying.xue@...driver.com, davem@...emloft.net,
edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com,
netdev@...r.kernel.org, tipc-discussion@...ts.sourceforge.net,
linux-kernel@...r.kernel.org
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@...il.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.
Powered by blists - more mailing lists