netdev - Re: Scalability of interface creation and deletion

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1304923036.3207.105.camel@edumazet-laptop>
Date:	Mon, 09 May 2011 08:37:16 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Alex Bligh <alex@...x.org.uk>
Cc:	paulmck@...ux.vnet.ibm.com, netdev@...r.kernel.org,
	Jesse Gross <jesse@...ira.com>,
	Ben Greear <greearb@...delatech.com>
Subject: Re: Scalability of interface creation and deletion

Le lundi 09 mai 2011 à 06:37 +0100, Alex Bligh a écrit :
> 
> --On 8 May 2011 23:00:47 +0200 Eric Dumazet <eric.dumazet@...il.com> wrote:
> 
> > We can probably speed things, but we should consider the following user
> > actions :
> 
> How about
> 
> > ip link add link eth0 vlan103 type vlan id 103
> > ip link del vlan103
> 
> Removes and unlinks structures, including making name available, sending
> out netlink messages, but doesn't free things

Most of the cleanup work has to be done with RTNL being held, and this
might because of transaction atomicity requirement.

In your test you dismantle idle devices. Now think a bit when you have
both trafic in and out, sockets with destinations still pointing to the
device, in flight arp requests, all this using RCU of course.

When you dismantle one device (or several in case of a module unload),
this can have implications on other devices (see veth cas for an obvious
example : this automatically removes the peer device), but also on
routes, neighbours, cached routes, various protocol cleanups, ... and so
on. Few people even on netdev understand the whole picture.

Given that 99.99% machines setup netdevice at boot time only, and hardly
consider dismantles, we netdev guys were pragmatic and safe. Two or
three synchronize_rcu() were considered as a non issue.

It seems there is interest to improve things now.

One way is to allow more batching and delegation, and I am working on
that right now, using a kthread, so that we dont block the requester for
the whole device dismantle.

This kthread might use call_rcu() driven state machine, but that is a
detail of implementation, since only kthread would be impacted.

I am pretty busy at work these days, so dont expect patches before some
time :)

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html