Re: [PATCH 6.6.y] NFSD: simplify error paths in nfsd_svc()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Aug 27, 2024 at 02:25:03PM +0000, Chuck Lever III wrote:
> 
> 
> > On Aug 27, 2024, at 8:46 AM, Greg KH <greg@xxxxxxxxx> wrote:
> > 
> > On Sat, Aug 24, 2024 at 12:21:37PM -0400, cel@xxxxxxxxxx wrote:
> >> From: NeilBrown <neilb@xxxxxxx>
> >> 
> >> [ Upstream commit bf32075256e9dd9c6b736859e2c5813981339908 ]
> >> 
> >> The error paths in nfsd_svc() are needlessly complex and can result in a
> >> final call to svc_put() without nfsd_last_thread() being called.  This
> >> results in the listening sockets not being closed properly.
> >> 
> >> The per-netns setup provided by nfsd_startup_new() and removed by
> >> nfsd_shutdown_net() is needed precisely when there are running threads.
> >> So we don't need nfsd_up_before.  We don't need to know if it *was* up.
> >> We only need to know if any threads are left.  If none are, then we must
> >> call nfsd_shutdown_net().  But we don't need to do that explicitly as
> >> nfsd_last_thread() does that for us.
> >> 
> >> So simply call nfsd_last_thread() before the last svc_put() if there are
> >> no running threads.  That will always do the right thing.
> >> 
> >> Also discard:
> >> pr_info("nfsd: last server has exited, flushing export cache\n");
> >> It may not be true if an attempt to start the first server failed, and
> >> it isn't particularly helpful and it simply reports normal behaviour.
> >> 
> >> Signed-off-by: NeilBrown <neilb@xxxxxxx>
> >> Reviewed-by: Jeff Layton <jlayton@xxxxxxxxxx>
> >> Signed-off-by: Chuck Lever <chuck.lever@xxxxxxxxxx>
> >> ---
> >> fs/nfsd/nfssvc.c | 14 ++++----------
> >> 1 file changed, 4 insertions(+), 10 deletions(-)
> >> 
> >> Reported-by: Li Lingfeng <lilingfeng3@xxxxxxxxxx>
> >> Suggested-by: Li Lingfeng <lilingfeng3@xxxxxxxxxx>
> >> Tested-by: Li Lingfeng <lilingfeng3@xxxxxxxxxx>
> > 
> > Odd placement of these :)
> 
> Wasn't sure I was supposed to add them to the actual
> patch description because they weren't part of the
> original upstream commit.
> 
> But if that's OK to do for stable patches, I will
> add them in the usual spot next time.

Yes please, thanks!




[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux