From: Andrew Morton <akpm@linux-foundation.org>
To: ebiederm@xmission.com (Eric W. Biederman)
Cc: linux-kernel@vger.kernel.org, adobriyan@gmail.com,
viro@ZenIV.linux.org.uk, containers@lists.osdl.org
Subject: Re: [PATCH 2/7] proc: Implement support for automounts in task directories
Date: Thu, 6 Nov 2008 20:28:22 -0800 [thread overview]
Message-ID: <20081106202822.a1af8a6e.akpm@linux-foundation.org> (raw)
In-Reply-To: <m1iqr0urb8.fsf@frodo.ebiederm.org>
On Thu, 06 Nov 2008 19:51:23 -0800 ebiederm@xmission.com (Eric W. Biederman) wrote:
> If we could do all of this with reference counting so that the
> mount would persist exactly until the last user of it has gone
> away without a periodic poll I would love it. But the infrastructure
> doesn't support that today,
Well that sucks. The free-on-last-put idiom occurs in so many places
and serves us so well. I wonder what went wrong here?
I guess it has interactions with dentry and inode cache aging which
could get tricky.
> and where this is at least partially
> a bug fix I would rather not have the change depend on enhancing
> the VFS.
>
> The algorithm is actually very aggressive and in practice you don't
> see any /proc/<pid>/net showing up as a mount point.
Do you think it has failure modes? Most particularly: obscure usage
patterns which can cause memory exhaustion?
> > Obviously, that becomes clearer as one spends more time with the code,
> > but I wonder whether this has all been made as maintainble as it
> > possibly could be.
>
> Good question.
>
> In the sense of will we have to go through and futz with the code all
> of the time. The abstraction seems good. You put a mount on
> the proc_automounts list with do_add_mounts and it goes away eventually
> with all of the vfs rules maintained.
>
> In the sense of can the code be read? Perhaps it could be better.
> I expect it helps to have run the code and see /proc/net as a filesystem.
> that is magically mounted.
'twould be a useful contribution if you were to enshrine your
discoveries in /*these things*/. You knew I was working up to that :)
next prev parent reply other threads:[~2008-11-07 4:29 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 [this message]
2008-11-07 15:51 ` Eric W. Biederman
2008-11-07 16:05 ` Andrew Morton
2008-11-07 16:58 ` Eric W. Biederman
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20081106202822.a1af8a6e.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=adobriyan@gmail.com \
--cc=containers@lists.osdl.org \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@ZenIV.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox