[PATCH -next] nfsd: Drop LIST_HEAD where the variable it declares is never used.

[PATCH -next] nfsd: Drop LIST_HEAD where the variable it declares is never used.

[Mao Wenan]

The declarations were introduced with the file, but the declared
variables were not used.

Fixes: 65294c1f2c5e ("nfsd: add a new struct file caching facility to nfsd")
Signed-off-by: Mao Wenan <maowenan@huawei.com>
---
 fs/nfsd/filecache.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/fs/nfsd/filecache.c b/fs/nfsd/filecache.c
index ef55e9b..32a9bf2 100644
--- a/fs/nfsd/filecache.c
+++ b/fs/nfsd/filecache.c
@@ -685,8 +685,6 @@ nfsd_file_cache_purge(struct net *net)
 void
 nfsd_file_cache_shutdown(void)
 {
-	LIST_HEAD(dispose);
-
 	set_bit(NFSD_FILE_SHUTDOWN, &nfsd_file_lru_flags);
 
 	lease_unregister_notifier(&nfsd_file_lease_notifier);
-- 
2.7.4

Re: [PATCH -next] nfsd: Drop LIST_HEAD where the variable it declares is never used.

[Chuck Lever]

Hi Mao-

> On Nov 1, 2019, at 7:40 AM, Mao Wenan <maowenan@huawei.com> wrote:
> 
> The declarations were introduced with the file, but the declared
> variables were not used.
> 
> Fixes: 65294c1f2c5e ("nfsd: add a new struct file caching facility to nfsd")

I'm not sure a Fixes: tag is necessary here? 65294c1f2c5e
works fine without this change, and it's not something we
would need to backport into stable kernels.

This is more of a clean up patch.


> Signed-off-by: Mao Wenan <maowenan@huawei.com>
> ---
> fs/nfsd/filecache.c | 2 --
> 1 file changed, 2 deletions(-)
> 
> diff --git a/fs/nfsd/filecache.c b/fs/nfsd/filecache.c
> index ef55e9b..32a9bf2 100644
> --- a/fs/nfsd/filecache.c
> +++ b/fs/nfsd/filecache.c
> @@ -685,8 +685,6 @@ nfsd_file_cache_purge(struct net *net)
> void
> nfsd_file_cache_shutdown(void)
> {
> -	LIST_HEAD(dispose);
> -
> 	set_bit(NFSD_FILE_SHUTDOWN, &nfsd_file_lru_flags);
> 
> 	lease_unregister_notifier(&nfsd_file_lease_notifier);
> -- 
> 2.7.4
> 

--
Chuck Lever

Re: [PATCH -next] nfsd: Drop LIST_HEAD where the variable it declares is never used.

[Dan Carpenter]

On Fri, Nov 01, 2019 at 09:36:27AM -0400, Chuck Lever wrote:
> Hi Mao-
> 
> > On Nov 1, 2019, at 7:40 AM, Mao Wenan <maowenan@huawei.com> wrote:
> > 
> > The declarations were introduced with the file, but the declared
> > variables were not used.
> > 
> > Fixes: 65294c1f2c5e ("nfsd: add a new struct file caching facility to nfsd")
> 
> I'm not sure a Fixes: tag is necessary here? 65294c1f2c5e
> works fine without this change, and it's not something we
> would need to backport into stable kernels.
> 
> This is more of a clean up patch.
> 

Fixes is not really related to backports or stable.  I would agree that
this isn't a bug but just a cleanup, but the problem is that other
people want Fixes tags for everything...

Yesterday I sent a cleanup patch and I almost put the Fixes tag under
the --- cut off but in the end I just deleted it...  It's hard to know
what the right thing is.

regards,
dan carpenter

Re: [PATCH -next] nfsd: Drop LIST_HEAD where the variable it declares is never used.

[J. Bruce Fields]

On Fri, Nov 01, 2019 at 05:49:21PM +0300, Dan Carpenter wrote:
> On Fri, Nov 01, 2019 at 09:36:27AM -0400, Chuck Lever wrote:
> > > On Nov 1, 2019, at 7:40 AM, Mao Wenan <maowenan@huawei.com> wrote:
> > > 
> > > The declarations were introduced with the file, but the declared
> > > variables were not used.
> > > 
> > > Fixes: 65294c1f2c5e ("nfsd: add a new struct file caching facility to nfsd")

Thanks, applying for 5.5.

> > I'm not sure a Fixes: tag is necessary here? 65294c1f2c5e
> > works fine without this change, and it's not something we
> > would need to backport into stable kernels.
> > 
> > This is more of a clean up patch.
> > 
> 
> Fixes is not really related to backports or stable.  I would agree that
> this isn't a bug but just a cleanup, but the problem is that other
> people want Fixes tags for everything...
> 
> Yesterday I sent a cleanup patch and I almost put the Fixes tag under
> the --- cut off but in the end I just deleted it...  It's hard to know
> what the right thing is.

It doesn't have a stable cc and it's pretty obvious cleanup, so I guess
there's no harm in it.

I could go either way.  But I'll leave the patch as is unless someone
comes up with a clear policy.

--b.