Re: [git pull] vfs.git - including i_mutex wrappers
From: Al Viro
Date: Sat Jan 23 2016 - 20:20:11 EST
On Sun, Jan 24, 2016 at 11:26:58AM +1100, Dave Chinner wrote:
> That's fair enough. However, compare this to how core locking
> changes occur in the mm subsystem - they go through multiple patch
> postings and review so there's no surprise when the pull request
... and the thread in question has grown from precisely that (and not the first
iteration, either) for earlier such change (RCU symlinks). Subsequent one
(follow_link -> get_link, with RCU symlink traversal for non-embedded
symlinks) also went through fsdevel mailbombs (a couple of iterations, IIRC).
Seriously, when it comes to actual fs-visible behaviour changes (rather than
"please, try and use these helpers instead of open-coding ->i_mutex access"
done exactly to avoid the inter-tree dependencies from hell while that work
is being done) fsdevel will be hit by such mailbomb and probably more than
For now it's really just a reduction of trivial conflicts for the next cycle;
eventually it's going to be a weaker VFS exclusion on ->lookup(). Which had
been loudly demanded quite a few times, and I don't recall any filesystem
developers _ever_ objecting to that.
Speaking of the earlier changes - IIRC, there had been plans to start
hashing (at least some of) XFS symlinks. I think it was from hch, along
the lines of "stash a buffer with symlink body into ->i_link the first time
around, free it from inode eviction". As long as that freeing is RCU-delayed,
doing so would work just fine and give you symlink traversal without dropping
from RCU mode... OTOH, if that gets resurrected, it probably ought to go
through XFS tree - all VFS infrastructure is there (since 4.2), so it's
purely XFS business at this point... One thing to watch out for is that
RCU delay - see shmem.c fix in the same pull request for related example.