Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <CAOQ4uxj_DLm8_stRJPR7i8bp9aJ5VtjzWqHL2egCTKe3M-6KSw@mail.gmail.com>
 <pw3ljisf6ctpku2o44bdy3aaqdt4ofnedrdt4a4qylhasxsli6@wxhy3nsjcwn4>
In-Reply-To: <pw3ljisf6ctpku2o44bdy3aaqdt4ofnedrdt4a4qylhasxsli6@wxhy3nsjcwn4>
From:   Amir Goldstein <amir73il@gmail.com>
Date:   Tue, 27 Jun 2023 09:14:21 +0300
Message-ID: <CAOQ4uxh7i_s4R9pFJPENALdWGG5-dDhqPLEUXuJqSoHraktFiA@mail.gmail.com>
Subject: Re: [PATCH v2 0/3] fanotify accounting for fs/splice.c
To:     =?UTF-8?B?0L3QsNCx?= <nabijaczleweli@nabijaczleweli.xyz>
Cc:     Alexander Viro <viro@zeniv.linux.org.uk>,
        Christian Brauner <brauner@kernel.org>,
        linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
        Jan Kara <jack@suse.cz>,
        Chung-Chiang Cheng <cccheng@synology.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Tue, Jun 27, 2023 at 2:08=E2=80=AFAM =D0=BD=D0=B0=D0=B1 <nabijaczleweli@=
nabijaczleweli.xyz> wrote:
>
> "people just forget to add inotify hooks to their I/O routines as a rule"=
?
> Guess what I did, fully knowing that some are missing in this file :)
>
> =3D=3D> te.c <=3D=3D
> #define _GNU_SOURCE
> #include <fcntl.h>
> #include <stdio.h>
> int main() {
>   ssize_t rd, acc =3D 0;
>   while ((rd =3D tee(0, 1, 128 * 1024 * 1024, 0)) > 0)
>     acc +=3D rd;
>   fprintf(stderr, "te=3D%zd: %m\n", acc);
> }
>
> =3D=3D> vm.c <=3D=3D
> #define _GNU_SOURCE
> #include <fcntl.h>
> #include <stdio.h>
> #include <string.h>
> static char sb[1024 * 1024];
> int main() {
>   memcpy(sb, "=C5=BCupan", sizeof("=C5=BCupan"));
>   ssize_t rd =3D
>       vmsplice(1, &(struct iovec){.iov_base =3D sb, .iov_len =3D sizeof(s=
b)}, 1,
>                SPLICE_F_GIFT);
>   fprintf(stderr, "vm=3D%zd: %m\n", rd);
> }
>
>
> echo zupa | ./te > fifo tees a few times and then blocks when the pipe
> fills, at which point we get into the broken state.
>
> Similarly, ./vm > fifo (with the default 64k F_GETPIPE_SZ) enters that
> same state instantly.
>
> With 2/3 and 3/3, they instead do
>   1: mask=3D2, cook=3D0, len=3D0, name=3D
>   rd=3D80
>   1: mask=3D2, cook=3D0, len=3D0, name=3D
>   rd=3D80
>   ...
> in a loop, as-expected, and
>   # ./vm > fifo
>   vm=3D65200: Success
>   1: mask=3D2, cook=3D0, len=3D0, name=3D
>   rd=3D65200
>
> I took the liberty of marking 2/3 and 3/3 as Fixes: of the original
> fanotify-in-splice commit as well, I think they fit the bill.
>

Thank you for doing this thorough research on all the variants!

It would be great if you could add test coverage for these syscalls.

Simplest would be to clone an LTP inotify test, e.g.
ltp/testcases/kernel/syscalls/inotify/inotify01

for the different splice syscall variants (sendfile as well).

LTP already has other tests for all those syscalls, so there are plenty
of examples of how to use the LTP helpers to test those syscalls.

You can either clone one inotify test per syscall, or clone one inotify
test that creates a fifo instead of a file that inotify watches
and use a test cases array for the different syscalls to test
(see example of test cases array in inotify10 test).

Thanks,
Amir.