[PATCH v5 0/3] fanotify accounting for fs/splice.c

["Ahelenia Ziemiańska" <nabijaczleweli@nabijaczleweli.xyz>]

[-- Attachment #1: Type: text/plain, Size: 1747 bytes --]

Previously: https://lore.kernel.org/linux-fsdevel/jbyihkyk5dtaohdwjyivambb2gffyjs3dodpofafnkkunxq7bu@jngkdxx65pux/t/#u

In short:
  * most read/write APIs generate ACCESS/MODIFY for the read/written file(s)
  * except the [vm]splice/tee family
    (actually, since 6.4, splice itself /does/ generate events but only
     for the non-pipes being spliced from/to; this commit is Fixes:ed)
  * userspace that registers (i|fa)notify on pipes usually relies on it
    actually working (coreutils tail -f is the primo example)
  * it's sub-optimal when someone with a magic syscall can fill up a
    pipe simultaneously ensuring it will never get serviced

Thus: actually generate ACCESS/MODIFY for all the
[vm]spliced/teed-from/to files.

LTP tests are staged in
  https://git.sr.ht/~nabijaczleweli/ltp/commit/v4
("inotify13: new test for fs/splice.c functions vs pipes vs inotify"),
validating that one A and/or one M event per [vm]splice(), tee(),
and sendfile() is generated ‒
without this patchset, this only holds for sendfile().

Amir has identified a potential performance impact caused by
correctly generating events, and has prepared patches at
  https://github.com/amir73il/linux/commits/fsnotify_pipe
that optimise the most common cases more aggressively.

Please review, and please consider taking these through the vfs
tree for 6.6.

Thanks,
Ahelenia Ziemiańska (3):
  splice: always fsnotify_access(in), fsnotify_modify(out) on success
  splice: fsnotify_access(fd)/fsnotify_modify(fd) in vmsplice
  splice: fsnotify_access(in), fsnotify_modify(out) on success in tee

 fs/splice.c | 43 +++++++++++++++++++++++++------------------
 1 file changed, 25 insertions(+), 18 deletions(-)

-- 
2.39.2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]