xfs
[Top] [All Lists]

Re: xfs_file_splice_read: possible circular locking dependency detected

To: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
Subject: Re: xfs_file_splice_read: possible circular locking dependency detected
From: Al Viro <viro@xxxxxxxxxxxxxxxxxx>
Date: Wed, 14 Sep 2016 05:26:00 +0100
Cc: Dave Chinner <david@xxxxxxxxxxxxx>, CAI Qian <caiqian@xxxxxxxxxx>, linux-xfs <linux-xfs@xxxxxxxxxxxxxxx>, xfs@xxxxxxxxxxx, Jens Axboe <axboe@xxxxxxxxx>, Nick Piggin <npiggin@xxxxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <CA+55aFznQaOWoSMNphgGJJWZ=8-odrc0DAUMzfGPQe+_N4UgNA@xxxxxxxxxxxxxx>
References: <20160908235521.GL2356@xxxxxxxxxxxxxxxxxx> <20160909015324.GD30056@dastard> <CA+55aFzohsUXj_3BeFNr2t50Wm=G+7toRDEz=Tk7VJqP3n1hXQ@xxxxxxxxxxxxxx> <CA+55aFxrqCng2Qxasc9pyMrKUGFjo==fEaFT1vkH9Lncte3RgQ@xxxxxxxxxxxxxx> <20160909023452.GO2356@xxxxxxxxxxxxxxxxxx> <CA+55aFwHQMjO4-vtfB9-ytc=o+DRo-HXVGckvXLboUxgpwb7_g@xxxxxxxxxxxxxx> <20160909221945.GQ2356@xxxxxxxxxxxxxxxxxx> <CA+55aFzTOOB6oEVaaGD0N7Uznk-W9+ULPwzsxS_L_oZqGVSeLA@xxxxxxxxxxxxxx> <20160914031648.GB2356@xxxxxxxxxxxxxxxxxx> <CA+55aFznQaOWoSMNphgGJJWZ=8-odrc0DAUMzfGPQe+_N4UgNA@xxxxxxxxxxxxxx>
Sender: Al Viro <viro@xxxxxxxxxxxxxxxx>
User-agent: Mutt/1.6.1 (2016-04-27)
On Tue, Sep 13, 2016 at 08:49:58PM -0700, Linus Torvalds wrote:
 
> I'd also like to simplify the splice code if at all possible.

Then pipe_buffer it is; it will take a bit of surgery, but I'd expect
the end result to be much simpler.  OK, so splice_pipe_desc switches
from the pages/partial_pages/ops/spd_release to pipe_bufs, and I'm
actually tempted to replace nr_pages with "the rest of ->pipe_bufs[] has
NULL ->page".  Then it becomes simply
struct splice_pipe_desc {
        struct pipe_buffer *bufs;
        int nbufs;
        unsigned flags;
}, perhaps with struct pipe_buffer _bufs[INLINE_SPLICE_BUFS]; in the end.
struct partial_page simply dies...

Next question: what to do with sanitizing flags in splice(2)/vmsplice(2)/tee(2)?
Right now we accept anything, and quietly ignore everything outside of lower
4 bits.  Should we start masking everything else out and/or warning about
anything unexpected?

        What I definitely want for splice_to_pipe() is an additional flag for
"fail unless there's enough space to copy everything".  Having fuse open-code
splice_to_pipe() with all its guts is just plain wrong.  I'm not saying that
it should be possible to set in splice(2) arguments; it's obviously an ABI
breakage, since currently we ignore all unknown bits.  The question is whether
we mask the unknown bits quietly; doing that with yelling might allow to
make them eventually available.

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