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]

Date:	Fri, 11 Mar 2016 21:58:54 +0100
From:	Florian Westphal <fw@...len.de>
To:	David Miller <davem@...emloft.net>
Cc:	gorcunov@...il.com, xiyou.wangcong@...il.com,
	alexei.starovoitov@...il.com, 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, pablo@...filter.org,
	netfilter-devel@...r.kernel.org
Subject: Re: [RFC] net: ipv4 -- Introduce ifa limit per net

David Miller <davem@...emloft.net> wrote:
> From: Cyrill Gorcunov <gorcunov@...il.com>
> Date: Fri, 11 Mar 2016 01:40:56 +0300
> 
> > On Thu, Mar 10, 2016 at 05:36:30PM -0500, David Miller wrote:
> >> > 
> >> > Works like a charm! So David, what are the next steps then?
> >> > Mind to gather all your patches into one (maybe)?
> >> 
> >> I'll re-review all of the changes tomorrow and also look into ipv6
> >> masq, to see if it needs the same treatment, as well.
> >> 
> >> Thanks for all of your help and testing so far.
> > 
> > Thanks a lot, David!
> 
> Cyrill please retest this final patch and let me know if it still works
> properly.
> 
> I looked at ipv6, and it's more complicated.  The problem is that ipv6
> doesn't mark the inet6dev object as dead in the NETDEV_DOWN case, in
> fact it keeps the object around.  It only releases it and marks it
> dead in the NETDEV_UNREGISTER case.
> 
> We pay a very large price for having allowed the behavior of ipv6 and
> ipv4 to diverge so greatly in these areas :-(
> 
> Nevertheless we should try to fix it somehow, maybe we can detect the
> situation in another way for the ipv6 side.

Note that as the ipv6 inet notifier is atomic; now that
nf_ct_iterate_cleanup can schedule the ipv6 masq version defers the
cleanup to a work queue, with a backlog cap of 16.  So in case
of a gazillion events most will be ignored and teardown should not be
delayed (at least not even close to what ipv4 masq did).