Message-ID: <2172b7be16ff5b93da967a412ab47834b7444b21.camel@kernel.org>
Subject: Re: [PATCH] NFS: avoid infinite NFS4ERR_OLD_STATEID loops
From:   Trond Myklebust <trondmy@kernel.org>
To:     NeilBrown <neilb@suse.de>, Anna Schumaker <anna@kernel.org>
Cc:     Olga Kornievskaia <aglo@umich.edu>,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Date:   Mon, 13 Feb 2023 21:57:01 -0500
In-Reply-To: <167632902904.1896.16364452992981515041@noble.neil.brown.name>
References: <167632902904.1896.16364452992981515041@noble.neil.brown.name>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT
User-Agent: Evolution 3.46.3 (3.46.3-1.fc37) 
MIME-Version: 1.0
Precedence: bulk

On Tue, 2023-02-14 at 09:57 +1100, NeilBrown wrote:
> 
> Linux-NFS responds to NFS4ERR_OLD_STATEID by simply retrying the
> request, hoping to make use of an updated stateid that might have
> arrived from the server.  This is usually successful.
> 
> However if the client and server get out-of-sync for some reason and
> if
> there is no new stateid to try, this can result in an indefinite loop
> which looks a bit like a DoS attack.
> 
> This can particularly happen when a server replies with success to an
> OPEN request, but fails a subsequent GETATTR.  This has been observed
> with Netapp and Hitachi servers when a concurrent unlink from a
> different client removes the file between the OPEN and the GETATTR. 
> The
> GETATTR returns NFS4ERR_STALE.

Then they are both badly broken servers, and people should complain to
NetApp and Hitachi. We're still not fixing their server bugs in the
Linux client.

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