To: linux-nfs@vger.kernel.org
Mime-Version: 1.0
Reply-To: dick.streefland@altium.nl (Dick Streefland)
References: <4d25.5034e746.eefd1@altium.nl> <4d25.5034e746.eefd1@altium.nl> <503609BF.60809@panasas.com> <2bd0.50368cb9.925d7@altium.nl>
From: dick.streefland@altium.nl (Dick Streefland)
Subject: Re: NFSv3 client hang on many simultanious reads
Content-Type: text/plain; charset=us-ascii
Message-ID: <6876.503e06e7.53da5@altium.nl>
Date: Wed, 29 Aug 2012 12:11:19 -0000
From: rnews@altium.nl
Sender: linux-nfs-owner@vger.kernel.org

dick.streefland@altium.nl (Dick Streefland) wrote:
| Could this chunk cause a deadlock?
| 
| @@ -1001,10 +1004,25 @@ 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;
| +
|  	task->tk_status = -EIO;
|  	spin_lock(&xprt->reserve_lock);
|  	xprt_alloc_slot(task);
|  	spin_unlock(&xprt->reserve_lock);
| +	xprt_release_write(xprt, task);
|  }

I doublechecked, and this chunk does indeed cause the hang.
According to the comment, the lock is not strictly needed.
So how about simply reverting this?

-- 
Dick