Re: [PATCH 1/2] NFSD: Use nfsd_iter_read() when ->splice_read is not zero-copy

On Wed, Aug 19, 2026 at 08:54:11AM +1000, NeilBrown wrote:
> On Tue, 18 Aug 2026, Ameer Hamza wrote:
> > For some files splicing a READ cannot avoid a copy: gfs2, kernfs
> > and the cifs direct-I/O modes use copy_splice_read() as their
> > ->splice_read, and the VFS substitutes it for DAX files.
> > copy_splice_read() allocates a fresh page for every page of
> > payload and reads into it; nfsd_splice_actor() then installs
> > those pages in rq_respages, displacing Reply pages the thread
> > already owns. Both sets of pages are then freed.
> > 
> > Route these READs through nfsd_iter_read() instead. It performs
> > the same single copy, but into the thread's own Reply pages, so
> > the per-READ allocation and the displacement both disappear. On
> > its own this is not expected to raise throughput; it changes
> > which pages a Reply is built from so that the next patch can
> > recycle them.
> > 
> > 9p and ceph fall back to copy_splice_read() only inside their
> > own ->splice_read methods, which nfsd_splice_read_is_zero_copy()
> > cannot detect,
> 
> I think that if we are going to do this then we should do it properly
> and make it easy to detect these cases.
> 
> Could we add an FMODE flags FMODE_DONT_COPY_FOR_SPLICE which causes
> copy_splice_read() to return -ENOTSUP or similar.
> Then nfsd can call splice_read if it appear to exist, but set that flag.
> If it fails with -ENOTSUP, fall back to iter_read.
> 
> I really don't like the approach of explicitly testing whether
> f_op->splice_read is a particular value.

Thanks, this indeed works better. I believe it also covers 9p and
ceph falling back to copy_splice_read() internally, which the
helper could not see. I will work it out this way for v2.