Re: [PATCH 1/2] NFSD: Fix duplicate fsnotify access events for iterator READs
From: Amir Goldstein
Date: Sat Aug 22 2026 - 06:21:41 EST
On Wed, Aug 19, 2026 at 4:04 PM Chuck Lever <cel@xxxxxxxxxx> wrote:
>
>
>
> On Wed, Aug 19, 2026, at 2:02 AM, Christoph Hellwig wrote:
> > Well, that is the underlying bug here. ->splice_read should not
> > skip fsnotify events and nfsd should not work around this as
> > fsnotify is not the business of the users of VFS APIs.
>
> I asked for the duplicate event to be split out of Ameer's larger
> series as a backportable fix because there is clearly a bug here.
> But NFSD might not be the correct place to address it.
>
> Today the fsnotify event comes from the system call implementations,
> not from the splice helpers. do_sendfile() calls fsnotify_access()
> once do_splice_direct() returns, and do_splice() does the same for
> splice(2), while vfs_splice_read() and splice_direct_to_actor()
> emit nothing. vfs_iocb_iter_read() is the outlier, emitting from
> inside the helper.
>
> NFSD calls splice_direct_to_actor() directly, so on that path it
> acts like do_sendfile() and emits the event itself. That is why
> the fsnotify event counts differ between NFSD's two read paths.
> Moving the fsnotify call site down into ->splice_read would double
> up sendfile events unless the system call implementations stop
> emitting it at the same time.
>
> Jan, Amir, what are your thoughts?
>
Here are some thoughts and points for consideration.
(1) In this series
https://lore.kernel.org/linux-fsdevel/20231122122715.2561213-1-amir73il@xxxxxxxxx/
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
Whether or not this is prettier than nfsd adding the fsnotify hooks
is a matter of taste, but I can live with either.
Thanks,
Amir.