xfs_file_splice_read: possible circular locking dependency detected

[Linus Torvalds]

On Fri, Sep 9, 2016 at 3:19 PM, Al Viro <viro at zeniv.linux.org.uk> wrote:
>
> Cooking it...  The thing I really hate about the use of pipe_buffer is that
> we want to keep the "use on-stack array for default pipe size" trick, and
> pipe_buffer is fatter than I'd like.  Instead of pointer + two numbers +
> something to indicate whether it's picked from page cache or something we'd
> allocated we get get pointer + int + int + pointer + int + long, which turns
> into 5 words on 64bit.  With 16-element array of those on stack frame, it's
> not nice - more than half kilobyte of stack space with ->read_iter() yet to
> be called...  bvec would be better (60% savings boils down to 384 bytes
> shaved off that thing), but we'd need to play games with encoding the "is
> it page cache or not" bit somewhere in it.

No, please don't play games like that.

I think you'd be better off with just a really small on-stack case
(like maybe 2-3 entries), and just allocate anything bigger
dynamically. Or you could even see how bad it is if you just
force-limit it to max 4 entries or something like that and just do
partial writes.

>From when I looked at things (admittedly a *long* time ago), the
buffer sizes for things like read/write system calls were *very*
skewed.

There's a lot of small stuff, then there is the stuff that actually
honors st.st_blksize (normally one page), and then there is the big
buffers stuff.

And the thing is, the big buffers are almost never worth it. It's
often better to have a tight loop over smaller data than bouncing lots
of data into buffers and then out of buffers.

So I suspect all the "let's do many pages in one go" stuff is actually
not worth it. Especially since the pipes will basically force a wait
event when the pipe buffers fill up anyway.

So feel free to try maxing out using only a small handful of
pipe_buffer entries. Returning partial IO from splice() is fine.

                   Linus