[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230726214613.7fee0d7b@kernel.org>
Date: Wed, 26 Jul 2023 21:46:13 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Chengfeng Ye <dg573847474@...il.com>
Cc: isdn@...ux-pingi.de, alexanderduyck@...com, duoming@....edu.cn,
yangyingliang@...wei.com, davem@...emloft.net,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mISDN: hfcpci: Fix potential deadlock on &hc->lock
On Tue, 25 Jul 2023 17:37:28 +0000 Chengfeng Ye wrote:
> As &hc->lock is acquired by both timer _hfcpci_softirq() and hardirq
> hfcpci_int(), the timer should disable irq before lock acquisition
> otherwise deadlock could happen if the timmer is preemtped by the hadr irq.
>
> Possible deadlock scenario:
> hfcpci_softirq() (timer)
> -> _hfcpci_softirq()
> -> spin_lock(&hc->lock);
> <irq interruption>
> -> hfcpci_int()
> -> spin_lock(&hc->lock); (deadlock here)
>
> This flaw was found by an experimental static analysis tool I am developing
> for irq-related deadlock.
>
> The tentative patch fixes the potential deadlock by spin_lock_irq()
> in timer.
>
> But the patch could be not enough since between the lock critical section
> inside the timer, tx_birq() is called in which a lot of stuff is executed
> such as dev_kfree_skb(). I am not sure what's the best way to solve this
> potential deadlock problem.
Yeah, the dev_kfree_skb() should be dev_kfree_skb_any() or _irq()
> Signed-off-by: Chengfeng Ye <dg573847474@...il.com>
LGTM, but please repost with a Fixes tag added.
--
pw-bot: cr
Powered by blists - more mailing lists