Re: [git pull] vfs.git - including i_mutex wrappers

[Al Viro <viro@ZenIV.linux.org.uk>]

On Sun, Jan 24, 2016 at 11:53:04AM +1100, Dave Chinner wrote:
> > readdir() is another potential target for weaker exclusion (i.e. switching
> > it to taking that thing shared), but that's a separate story and I'd prefer
> > to deal with ->lookup() first.  There are potentially hairy issues around
> > the instances that pre-seed dcache and I don't want to mix them into the
> > initial series.
> 
> So you're doing this for purely to enable lookup concurrency, not
> for anyone else to be able to use the inode lock as a read/write
> lock? Can anyone use the inode rwsem as a read/write lock for their
> own purposes? If so, we can probably use it to replace the XFS
> IOLOCK and so effectively remove a layer of locking in various
> XFS IO paths. What's the policy you are proposing here?

Depends...  I definitely want to keep directory modifiers with that thing
taken exclusive, with lookup and possibly readdir - shared.  Non-directories...
it's mostly up to filesystems; the only place where VFS cares is setattr
and {set,remove}xattr, and that probably should stay exclusive (or be
separated, for that matter, but I hadn't looked into implications of that;
we probably can do that, but there might be dragons).

For data operations on regular files it's probably up to filesystems, as
i_mutex is now.  Not sure if IOLOCK would map well on that; can you live with
that thing taken outside of transaction?