Re: [PATCH 1/2] NFSD: Fix duplicate fsnotify access events for iterator READs
"Chuck Lever" <[email protected]>
| Newsgroups | org.kernel.vger.linux-nfs,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
On Sat, Aug 22, 2026, at 6:21 AM, Amir Goldstein wrote: > (1) In this series > https://lore.kernel.org/linux-fsdevel/[email protected]/ > we intentionally moved the permission hook outside > of the splice iterators because we wanted to avoid calling them > with freeze protection held and also there were some duplicate calls > for this work. > > At this point in time, the fsnotify_{access,modify} post hooks are > usually called > from the same context as the matching permission/security hooks. > It doesn't have to be this way, but it's a good mental model IMO. > > (2) emitting many READ events from an iterator instead of one event for > the user's READ request is more noisy and serves no purpose to users. > In most cases (but not always) those events could be merged, but at the > cost of futile CPU cycles. > > From a quick inspection of the code, it looks like: > - fsnotify_access() is missing in vfs_splice_read() > - the naming convention for splice_ do_splice_ vfs_splice_ is a horror > - we could make the low level splice_direct_to_actor() static and possibly > rename it to splice_direct_to_actor_sd() or something > - we could export vfs_splice_direct_to_actor() for nfsd which wraps > splice_direct_to_actor() with permission hook and fsnotify_access IIUC this last bullet seems like clean layering to me. Do you want to propose a patch or shall I? -- Chuck Lever