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? Dan -- Dan Shelton - Cluster Specialist Win/Lin/Bsd
