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:
signature.asc
Description: PGP signature
