Re: [git pull] more vfs bits

[Al Viro]

On Sat, Feb 21, 2015 at 02:45:34PM -0800, Linus Torvalds wrote:
> So I've pulled this, but quite frankly, I think I will unpull it again
> unless you actually state *what* the advantages of this pointless
> series of endless patches are.

> And no, that "explanation" in commit b717805b3c8b is not an
> explanation. Why should filesystems have to know/care. Any use of
> "fs_inode()" clearly does *not* specify upper/lower, so what the f*ck
> is the advantage of that helper wrt just making the rule be that
> "dentry->d_inode" is that unspecified thing.
> 
> Explain it, or that crap gets undone.

Use of fs_inode does not specify upper/lower; it's choice of dentry_inode() vs.
fs_inode().  And d_inode() side of that pile is what I didn't cherry-pick
from David's tree - it was too massive already.

FWIW, I probably should've collapsed the per-fs patches together, or
held them back until the next cycle; I understand why David did them
that way (less painful rebasing that stuff), but once they switch from
"try to stay sane while developing" to "into the tree it goes" mode,
they ought to have been collapsed together.  And that's something I should
have done - my fault.

Filesystems (non-layered ones) should *not* care; this fs_inode() thing is
exactly what we do right now and, unlike dentry_inode(), it is intended to
stay that way.  And yes, we could've bloody well have left it as ->d_inode;
it's no more than an annotation.  What it gives is a way to keep track of
the accesses that remain to be annotated.

Looking at that queue, it might make sense to hold back everything in that
series past "fanotify: Fix up scripted S_ISDIR/S_ISREG/S_ISLNK conversions"
for now - keep in in vfs.git for the next cycle.  My reason for pushing those
now had been no better than wanting to be rid of the trivial bits to make
life a bit easier for the next couple of months, avoiding fun on on each
conflict with every actively changing filesystem.  With the bulk of such
places annotated at once, the work would be limited to VFS proper plus
a bit of whack-a-mole in the end of cycle, pretty much consisting of annotating
the new ->d_inode instances in filesystems (all to fs_inode(), of course).
But that should've been spelled out in pull request *and* done in one
commit instead of that long tail.  Again, my apologies.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/