netdev - Re: [RFC] net: ipv4 -- Introduce ifa limit per net

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: <20160305170057.GN4184@uranus.lan>
Date:	Sat, 5 Mar 2016 20:00:57 +0300
From:	Cyrill Gorcunov <gorcunov@...il.com>
To:	David Miller <davem@...emloft.net>
Cc:	eric.dumazet@...il.com, netdev@...r.kernel.org, solar@...nwall.com,
	vvs@...tuozzo.com, avagin@...tuozzo.com, xemul@...tuozzo.com,
	vdavydov@...tuozzo.com, khorenko@...tuozzo.com
Subject: Re: [RFC] net: ipv4 -- Introduce ifa limit per net

On Sat, Mar 05, 2016 at 11:33:12AM -0500, David Miller wrote:
> > and until everything get cleaned up I couldn't connect
> > to the node via ssh. I continue playing with patch maybe
> > I find some other optimization paths. Thanks!
> 
> What is the order of magnitude of the delay, as a function of
> number of IP aliases installed, compred to before the patch?

You know I didn't measured precise numbers. The script (which
I of course forgot to attach in first report) creates 65025
addresses and on exit it takes ~10 minutes (it also depends
on load on the host because I've been testing inside VM).

I'll create some kind of graph for that if you interested,
should I?

> The remaining cost you are seeing comes of course from the router
> deletion, whose path is:
> 
> 	blocking_notifier_call_chain(&inetaddr_chain, NETDEV_DOWN, ifa1);
> 		fib_inetaddr_event()
> 			fib_del_ifaddr(ifa, NULL);
> 
> Which does another full list scan trying to handle primaries and
> secondaries.
> 
> Probably the same optimization can be applied there, see patch below.
> And if that doesn't do it, there is a really easy way to batch the
> delete by scanning the FIB tree in one go and deleting every entry
> that points to "in_dev".  But I suspect we really won't need that.

I'll test it David, in a couple of hours I hope. And report the
result.

	Cyrill