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
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,
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
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
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
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 a single
pipe_buffer. And that could badly confuse a bunch of code.
Can that