All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Horman <horms@kernel.org>
To: Jijie Shao <shaojijie@huawei.com>
Cc: davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
	pabeni@redhat.com, andrew+netdev@lunn.ch, shenjian15@huawei.com,
	liuyonglong@huawei.com, chenhao418@huawei.com,
	jonathan.cameron@huawei.com,
	shameerali.kolothum.thodi@huawei.com, salil.mehta@huawei.com,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net 1/3] net: hibmcge: fix rtnl deadlock issue
Date: Fri, 1 Aug 2025 12:05:18 +0100	[thread overview]
Message-ID: <20250801110518.GN8494@horms.kernel.org> (raw)
In-Reply-To: <15388e7f-45a8-4356-88c9-45848c3a296f@huawei.com>

On Fri, Aug 01, 2025 at 06:44:36PM +0800, Jijie Shao wrote:
> 
> on 2025/8/1 18:05, Simon Horman wrote:
> > On Thu, Jul 31, 2025 at 09:47:47PM +0800, Jijie Shao wrote:
> > > Currently, the hibmcge netdev acquires the rtnl_lock in
> > > pci_error_handlers.reset_prepare() and releases it in
> > > pci_error_handlers.reset_done().
> > > 
> > > However, in the PCI framework:
> > > pci_reset_bus - __pci_reset_slot - pci_slot_save_and_disable_locked -
> > >   pci_dev_save_and_disable - err_handler->reset_prepare(dev);
> > > 
> > > In pci_slot_save_and_disable_locked():
> > > 	list_for_each_entry(dev, &slot->bus->devices, bus_list) {
> > > 		if (!dev->slot || dev->slot!= slot)
> > > 			continue;
> > > 		pci_dev_save_and_disable(dev);
> > > 		if (dev->subordinate)
> > > 			pci_bus_save_and_disable_locked(dev->subordinate);
> > > 	}
> > > 
> > > This will iterate through all devices under the current bus and execute
> > > err_handler->reset_prepare(), causing two devices of the hibmcge driver
> > > to sequentially request the rtnl_lock, leading to a deadlock.
> > > 
> > > Since the driver now executes netif_device_detach()
> > > before the reset process, it will not concurrently with
> > > other netdev APIs, so there is no need to hold the rtnl_lock now.
> > > 
> > > Therefore, this patch removes the rtnl_lock during the reset process and
> > > adjusts the position of HBG_NIC_STATE_RESETTING to ensure
> > > that multiple resets are not executed concurrently.
> > > 
> > > Fixes: 3f5a61f6d504f ("net: hibmcge: Add reset supported in this module")
> > > Signed-off-by: Jijie Shao <shaojijie@huawei.com>
> > > ---
> > >   drivers/net/ethernet/hisilicon/hibmcge/hbg_err.c | 13 ++++---------
> > >   1 file changed, 4 insertions(+), 9 deletions(-)
> > > 
> > > diff --git a/drivers/net/ethernet/hisilicon/hibmcge/hbg_err.c b/drivers/net/ethernet/hisilicon/hibmcge/hbg_err.c
> > > index 503cfbfb4a8a..94bc6f0da912 100644
> > > --- a/drivers/net/ethernet/hisilicon/hibmcge/hbg_err.c
> > > +++ b/drivers/net/ethernet/hisilicon/hibmcge/hbg_err.c
> > > @@ -53,9 +53,11 @@ static int hbg_reset_prepare(struct hbg_priv *priv, enum hbg_reset_type type)
> > >   {
> > >   	int ret;
> > > -	ASSERT_RTNL();
> > > +	if (test_and_set_bit(HBG_NIC_STATE_RESETTING, &priv->state))
> > > +		return -EBUSY;
> > >   	if (netif_running(priv->netdev)) {
> > > +		clear_bit(HBG_NIC_STATE_RESETTING, &priv->state);
> > >   		dev_warn(&priv->pdev->dev,
> > >   			 "failed to reset because port is up\n");
> > >   		return -EBUSY;
> > > @@ -64,7 +66,6 @@ static int hbg_reset_prepare(struct hbg_priv *priv, enum hbg_reset_type type)
> > >   	netif_device_detach(priv->netdev);
> > >   	priv->reset_type = type;
> > > -	set_bit(HBG_NIC_STATE_RESETTING, &priv->state);
> > >   	clear_bit(HBG_NIC_STATE_RESET_FAIL, &priv->state);
> > >   	ret = hbg_hw_event_notify(priv, HBG_HW_EVENT_RESET);
> > >   	if (ret) {
> > > @@ -84,10 +85,8 @@ static int hbg_reset_done(struct hbg_priv *priv, enum hbg_reset_type type)
> > >   	    type != priv->reset_type)
> > >   		return 0;
> > > -	ASSERT_RTNL();
> > > -
> > > -	clear_bit(HBG_NIC_STATE_RESETTING, &priv->state);
> > >   	ret = hbg_rebuild(priv);
> > > +	clear_bit(HBG_NIC_STATE_RESETTING, &priv->state);
> > Hi Jijie,
> > 
> > If I understand things correctly, then with this patch the
> > HBG_NIC_STATE_RESETTING bit is used to prevent concurrent execution.
> > 
> > Noting that a reset may be triggered via eththool, where hbg_reset() is
> > used as a callback, I am concerned about concurrency implications for lines
> > below this one.
> 
> Yes, just like the following, it can lead to reset and net open concurrency.
> ===========
> 
>      reset1                                              reset2                               open
> 
> set_bit HBG_NIC_STATE_RESETTING
> 
>      netif_device_detach()
>      resetting...
> 
> clear_bit HBG_NIC_STATE_RESETTING
>                                               set_bit HBG_NIC_STATE_RESETTING
>                                                    netif_device_detach()
> 
>       netif_device_attach()
>                                                          resetting...                     hbg_net_open()
>                                                                                           hbg_txrx_init()
> 
>                                               clear_bit HBG_NIC_STATE_RESETTING
>                                                       netif_device_attach()
> 
> ============
> Thank you for your reminder.
> I will fix it in V2

Likewise, thanks.

-- 
pw-bot: cr


  reply	other threads:[~2025-08-01 11:05 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-31 13:47 [PATCH net 0/3] There are some bugfix for hibmcge ethernet driver Jijie Shao
2025-07-31 13:47 ` [PATCH net 1/3] net: hibmcge: fix rtnl deadlock issue Jijie Shao
2025-08-01 10:05   ` Simon Horman
2025-08-01 10:44     ` Jijie Shao
2025-08-01 11:05       ` Simon Horman [this message]
2025-07-31 13:47 ` [PATCH net 2/3] net: hibmcge: fix the division by zero issue Jijie Shao
2025-08-01 10:11   ` Simon Horman
2025-08-01 10:46     ` Jijie Shao
2025-07-31 13:47 ` [PATCH net 3/3] net: hibmcge: fix the np_link_fai error reporting issue Jijie Shao
2025-08-01 10:20   ` Simon Horman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250801110518.GN8494@horms.kernel.org \
    --to=horms@kernel.org \
    --cc=andrew+netdev@lunn.ch \
    --cc=chenhao418@huawei.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=jonathan.cameron@huawei.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=liuyonglong@huawei.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=salil.mehta@huawei.com \
    --cc=shameerali.kolothum.thodi@huawei.com \
    --cc=shaojijie@huawei.com \
    --cc=shenjian15@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.