Linux NFS development
 help / color / mirror / Atom feed
* [PATCH] nfsd: Remove incorrect check in nfsd4_validate_stateid
@ 2023-07-18 12:38 trondmy
  2023-07-18 13:35 ` Jeff Layton
  0 siblings, 1 reply; 7+ messages in thread
From: trondmy @ 2023-07-18 12:38 UTC (permalink / raw)
  To: Chuck Lever; +Cc: linux-nfs

From: Trond Myklebust <trond.myklebust@hammerspace.com>

If the client is calling TEST_STATEID, then it is because some event
occurred that requires it to check all the stateids for validity and
call FREE_STATEID on the ones that have been revoked. In this case,
either the stateid exists in the list of stateids associated with that
nfs4_client, in which case it should be tested, or it does not. There
are no additional conditions to be considered.

Reported-by: Frank Ch. Eigler <fche@redhat.com>
Fixes: 663e36f07666 ("nfsd4: kill warnings on testing stateids with mismatched clientids")
Cc: stable@vger.kernel.org
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
---
 fs/nfsd/nfs4state.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
index 6e61fa3acaf1..3aefbad4cc09 100644
--- a/fs/nfsd/nfs4state.c
+++ b/fs/nfsd/nfs4state.c
@@ -6341,8 +6341,6 @@ static __be32 nfsd4_validate_stateid(struct nfs4_client *cl, stateid_t *stateid)
 	if (ZERO_STATEID(stateid) || ONE_STATEID(stateid) ||
 		CLOSE_STATEID(stateid))
 		return status;
-	if (!same_clid(&stateid->si_opaque.so_clid, &cl->cl_clientid))
-		return status;
 	spin_lock(&cl->cl_lock);
 	s = find_stateid_locked(cl, stateid);
 	if (!s)
-- 
2.41.0


^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: [PATCH] nfsd: Remove incorrect check in nfsd4_validate_stateid
  2023-07-18 12:38 [PATCH] nfsd: Remove incorrect check in nfsd4_validate_stateid trondmy
@ 2023-07-18 13:35 ` Jeff Layton
  2023-07-18 13:51   ` Trond Myklebust
  0 siblings, 1 reply; 7+ messages in thread
From: Jeff Layton @ 2023-07-18 13:35 UTC (permalink / raw)
  To: trondmy, Chuck Lever; +Cc: linux-nfs

On Tue, 2023-07-18 at 08:38 -0400, trondmy@kernel.org wrote:
> From: Trond Myklebust <trond.myklebust@hammerspace.com>
> 
> If the client is calling TEST_STATEID, then it is because some event
> occurred that requires it to check all the stateids for validity and
> call FREE_STATEID on the ones that have been revoked. In this case,
> either the stateid exists in the list of stateids associated with that
> nfs4_client, in which case it should be tested, or it does not. There
> are no additional conditions to be considered.
> 
> Reported-by: Frank Ch. Eigler <fche@redhat.com>
> Fixes: 663e36f07666 ("nfsd4: kill warnings on testing stateids with mismatched clientids")
> Cc: stable@vger.kernel.org
> Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
> ---
>  fs/nfsd/nfs4state.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
> index 6e61fa3acaf1..3aefbad4cc09 100644
> --- a/fs/nfsd/nfs4state.c
> +++ b/fs/nfsd/nfs4state.c
> @@ -6341,8 +6341,6 @@ static __be32 nfsd4_validate_stateid(struct nfs4_client *cl, stateid_t *stateid)
>  	if (ZERO_STATEID(stateid) || ONE_STATEID(stateid) ||
>  		CLOSE_STATEID(stateid))
>  		return status;
> -	if (!same_clid(&stateid->si_opaque.so_clid, &cl->cl_clientid))
> -		return status;
>  	spin_lock(&cl->cl_lock);
>  	s = find_stateid_locked(cl, stateid);
>  	if (!s)

IDGI. Is this fixing an actual bug? Granted this code does seem
unnecessary, but removing it doesn't seem like it will cause any
user-visible change in behavior. Am I missing something?
-- 
Jeff Layton <jlayton@kernel.org>

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] nfsd: Remove incorrect check in nfsd4_validate_stateid
  2023-07-18 13:35 ` Jeff Layton
