On Sat, 2024-02-17 at 00:34 +0100, Dan Shelton wrote: > On Thu, 15 Feb 2024 at 23:11, Dai Ngo <dai.ngo@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx
