All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Neil Brown <neilb@suse.de>
Cc: "J. Bruce Fields" <bfields@redhat.com>,
	linux-nfs@vger.kernel.org,
	Menyhart Zoltan <Zoltan.Menyhart@bull.net>
Subject: Re: [PATCH 1/4] svcrpc: never clear XPT_BUSY on dead xprt
Date: Tue, 26 Oct 2010 08:59:47 -0400	[thread overview]
Message-ID: <20101026125947.GA19445@fieldses.org> (raw)
In-Reply-To: <20101026122820.1518ec7e@notabene>

On Tue, Oct 26, 2010 at 12:28:20PM +1100, Neil Brown wrote:
> On Mon, 25 Oct 2010 20:30:08 -0400
> "J. Bruce Fields" <bfields@fieldses.org> wrote:
> > 
> >     svcrpc: simplify svc_close_xprt, fix minor race
> >     
> >     We're assuming that in the XPT_BUSY case, somebody else will take care
> >     of the close.  But that's not necessarily the case (e.g. if
> >     svc_xprt_enqueue() exits due to a lack of write space).  So the close
> >     could in theory be delayed indefinitely.  We should be calling
> >     svc_xprt_enqueue() after every set of XPT_CLOSE.
> >     
> >     Also with svc_close_all() no longer relying on svc_close, it no longer
> >     needs to be able to immediately do the svc_delete_xprt() itself.
> >     
> >     Signed-off-by: J. Bruce Fields <bfields@redhat.com>
> > 
> > diff --git a/net/sunrpc/svc_xprt.c b/net/sunrpc/svc_xprt.c
> > index 8c018df..dfee123 100644
> > --- a/net/sunrpc/svc_xprt.c
> > +++ b/net/sunrpc/svc_xprt.c
> > @@ -928,11 +928,7 @@ void svc_delete_xprt(struct svc_xprt *xprt)
> >  void svc_close_xprt(struct svc_xprt *xprt)
> >  {
> >  	set_bit(XPT_CLOSE, &xprt->xpt_flags);
> > -	if (test_and_set_bit(XPT_BUSY, &xprt->xpt_flags))
> > -		/* someone else will have to effect the close */
> > -		return;
> > -
> > -	svc_delete_xprt(xprt);
> > +	svc_xprt_enqueue(xprt);
> >  }
> >  EXPORT_SYMBOL_GPL(svc_close_xprt);
> >  
> 
> I'm not quite so sure about this one.
> 
> svc_close_xprt gets called when user-space writes some magic string to some
> magic file.  This could be done when there are no active nfsd threads.
> It is a bit far fetched, but you could tell nfsd to open a socket, then tell
> it to close it, before telling it to start any threads.
> 
> In that case the socket would stay open until the first thread was started.

Thanks, that's an odd case, but I think you're right.  OK:

--b.

commit 6a04c0fa098b60e93d4077c12f7fa7a2f189df95
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Mon Oct 25 20:24:48 2010 -0400

    svcrpc: fix minor svc_close_xprt race
    
    We're assuming that in the XPT_BUSY case, somebody else will take care
    of the close.  But that's not necessarily the case.  So the close could
    in theory be delayed indefinitely.

    We should instead be calling svc_xprt_enqueue() after every set of
    XPT_CLOSE.
    
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>

