Re: [PATCH 1/2] NFSD: Fix duplicate fsnotify access events for iterator READs

On Mon, Aug 24, 2026 at 6:57 AM Christoph Hellwig <[email protected]> wrote:
>
> On Sat, Aug 22, 2026 at 12:21:12PM +0200, 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.
>
> This got me into a little rathole of looking into the other
> do_splice_direct_actor callers.  And I still don't understand why
> taking file_start_write outside the main splice machinery is fine
> for splice_file_range callers, but not for do_splice_direct callers,
> and what consideration exists for potential new callers.

Tough question.
If I can retrace my steps:
The main consideration in the "Tidy up file permission hooks"
work was to move permission hooks outside of sb_start_write()
to avoid "first order deadlocks" from pre-content events (and LSMs),
but I think we also tried best effort to avoid holding
file_start_write(out) while
performing read on file in, to avoid "second order deadlocks" with
weird setups like:
https://lore.kernel.org/linux-fsdevel/5lz5jq7gzoejbywmh56ayfkdiuqsjd2s5pl5uvlflfxc5lq4rr@thr4hrkw67d2/

For the first order deadlocks, both flavors are fine:
1. permission + file_start_write() in ceph_copy_file_range() +
    splice_file_range()
2. permission + do_splice_direct() in vfs_copy_file_range()

->copy_file_range() are called from vfs_copy_file_range() with
file_start_write() held so ceph_copy_file_range() needs to use
the first flavor.

But at least it's holding file_start_write() on ceph fs while reading
a file from cephfs (maybe not the same sb though).

The use cases of do_splice_direct() from ovl copy up
nfsd/ksmbd copy_file_range (*) have more potential of hitting the
second order deadlocks, so they try to avoid them with more
granular file_start_write().

TBH, I don't think that we proved to what extent this helps avoid
the second order deadlocks because obviously, those deadlocks
are still possible.

(*) In the past copy_file_range(2) across different fs was also
a use case, but we stopped supporting that use case.

Anyway, there could definitely be other reasons for the
do_splice_direct/splice_file_range split which I do not remember,
but hey, at least the kerneldoc for these helpers is pretty clear...

Thanks,
Amir.