Hi Colin-
> On Jan 28, 2021, at 9:49 AM, Colin King <[email protected]> wrote:
>
> From: Colin Ian King <[email protected]>
>
> The call to find_stateid_by_type is setting the return value in *stid
> yet the NULL check of the return is checking stid instead of *stid.
> Fix this by adding in the missing pointer * operator.
>
> Addresses-Coverity: ("Dereference before null check")
> Fixes: 6cdaa72d4dde ("nfsd: find_cpntf_state cleanup")
> Signed-off-by: Colin Ian King <[email protected]>
Thanks for your patch. I've committed it to the for-next branch at
git://git.kernel.org/pub/scm/linux/kernel/git/cel/linux.git
in preparation for the v5.12 merge window, with the following changes:
- ^statid^stateid
- Fixes: tag removed, since no stable backport is necessary
The commit you are fixing has not been merged upstream yet.
> ---
> 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 f554e3480bb1..423fd6683f3a 100644
> --- a/fs/nfsd/nfs4state.c
> +++ b/fs/nfsd/nfs4state.c
> @@ -5824,7 +5824,7 @@ static __be32 find_cpntf_state(struct nfsd_net *nn, stateid_t *st,
>
> *stid = find_stateid_by_type(found, &cps->cp_p_stateid,
> NFS4_DELEG_STID|NFS4_OPEN_STID|NFS4_LOCK_STID);
> - if (stid)
> + if (*stid)
> status = nfs_ok;
> else
> status = nfserr_bad_stateid;
> --
> 2.29.2
>
--
Chuck Lever
On Thu, Jan 28, 2021 at 03:05:06PM +0000, Chuck Lever wrote:
> Hi Colin-
>
> > On Jan 28, 2021, at 9:49 AM, Colin King <[email protected]> wrote:
> >
> > From: Colin Ian King <[email protected]>
> >
> > The call to find_stateid_by_type is setting the return value in *stid
> > yet the NULL check of the return is checking stid instead of *stid.
> > Fix this by adding in the missing pointer * operator.
> >
> > Addresses-Coverity: ("Dereference before null check")
> > Fixes: 6cdaa72d4dde ("nfsd: find_cpntf_state cleanup")
> > Signed-off-by: Colin Ian King <[email protected]>
>
> Thanks for your patch. I've committed it to the for-next branch at
>
> git://git.kernel.org/pub/scm/linux/kernel/git/cel/linux.git
>
> in preparation for the v5.12 merge window, with the following changes:
>
> - ^statid^stateid
> - Fixes: tag removed, since no stable backport is necessary
Please keep the "Fixes:" tag! It's still very useful information. For
example, if someone needs to backport the original patch, this is a
reminder they'll want this one as well.
(Of course, if you fold this patch into the earlier one instead, that's
a different situation.)
--b.
> The commit you are fixing has not been merged upstream yet.
>
>
> > ---
> > 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 f554e3480bb1..423fd6683f3a 100644
> > --- a/fs/nfsd/nfs4state.c
> > +++ b/fs/nfsd/nfs4state.c
> > @@ -5824,7 +5824,7 @@ static __be32 find_cpntf_state(struct nfsd_net *nn, stateid_t *st,
> >
> > *stid = find_stateid_by_type(found, &cps->cp_p_stateid,
> > NFS4_DELEG_STID|NFS4_OPEN_STID|NFS4_LOCK_STID);
> > - if (stid)
> > + if (*stid)
> > status = nfs_ok;
> > else
> > status = nfserr_bad_stateid;
> > --
> > 2.29.2
> >
>
> --
> Chuck Lever
>
>
On Thu, Jan 28, 2021 at 03:05:06PM +0000, Chuck Lever wrote:
> Hi Colin-
>
> > On Jan 28, 2021, at 9:49 AM, Colin King <[email protected]> wrote:
> >
> > From: Colin Ian King <[email protected]>
> >
> > The call to find_stateid_by_type is setting the return value in *stid
> > yet the NULL check of the return is checking stid instead of *stid.
> > Fix this by adding in the missing pointer * operator.
> >
> > Addresses-Coverity: ("Dereference before null check")
> > Fixes: 6cdaa72d4dde ("nfsd: find_cpntf_state cleanup")
> > Signed-off-by: Colin Ian King <[email protected]>
>
> Thanks for your patch. I've committed it to the for-next branch at
>
> git://git.kernel.org/pub/scm/linux/kernel/git/cel/linux.git
>
> in preparation for the v5.12 merge window, with the following changes:
>
> - ^statid^stateid
> - Fixes: tag removed, since no stable backport is necessary
>
> The commit you are fixing has not been merged upstream yet.
Fixes tags don't meant the patch has to be backported. Is your tree
rebased? In that case, the fixes tag probably doesn't make sense
because the tag can change. You might want to just consider folding
Colin's fix into the original commit.
Fixes tags are used for a lot of different things:
1) If there is a fixes tag, then you can tell it does *NOT* have to
be back ported because the original commit is not in the stable
tree. It saves time for the stable maintainers.
2) Metrics to figure out how quickly we are fixing bugs.
3) Sometimes the Fixes tag helps because we want to review the original
patch to see what the intent was.
All sorts of stuff. Etc.
regards,
dan carpenter
Hi Dan-
> On Jan 28, 2021, at 10:34 AM, Dan Carpenter <[email protected]> wrote:
>
> On Thu, Jan 28, 2021 at 03:05:06PM +0000, Chuck Lever wrote:
>> Hi Colin-
>>
>>> On Jan 28, 2021, at 9:49 AM, Colin King <[email protected]> wrote:
>>>
>>> From: Colin Ian King <[email protected]>
>>>
>>> The call to find_stateid_by_type is setting the return value in *stid
>>> yet the NULL check of the return is checking stid instead of *stid.
>>> Fix this by adding in the missing pointer * operator.
>>>
>>> Addresses-Coverity: ("Dereference before null check")
>>> Fixes: 6cdaa72d4dde ("nfsd: find_cpntf_state cleanup")
>>> Signed-off-by: Colin Ian King <[email protected]>
>>
>> Thanks for your patch. I've committed it to the for-next branch at
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/cel/linux.git
>>
>> in preparation for the v5.12 merge window, with the following changes:
>>
>> - ^statid^stateid
>> - Fixes: tag removed, since no stable backport is necessary
>>
>> The commit you are fixing has not been merged upstream yet.
>
> Fixes tags don't meant the patch has to be backported. Is your tree
> rebased? In that case, the fixes tag probably doesn't make sense
> because the tag can change. You might want to just consider folding
> Colin's fix into the original commit.
Yes, this branch can be rebased on occasion. Since you and Bruce
suggest squashing the fix into the original patch, I will do that.
> Fixes tags are used for a lot of different things:
> 1) If there is a fixes tag, then you can tell it does *NOT* have to
> be back ported because the original commit is not in the stable
> tree. It saves time for the stable maintainers.
> 2) Metrics to figure out how quickly we are fixing bugs.
> 3) Sometimes the Fixes tag helps because we want to review the original
> patch to see what the intent was.
>
> All sorts of stuff. Etc.
Yep, I'm a fan of all that. I just want to avoid poking the stable
automation bear when it's unnecessary.
--
Chuck Lever
On Thu, Jan 28, 2021 at 03:53:36PM +0000, Chuck Lever wrote:
> > On Jan 28, 2021, at 10:34 AM, Dan Carpenter <[email protected]> wrote:
> > Fixes tags are used for a lot of different things:
> > 1) If there is a fixes tag, then you can tell it does *NOT* have to
> > be back ported because the original commit is not in the stable
> > tree. It saves time for the stable maintainers.
> > 2) Metrics to figure out how quickly we are fixing bugs.
> > 3) Sometimes the Fixes tag helps because we want to review the original
> > patch to see what the intent was.
> >
> > All sorts of stuff. Etc.
>
> Yep, I'm a fan of all that. I just want to avoid poking the stable
> automation bear when it's unnecessary.
I've routinely had patches with Fixes: lines referencing other queued-up
patches, and I didn't get any stable mail about it.
100% not something to worry about.
--b.