2021-11-30 11:21:46

by Wei Yongjun

[permalink] [raw]
Subject: [PATCH -next] NFSD: make symbol 'nfsd_notifier_lock' static

The sparse tool complains as follows:

fs/nfsd/nfssvc.c:437:1: warning:
symbol 'nfsd_notifier_lock' was not declared. Should it be static?

This symbol is not used outside of nfssvc.c, so marks it static.

Fixes: 6ac25fbcbde9 ("NFSD: simplify locking for network notifier.")
Reported-by: Hulk Robot <[email protected]>
Signed-off-by: Wei Yongjun <[email protected]>
---
fs/nfsd/nfssvc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/nfsd/nfssvc.c b/fs/nfsd/nfssvc.c
index 070525fbc1ad..14c1ef6f8cc7 100644
--- a/fs/nfsd/nfssvc.c
+++ b/fs/nfsd/nfssvc.c
@@ -434,7 +434,7 @@ static void nfsd_shutdown_net(struct net *net)
nfsd_shutdown_generic();
}

-DEFINE_SPINLOCK(nfsd_notifier_lock);
+static DEFINE_SPINLOCK(nfsd_notifier_lock);
static int nfsd_inetaddr_event(struct notifier_block *this, unsigned long event,
void *ptr)
{



2021-11-30 20:20:02

by Chuck Lever

[permalink] [raw]
Subject: Re: [PATCH -next] NFSD: make symbol 'nfsd_notifier_lock' static



> On Nov 30, 2021, at 6:34 AM, Wei Yongjun <[email protected]> wrote:
>
> The sparse tool complains as follows:
>
> fs/nfsd/nfssvc.c:437:1: warning:
> symbol 'nfsd_notifier_lock' was not declared. Should it be static?
>
> This symbol is not used outside of nfssvc.c, so marks it static.
>
> Fixes: 6ac25fbcbde9 ("NFSD: simplify locking for network notifier.")
> Reported-by: Hulk Robot <[email protected]>
> Signed-off-by: Wei Yongjun <[email protected]>
> ---
> fs/nfsd/nfssvc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/nfsd/nfssvc.c b/fs/nfsd/nfssvc.c
> index 070525fbc1ad..14c1ef6f8cc7 100644
> --- a/fs/nfsd/nfssvc.c
> +++ b/fs/nfsd/nfssvc.c
> @@ -434,7 +434,7 @@ static void nfsd_shutdown_net(struct net *net)
> nfsd_shutdown_generic();
> }
>
> -DEFINE_SPINLOCK(nfsd_notifier_lock);
> +static DEFINE_SPINLOCK(nfsd_notifier_lock);
> static int nfsd_inetaddr_event(struct notifier_block *this, unsigned long event,
> void *ptr)
> {
>

Thanks! This was pushed to the tip of the for-next branch at

https://git.kernel.org/pub/scm/linux/kernel/git/cel/linux.git

I removed the Fixes: line because a backport is unnecessary, and
the commit ID is not yet permanent.


--
Chuck Lever




2021-12-03 11:25:49

by Dan Carpenter

[permalink] [raw]
Subject: Re: [PATCH -next] NFSD: make symbol 'nfsd_notifier_lock' static

On Tue, Nov 30, 2021 at 08:19:47PM +0000, Chuck Lever III wrote:
> >
> > -DEFINE_SPINLOCK(nfsd_notifier_lock);
> > +static DEFINE_SPINLOCK(nfsd_notifier_lock);
> > static int nfsd_inetaddr_event(struct notifier_block *this, unsigned long event,
> > void *ptr)
> > {
> >
>
> Thanks! This was pushed to the tip of the for-next branch at
>
> https://git.kernel.org/pub/scm/linux/kernel/git/cel/linux.git
>
> I removed the Fixes: line because a backport is unnecessary, and
> the commit ID is not yet permanent.

Removing the tag, makes it more complicated for backporters. Before
they could tell automatically from the Fixes tag that backporting was
not necessary.

On the other hand, does this patch really need a Fixes tag since it's
not a runtime bug? Different maintainers take different sides in that
argument.

If the patch needed a fixes tag then a lot of maintainers have scripts
to update the tag during a rebase. There are also automated tool run on
linux-next which emails a warning when the Fixes tags point to an
invalid hash.

regards,
dan carpenter


2021-12-03 15:17:49

by Chuck Lever

[permalink] [raw]
Subject: Re: [PATCH -next] NFSD: make symbol 'nfsd_notifier_lock' static



> On Dec 3, 2021, at 6:25 AM, Dan Carpenter <[email protected]> wrote:
>
> On Tue, Nov 30, 2021 at 08:19:47PM +0000, Chuck Lever III wrote:
>>>
>>> -DEFINE_SPINLOCK(nfsd_notifier_lock);
>>> +static DEFINE_SPINLOCK(nfsd_notifier_lock);
>>> static int nfsd_inetaddr_event(struct notifier_block *this, unsigned long event,
>>> void *ptr)
>>> {
>>>
>>
>> Thanks! This was pushed to the tip of the for-next branch at
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/cel/linux.git
>>
>> I removed the Fixes: line because a backport is unnecessary, and
>> the commit ID is not yet permanent.
>
> Removing the tag, makes it more complicated for backporters. Before
> they could tell automatically from the Fixes tag that backporting was
> not necessary.
>
> On the other hand, does this patch really need a Fixes tag since it's
> not a runtime bug? Different maintainers take different sides in that
> argument.
>
> If the patch needed a fixes tag then a lot of maintainers have scripts
> to update the tag during a rebase. There are also automated tool run on
> linux-next which emails a warning when the Fixes tags point to an
> invalid hash.

Hi Dan, the patch fixes a bug in my for-next branch, not in mainline.
There's really no need for a Fixes: tag.


--
Chuck Lever




2021-12-03 15:19:58

by J. Bruce Fields

[permalink] [raw]
Subject: Re: [PATCH -next] NFSD: make symbol 'nfsd_notifier_lock' static

On Fri, Dec 03, 2021 at 03:17:30PM +0000, Chuck Lever III wrote:
>
>
> > On Dec 3, 2021, at 6:25 AM, Dan Carpenter <[email protected]> wrote:
> >
> > On Tue, Nov 30, 2021 at 08:19:47PM +0000, Chuck Lever III wrote:
> >>>
> >>> -DEFINE_SPINLOCK(nfsd_notifier_lock);
> >>> +static DEFINE_SPINLOCK(nfsd_notifier_lock);
> >>> static int nfsd_inetaddr_event(struct notifier_block *this, unsigned long event,
> >>> void *ptr)
> >>> {
> >>>
> >>
> >> Thanks! This was pushed to the tip of the for-next branch at
> >>
> >> https://git.kernel.org/pub/scm/linux/kernel/git/cel/linux.git
> >>
> >> I removed the Fixes: line because a backport is unnecessary, and
> >> the commit ID is not yet permanent.
> >
> > Removing the tag, makes it more complicated for backporters. Before
> > they could tell automatically from the Fixes tag that backporting was
> > not necessary.
> >
> > On the other hand, does this patch really need a Fixes tag since it's
> > not a runtime bug? Different maintainers take different sides in that
> > argument.
> >
> > If the patch needed a fixes tag then a lot of maintainers have scripts
> > to update the tag during a rebase. There are also automated tool run on
> > linux-next which emails a warning when the Fixes tags point to an
> > invalid hash.
>
> Hi Dan, the patch fixes a bug in my for-next branch, not in mainline.
> There's really no need for a Fixes: tag.

Assuming it doesn't get folded into the fixed patch before going
upstream, it'd be useful information to have there.

--b.

2021-12-03 15:28:17

by Chuck Lever

[permalink] [raw]
Subject: Re: [PATCH -next] NFSD: make symbol 'nfsd_notifier_lock' static



> On Dec 3, 2021, at 10:19 AM, Bruce Fields <[email protected]> wrote:
>
> On Fri, Dec 03, 2021 at 03:17:30PM +0000, Chuck Lever III wrote:
>>
>>
>>> On Dec 3, 2021, at 6:25 AM, Dan Carpenter <[email protected]> wrote:
>>>
>>> On Tue, Nov 30, 2021 at 08:19:47PM +0000, Chuck Lever III wrote:
>>>>>
>>>>> -DEFINE_SPINLOCK(nfsd_notifier_lock);
>>>>> +static DEFINE_SPINLOCK(nfsd_notifier_lock);
>>>>> static int nfsd_inetaddr_event(struct notifier_block *this, unsigned long event,
>>>>> void *ptr)
>>>>> {
>>>>>
>>>>
>>>> Thanks! This was pushed to the tip of the for-next branch at
>>>>
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/cel/linux.git
>>>>
>>>> I removed the Fixes: line because a backport is unnecessary, and
>>>> the commit ID is not yet permanent.
>>>
>>> Removing the tag, makes it more complicated for backporters. Before
>>> they could tell automatically from the Fixes tag that backporting was
>>> not necessary.
>>>
>>> On the other hand, does this patch really need a Fixes tag since it's
>>> not a runtime bug? Different maintainers take different sides in that
>>> argument.
>>>
>>> If the patch needed a fixes tag then a lot of maintainers have scripts
>>> to update the tag during a rebase. There are also automated tool run on
>>> linux-next which emails a warning when the Fixes tags point to an
>>> invalid hash.
>>
>> Hi Dan, the patch fixes a bug in my for-next branch, not in mainline.
>> There's really no need for a Fixes: tag.
>
> Assuming it doesn't get folded into the fixed patch before going
> upstream, it'd be useful information to have there.

I'm sorry, but I don't see how that information is useful for a
fixing a patch that is in the same merge set. I'll fold it in.


--
Chuck Lever