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

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

[Wei Yongjun]

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 <hulkci@huawei.com>
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
 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)
 {

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

[Chuck Lever III]

> On Nov 30, 2021, at 6:34 AM, Wei Yongjun <weiyongjun1@huawei.com> 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 <hulkci@huawei.com>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> ---
> 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

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

[Dan Carpenter]

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

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

[Chuck Lever III]

> On Dec 3, 2021, at 6:25 AM, Dan Carpenter <dan.carpenter@oracle.com> 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

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

[Bruce Fields]

On Fri, Dec 03, 2021 at 03:17:30PM +0000, Chuck Lever III wrote:
> 
> 
> > On Dec 3, 2021, at 6:25 AM, Dan Carpenter <dan.carpenter@oracle.com> 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.

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

[Chuck Lever III]

> On Dec 3, 2021, at 10:19 AM, Bruce Fields <bfields@fieldses.org> 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 <dan.carpenter@oracle.com> 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