xfs
[Top] [All Lists]

Re: [PATCH 04/12] splice: lift pipe_lock out of splice_to_pipe()

To: Al Viro <viro@xxxxxxxxxxxxxxxxxx>
Subject: Re: [PATCH 04/12] splice: lift pipe_lock out of splice_to_pipe()
From: Miklos Szeredi <miklos@xxxxxxxxxx>
Date: Mon, 26 Sep 2016 15:35:12 +0200
Cc: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>, Dave Chinner <david@xxxxxxxxxxxxx>, CAI Qian <caiqian@xxxxxxxxxx>, linux-xfs <linux-xfs@xxxxxxxxxxxxxxx>, xfs@xxxxxxxxxxx, Jens Axboe <axboe@xxxxxxxxx>, Nick Piggin <npiggin@xxxxxxxxx>, linux-fsdevel <linux-fsdevel@xxxxxxxxxxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=szeredi.hu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uWT8kK1YRghNlCneGJ/jhuFznh/La4c2JINFpdhCnHo=; b=LvWQ8W4CEFjyDdMEyyWFegcj/4CLX5MAcvyVUUKsEHaM3xDiKE0O5NAOnAeCR5EidD QxaGjtbk5TYyl2MNhb0OG/YL6C8Ekia6GaHPdQCyH6SsojvaWT1vzEB1LAti9b/slNu+ FJEvzLMOF0/ePv3rvxKuGJA9OHGyyfFYVtfOQ=
In-reply-to: <20160924035951.GN2356@xxxxxxxxxxxxxxxxxx>
References: <20160914031648.GB2356@xxxxxxxxxxxxxxxxxx> <CA+55aFznQaOWoSMNphgGJJWZ=8-odrc0DAUMzfGPQe+_N4UgNA@xxxxxxxxxxxxxx> <20160914042559.GC2356@xxxxxxxxxxxxxxxxxx> <20160917082007.GA6489@xxxxxxxxxxxxxxxxxx> <20160917190023.GA8039@xxxxxxxxxxxxxxxxxx> <20160923190032.GA25771@xxxxxxxxxxxxxxxxxx> <20160923190326.GB2356@xxxxxxxxxxxxxxxxxx> <CA+55aFxzPH2AYvDVWSAomO6bN_sW4+qDv87Xbq8XHMyvBEYe+w@xxxxxxxxxxxxxx> <20160923201025.GJ2356@xxxxxxxxxxxxxxxxxx> <CA+55aFyr-X_6FcWkSXBUcxV0p1BUZw8d=46wawv2x+8y7f8YcQ@xxxxxxxxxxxxxx> <20160924035951.GN2356@xxxxxxxxxxxxxxxxxx>
On Sat, Sep 24, 2016 at 5:59 AM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
> * splice_to_pipe() stops at pipe overflow and does *not* take pipe_lock
> * ->splice_read() instances do the same
> * vmsplice_to_pipe() and do_splice() (ultimate callers of splice_to_pipe())
>   arrange for waiting, looping, etc. themselves.
>
> That should make pipe_lock the outermost one.
>
> Unfortunately, existing rules for the amount passed by vmsplice_to_pipe()
> and do_splice() are quite ugly _and_ userland code can be easily broken
> by changing those.  It's not even "no more than the maximal capacity of
> this pipe" - it's "once we'd fed pipe->nr_buffers pages into the pipe,
> leave instead of waiting".
>
> Considering how poorly these rules are documented, let's try "wait for some
> space to appear, unless given SPLICE_F_NONBLOCK, then push into pipe
> and if we run into overflow, we are done".
>
> Signed-off-by: Al Viro <viro@xxxxxxxxxxxxxxxxxx>
> ---
>  fs/fuse/dev.c |   2 -
>  fs/splice.c   | 138 
> +++++++++++++++++++++++++++-------------------------------
>  2 files changed, 63 insertions(+), 77 deletions(-)
>

[...]

> @@ -1546,14 +1528,20 @@ static long vmsplice_to_pipe(struct file *file, const 
> struct iovec __user *uiov,
>                 return -ENOMEM;
>         }
>
> -       spd.nr_pages = get_iovec_page_array(&from, spd.pages,
> -                                           spd.partial,
> -                                           spd.nr_pages_max);
> -       if (spd.nr_pages <= 0)
> -               ret = spd.nr_pages;
> -       else
> -               ret = splice_to_pipe(pipe, &spd);
> -
> +       pipe_lock(pipe);
> +       ret = wait_for_space(pipe, flags);
> +       if (!ret) {
> +               spd.nr_pages = get_iovec_page_array(&from, spd.pages,
> +                                                   spd.partial,
> +                                                   spd.nr_pages_max);
> +               if (spd.nr_pages <= 0)
> +                       ret = spd.nr_pages;
> +               else
> +                       ret = splice_to_pipe(pipe, &spd);
> +               pipe_unlock(pipe);
> +               if (ret > 0)
> +                       wakeup_pipe_readers(pipe);
> +       }

Unbalanced pipe_lock()?

Also, while it doesn't hurt, the constification of the "from" argument
of get_iovec_page_array() looks only noise in this patch.

Thanks,
Miklos

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