Received-SPF: pass (google.com: domain of linux-nfs+bounces-1999-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Precedence: bulk
MIME-Version: 1.0
References: <1708034722-15329-1-git-send-email-dai.ngo@oracle.com>
In-Reply-To: <1708034722-15329-1-git-send-email-dai.ngo@oracle.com>
From: Dan Shelton <dan.f.shelton@gmail.com>
Date: Sat, 17 Feb 2024 00:34:45 +0100
Message-ID: <CAAvCNcDDb4L2tcbBCcufFg=TLeFSrui4MHFuEeNUA+1VZyXLxQ@mail.gmail.com>
Subject: Re: PATCH [v3 0/2] NFSD: use CB_GETATTR to handle GETATTR conflict
 with write delegation
To: linux-nfs@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"

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?

Dan
-- 
Dan Shelton - Cluster Specialist Win/Lin/Bsd