Fixed the issue for me.
Tested-by: Dmitry Vyukov <dvyukov@xxxxxxxxxx>
Thanks for quick fixes!
On Mon, Nov 23, 2015 at 1:09 PM, Jan Kara <jack@xxxxxxx> wrote:
> Commit 296291cdd162 (mm: make sendfile(2) killable) fixed an issue where
> sendfile(2) was doing a lot of tiny writes into a filesystem and thus
> was unkillable for a long time. However sendfile(2) can be (mis)used to
> issue lots of writes into arbitrary file descriptor such as evenfd or
> similar special file descriptors which never hit the standard filesystem
> write path and thus are still unkillable. E.g. the following example
> from Dmitry burns CPU for ~16s on my test system without possibility to
> be killed:
>
> int r1 = eventfd(0, 0);
> int r2 = memfd_create("", 0);
> unsigned long n = 1<<30;
> fallocate(r2, 0, 0, n);
> sendfile(r1, r2, 0, n);
>
> There are actually quite a few tests for pending signals in sendfile
> code however we data to write is always available none of them seems to
> trigger. So fix the problem by adding a test for pending signal into
> splice_from_pipe_next() also before the loop waiting for pipe buffers to
> be available. This should fix all the lockup issues with sendfile of the
> do-ton-of-tiny-writes nature.
>
> CC: stable@xxxxxxxxxxxxxxx
> Reported-by: Dmitry Vyukov <dvyukov@xxxxxxxxxx>
> Signed-off-by: Jan Kara <jack@xxxxxxx>
> ---
> fs/splice.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/fs/splice.c b/fs/splice.c
> index 801c21cd77fe..22adbbe51e52 100644
> --- a/fs/splice.c
> +++ b/fs/splice.c
> @@ -809,6 +809,13 @@ static int splice_from_pipe_feed(struct pipe_inode_info *pipe, struct splice_des
> */
> static int splice_from_pipe_next(struct pipe_inode_info *pipe, struct splice_desc *sd)
> {
> + /*
> + * Check for signal early to make process killable when there are
> + * always buffers available
> + */
> + if (signal_pending(current))
> + return -ERESTARTSYS;
> +
> while (!pipe->nrbufs) {
> if (!pipe->writers)
> return 0;
> --
> 2.1.4
>
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html