All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stanislav Fomichev <stfomichev@gmail.com>
To: Breno Leitao <leitao@debian.org>
Cc: Stanislav Fomichev <sdf@fomichev.me>,
	kuniyu@amazon.com, netdev@vger.kernel.org, davem@davemloft.net,
	edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
	linux-kernel@vger.kernel.org, michael.chan@broadcom.com,
	pavan.chebbi@broadcom.com, andrew+netdev@lunn.ch,
	Taehee Yoo <ap420073@gmail.com>
Subject: Re: [PATCH net] bnxt_en: bring back rtnl lock in bnxt_shutdown
Date: Mon, 31 Mar 2025 08:29:53 -0700	[thread overview]
Message-ID: <Z-q08YfJMq8Q76ki@mini-arch> (raw)
In-Reply-To: <Z+qAYXmGY08pQKKb@gmail.com>

On 03/31, Breno Leitao wrote:
> Hello Stanislav,
> 
> On Fri, Mar 28, 2025 at 10:42:16AM -0700, Stanislav Fomichev wrote:
> > Taehee reports missing rtnl from bnxt_shutdown path:
> > 
> > inetdev_event (./include/linux/inetdevice.h:256 net/ipv4/devinet.c:1585)
> > notifier_call_chain (kernel/notifier.c:85)
> > __dev_close_many (net/core/dev.c:1732 (discriminator 3))
> > kernel/locking/mutex.c:713 kernel/locking/mutex.c:732)
> > dev_close_many (net/core/dev.c:1786)
> > netif_close (./include/linux/list.h:124 ./include/linux/list.h:215
> > bnxt_shutdown (drivers/net/ethernet/broadcom/bnxt/bnxt.c:16707) bnxt_en
> > pci_device_shutdown (drivers/pci/pci-driver.c:511)
> > device_shutdown (drivers/base/core.c:4820)
> > kernel_restart (kernel/reboot.c:271 kernel/reboot.c:285)
> 
> I've got this issue as well.
> 
> > 
> > Bring back the rtnl lock.
> > 
> > Link: https://lore.kernel.org/netdev/CAMArcTV4P8PFsc6O2tSgzRno050DzafgqkLA2b7t=Fv_SY=brw@mail.gmail.com/
> > Fixes: 004b5008016a ("eth: bnxt: remove most dependencies on RTNL")
> > Reported-by: Taehee Yoo <ap420073@gmail.com>
> > Signed-off-by: Stanislav Fomichev <sdf@fomichev.me>
> 
> Tested-by: Breno Leitao <leitao@debian.org>
> 
> > ---
> >  drivers/net/ethernet/broadcom/bnxt/bnxt.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
> > index 934ba9425857..1a70605fad38 100644
> > --- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
> > +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
> > @@ -16698,6 +16698,7 @@ static void bnxt_shutdown(struct pci_dev *pdev)
> >  	if (!dev)
> >  		return;
> >  
> > +	rtnl_lock();
> >  	netdev_lock(dev);
> 
> can't we leverage the `struct net_device->lock` for the shutdown.
> Basically we have the lock the single device we are turning it down.
> 
> I am wondering if we really need the big RTNL lock. This is my
> understanding of what is happening:
> 
> pci_device_shutdown() is called for a single device
>  - netdev_lock(dev)
>  - netif_close(dev);
>     - dev_close_many(&single, true);
>       - __dev_close_many()
>         - ASSERT_RTNL();
> 
> Basically we ware only closing one device, and the net_device->lock
> is already held. Shouldn't it be enough?

[..]

> Can we do something like this (from my naive point of view):
> 
> 	 static void __dev_close_many(struct list_head *head)
> 	  {
> 		  struct net_device *dev;
> 
> 	-         ASSERT_RTNL();
> 		  might_sleep();
> 
> 		  list_for_each_entry(dev, head, close_list) {
> 	+	  	ASSERT_RTNL_NET(dev);
> 			...
> 		  }

- netif_close adds dev->close_list to the list (if it was up)
- __dev_close_many walks over that list, so your new assert should
  trigger as well

But also in general, it would be nice to keep existing
rtnl+instance_lock scheme for now (except were we want to explicitly opt
out, as in queue apis); we can follow up later to un-rtnl the rest.

  reply	other threads:[~2025-03-31 15:29 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-28 17:42 [PATCH net] bnxt_en: bring back rtnl lock in bnxt_shutdown Stanislav Fomichev
2025-03-29 10:25 ` Taehee Yoo
2025-03-31 11:45 ` Breno Leitao
2025-03-31 15:29   ` Stanislav Fomichev [this message]
2025-03-31 16:53     ` Breno Leitao
2025-03-31 17:16       ` Jakub Kicinski
2025-04-01  0:10 ` patchwork-bot+netdevbpf

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=Z-q08YfJMq8Q76ki@mini-arch \
    --to=stfomichev@gmail.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=ap420073@gmail.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=kuba@kernel.org \
    --cc=kuniyu@amazon.com \
    --cc=leitao@debian.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michael.chan@broadcom.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=pavan.chebbi@broadcom.com \
    --cc=sdf@fomichev.me \
    /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.