Re: RFC: NFSD administrative interface to prevent offering NFSv4 delegation

[Chuck Lever <chuck.lever@oracle.com>]

On 11/9/25 1:57 PM, Benjamin Coddington wrote:
> On 4 Nov 2025, at 10:54, Chuck Lever wrote:
> 
>> NFSD has long had some ability to disable NFSv4 delegation, by disabling
>> fs leases.
>>
>> However it would be nice to have more fine-grained control, for example
>> in cases where read delegation seems to work well but the newer forms
>> of delegation (directory, or attribute) might have bugs or performance
>> problems, and need to be disabled. There are also testing scenarios
>> where a unit test might focus specifically on one type of delegation.
>>
>> A little brainstorming:
>>
>> * Controls would be per net namespace
>> * Allow read delegations, or read and write
>> * Control attribute delegations too? Perhaps yes.
>> * Ignore the OPEN_XOR_DELEG flag? Either that, or mask off the
>>   advertised feature flag.
>> * Change of setting would cause immediate behavior change; no
>>   server restart needed
>> * Control directory delegations too (when they arrive)
>>
>> Is this for NFSD only, or also for local accessors (via the VFS) on the
>> NFS server?
>>
>> Should this be plumbed into NFSD netlink, or into /sys ?
>>
>> Any thoughts/opinions/suggestions are welcome at this point.
> 
> Happy to read this.
> 
> I think this would be most welcomed by the distros - there's been a lot of
> instances of "disable delegations" with the big knob
> /proc/sys/fs/leases-enable
> 
> I'd also like to be able to twiddle these bits for clients as well, and
> lacking a netlink tool to do it for the client the logical place might be
> the client's sysfs interface.

Jeff is working on a system call API that disables delegation on the
client, to write unit tests against. Trond also proposed one, years ago.
On the client you might want to disable delegation per file.


> Would you also look to grain these settings per-client?  The server's
> per-client interface in proc has been fantastic.
> 
> Ben

The issue with per-client control is that, if the client hasn't already
contacted the server, we don't know how to identify that client to
the server administrator. We can't use the client's IP address because
the client could be multi-homed or DHCP-configured.

So, per client, the settings would have to be done every time the client
contacts the server after either one has rebooted (I think).

If we're doing per net-namespace on the server, that becomes easier to
implement and document. Each container instance has its own settings
that apply to all exports from that container.


-- 
Chuck Lever