From: "J. Bruce Fields" <bfields@fieldses.org>
To: Mi Jinlong <mijinlong@cn.fujitsu.com>
Cc: NFSv3 list <linux-nfs@vger.kernel.org>,
"Trond.Myklebust" <trond.myklebust@fys.uio.no>,
Chuck Lever <chuck.lever@oracle.com>
Subject: Re: [RFC] kernel panic at svc_xprt_release
Date: Mon, 29 Mar 2010 21:07:53 -0400 [thread overview]
Message-ID: <20100330010753.GH24251@fieldses.org> (raw)
In-Reply-To: <20100330005748.GG24251@fieldses.org>
On Mon, Mar 29, 2010 at 08:57:48PM -0400, J. Bruce Fields wrote:
> Hm, OK, so it does look like tcp_close() can sleep, so we are wrong to
> be calling svc_xprt_put() while holding sv_lock.
>
> The commit ab1b18f "sunrpc: remove unnecessary svc_xprt_put" gets rid of
> one svc_xprt_put(), and the remaining final svc_xprt_put() could easily
> be delayed till after we drop the lock.
So, perhaps we want the following.
--b.
commit 788e69e548cc8d127b90f0de1f7b7e983d1d587a
Author: J. Bruce Fields <bfields@citi.umich.edu>
Date: Mon Mar 29 21:02:31 2010 -0400
svcrpc: don't hold sv_lock over svc_xprt_put()
svc_xprt_put() can call tcp_close(), which can sleep, so we shouldn't be
holding this lock.
In fact, only the xpt_list removal and the sv_tmpcnt decrement should
need the sv_lock here.
Reported-by: Mi Jinlong <mijinlong@cn.fujitsu.com>
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
diff --git a/net/sunrpc/svc_xprt.c b/net/sunrpc/svc_xprt.c
index 8f0f1fb..c334f54 100644
--- a/net/sunrpc/svc_xprt.c
+++ b/net/sunrpc/svc_xprt.c
@@ -892,12 +892,12 @@ void svc_delete_xprt(struct svc_xprt *xprt)
*/
if (test_bit(XPT_TEMP, &xprt->xpt_flags))
serv->sv_tmpcnt--;
+ spin_unlock_bh(&serv->sv_lock);
while ((dr = svc_deferred_dequeue(xprt)) != NULL)
kfree(dr);
svc_xprt_put(xprt);
- spin_unlock_bh(&serv->sv_lock);
}
void svc_close_xprt(struct svc_xprt *xprt)
prev parent reply other threads:[~2010-03-30 1:05 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-24 9:39 [RFC] kernel panic at svc_xprt_release Mi Jinlong
2010-03-30 0:57 ` J. Bruce Fields
2010-03-30 1:07 ` J. Bruce Fields [this message]
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=20100330010753.GH24251@fieldses.org \
--to=bfields@fieldses.org \
--cc=chuck.lever@oracle.com \
--cc=linux-nfs@vger.kernel.org \
--cc=mijinlong@cn.fujitsu.com \
--cc=trond.myklebust@fys.uio.no \
/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.