Re: xfs_file_splice_read: possible circular locking dependency detected

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

On Fri, Sep 09, 2016 at 07:38:35AM +1000, Dave Chinner wrote:

> It's not an XFS specific problem: any filesystem that supports hole
> punch and it's fallocate() friends needs this high level splice IO
> exclusion as well.

How is hole punch different from truncate()?  My reading of the situation
is that we don't need exclusion between that and insertion into pipe;
only for "gather uptodate page references" part.  If some page gets
evicted afterwards... how is that different from having that happen
right after we'd finished with ->splice_read()?  Am I missing something
subtle in there?

I'm still looking at the O_DIRECT paths in that stuff; we'll probably
need iov_iter_get_pages() for these suckers to allocate pages and stick
them into slots.  The tricky part is to get the semantics of iov_iter_advance()
right for them, but it does look feasible.

Again, what I propose is a new iov_iter flavour.  Backed by pipe_buffer array,
used only for reads (i.e. copy to, not copy from).  Three states for element:
pagecache one, copied data, empty.  Semantics:
	* copy_page_to_iter(): grab a reference to page and stick it into
the next element (making it a pagecache one) with offset and len coming
directly from arguments.
	* copy_to_iter(): if the last element is a 'copied data' with empty
space remaining - copy to the end.  Otherwise allocate a new page and stick
it into the next element (making it 'copied data'), then copy into it.  If 
still not all data copied, do the same for the next element, etc.  Of course,
if there's no elements left, we are done copying.
	* zero_iter(): ditto, with s/copy/fill with zeroes/
	* iov_iter_get_pages(): allocate pages, stick them into the next
slots (making those 'copied data').  That might need some changes, though -
I'm still looking through the users.  The tricky part is decision when to
update the lengths.
	* iov_iter_get_pages_alloc(): not sure, hadn't really looked yet.
	* iov_iter_alignment(): probably just returns 0.
	* iov_iter_advance(): probably like bvec variant.