[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1336014721.7370.32.camel@marge.simpson.net>
Date: Thu, 03 May 2012 05:12:01 +0200
From: Mike Galbraith <efault@....de>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: "Eric W. Biederman" <ebiederm@...ssion.com>,
Oleg Nesterov <oleg@...hat.com>,
LKML <linux-kernel@...r.kernel.org>,
Pavel Emelyanov <xemul@...allels.com>,
Cyrill Gorcunov <gorcunov@...nvz.org>,
Louis Rilling <louis.rilling@...labs.com>
Subject: Re: [PATCH] Re: [RFC PATCH] namespaces: fix leak on fork() failure
On Tue, 2012-05-01 at 13:42 -0700, Andrew Morton wrote:
> On Tue, 01 May 2012 13:35:03 -0700
> ebiederm@...ssion.com (Eric W. Biederman) wrote:
>
> >
> > Andrew can you please pick up this patch?
>
> Sure. I assume it's fixing a post-3.4 regression? No -stable backport
> needed?
Dunno what all should go to stable, but anyone using vsftpd will
appreciate something going. Large leakage was initially reported
against 3.1. That was bisected to..
423e0ab0 VFS : mount lock scalability for internal mounts
Subsequent fixes which did not go to stable were applied..
905ad269 procfs: fix a vfsmount longterm reference leak
6f686574 ... and the same kind of leak for mqueue
..but leakage persists even with fork failure hole plugged.
The one (at least) that remains, grabbing pid references while we wait
for RCU destruction of pid/namespace and our subsequently never
destroying namespace is being annoying. Yesterday I ran up >4600 leaks
with 10 background instances of the testcase (time that, egad), much
MUCH later ~4000 were released. Between huge delay and ftrace simply
refusing to trace out of lined get_pid(), I'm having a jolly time trying
to get an 8x10 color glossy of the leaky event to stare at.
Whatever goes to stable, what fixes this little bugger should go too.
> hm, Mike had some test code. If that was put in
> tools/testing/selftests/nsproxy, this leak wouldn't happen again!
I didn't write it, that and a perl script to monitor leakage came along
with bug report.
-Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists