Re: xfs_file_splice_read: possible circular locking dependency detected

On Wed, Sep 07, 2016 at 09:59:17AM +1000, Dave Chinner wrote:

> Not sure I quite follow - where do the pages come from? Do we
> allocate new pages that get put into the bvec, then run the read
> which copies data from the page cache page into them, then hand
> those pages in the bvec to the pipe?

Nope.  generic_file_read_iter() (do_generic_file_read(), in the end)
finds them in page cache, or allocates and sticks them into pagecache,
makes sure that they are uptodate, etc.   And passes them to
copy_page_to_iter(), which would, for this iov_iter flavour, just grab
a reference to page and stash it into bvec.  There's your zero-copy,
exactly as it works now.  Only __generic_file_splice_read() open-codes
everything ->read_iter() would do, sans the locks filesystem would need.

> This has the same "data copy in the splice read path" as the above
> interface. However, I suspect that this interface could actually be
> used for zero copy (by stealing pages from the page cache rather
> than allocating new pages and copying), so it may be a better way to
> proceed...

For copy_page_to_iter() we have a page; for copy_to_iter() the data comes
from hell knows what - kmalloc'ed array into which we'd decrypted something,
results of sprintf() into on-stack array, etc.  So the counterparts of
copy_to_iter() callers must be non-zerocopy.  copy_page_to_iter() is the
potential zerocopy path and we do get zerocopy there that way.

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs