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, 27 Jun 2014 17:09:15 -0700
From:	Cong Wang <xiyou.wangcong@...il.com>
To:	David Miller <davem@...emloft.net>
Cc:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	Patrick McHardy <kaber@...sh.net>,
	Stephen Hemminger <stephen@...workplumber.org>,
	Cong Wang <cwang@...pensource.com>,
	Stefan Bader <stefan.bader@...onical.com>,
	stephane.graber@...onical.com, chris.j.arges@...onical.com,
	Serge Hallyn <serge.hallyn@...onical.com>
Subject: Re: [Patch net-next] net: make neigh tables per netns

On Thu, Jun 26, 2014 at 3:44 PM, David Miller <davem@...emloft.net> wrote:
>
> First of all it is clear that once you start creating containers on the
> order of half the global neigh limit, yes you will run into problems as
> it's easy to have 2 or more outputs in flight.
>
> So it would perhaps be wise to scale the limits (in some way) based
> upon the number of namespaces, but still keep it a global limit.
>
> These entries consume a global resource (memory) and benefit from
> global sharing, so I am still convinced that making the tables
> themselves per-ns does not make any sense.
>
> Secondly, if there are things holding onto neighbour entries for real
> we should find this out.  Once could audit neigh_lookup*() invocations
> to see where that might be happening.  Also neigh_create() calls with
> 'want_ref' set to true.
>

Hmm, I did overlook the potential DOS problem. But hold on, isn't
IP fragments have the same problem? The fragment queues are per
netns, and the thresh is per netns as well, we will eventually have
memory pressure as well.

I will dig this deeper to see if there is any better solution.

Thanks.
--
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

Powered by blists - more mailing lists