Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) client-ip=23.128.96.36;
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
From:   "NeilBrown" <neilb@suse.de>
To:     "Chuck Lever III" <chuck.lever@oracle.com>
Cc:     "Jeff Layton" <jlayton@kernel.org>,
        "Linux NFS Mailing List" <linux-nfs@vger.kernel.org>,
        "Olga Kornievskaia" <kolga@netapp.com>,
        "Dai Ngo" <dai.ngo@oracle.com>, "Tom Talpey" <tom@talpey.com>
Subject: Re: [PATCH 6/6] nfsd: allow delegation state ids to be revoked and then freed
In-reply-to: <D2B988F4-D8F5-4A5A-BC97-F67D19A76C78@oracle.com>
References: <20231101010049.27315-1-neilb@suse.de>,
 <20231101010049.27315-7-neilb@suse.de>,
 <4C3DBAFF-4C83-4DB4-A6C6-D9C4387BF1F4@oracle.com>,
 <169880769331.24305.7672914147957308642@noble.neil.brown.name>,
 <D2B988F4-D8F5-4A5A-BC97-F67D19A76C78@oracle.com>
Date:   Wed, 01 Nov 2023 18:43:11 +1100
Message-id: <169882459188.24305.13216722681220510683@noble.neil.brown.name>
Precedence: bulk

On Wed, 01 Nov 2023, Chuck Lever III wrote:
> 
> > On Oct 31, 2023, at 8:01 PM, NeilBrown <neilb@suse.de> wrote:
> > 
> > On Wed, 01 Nov 2023, Chuck Lever III wrote:
> >> Howdy Neil-
> >> 
> >>> On Oct 31, 2023, at 5:57 PM, NeilBrown <neilb@suse.de> wrote:
> >>> 
> >>> Revoking state through 'unlock_filesystem' now revokes any delegation
> >>> states found.  When the stateids are then freed by the client, the
> >>> revoked stateids will be cleaned up correctly.
> >> 
> >> Here's my derpy question of the day.
> >> 
> >> "When the stateids are then freed by the client" seems to be
> >> a repeating trope, and it concerns me a bit (probably because
> >> I haven't yet learned how this mechanism /currently/ works)...
> >> 
> >> In the case when the client has actually vanished (eg, was
> >> destroyed by an orchestrator), it's not going to be around
> >> to actively free revoked state. Doesn't that situation result
> >> in pinned state on the server? I would expect that's a primary
> >> use case for "unlock_filesystem."
> > 
> > If a client is de-orchestrated then it will stop renewing its lease, and
> > regular cleanup of expired state will kick in after one lease period.
> 
> Thanks for educating me.
> 
> Such state actually stays around for much longer now as
> expired but renewable state. Does unlock_filesystem need
> to purge courtesy state too, to make the target filesystem
> unexportable and unmountable?

I don't think there is any special case there that we need to deal with.
I haven't explored in detail but I think "courtesy" state is managed at
the client level.  Some clients still have valid leases, others are
being maintained only as a courtesy.  At the individual state level
there is no difference.  The "unlock_filesystem" code examines all
states for all client and selects those for the target filesystem and
revokes those.

NeilBrown


> 
> 
> > So for NFSv4 we don't need to worry about disappearing clients.
> > For NFSv3 (or more specifically for NLM) we did and locks could hang
> > around indefinitely if the client died.
> > For that reason we have /proc/fs/nfsd/unlock_ip which discards all NFSv3
> > lock state for a given client.  Extending that to NFSv4 is not needed
> > because of leases, and not meaningful because of trunking - a client
> > might have several IP's.
> > 
> > unlock_filesystem is for when the client is still active and we want to
> > let it (them) continue accessing some filesystems, but not all.
> > 
> > NeilBrown
> > 
> > 
> >> 
> >> Maybe I've misunderstood something fundamental.
> >> 
> >> 
> >> --
> >> Chuck Lever
> 
> 
> --
> Chuck Lever
> 
> 
>