Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
From:   "NeilBrown" <neilb@suse.de>
To:     "Trond Myklebust" <trondmy@kernel.org>
Cc:     "Anna Schumaker" <anna@kernel.org>,
        "Olga Kornievskaia" <aglo@umich.edu>,
        "Linux NFS Mailing List" <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH] NFS: avoid infinite NFS4ERR_OLD_STATEID loops
In-reply-to: <2172b7be16ff5b93da967a412ab47834b7444b21.camel@kernel.org>
References: <167632902904.1896.16364452992981515041@noble.neil.brown.name>,
 <2172b7be16ff5b93da967a412ab47834b7444b21.camel@kernel.org>
Date:   Tue, 14 Feb 2023 14:07:23 +1100
Message-id: <167634404344.1896.17506326638015125882@noble.neil.brown.name>
Precedence: bulk

On Tue, 14 Feb 2023, Trond Myklebust wrote:
> 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.

It's not about fixing a server bug.  It is defensive programming.  We
shouldn't let a buggy server cause a melt-down.

> 
> NACK...

Oh well, I tried.

Thanks,
NeilBrown


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