LKML Archive on
help / color / mirror / Atom feed
From: (Eric W. Biederman)
To: Andrew Morton <>
Subject: Re: [PATCH 2/7] proc: Implement support for automounts in task directories
Date: Fri, 07 Nov 2008 08:58:34 -0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <> (Andrew Morton's message of "Fri, 7 Nov 2008 08:05:29 -0800")

Andrew Morton <> writes:

> I was thinking more along the lines of some repeated operation which
> generates reclaimable storage, only nothing reclaims that storage
> sufficiently promptly (the 500 second delay, perhaps).
> Like the problem we had with SLAB_DESTROY_BY_RCU and, umm, I think it
> was route cache entries increasing like mad and not getting reaped.

Well what happens is I run reclaim that chain whenever a process
exits or every 500s.  The 500s is really the backup in case
we don't have any processes exiting, which is a really
strange workload.

Now maybe there is an extremely perverse case out there that
can trigger some bad behavior.  But I can't think of anything
like that at the moment.  It would require accessing a lot
of /proc/<pid>/net directories and holding them open even after
their files were gone, pinning a lot of mounts, and then
use a lot of memory elsewhere.  Where the problem would
be that the code is not well tied in with memory reclaim.

A mount is not a big or expensive structure and it requires
a fd somewhere to keep it alive past exit.  Thinking back
to my analysis on /proc a few years ago where I introduced
struct pid to prevent lowmem exhaustion.  I can't think of
a case where it would be a problem or user triggerable.
Basically you have to have a fd open for every proc inode
that lives past process exit.  And we have hard limits on
the number of fds a process can open and limits on the
number of processes we can have.

One of the things on my todo list to look at sometime is the issue
that mounts can deny you the permission to delete a file or directory
when the mount is in another mount namespace.  It is a pretty nasty
DOS from my opinion.  Especially when the last process holding open
the mount namespace oopses and there is no way to remove the mount.
However that DOS is only available to root today so it doesn't feel
like a huge danger.  To fix that we would need to introduce some
better mount reaping logic.  Which I expect would remove the need for
the proc_automounts.   That is tricky subtle vfs logic and I don't
plan to rush into it.


  reply	other threads:[~2008-11-07 17:05 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-06 10:38 [PATCH 1/7] vfs: Fix shrink_submounts Eric W. Biederman
2008-11-06 10:48 ` [PATCH 2/7] proc: Implement support for automounts in task directories Eric W. Biederman
2008-11-06 10:49   ` [PATCH 3/7] proc: Support multiple filesystems using the proc generic infrastructure Eric W. Biederman
2008-11-06 10:53     ` [PATCH 4/7] proc: Make /proc/net it's own filesystem Eric W. Biederman
2008-11-06 10:56       ` [PATCH 5/7] proc_net: Don't show the wrong /proc/net after unshare Eric W. Biederman
2008-11-06 10:57         ` [PATCH 6/7] proc_net: Simplify network namespace lookup Eric W. Biederman
2008-11-06 10:58           ` [PATCH 7/7] proc: Cleanup proc_flush_task Eric W. Biederman
2008-11-07  1:25   ` [PATCH 2/7] proc: Implement support for automounts in task directories Andrew Morton
2008-11-07  2:02     ` Eric W. Biederman
2008-11-07  1:26   ` Andrew Morton
2008-11-07  2:05     ` Eric W. Biederman
2008-11-07  2:49       ` Andrew Morton
2008-11-07  3:51         ` Eric W. Biederman
2008-11-07  4:28           ` Andrew Morton
2008-11-07 15:51             ` Eric W. Biederman
2008-11-07 16:05               ` Andrew Morton
2008-11-07 16:58                 ` Eric W. Biederman [this message]
2008-11-13 23:39                 ` Eric W. Biederman
2008-11-19  0:07                   ` Alexey Dobriyan
2008-11-19  2:35                     ` Alexey Dobriyan
2008-11-19 13:20                       ` Eric W. Biederman
2008-11-07  4:41   ` Alexey Dobriyan
2008-11-07 16:04     ` [PATCH] proc: Supply proc_shrink_automounts when CONFIG_PROC_FS=N Eric W. Biederman
2008-11-07  1:22 ` [PATCH 1/7] vfs: Fix shrink_submounts Andrew Morton
2008-11-07  2:06   ` Eric W. Biederman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \
    --subject='Re: [PATCH 2/7] proc: Implement support for automounts in task directories' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).