@ 2023-07-18 13:51   ` Trond Myklebust
  2023-07-18 14:10     ` Jeff Layton
  2023-07-18 14:12     ` Chuck Lever III
  0 siblings, 2 replies; 7+ messages in thread
From: Trond Myklebust @ 2023-07-18 13:51 UTC (permalink / raw)
  To: Jeff Layton, Chuck Lever; +Cc: linux-nfs

On Tue, 2023-07-18 at 09:35 -0400, Jeff Layton wrote:
> On Tue, 2023-07-18 at 08:38 -0400, trondmy@kernel.org wrote:
> > From: Trond Myklebust <trond.myklebust@hammerspace.com>
> > 
> > If the client is calling TEST_STATEID, then it is because some
> > event
> > occurred that requires it to check all the stateids for validity
> > and
> > call FREE_STATEID on the ones that have been revoked. In this case,
> > either the stateid exists in the list of stateids associated with
> > that
> > nfs4_client, in which case it should be tested, or it does not.
> > There
> > are no additional conditions to be considered.
> > 
> > Reported-by: Frank Ch. Eigler <fche@redhat.com>
> > Fixes: 663e36f07666 ("nfsd4: kill warnings on testing stateids with
> > mismatched clientids")
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
> > ---
> >  fs/nfsd/nfs4state.c | 2 --
> >  1 file changed, 2 deletions(-)
> > 
> > diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
> > index 6e61fa3acaf1..3aefbad4cc09 100644
> > --- a/fs/nfsd/nfs4state.c
> > +++ b/fs/nfsd/nfs4state.c
> > @@ -6341,8 +6341,6 @@ static __be32 nfsd4_validate_stateid(struct
> > nfs4_client *cl, stateid_t *stateid)
> >         if (ZERO_STATEID(stateid) || ONE_STATEID(stateid) ||
> >                 CLOSE_STATEID(stateid))
> >                 return status;
> > -       if (!same_clid(&stateid->si_opaque.so_clid, &cl-
> > >cl_clientid))
> > -               return status;
> >         spin_lock(&cl->cl_lock);
> >         s = find_stateid_locked(cl, stateid);
> >         if (!s)
> 
> IDGI. Is this fixing an actual bug? Granted this code does seem
> unnecessary, but removing it doesn't seem like it will cause any
> user-visible change in behavior. Am I missing something?

It was clearly triggering in
https://bugzilla.redhat.com/show_bug.cgi?id=2176575

Furthermore, if you look at commit 663e36f07666, you'll see that all it
does is remove the log message because "it is expected". For some
unknown reason, it did not register that "then the check is incorrect".

So yes, this is fixing a real bug.

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



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] nfsd: Remove incorrect check in nfsd4_validate_stateid
  2023-07-18 13:51   ` Trond Myklebust
@ 2023-07-18 14:10     ` Jeff Layton
  2023-07-18 14:12     ` Chuck Lever III
  1 sibling, 0 replies; 7+ messages in thread
From: Jeff Layton @ 2023-07-18 14:10 UTC (permalink / raw)
  To: Trond Myklebust, Chuck Lever; +Cc: linux-nfs

On Tue, 2023-07-18 at 09:51 -0400, Trond Myklebust wrote:
> On Tue, 2023-07-18 at 09:35 -0400, Jeff Layton wrote:
> > On Tue, 2023-07-18 at 08:38 -0400, trondmy@kernel.org wrote:
> > > From: Trond Myklebust <trond.myklebust@hammerspace.com>
> > > 
> > > If the client is calling TEST_STATEID, then it is because some
> > > event
> > > occurred that requires it to check all the stateids for validity
> > > and
> > > call FREE_STATEID on the ones that have been revoked. In this case,
> > > either the stateid exists in the list of stateids associated with
> > > that
> > > nfs4_client, in which case it should be tested, or it does not.
> > > There
> > > are no additional conditions to be considered.
> > > 
> > > Reported-by: Frank Ch. Eigler <fche@redhat.com>
> > > Fixes: 663e36f07666 ("nfsd4: kill warnings on testing stateids with
> > > mismatched clientids")
> > > Cc: stable@vger.kernel.org
> > > Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
> > > ---
> > >  fs/nfsd/nfs4state.c | 2 --
> > >  1 file changed, 2 deletions(-)
> > > 
> > > diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
> > > index 6e61fa3acaf1..3aefbad4cc09 100644
> > > --- a/fs/nfsd/nfs4state.c
> > > +++ b/fs/nfsd/nfs4state.c
> > > @@ -6341,8 +6341,6 @@ static __be32 nfsd4_validate_stateid(struct
> > > nfs4_client *cl, stateid_t *stateid)
> > >         if (ZERO_STATEID(stateid) || ONE_STATEID(stateid) ||
> > >                 CLOSE_STATEID(stateid))
> > >                 return status;
> > > -       if (!same_clid(&stateid->si_opaque.so_clid, &cl-
> > > > cl_clientid))
> > > -               return status;
> > >         spin_lock(&cl->cl_lock);
> > >         s = find_stateid_locked(cl, stateid);
> > >         if (!s)
> > 
> > IDGI. Is this fixing an actual bug? Granted this code does seem
> > unnecessary, but removing it doesn't seem like it will cause any
> > user-visible change in behavior. Am I missing something?
> 
> It was clearly triggering in
> https://bugzilla.redhat.com/show_bug.cgi?id=2176575
> 
> Furthermore, if you look at commit 663e36f07666, you'll see that all it
> does is remove the log message because "it is expected". For some
> unknown reason, it did not register that "then the check is incorrect".
> 

Yeah, that commit just removes the warning, AFAICT.

> So yes, this is fixing a real bug.
> 

My assumption was that for any stateid that the server hands out, the
si_opaque.so_clid must match the clid. But...it looks like s2s copy
might have changed that rule?

In any case, the patch looks fine, so I have no objection. I'm just
trying to understand how this could happen.

Reviewed-by: Jeff Layton <jlayton@kernel.org>

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] nfsd: Remove incorrect check in nfsd4_validate_stateid
  2023-07-18 13:51   ` Trond Myklebust
  2023-07-18 14:10     ` Jeff Layton
