netdev - Re: [PATCH net-next 0/9] selective (per/namespace) flush of rt

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:	Mon, 07 Jul 2008 14:39:41 +0400
From:	"Denis V. Lunev" <den@...nvz.org>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	David Miller <davem@...emloft.net>, containers@...ts.osdl.org,
	netdev@...r.kernel.org
Subject: Re: [PATCH net-next 0/9] selective (per/namespace) flush of
	rt_cache


On Mon, 2008-07-07 at 03:29 -0700, Eric W. Biederman wrote:
> David Miller <davem@...emloft.net> writes:
> 
> > From: "Denis V. Lunev" <den@...nvz.org>
> > Date: Fri, 04 Jul 2008 17:16:00 +0400
> >
> >> This series of patches implements selective rt cache flushing to make
> >> sure that in one namespace we'll not been able to affect the performance
> >> of other from the user space.
> >
> > Applied and pushed out to net-next-2.6, thanks.
> >
> > Although I wish patch 9 didn't have to be so ugly. :-/ Also, is it
> > really the right thing to do if another namespace's RT cache entries
> > are in fact chewing up all the slots in a hash chain?  I think
> > the replacement garbage collection algorithm should be namespace
> > agnostic.
> 
> My VM experience agrees.  The requested flushes from inside the namespace
> and for namespace exit really should just flush the routes for that namespace.
> However for general route caching and expiry I don't see the point of making
> the code per namespace, and my gut feel is that is likely to reduce average
> case performance at the cost of better isolation between namespaces.
> 
> Denis did I read the patches right and you are making all route cache flushes
> per namespace?  Including the periodic expiry?
yes. The reason for the latter is that we can't pin namespace list in
the timer, so it is better to have a separate timer for each namespace.
The similar approach has been discussed for IPv6 flushing if my memory
does not fail me.

Though, generic rt cache garbage collecting is left untouched and from
my point of view it should be left as it is. At least we use this
approach in OpenVz.

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