Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 26 Jul 2023 21:46:13 -0700
From:   Jakub Kicinski <kuba@kernel.org>
To:     Chengfeng Ye <dg573847474@gmail.com>
Cc:     isdn@linux-pingi.de, alexanderduyck@fb.com, duoming@zju.edu.cn,
        yangyingliang@huawei.com, davem@davemloft.net,
        netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mISDN: hfcpci: Fix potential deadlock on &hc->lock
Message-ID: <20230726214613.7fee0d7b@kernel.org>
In-Reply-To: <20230725173728.13816-1-dg573847474@gmail.com>
References: <20230725173728.13816-1-dg573847474@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

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@gmail.com>

LGTM, but please repost with a Fixes tag added.
-- 
pw-bot: cr