Messages in this thread | | | Date | Sun, 24 Jan 2016 01:20:02 +0000 | From | Al Viro <> | Subject | Re: [git pull] vfs.git - including i_mutex wrappers |
| |
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 > comes.
... 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 once.
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.
| |