From: Andrew Morton <akpm@linux-foundation.org>
To: "Eric W. Biederman" <ebiederm@xmission.com>
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 :)
WARNING: multiple messages have this Message-ID (diff)
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:28 UTC|newest]
Thread overview: 38+ 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:38 ` 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:48 ` Eric W. Biederman
[not found] ` <m1abcd2kqk.fsf-B27657KtZYmhTnVgQlOflh2eb7JE58TQ@public.gmane.org>
2008-11-06 10:49 ` [PATCH 3/7] proc: Support multiple filesystems using the proc generic infrastructure Eric W. Biederman
2008-11-06 10:49 ` Eric W. Biederman
[not found] ` <m163n12ko9.fsf_-_-B27657KtZYmhTnVgQlOflh2eb7JE58TQ@public.gmane.org>
2008-11-06 10:53 ` [PATCH 4/7] proc: Make /proc/net it's own filesystem Eric W. Biederman
2008-11-06 10:53 ` Eric W. Biederman
[not found] ` <m1y6zx15yj.fsf_-_-B27657KtZYmhTnVgQlOflh2eb7JE58TQ@public.gmane.org>
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:56 ` Eric W. Biederman
[not found] ` <m1skq515ti.fsf_-_-B27657KtZYmhTnVgQlOflh2eb7JE58TQ@public.gmane.org>
2008-11-06 10:57 ` [PATCH 6/7] proc_net: Simplify network namespace lookup Eric W. Biederman
2008-11-06 10:57 ` Eric W. Biederman
2008-11-06 10:58 ` [PATCH 7/7] proc: Cleanup proc_flush_task Eric W. Biederman
2008-11-06 10:58 ` Eric W. Biederman
2008-11-07 1:25 ` [PATCH 2/7] proc: Implement support for automounts in task directories Andrew Morton
2008-11-07 1:25 ` Andrew Morton
2008-11-07 2:02 ` Eric W. Biederman
2008-11-07 1:26 ` Andrew Morton
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 2:49 ` Andrew Morton
2008-11-07 3:51 ` Eric W. Biederman
2008-11-07 4:28 ` Andrew Morton [this message]
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: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 1:22 ` 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.