@ 2023-07-18 14:12     ` Chuck Lever III
  2023-07-18 14:30       ` Trond Myklebust
  1 sibling, 1 reply; 7+ messages in thread
From: Chuck Lever III @ 2023-07-18 14:12 UTC (permalink / raw)
  To: Trond Myklebust; +Cc: Jeff Layton, Linux NFS Mailing List



> On Jul 18, 2023, at 9:51 AM, Trond Myklebust <trondmy@kernel.org> wrote:
> 
> On Tue, 2023-07-18 at 09:35 -0400, Jeff Layton wrote:
>> On Tue, 2023-07-18 at 08:38 -0400, trondmy@kernel.org wrote:
>>> From: Trond Myklebust <trond.myklebust@hammerspace.com>
>>> 
>>> If the client is calling TEST_STATEID, then it is because some
>>> event
>>> occurred that requires it to check all the stateids for validity
>>> and
>>> call FREE_STATEID on the ones that have been revoked. In this case,
>>> either the stateid exists in the list of stateids associated with
>>> that
>>> nfs4_client, in which case it should be tested, or it does not.
>>> There
>>> are no additional conditions to be considered.
>>> 
>>> Reported-by: Frank Ch. Eigler <fche@redhat.com>
>>> Fixes: 663e36f07666 ("nfsd4: kill warnings on testing stateids with
>>> mismatched clientids")
>>> Cc: stable@vger.kernel.org
>>> Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
>>> ---
>>>  fs/nfsd/nfs4state.c | 2 --
>>>  1 file changed, 2 deletions(-)
>>> 
>>> diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
>>> index 6e61fa3acaf1..3aefbad4cc09 100644
>>> --- a/fs/nfsd/nfs4state.c
>>> +++ b/fs/nfsd/nfs4state.c
>>> @@ -6341,8 +6341,6 @@ static __be32 nfsd4_validate_stateid(struct
>>> nfs4_client *cl, stateid_t *stateid)
>>>         if (ZERO_STATEID(stateid) || ONE_STATEID(stateid) ||
>>>                 CLOSE_STATEID(stateid))
>>>                 return status;
>>> -       if (!same_clid(&stateid->si_opaque.so_clid, &cl-
>>>> cl_clientid))
>>> -               return status;
>>>         spin_lock(&cl->cl_lock);
>>>         s = find_stateid_locked(cl, stateid);
>>>         if (!s)
>> 
>> IDGI. Is this fixing an actual bug? Granted this code does seem
>> unnecessary, but removing it doesn't seem like it will cause any
>> user-visible change in behavior. Am I missing something?
> 
> It was clearly triggering in
> https://bugzilla.redhat.com/show_bug.cgi?id=2176575
> 
> Furthermore, if you look at commit 663e36f07666, you'll see that all it
> does is remove the log message because "it is expected". For some
> unknown reason, it did not register that "then the check is incorrect".

I don't think 663e36f altered this logic: it "returned status"
when it emitted the warning, and it "returned status" after
the warning was removed.


> So yes, this is fixing a real bug.

If there is a bug, wouldn't it have been introduced when the
"!same_clid()" check was added?

Fixes: 7df302f75ee2 ("NFSD: TEST_STATEID should not return NFS4ERR_STALE_STATEID")


--
Chuck Lever



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] nfsd: Remove incorrect check in nfsd4_validate_stateid
  2023-07-18 14:12     ` Chuck Lever III
@ 2023-07-18 14:30       ` Trond Myklebust
  2023-07-18 18:15         ` Chuck Lever III
  0 siblings, 1 reply; 7+ messages in thread
From: Trond Myklebust @ 2023-07-18 14:30 UTC (permalink / raw)
  To: Chuck Lever III; +Cc: Jeff Layton, Linux NFS Mailing List

On Tue, 2023-07-18 at 14:12 +0000, Chuck Lever III wrote:
> 
> 
> > On Jul 18, 2023, at 9:51 AM, Trond Myklebust <trondmy@kernel.org>
> > wrote:
> > 
> > On Tue, 2023-07-18 at 09:35 -0400, Jeff Layton wrote:
> > > On Tue, 2023-07-18 at 08:38 -0400, trondmy@kernel.org wrote:
> > > > From: Trond Myklebust <trond.myklebust@hammerspace.com>
> > > > 
> > > > If the client is calling TEST_STATEID, then it is because some
> > > > event
> > > > occurred that requires it to check all the stateids for
> > > > validity
> > > > and
> > > > call FREE_STATEID on the ones that have been revoked. In this
> > > > case,
> > > > either the stateid exists in the list of stateids associated
> > > > with
> > > > that
> > > > nfs4_client, in which case it should be tested, or it does not.
> > > > There
> > > > are no additional conditions to be considered.
> > > > 
> > > > Reported-by: Frank Ch. Eigler <fche@redhat.com>
> > > > Fixes: 663e36f07666 ("nfsd4: kill warnings on testing stateids
> > > > with
> > > > mismatched clientids")
> > > > Cc: stable@vger.kernel.org
> > > > Signed-off-by: Trond Myklebust
> > > > <trond.myklebust@hammerspace.com>
> > > > ---
> > > >  fs/nfsd/nfs4state.c | 2 --
> > > >  1 file changed, 2 deletions(-)
> > > > 
> > > > diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
> > > > index 6e61fa3acaf1..3aefbad4cc09 100644
> > > > --- a/fs/nfsd/nfs4state.c
> > > > +++ b/fs/nfsd/nfs4state.c
> > > > @@ -6341,8 +6341,6 @@ static __be32
> > > > nfsd4_validate_stateid(struct
> > > > nfs4_client *cl, stateid_t *stateid)
> > > >         if (ZERO_STATEID(stateid) || ONE_STATEID(stateid) ||
> > > >                 CLOSE_STATEID(stateid))
> > > >                 return status;
> > > > -       if (!same_clid(&stateid->si_opaque.so_clid, &cl-
> > > > > cl_clientid))
> > > > -               return status;
> > > >         spin_lock(&cl->cl_lock);
> > > >         s = find_stateid_locked(cl, stateid);
> > > >         if (!s)
> > > 
> > > IDGI. Is this fixing an actual bug? Granted this code does seem
> > > unnecessary, but removing it doesn't seem like it will cause any
> > > user-visible change in behavior. Am I missing something?
> > 
> > It was clearly triggering in
> > https://bugzilla.redhat.com/show_bug.cgi?id=2176575
> > 
> > Furthermore, if you look at commit 663e36f07666, you'll see that
> > all it
> > does is remove the log message because "it is expected". For some
> > unknown reason, it did not register that "then the check is
> > incorrect".
> 
> I don't think 663e36f altered this logic: it "returned status"
> when it emitted the warning, and it "returned status" after
> the warning was removed.
> 
> 
> > So yes, this is fixing a real bug.
> 
> If there is a bug, wouldn't it have been introduced when the
> "!same_clid()" check was added?
> 

Correct.

> Fixes: 7df302f75ee2 ("NFSD: TEST_STATEID should not return
> NFS4ERR_STALE_STATEID")
> 

It can't fix anything older than that patch, because it won't apply.

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



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] nfsd: Remove incorrect check in nfsd4_validate_stateid
  2023-07-18 14:30       ` Trond Myklebust
