From: J. Bruce Fields <bfields@xxxxxxxxxx> We saw a report of a NULL dereference in xprt_autoclose: https://bugzilla.redhat.com/show_bug.cgi?id=611938 This appears to be the result of an xprt's task_cleanup running after the xprt is destroyed. Nothing in the current code appears to prevent that. Signed-off-by: J. Bruce Fields <bfields@xxxxxxxxxx> --- net/sunrpc/xprt.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) On Tue, Aug 03, 2010 at 02:49:23PM -0400, Trond Myklebust wrote: > Hmm... On the other hand, since xprt_destroy() may get called from > inside the rpciod_workqueue, the wait_on_bit_lock() may end up > deadlocking. > > Nevermind, then. Let's go with the cancel_work_sync(). Here you are--only if you don't have something equivalent already queued up.--b. diff --git a/net/sunrpc/xprt.c b/net/sunrpc/xprt.c index dcd0132..2a1f664 100644 --- a/net/sunrpc/xprt.c +++ b/net/sunrpc/xprt.c @@ -1129,6 +1129,7 @@ static void xprt_destroy(struct kref *kref) rpc_destroy_wait_queue(&xprt->sending); rpc_destroy_wait_queue(&xprt->resend); rpc_destroy_wait_queue(&xprt->backlog); + cancel_work_sync(&xprt->task_cleanup); /* * Tear down transport state and free the rpc_xprt */ -- 1.7.0.4 -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