diff --git a/net/sunrpc/svc_xprt.c b/net/sunrpc/svc_xprt.c
index 8c018df..99996ad 100644
--- a/net/sunrpc/svc_xprt.c
+++ b/net/sunrpc/svc_xprt.c
@@ -928,10 +928,17 @@ void svc_delete_xprt(struct svc_xprt *xprt)
 void svc_close_xprt(struct svc_xprt *xprt)
 {
 	set_bit(XPT_CLOSE, &xprt->xpt_flags);
-	if (test_and_set_bit(XPT_BUSY, &xprt->xpt_flags))
+	if (test_and_set_bit(XPT_BUSY, &xprt->xpt_flags)) {
 		/* someone else will have to effect the close */
+		svc_xprt_enqueue(xprt);
 		return;
-
+	}
+	/*
+	 * We expect svc_close_xprt() to work even when no threads are
+	 * running (e.g., while configuring the server before starting
+	 * any threads), so if the transport isn't busy, we delete
+	 * it ourself:
+	 */
 	svc_delete_xprt(xprt);
 }
 EXPORT_SYMBOL_GPL(svc_close_xprt);

  reply	other threads:[~2010-10-26 12:59 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-01 12:17 Relocate NFS root FS for maintenance Greg
2010-09-01 17:34 ` J. Bruce Fields
2010-09-01 21:52 ` Tom Haynes
2010-09-02  7:32   ` Greg
2010-09-02 16:06     ` J. Bruce Fields
2010-09-07  6:59       ` Greg
2010-09-02  6:56 ` statfs() gives ESTALE error Menyhart Zoltan
2010-09-07 18:32   ` Trond Myklebust
2010-09-08 13:33 ` Re :statfs() " Menyhart Zoltan
2010-09-08 20:25   ` Trond Myklebust
2010-09-09  8:12 ` Menyhart Zoltan
2010-09-20 12:49 ` Locking question around "...PagePrivate()" Menyhart Zoltan
2010-09-20 13:55   ` Trond Myklebust
2010-10-05  8:22 ` "xprt" reference count drops to 0 Menyhart Zoltan
2010-10-21 20:38   ` J. Bruce Fields
2010-10-22 15:00     ` Menyhart Zoltan
2010-10-22 21:20       ` J. Bruce Fields
2010-10-22 23:01         ` J. Bruce Fields
2010-10-22 23:21           ` J. Bruce Fields
2010-10-23  3:32             ` J. Bruce Fields
2010-10-25  1:09               ` J. Bruce Fields
2010-10-25  1:21                 ` [PATCH 1/4] svcrpc: never clear XPT_BUSY on dead xprt J. Bruce Fields
2010-10-25  1:43                   ` Neil Brown
2010-10-25 20:21                     ` J. Bruce Fields
2010-10-25 22:58                       ` Neil Brown
2010-10-25 23:03                         ` J. Bruce Fields
2010-10-25 23:54                           ` Neil Brown
2010-10-26  0:11                             ` J. Bruce Fields
2010-10-26  0:28                               ` J. Bruce Fields
2010-10-26  0:30                                 ` J. Bruce Fields
2010-10-26  1:28                                   ` Neil Brown
2010-10-26 12:59                                     ` J. Bruce Fields [this message]
2010-10-26 16:05                                       ` J. Bruce Fields
2010-11-12 19:00                                         ` J. Bruce Fields
2010-10-25  1:21                 ` [PATCH 2/4] svcrpc: assume svc_delete_xprt() called only once J. Bruce Fields
2010-10-25  1:21                 ` [PATCH 3/4] svcrpc: no need for XPT_DEAD check in svc_xprt_enqueue J. Bruce Fields
2010-10-25  1:21                 ` [PATCH 4/4] svcrpc: svc_tcp_sendto XTP_DEAD check is redundant J. Bruce Fields
2010-10-25  2:10                   ` Neil Brown
2010-10-25 15:03                     ` J. Bruce Fields
2010-10-25 17:46                       ` J. Bruce Fields
2010-10-25 23:08                         ` Neil Brown
2010-10-26  1:33                           ` J. Bruce Fields
2010-10-25 23:23                       ` Neil Brown
2010-10-26  1:25                         ` J. Bruce Fields
2010-10-25 11:56         ` "xprt" reference count drops to 0 Menyhart Zoltan
2010-10-25 14:36           ` J. Bruce Fields

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20101026125947.GA19445@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=Zoltan.Menyhart@bull.net \
    --cc=bfields@redhat.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=neilb@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.