@ 2023-07-18 18:15         ` Chuck Lever III
  0 siblings, 0 replies; 7+ messages in thread
From: Chuck Lever III @ 2023-07-18 18:15 UTC (permalink / raw)
  To: Trond Myklebust; +Cc: Jeff Layton, Linux NFS Mailing List



> On Jul 18, 2023, at 10:30 AM, Trond Myklebust <trondmy@kernel.org> wrote:
> 
> On Tue, 2023-07-18 at 14:12 +0000, Chuck Lever III wrote:
>> 
>> 
>>> On Jul 18, 2023, at 9:51 AM, Trond Myklebust <trondmy@kernel.org>
>>> wrote:
>>> 
>>> On Tue, 2023-07-18 at 09:35 -0400, Jeff Layton wrote:
>>>> On Tue, 2023-07-18 at 08:38 -0400, trondmy@kernel.org wrote:
>>>>> From: Trond Myklebust <trond.myklebust@hammerspace.com>
>>>>> 
>>>>> If the client is calling TEST_STATEID, then it is because some
>>>>> event
>>>>> occurred that requires it to check all the stateids for
>>>>> validity
>>>>> and
>>>>> call FREE_STATEID on the ones that have been revoked. In this
>>>>> case,
>>>>> either the stateid exists in the list of stateids associated
>>>>> with
>>>>> that
>>>>> nfs4_client, in which case it should be tested, or it does not.
>>>>> There
>>>>> are no additional conditions to be considered.
>>>>> 
>>>>> Reported-by: Frank Ch. Eigler <fche@redhat.com>
>>>>> Fixes: 663e36f07666 ("nfsd4: kill warnings on testing stateids
>>>>> with
>>>>> mismatched clientids")
>>>>> Cc: stable@vger.kernel.org
>>>>> Signed-off-by: Trond Myklebust
>>>>> <trond.myklebust@hammerspace.com>
>>>>> ---
>>>>>  fs/nfsd/nfs4state.c | 2 --
>>>>>  1 file changed, 2 deletions(-)
>>>>> 
>>>>> diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
>>>>> index 6e61fa3acaf1..3aefbad4cc09 100644
>>>>> --- a/fs/nfsd/nfs4state.c
>>>>> +++ b/fs/nfsd/nfs4state.c
>>>>> @@ -6341,8 +6341,6 @@ static __be32
>>>>> nfsd4_validate_stateid(struct
>>>>> nfs4_client *cl, stateid_t *stateid)
>>>>>         if (ZERO_STATEID(stateid) || ONE_STATEID(stateid) ||
>>>>>                 CLOSE_STATEID(stateid))
>>>>>                 return status;
>>>>> -       if (!same_clid(&stateid->si_opaque.so_clid, &cl-
>>>>>> cl_clientid))
>>>>> -               return status;
>>>>>         spin_lock(&cl->cl_lock);
>>>>>         s = find_stateid_locked(cl, stateid);
>>>>>         if (!s)
>>>> 
>>>> IDGI. Is this fixing an actual bug? Granted this code does seem
>>>> unnecessary, but removing it doesn't seem like it will cause any
>>>> user-visible change in behavior. Am I missing something?
>>> 
>>> It was clearly triggering in
>>> https://bugzilla.redhat.com/show_bug.cgi?id=2176575
>>> 
>>> Furthermore, if you look at commit 663e36f07666, you'll see that
>>> all it
>>> does is remove the log message because "it is expected". For some
>>> unknown reason, it did not register that "then the check is
>>> incorrect".
>> 
>> I don't think 663e36f altered this logic: it "returned status"
>> when it emitted the warning, and it "returned status" after
>> the warning was removed.
>> 
>> 
>>> So yes, this is fixing a real bug.
>> 
>> If there is a bug, wouldn't it have been introduced when the
>> "!same_clid()" check was added?
>> 
> 
> Correct.
> 
>> Fixes: 7df302f75ee2 ("NFSD: TEST_STATEID should not return
>> NFS4ERR_STALE_STATEID")
>> 
> 
> It can't fix anything older than that patch, because it won't apply.

Testing now. I plan to apply it to nfsd-fixes (for 6.5-rc).


--
Chuck Lever



^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2023-07-18 18:15 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-07-18 12:38 [PATCH] nfsd: Remove incorrect check in nfsd4_validate_stateid trondmy
2023-07-18 13:35 ` Jeff Layton
2023-07-18 13:51   ` Trond Myklebust
2023-07-18 14:10     ` Jeff Layton
2023-07-18 14:12     ` Chuck Lever III
2023-07-18 14:30       ` Trond Myklebust
2023-07-18 18:15         ` Chuck Lever III

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox