On Mon, 2 May 2022 00:01:46 -0700 Andrei Vagin <avagin@xxxxxxxxx> 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.
