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
