Re: PATCH [v3 0/2] NFSD: use CB_GETATTR to handle GETATTR conflict with write delegation

[Trond Myklebust <trondmy@hammerspace.com>]

On Sat, 2024-02-17 at 00:34 +0100, Dan Shelton wrote:
> On Thu, 15 Feb 2024 at 23:11, Dai Ngo <dai.ngo@oracle.com> wrote:
> > 
> > Currently GETATTR conflict with a write delegation is handled by
> > recalling the delegation before replying to the GETATTR.
> > 
> > This patch series add supports for CB_GETATTR callback to get the
> > latest
> > change_info and size information of the file from the client that
> > holds
> > the delegation to reply to the GETATTR from the second client.
> > 
> > NOTE: this patch series is mostly the same as the previous patches
> > which
> > were backed out when un unrelated problem of NFSD server hang on
> > reboot
> > was reported.
> > 
> > The only difference is the wait_on_bit() in
> > nfsd4_deleg_getattr_conflict was
> > replaced with wait_on_bit_timeout() with 30ms timeout to avoid a
> > potential
> > DOS attack by exhausting NFSD kernel threads with GETATTR
> > conflicts.
> 
> I have a concern about this static and very tiny timeout.
> What will happen if the ICMPv6 latency is well over 30ms, like 660ms
> (average 250mbit/s satellite latency)?
> 
> Would that not ruin delegations?

That's a very valid point, not least because clients do not optimise
for back channel RPC calls, and because the consequences of a timeout
would be either to recall the delegation or to fence the client. The
former just makes a bad back channel situation worse. The latter just
interrupts I/O for no good reason
.

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com