Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
Date:   Sat, 7 May 2022 14:52:24 -0700
From:   Andrew Morton <akpm@linux-foundation.org>
To:     Andrei Vagin <avagin@gmail.com>
Cc:     LKML <linux-kernel@vger.kernel.org>,
        linux-fsdevel <linux-fsdevel@vger.kernel.org>, stable@kernel.org,
        Alexander Viro <viro@zeniv.linux.org.uk>
Subject: Re: [PATCH] fs: sendfile handles O_NONBLOCK of out_fd
Message-Id: <20220507145224.a9b6555969d6e66586b6514c@linux-foundation.org>
In-Reply-To: <CANaxB-wcf0Py9eCeA8YKcBSnwzW6pKAD5edCDUadebmo=JLYhA@mail.gmail.com>
References: <20220415005015.525191-1-avagin@gmail.com>
        <CANaxB-wcf0Py9eCeA8YKcBSnwzW6pKAD5edCDUadebmo=JLYhA@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Mon, 2 May 2022 00:01:46 -0700 Andrei Vagin <avagin@gmail.com> wrote:

> Andrew, could you take a look at this patch?
> 
> Here is a small reproducer for the problem:
> 
> #define _GNU_SOURCE /* See feature_test_macros(7) */
> #include <fcntl.h>
> #include <stdio.h>
> #include <unistd.h>
> #include <errno.h>
> #include <sys/stat.h>
> #include <sys/types.h>
> #include <sys/sendfile.h>
> 
> 
> #define FILE_SIZE (1UL << 30)
> int main(int argc, char **argv) {
>         int p[2], fd;
> 
>         if (pipe2(p, O_NONBLOCK))
>                 return 1;
> 
>         fd = open(argv[1], O_RDWR | O_TMPFILE, 0666);
>         if (fd < 0)
>                 return 1;
>         ftruncate(fd, FILE_SIZE);
> 
>         if (sendfile(p[1], fd, 0, FILE_SIZE) == -1) {
>                 fprintf(stderr, "FAIL\n");
>         }
>         if (sendfile(p[1], fd, 0, FILE_SIZE) != -1 || errno != EAGAIN) {
>                 fprintf(stderr, "FAIL\n");
>         }
>         return 0;
> }
> 
> It worked before b964bf53e540, it is stuck after b964bf53e540, and it
> works again with this fix.

Thanks.  How did b964bf53e540 cause this?  do_splice_direct()
accidentally does the right thing even when SPLICE_F_NONBLOCK was not
passed?

I assume that Al will get to this.  Meanwhile I can toss it
into linux-next to get some exposure and so it won't be lost.