From: Jeff Layton <jlayton@kernel.org>
To: NeilBrown <neilb@suse.de>
Cc: Chuck Lever <chuck.lever@oracle.com>,
Olga Kornievskaia <okorniev@redhat.com>,
Dai Ngo <Dai.Ngo@oracle.com>, Tom Talpey <tom@talpey.com>,
linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] nfsd: allow SC_STATUS_FREEABLE when searching via nfs4_lookup_stateid()
Date: Thu, 13 Feb 2025 07:52:05 -0500 [thread overview]
Message-ID: <a4bdb6dd9d20fecce52a3fd35650aadc52d2e05e.camel@kernel.org> (raw)
In-Reply-To: <173939479366.22054.8896171620747680077@noble.neil.brown.name>
On Thu, 2025-02-13 at 08:13 +1100, NeilBrown wrote:
> On Thu, 13 Feb 2025, Jeff Layton wrote:
> > When a delegation is revoked, it's initially marked with
> > SC_STATUS_REVOKED, or SC_STATUS_ADMIN_REVOKED and later, it's marked
> > with the SC_STATUS_FREEABLE flag, which denotes that it is waiting for
> > s FREE_STATEID call.
> >
> > nfs4_lookup_stateid() accepts a statusmask that includes the status
> > flags that a found stateid is allowed to have. Currently, that mask
> > never includes SC_STATUS_FREEABLE, which means that revoked delegations
> > are (almost) never found.
> >
> > Add SC_STATUS_FREEABLE to the always-allowed status flags.
>
> There are 4 calls to nfsd4_lookup_stateid(). One already has
> SC_STATUS_FREEABLE passed. Which of the others need it?
> If all of them, then this patch is sensible but should also remove the
> flag in the one place it is already passed.
> If only one other call needs it, then maybe we should just pass it
> there?
>
> Could you at least include in the description some detail of what
> request is failing and which particular nfsd4_lookup_stateid() call is
> relevant in that case?
>
> Thanks,
> NeilBrown
>
I think they all need it.
The DELEG8 test gets a delegation, and then lets the lease time out. It
then does a READ op and tests that it gets back NFS4ERR_DELEG_REVOKED.
The read path calls nfs4_preprocess_stateid_op(), so it's needed there
specifically to fix that bug.
1ac3629bf0125 ensures that SC_STATUS_ADMIN_REVOKED is always set in the
allowed mask. If that's always allowed, then FREEABLE must be too.
There is only a very narrow window of time when ADMIN_REVOKED or
REVOKED is set, and FREEABLE is not.
I'll respin and remove the other FREEABLE flag, since I think it should
be implied everywhere.
>
> >
> > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > ---
> > This fixes the pynfs DELEG8 test.
> > ---
> > fs/nfsd/nfs4state.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
> > index 153eeea2c7c999d003cd1f36cecb0dd4f6e049b8..56bf07d623d085589823f3fba18afa62c0b3dbd2 100644
> > --- a/fs/nfsd/nfs4state.c
> > +++ b/fs/nfsd/nfs4state.c
> > @@ -7051,7 +7051,7 @@ nfsd4_lookup_stateid(struct nfsd4_compound_state *cstate,
> > */
> > statusmask |= SC_STATUS_REVOKED;
> >
> > - statusmask |= SC_STATUS_ADMIN_REVOKED;
> > + statusmask |= SC_STATUS_ADMIN_REVOKED | SC_STATUS_FREEABLE;
> >
> > if (ZERO_STATEID(stateid) || ONE_STATEID(stateid) ||
> > CLOSE_STATEID(stateid))
> >
> > ---
> > base-commit: 4990d098433db18c854e75fb0f90d941eb7d479e
> > change-id: 20250212-nfsd-fixes-fa8047082335
> >
> > Best regards,
> > --
> > Jeff Layton <jlayton@kernel.org>
> >
> >
>
--
Jeff Layton <jlayton@kernel.org>
next prev parent reply other threads:[~2025-02-13 12:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-12 16:29 [PATCH] nfsd: allow SC_STATUS_FREEABLE when searching via nfs4_lookup_stateid() Jeff Layton
2025-02-12 16:34 ` Chuck Lever
2025-02-12 16:36 ` Jeff Layton
2025-02-12 21:13 ` NeilBrown
2025-02-13 12:52 ` Jeff Layton [this message]
2025-02-12 21:41 ` Dai Ngo
2025-02-13 12:55 ` Jeff Layton
2025-04-17 12:48 ` Benjamin Coddington
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a4bdb6dd9d20fecce52a3fd35650aadc52d2e05e.camel@kernel.org \
--to=jlayton@kernel.org \
--cc=Dai.Ngo@oracle.com \
--cc=chuck.lever@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=neilb@suse.de \
--cc=okorniev@redhat.com \
--cc=tom@talpey.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.