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-kernel |
|---|---|
| Message-ID | <[email protected]> |
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? -- Chuck Lever