Re: [PATCH, RFC] xfs: remove i_iolock and use i_rwsem in the VFS inode instead

[Christoph Hellwig <hch@lst.de>]

On Fri, Sep 09, 2016 at 10:44:50AM +0200, Peter Zijlstra wrote:
> Do tell; note however that due to the strict write owner, we can do
> things like the optimistic spinning which improved writer->writer
> performance significantly.
> 
> Also note that !owner locks create problems for RT.

Your clearly missed out on our little Linux-RT conference in June :)

While I basically agree with you there is an important class of problems
that warrant a non-owner release, and that is I/O.  The easiest example
(which also happens to be somewhat relevant for this thread) is the
XFS iolock (or i_rwsem for that matter).  We need to hold this over
file writes, but for direct I/O those always go out to disk.  In the
AIO case there simply is no owner left once control is handed off
to the disk / controller and we'll only be able to unlock once we
get a completion.  Currenrly we work around that using i_dio_count
and a hashed waitqueue, but in many ways that solution is worse than
the problem (and I say that as the person that introduced it!).

We have many many similar issues all over the tree, and people are
"fixing" it using home grown lock primitives like the one above
or using bitlocks (see the recent thread on cross-release semantics
for those).  I think everyone would be better server by accepting
that this case exists and finding a place for it in the framework.
E.g. for RT trying to boost something that is fully under control
of hardware is pointless, but if we have a way to transfer a lock
from an owner to a hardware owned state we could at least boost
until that handoff happened.

None of that is really relevant for this thread though - no cross
release involved in the case that's tripping up lockdep here, just
lock "borrowing" using a synchronous work item.  The real root cause
here is the too small kernel stack that led to this workqueue.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs