Re: [PATCH v3] NFSD: Implement NFSD_IO_DIRECT for NFS WRITE

[Chuck Lever <cel@kernel.org>]

On 10/17/25 5:03 PM, Mike Snitzer wrote:
> On Fri, Oct 17, 2025 at 10:13:14AM -0400, Chuck Lever wrote:
>> On 10/15/25 6:13 PM, Mike Snitzer wrote:

>>> +	*cnt = 0;
>>> +	for (int i = 0; i < n_iters; i++) {
>>> +		if (iter_is_dio_aligned[i])
>>> +			kiocb->ki_flags |= IOCB_DIRECT;
>>> +		else
>>> +			kiocb->ki_flags &= ~IOCB_DIRECT;
>>> +
>>> +		host_err = vfs_iocb_iter_write(file, kiocb, &iter[i]);
>>> +		if (host_err < 0) {
>>> +			/*
>>> +			 * VFS will return -ENOTBLK if DIO WRITE fails to
>>> +			 * invalidate the page cache. Retry using buffered IO.
>>> +			 */
>>
>> I'm debating with myself whether, now that NFSD is using DIO, nfserrno
>> should get a mapping from ENOTBLK to nfserr_serverfault or nfserr_io,
>> simply as a defensive measure.
>>
>> I kind of like the idea that we get a warning in nfserrno: "hey, I
>> didn't expect ENOTBLK here" so I'm leaning towards leaving it as is
>> for now.
> 
> While ENOTBLK isn't expected, it is a real possibility from the MM
> subsystem's inability invalidate the page cache ("for reasons").
> 
> So it isn't that NFSD would've done anything wrong.. it just needs to
> deal with the possibility (as should any other DIO write in kernel).
Well my point is that if the MM/VFS can return this on a buffered write,
should NFSD be prepared to deal with it in other places besides this
path? I think it's handling ENOTBLK correctly here. Just wondering about
elsewhere.

This is something we can set aside and worry about after merge. It
actually has more to do with the existing parts of NFSD, not the new
direct write code path.

I'll repost the "stable_how" patch and this one together in a new
series, for Christoph, and pull that series into nfsd-testing.


-- 
Chuck Lever