lkml.org 
[lkml]   [2017]   [Feb]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC 1/1] shiftfs: uid/gid shifting bind mount
From
Date
On Fri, 2017-02-17 at 02:55 +0000, Al Viro wrote:
> On Thu, Feb 16, 2017 at 07:56:30AM -0800, James Bottomley wrote:
>
> > > Hi James,
> > >
> > > Should it be "return d_splice_alias()" so that if we find an
> > > alias it is returned back to caller and passed in dentry can be
> > > freed. Though I don't know in what cases alias can be found. And
> > > if alias is found how do we make sure alias_dentry->d_fsdata is
> > > pointing to new (real dentry).
> >
> > It probably should be for the sake of the pattern. In our case I
> > don't think we can have any root aliases because the root dentry is
> > always pinned in the cache, so cache lookup should always find it.
>
> What does that have to do with root dentry? The real reason why that
> code works (FVerySVO) is that the damn thing allocates a new inode
> every time. Including the hardlinks, BTW.

Yes, this is a known characteristic of stacked filesystems. Is there
some magic I don't know about that would make it easier to reflect hard
links as aliases?

> So d_splice_alias() will always return NULL - there's no way for
> any dentries to be pointing to in-core struct inode you've
> just allocated. Short of a use-after-free, that is...
>
> Unless I'm missing something subtle, the whole thing is fucked
> in head wrt cache coherency - its dentries are blindly assumed to be
> forever valid, no matter what's happening with the underlying
> filesystem.

Hopefully the patch in the previous email fixes this.

James

\
 
 \ /
  Last update: 2017-02-17 18:35    [W:0.125 / U:0.076 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site