netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Paolo Abeni <pabeni@redhat.com>
Cc: davem@davemloft.net, netdev@vger.kernel.org, edumazet@google.com,
	mkubecek@suse.cz, lorenzo@kernel.org,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Neil Brown <neilb@suse.de>
Subject: Re: [PATCH net-next 1/2] net: store netdevs in an xarray
Date: Mon, 24 Jul 2023 10:27:41 -0700	[thread overview]
Message-ID: <20230724102741.469c0e42@kernel.org> (raw)
In-Reply-To: <2a531e60a0ea8187f1781d4075f127b01970321a.camel@redhat.com>

On Mon, 24 Jul 2023 18:23:03 +0200 Paolo Abeni wrote:
> On Mon, 2023-07-24 at 08:41 -0700, Jakub Kicinski wrote:
> > On Mon, 24 Jul 2023 10:18:04 +0200 Paolo Abeni wrote:  
> > > A possibly dumb question: why using an xarray over a plain list?  
> > 
> > We need to drop the lock during the walk.   
> 
> I should have looked more closely to patch 2/2.
> 
> > So for a list we'd need 
> > to either 
> >  - add explicit iteration "cursor" or   
> 
> Would a cursor require acquiring a netdev reference? If so it looks
> problematic (an evil/buggy userspace could keep such reference held for
> an unbounded amount of time).

I was thinking we can add a cursor which looks like:

struct netdev_list_node {
	struct list head_list;
	bool is_a_device;
};

then iteration can put this struct into its dump state and insert
*itself* into the device list. All iterations will then have to:

	struct netdev_list_node *lnode;

	list_for_each_entry... lnode) {
		/* skip cursors inserted into the list */
		if (!lnode->is_a_device)
			continue;
		netdev = containerof(lnode);

		...
	}

But then we need to add some code to .start and .stop callbacks
and make sure the "cursor" is removed if someone closes the socket
half way thru the dump.

> I agree xarray looks a better solution.

I do think xarray is the simplest solution.

> I still have some minor doubts WRT the 'missed device' scenario you
> described in the commit message. What if the user-space is doing
> 'create the new one before deleting the old one' with the assumption
> that at least one of old/new is always reported in dumps? Is that a too
> bold assumption?

The problem is kinda theoretical in the first place because it assumes
ifindexes got wrapped so that the new netdev comes "before" the old in
the xarray. Which would require adding and removing 2B netdevs, assuming
one add+remove takes 10 usec (impossibly fast), wrapping ifindex would
take 68 years.

And if that's not enough we can make the iteration index ulong 
(i.e. something separate from ifindex as ifindex is hardwired to 31b
by uAPI).

  reply	other threads:[~2023-07-24 17:27 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-22  1:42 [PATCH net-next 0/2] net: store netdevs in an xarray Jakub Kicinski
2023-07-22  1:42 ` [PATCH net-next 1/2] " Jakub Kicinski
2023-07-22  1:47   ` Jakub Kicinski
2023-07-24  8:18   ` Paolo Abeni
2023-07-24 15:41     ` Jakub Kicinski
2023-07-24 16:23       ` Paolo Abeni
2023-07-24 17:27         ` Jakub Kicinski [this message]
2023-07-24 19:07           ` Jakub Kicinski
2023-07-25 11:11             ` Paolo Abeni
2023-07-25 16:56               ` Jakub Kicinski
2023-07-25 17:54             ` Sabrina Dubroca
2023-07-25 19:45               ` Jakub Kicinski
2023-07-24 19:09   ` Leon Romanovsky
2023-07-22  1:42 ` [PATCH net-next 2/2] net: convert some netlink netdev iterators to depend on the xarray Jakub Kicinski
2023-07-24 15:28 ` [PATCH net-next 0/2] net: store netdevs in an xarray 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=20230724102741.469c0e42@kernel.org \
    --to=kuba@kernel.org \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=lorenzo@kernel.org \
    --cc=mkubecek@suse.cz \
    --cc=neilb@suse.de \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).