From patchwork Wed Sep 5 07:49:27 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Yan-Pai Chen X-Patchwork-Id: 1405831 Return-Path: X-Original-To: patchwork-linux-nfs@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork1.kernel.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by patchwork1.kernel.org (Postfix) with ESMTP id BE3BE40220 for ; Wed, 5 Sep 2012 07:55:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751388Ab2IEHzH (ORCPT ); Wed, 5 Sep 2012 03:55:07 -0400 Received: from plane.gmane.org ([80.91.229.3]:40252 "EHLO plane.gmane.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751128Ab2IEHzG (ORCPT ); Wed, 5 Sep 2012 03:55:06 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1T9ARz-000202-IJ for linux-nfs@vger.kernel.org; Wed, 05 Sep 2012 09:55:05 +0200 Received: from 59-124-179-67.HINET-IP.hinet.net ([59.124.179.67]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 05 Sep 2012 09:55:03 +0200 Received: from yanpai.chen by 59-124-179-67.HINET-IP.hinet.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 05 Sep 2012 09:55:03 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: linux-nfs@vger.kernel.org From: Yan-Pai Chen Subject: Re: [3.2.5] NFSv3 =?utf-8?b?Q0xPU0VfV0FJVA==?= hang Date: Wed, 5 Sep 2012 07:49:27 +0000 (UTC) Lines: 47 Message-ID: References: <20110909194509.GB6195@hostway.ca> <1315610322.17611.112.camel@lade.trondhjem.org> <20111020190334.GA22772@hostway.ca> <20120301225524.GB27595@hostway.ca> <20120302002511.GA4495@hostway.ca> <20120302184918.GA20702@hostway.ca> Mime-Version: 1.0 X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 59.124.179.67 (Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.0 Safari/537.4) Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org Simon Kirby 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. --- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html 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); }