Re: xfs_file_splice_read: possible circular locking dependency detected

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux