RFC: NFSD administrative interface to prevent offering NFSv4 delegation

RFC: NFSD administrative interface to prevent offering NFSv4 delegation

[Chuck Lever]

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.


-- 
Chuck Lever

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

[Benjamin Coddington]

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.

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

Ben

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

[Chuck Lever]

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

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

[Jeff Layton]

On Sun, 2025-11-09 at 15:47 -0500, Chuck Lever wrote:
> 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?
> > > 

I agree with all of the above bullet points. I think we should just
implement the more fine-grained controls for nfsd (at least initially).
OPEN_XOR_DELEG and attribute delegs don't have any relevance at the VFS
layer, so if we want to control all of these then it makes more sense
to do it in nfsd.

We could consider adding more fine-grained VFS layer controls later if
that's needed though.

> > > 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.
> 

Not exactly. I'm just adding fcntl() commands that allow you to set/get
delegations from userland:

https://lore.kernel.org/linux-nfs/20251105-dir-deleg-ro-v5-17-7ebc168a88ac@kernel.org/T/#u

The main reason I wanted these was for testing purposes (so we can
ensure that later VFS changes don't subtly break delegations).

> 
> > 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.
> 

Agreed. I don't think we can reasonably do this on a per-client basis,
because we don't have any stable long-term persistent record of clients
on the server. If the client disappears for a while, the server will
just forget about it.
-- 
Jeff Layton <jlayton@kernel.org>