All of lore.kernel.org
 help / color / mirror / Atom feed
From: Antoine Tenart <atenart@kernel.org>
To: Jakub Kicinski <kuba@kernel.org>
Cc: davem@davemloft.net, alexander.duyck@gmail.com,
	netdev@vger.kernel.org, Michal Kubecek <mkubecek@suse.cz>
Subject: Re: [PATCH net v2] net: avoid registering new queue objects after device unregistration
Date: Tue, 23 Nov 2021 12:18:30 +0100	[thread overview]
Message-ID: <163766631025.3372.17600281769888147460@kwain> (raw)
In-Reply-To: <20211122113742.16705a54@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>

Quoting Jakub Kicinski (2021-11-22 20:37:42)
> On Mon, 22 Nov 2021 17:56:06 +0100 Antoine Tenart wrote:
> > Quoting Jakub Kicinski (2021-11-22 17:31:44)
> > > On Mon, 22 Nov 2021 17:20:07 +0100 Antoine Tenart wrote:  
> > > >    veth_set_channels+0x1c3/0x550
> > > >    ethnl_set_channels+0x524/0x610  
> > > 
> > > The patch looks fine, but ethtool calls should not happen after
> > > unregister IMHO. Too many drivers would be surprised. 
> > > 
> > > Maybe we should catch unregistered devices in ethnl_ops_begin()?  
> > 
> > That might be good to have indeed, I'll have a look. I'm not sure about
> > other paths that could do the same: if there are, we might want to keep
> > the check in this patch as well. Or WARN to catch future misuses?
> 
> My knee jerk reaction was to add a WARN() just because I can't think
> why changing queue count after unregister would be needed. But it's not
> really illegal and we do support it before register, so why not after
> unregister..

It's a little tricky. The queue count can be changed before
registration (updating dev->real_num_rx/tx_queues only) but the queue
objects can't[1]. The symmetry would be to only allowing to update
dev->real_num_tx_queues after unregister (which seems useless).

This is what's actually done for Rx queues[2]. For Tx the issue we have
is a quirk that was added to allow qdiscs to remove their extra Tx
queues after unregister[3] as in unregister_netdevice_many the net
devices are unlisted and moved to NETREG_UNREGISTERING before the call
to dev_shutdown().

[1] https://elixir.bootlin.com/linux/v5.16-rc2/source/net/core/dev.c#L2918
[2] https://elixir.bootlin.com/linux/v5.16-rc2/source/net/core/dev.c#L2967
[3] 5c56580b74e5 ("net: Adjust TX queue kobjects if number of queues
    changes during unregister")

> We can venture a warning with a comment saying that this is just for
> catching bad uses and see if any driver hits it on a normal path?

With that a better fix seems to be what you suggested, in
ethnl_ops_begin. A WARN in netdev_queue_update_kobjects[4] detecting
misuses might be good as well as the logic is not that straightforward
here.

[4] Or in netif_set_real_num_tx_queues as it is already detecting when
    queues are being disabled. !disabling && NETREG_UNREGISTERING should
    be illegal or at least not update the kobjects.
    https://elixir.bootlin.com/linux/v5.16-rc2/source/net/core/dev.c#L2913

Thanks!
Antoine

      reply	other threads:[~2021-11-23 11:18 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-22 16:20 [PATCH net v2] net: avoid registering new queue objects after device unregistration Antoine Tenart
2021-11-22 16:31 ` Jakub Kicinski
2021-11-22 16:56   ` Antoine Tenart
2021-11-22 19:37     ` Jakub Kicinski
2021-11-23 11:18       ` Antoine Tenart [this message]

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=163766631025.3372.17600281769888147460@kwain \
    --to=atenart@kernel.org \
    --cc=alexander.duyck@gmail.com \
    --cc=davem@davemloft.net \
    --cc=kuba@kernel.org \
    --cc=mkubecek@suse.cz \
    --cc=netdev@vger.kernel.org \
    /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.