pidns memory leak

[Eric W. Biederman]

Sukadev Bhattiprolu <sukadev at linux.vnet.ibm.com> writes:

> Andrea,
>
> We have been running a leak in child pid namespaces and some early debugging
> points to the following commit:
>
>>> 	commit 7766755a2f249e7e0dabc5255a0a3d151ff79821
>>> 	Author: Andrea Arcangeli <andrea at suse.de>
>>> 	Date:   Mon Feb 4 22:29:21 2008 -0800
>>>
>
> Reverting the commit seems to fix the leak but we need to do some more
> analysis (like the lstat() question Daniel has).

Yes.

That entire path is an optimization.  It should not be needed for correct
operation.  Although it may be responsible for some false positives.

> However I have a basic question regarding the commit - the log mentions:
>
> 	> do_exit->release_task->mark_inode_dirty_sync->schedule() (will never
> 	> come back to run journal_stop)
>
> But release_task() calls shrink_dcache_parent() for a _procfs_ dentry. Does
> journal_stop() apply to procfs also ?

The problem when the that PF_EXITING check was introduced is that
shrink_dcache_parent could shrink dcache entries for other
filesystems.  Last I looked that is no longer the case and we can
remove that code.  As I recall proc_flush_task_mnt has a few other minor
bugs as well that could cause problems.

Ultimately what problems are you seeing?

Eric