Simon Kirby <sim@...> writes: > > Here's another CLOSE_WAIT hang, 3.2.5 client, 3.2.2 knfsd server, NFSv3. > Not sure why these are all happening again now. This cluster seems to > have a set of customers that are good at breaking things. ;) Hi all, I have the same problem in 3.3 kernel (client). After applying the following modification as suggested by Dick in http://www.spinics.net/lists/linux-nfs/msg32407.html, the problem is just gone. Does anyone know if they are related? Thanks. diff --git a/net/sunrpc/xprt.c b/net/sunrpc/xprt.c index c64c0ef..f979e9f 100644 --- a/net/sunrpc/xprt.c +++ b/net/sunrpc/xprt.c @@ -1071,24 +1071,9 @@ void xprt_reserve(struct rpc_task *task) { struct rpc_xprt *xprt = task->tk_xprt; - task->tk_status = 0; - if (task->tk_rqstp != NULL) - return; - - /* Note: grabbing the xprt_lock_write() here is not strictly needed, - * but ensures that we throttle new slot allocation if the transport - * is congested (e.g. if reconnecting or if we're out of socket - * write buffer space). - */ - task->tk_timeout = 0; - task->tk_status = -EAGAIN; - if (!xprt_lock_write(xprt, task)) - return; - spin_lock(&xprt->reserve_lock); xprt_alloc_slot(task); spin_unlock(&xprt->reserve_lock); - xprt_release_write(xprt, task); } -- 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
