xfs
[Top] [All Lists]

Re: xfs_file_splice_read: possible circular locking dependency detected

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: xfs_file_splice_read: possible circular locking dependency detected
From: Al Viro <viro@xxxxxxxxxxxxxxxxxx>
Date: Thu, 8 Sep 2016 21:35:05 +0100
Cc: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>, CAI Qian <caiqian@xxxxxxxxxx>, linux-xfs <linux-xfs@xxxxxxxxxxxxxxx>, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20160906235917.GO30056@dastard>
References: <723420070.1340881.1472835555274.JavaMail.zimbra@xxxxxxxxxx> <1832555471.1341372.1472835736236.JavaMail.zimbra@xxxxxxxxxx> <20160903003919.GI30056@dastard> <CA+55aFy17iuUYRSLO=e1e+W5oW8GRYy93myk816UjRgEFxQDOw@xxxxxxxxxxxxxx> <20160903014514.GB2356@xxxxxxxxxxxxxxxxxx> <20160906235917.GO30056@dastard>
Sender: Al Viro <viro@xxxxxxxxxxxxxxxx>
User-agent: Mutt/1.6.1 (2016-04-27)
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.

<Prev in Thread] Current Thread [Next in Thread>