Re: skb_splice_bits() and large chunks in pipe (was Re: xfs_file_splice_read: possible circular locking dependency detected

Al Viro wrote: > >* shoved into scatterlist, which gets fed into crypto/*.c machinery. > No way for a pipe_buffer stuff to get there, fortunately, because I would > be very surprised if it works correctly with compound pages and large > ranges in those. FWIW the

Re: skb_splice_bits() and large chunks in pipe (was Re: xfs_file_splice_read: possible circular locking dependency detected

On Sun, Sep 18, 2016 at 11:31:17PM +0100, Al Viro wrote: > At the moment there are 11 callers (10 in mainline; one more added in > conversion of vmsplice_to_pipe() to new pipe locking, but it's irrelevant > anyway - it gets fed an iovec-backed iov_iter). I'm looking through those > right now,

Re: skb_splice_bits() and large chunks in pipe (was Re: xfs_file_splice_read: possible circular locking dependency detected

On Sun, Sep 18, 2016 at 3:31 PM, Al Viro wrote: > > What worries me is iov_iter_get_pages() and friends. So honestly, if it worries you, I'm not going to complain at all if you decide that you'd rather translate the pipe_buffer[] array into a kvec by always splitting at

Re: skb_splice_bits() and large chunks in pipe (was Re: xfs_file_splice_read: possible circular locking dependency detected

On Sun, Sep 18, 2016 at 01:12:21PM -0700, Linus Torvalds wrote: > So if the splice code ends up being confused by "this is not just > inside a single page", then the splice code is buggy, I think. > > Why would splice_write() cases be confused anyway? A filesystem needs > to be able to handle

Re: skb_splice_bits() and large chunks in pipe (was Re: xfs_file_splice_read: possible circular locking dependency detected

On Sun, Sep 18, 2016 at 12:31 PM, Al Viro wrote: > FWIW, I'm not sure if skb_splice_bits() can't land us in trouble; fragments > might come from compound pages and I'm not entirely convinced that we won't > end up with coalesced fragments putting more than PAGE_SIZE into