On Sat, Nov 01, 2014 at 06:30:37PM +, Al Viro wrote:
> On Sat, Nov 01, 2014 at 03:06:20PM +, Al Viro wrote:
> > On Sat, Nov 01, 2014 at 08:38:04AM +, Al Viro wrote:
> > > OK, interim branch (_completely_ untested, and there's quite a bit of
> > > work remaining) is in vfs.git#nsfs.
> >
On Sat, Nov 01, 2014 at 06:30:37PM +, Al Viro wrote:
On Sat, Nov 01, 2014 at 03:06:20PM +, Al Viro wrote:
On Sat, Nov 01, 2014 at 08:38:04AM +, Al Viro wrote:
OK, interim branch (_completely_ untested, and there's quite a bit of
work remaining) is in vfs.git#nsfs.
...
On Sat, Nov 01, 2014 at 06:38:02PM +, Al Viro wrote:
> On Sat, Nov 01, 2014 at 11:23:34AM -0700, Eric W.Biederman wrote:
>
> > >From your description I am concerned about using the letter combination
> > >nsfs. I once used nsfd, and that was so close to nfsd that Linus got
> > >confused,
On Sat, Nov 01, 2014 at 11:23:34AM -0700, Eric W.Biederman wrote:
> >From your description I am concerned about using the letter combination
> >nsfs. I once used nsfd, and that was so close to nfsd that Linus got
> >confused, and hilarity ensued. nsfs isn't quite as bad but the
>
On Sat, Nov 01, 2014 at 03:06:20PM +, Al Viro wrote:
> On Sat, Nov 01, 2014 at 08:38:04AM +, Al Viro wrote:
> > OK, interim branch (_completely_ untested, and there's quite a bit of
> > work remaining) is in vfs.git#nsfs.
>
> ... except that what got pushed was completely buggered - the
On November 1, 2014 8:06:20 AM PDT, Al Viro wrote:
>On Sat, Nov 01, 2014 at 08:38:04AM +, Al Viro wrote:
>> OK, interim branch (_completely_ untested, and there's quite a bit of
>> work remaining) is in vfs.git#nsfs.
>
>... except that what got pushed was completely buggered - the last
On Sat, Nov 01, 2014 at 08:38:04AM +, Al Viro wrote:
> OK, interim branch (_completely_ untested, and there's quite a bit of
> work remaining) is in vfs.git#nsfs.
... except that what got pushed was completely buggered - the last changes
not committed *and* include/linux/ns_common.h not
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
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
On Sat, Nov 01, 2014 at 08:38:04AM +, Al Viro wrote:
OK, interim branch (_completely_ untested, and there's quite a bit of
work remaining) is in vfs.git#nsfs.
... except that what got pushed was completely buggered - the last changes
not committed *and* include/linux/ns_common.h not
On November 1, 2014 8:06:20 AM PDT, Al Viro v...@zeniv.linux.org.uk wrote:
On Sat, Nov 01, 2014 at 08:38:04AM +, Al Viro wrote:
OK, interim branch (_completely_ untested, and there's quite a bit of
work remaining) is in vfs.git#nsfs.
... except that what got pushed was completely buggered
On Sat, Nov 01, 2014 at 03:06:20PM +, Al Viro wrote:
On Sat, Nov 01, 2014 at 08:38:04AM +, Al Viro wrote:
OK, interim branch (_completely_ untested, and there's quite a bit of
work remaining) is in vfs.git#nsfs.
... except that what got pushed was completely buggered - the last
On Sat, Nov 01, 2014 at 11:23:34AM -0700, Eric W.Biederman wrote:
From your description I am concerned about using the letter combination
nsfs. I once used nsfd, and that was so close to nfsd that Linus got
confused, and hilarity ensued. nsfs isn't quite as bad but the
abbreviation
On Sat, Nov 01, 2014 at 06:38:02PM +, Al Viro wrote:
On Sat, Nov 01, 2014 at 11:23:34AM -0700, Eric W.Biederman wrote:
From your description I am concerned about using the letter combination
nsfs. I once used nsfd, and that was so close to nfsd that Linus got
confused, and
On Mon, Oct 13, 2014 at 07:29:45AM +0100, Al Viro wrote:
> there and get rid of pointless aliases. Oh, and we get a decent chance to
> kill d_instantiate_unique(), which is also nice. Or at least fold it into
> d_add_unique(), if we can't kill that sucker as well. And if we manage to
> kill it
Al Viro writes:
> But more fundamentally, this stuff has no business being in procfs. The
> *only* reason why we are putting them there (and get those inodes and
> dentries duplicated for different procfs instances) is this in
> do_loopback():
> if (!check_mnt(parent) ||
proc_ns_follow_link() is unique among the ->follow_link() instances
in several respects, some of them violating general asserts expected by
all kinds of VFS code.
First of all, it can lead to pairs with dentry
being completely unrelated to vfsmount. Suppose we bind such a
proc_ns_follow_link() is unique among the -follow_link() instances
in several respects, some of them violating general asserts expected by
all kinds of VFS code.
First of all, it can lead to vfsmount,dentry pairs with dentry
being completely unrelated to vfsmount. Suppose we bind
Al Viro v...@zeniv.linux.org.uk writes:
But more fundamentally, this stuff has no business being in procfs. The
*only* reason why we are putting them there (and get those inodes and
dentries duplicated for different procfs instances) is this in
do_loopback():
if (!check_mnt(parent)
On Mon, Oct 13, 2014 at 07:29:45AM +0100, Al Viro wrote:
there and get rid of pointless aliases. Oh, and we get a decent chance to
kill d_instantiate_unique(), which is also nice. Or at least fold it into
d_add_unique(), if we can't kill that sucker as well. And if we manage to
kill it
20 matches
Mail list logo
