From: Al Viro <viro@ZenIV.linux.org.uk>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC] dealing with proc_ns_follow_link() and "namespace" dentries
Date: Sat, 1 Nov 2014 08:38:04 +0000 [thread overview]
Message-ID: <20141101083804.GO7996@ZenIV.linux.org.uk> (raw)
In-Reply-To: <87r3ybwq0b.fsf@x220.int.ebiederm.org>
On Mon, Oct 13, 2014 at 03:42:28PM -0700, Eric W. Biederman wrote:
> >From looking at your proposed code that doesn't look like it will be
> any more difficult to maintain from the namespace side. So I have no
> objects with moving the code in that direction.
>
> > It's obviously a project for the next cycle and it'll require
> > some cooperation between vfs and userns trees, but not too much of it -
> > all we really need is a never-changed commit embedding that structure into
> > all ...ns and passing _that_ to proc_{alloc,free}_inum() replacements
> > Merged both into vfs.git #for-next and usern one. We can do that right
> > after -rc1. Incidentally, it might make sense to move refcount into that
> > common piece as well, but that's independent from the stuff above.
>
> That sounds like a reasonable direction to go. I think your schedule
> may be a tad optimistic time-wise, if for no other reason that code
> reviews take time, but that plan should work.
OK, interim branch (_completely_ untested, and there's quite a bit of
work remaining) is in vfs.git#nsfs. It will be refactored; moreover,
most of that stuff will move out from fs/proc/namespaces.c - either into
fs/nsfs.c or into kernel/nsproxy.c. And purely VFS followups are not even
touched yet - I know what I want to do, and I think there's no obstacles
left, but that's a separate story. "Filesystem for ns dentries/inodes"
part is done, though (modulo debugging and moving it out of fs/proc).
I wonder if we would be better off not using proc_alloc_inum() there -
it's not hard to do a separate allocator, especially since there's no
requirements re non-intersecting sets of inumbers for procfs and for this.
That's the last part shared with procfs...
Anyway, I'm going down right now (nearly 5am here), so further fun will have
to wait a bit...
next prev parent reply other threads:[~2014-11-01 8:38 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-13 6:29 [RFC] dealing with proc_ns_follow_link() and "namespace" dentries Al Viro
2014-10-13 22:42 ` Eric W. Biederman
2014-11-01 8:38 ` Al Viro [this message]
2014-11-01 15:06 ` Al Viro
2014-11-01 18:23 ` Eric W.Biederman
2014-11-01 18:38 ` Al Viro
2014-11-01 22:04 ` Al Viro
2014-11-01 18:30 ` Al Viro
2014-11-24 10:55 ` Al Viro
2014-10-14 0:41 ` Al Viro
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=20141101083804.GO7996@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=ebiederm@xmission.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/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;
as well as URLs for NNTP newsgroup(s).