From patchwork Mon Nov 21 18:14:17 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Cooper X-Patchwork-Id: 126887 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id F0E08B6F18 for ; Tue, 22 Nov 2011 05:14:24 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753729Ab1KUSOU (ORCPT ); Mon, 21 Nov 2011 13:14:20 -0500 Received: from smtp02.citrix.com ([66.165.176.63]:56306 "EHLO SMTP02.CITRIX.COM" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752924Ab1KUSOT (ORCPT ); Mon, 21 Nov 2011 13:14:19 -0500 X-IronPort-AV: E=Sophos;i="4.69,548,1315195200"; d="scan'208";a="171400813" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 21 Nov 2011 13:14:18 -0500 Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Mon, 21 Nov 2011 13:14:18 -0500 Message-ID: <4ECA94F9.4090503@citrix.com> Date: Mon, 21 Nov 2011 18:14:17 +0000 From: Andrew Cooper User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: Trond Myklebust , "linux-nfs@vger.kernel.org" , "netdev@vger.kernel.org" Subject: Re: NFS TCP race condition with SOCK_ASYNC_NOSPACE References: <4EC6A681.30902@citrix.com> <1321642368.2653.35.camel@lade.trondhjem.org> <4EC6AC47.60404@citrix.com> <1321643673.2653.41.camel@lade.trondhjem.org> <4EC6B82B.3000701@citrix.com> In-Reply-To: <4EC6B82B.3000701@citrix.com> X-Enigmail-Version: 1.1.2 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Following some debugging, I believe that the attached patch fixes the problem. Simply returning EAGAIN is not sufficient, as the task does not get requeued, and times out 13 seconds later (as per our mount options). Setting the SOCK_ASYNC_NOSPACE bit causes the requeue to happen. I realize that this is a gross hack and I should probably not be using SOCK_ASYNC_NOSPACE in that way. Is there a better way to achieve the same solution? diff -r 69bd2176baf9 net/sunrpc/xprtsock.c --- a/net/sunrpc/xprtsock.c Mon Nov 07 13:00:06 2011 +0000 +++ b/net/sunrpc/xprtsock.c Mon Nov 21 18:00:14 2011 +0000 @@ -503,17 +503,16 @@ static int xs_nospace(struct rpc_task *t /* Don't race with disconnect */ if (xprt_connected(xprt)) { - if (test_bit(SOCK_ASYNC_NOSPACE, &transport->sock->flags)) { - ret = -EAGAIN; - /* - * Notify TCP that we're limited by the application - * window size - */ - set_bit(SOCK_NOSPACE, &transport->sock->flags); - transport->inet->sk_write_pending++; - /* ...and wait for more buffer space */ - xprt_wait_for_buffer_space(task, xs_nospace_callback); - } + set_bit(SOCK_ASYNC_NOSPACE, &transport->sock->flags); + ret = -EAGAIN; + /* + * Notify TCP that we're limited by the application + * window size + */ + set_bit(SOCK_NOSPACE, &transport->sock->flags); + transport->inet->sk_write_pending++; + /* ...and wait for more buffer space */ + xprt_wait_for_buffer_space(task, xs_nospace_callback); } else { clear_bit(SOCK_ASYNC_NOSPACE, &transport->sock->flags); ret = -ENOTCONN;