Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <210f08ae5f0ba47c289293981f490fca848dd2ed.camel@kernel.org>
Subject: Re: [PATCH] NFS: Handle missing attributes in OPEN reply
From:   Trond Myklebust <trondmy@kernel.org>
To:     NeilBrown <neilb@suse.de>
Cc:     Trond Myklebust <trondmy@hammerspace.com>,
        Anna Schumaker <anna@kernel.org>,
        Olga Kornievskaia <aglo@umich.edu>,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Date:   Tue, 03 Jan 2023 20:15:36 -0500
In-Reply-To: <167279409373.13974.16504090316814568327@noble.neil.brown.name>
References: <167279203612.13974.15063003557908413815@noble.neil.brown.name>
        , <7a98c3e70bae70c44418ce8ac4b84f387b4ff850.camel@kernel.org>
         <167279409373.13974.16504090316814568327@noble.neil.brown.name>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT
User-Agent: Evolution 3.46.2 (3.46.2-1.fc37) 
MIME-Version: 1.0
Precedence: bulk

On Wed, 2023-01-04 at 12:01 +1100, NeilBrown wrote:
> On Wed, 04 Jan 2023, Trond Myklebust wrote:
> > 
> > 
> > If the server starts to reply NFS4ERR_STALE to GETATTR requests,
> > why do
> > we care about stateid values? Just mark the inode as stale and drop
> > it
> > on the floor.
> 
> We have a valid state from the server - we really shouldn't just
> ignore
> it.
> 
> Maybe it would be OK to mark the inode stale.  I don't know if
> various
> retry loops abort properly when the inode is stale.

Yes, they are all supposed to do that. Otherwise we would end up
looping forever in close(), for instance, since the PUTFH, GETATTR and
CLOSE can all return NFS4ERR_STALE as well.


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