Re: xfs_file_splice_read: possible circular locking dependency detected

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

On Sat, Sep 17, 2016 at 09:20:07AM +0100, Al Viro wrote:

> 5) that iov_iter flavour is backed by pipe.  {__,}generic_file_splice_read()
> is gone - we simply set an iov_iter over our locked pipe and pass it to
> ->read_iter().  That serves as ->splice_read() where generic_file_splice_read()
> used to be used, as well as nfs/ocfs2/gfs2/shmem instances.

6) The same happens to coda and lustre instances, taking a bunch of crud out
in case of lustre (IO_SPLICE handling parallel to IO_NORMAL and
->vui_io_subtype in general).  Moreover, skb_splice_bits() becomes very
similar to skb_copy_datagram_iter(), possibly allowing to replace at least
AF_UNIX ->splice_read() with the same generic ->read_iter()-based one - or
doing the same to _all_ socket ones.  Even more interesting is that
fuse_dev_splice_read() just might become replacable with that, at the price
of some massage (and simplifications) of fuse_copy_page().  If _that_ works
out, we are in a situation where that thing is universal for everything
that has ->read_iter() in the first place.  Most of the stuff that has
only ->read() uses default_file_splice_read(); the only irregular instances
left are kernel/relay.c and kernel/trace/trace.c ones.  Incidentally, these
irregulars are precisely the ones that make use of buf->private.