Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp1029119ybp; Thu, 17 Oct 2019 07:05:26 -0700 (PDT) X-Google-Smtp-Source: APXvYqwAFSyZGdDfS4E6FpmJLREY8NiwxbJSO0Zy+6cWeJ3ZigEZ7nYh8LuhbdUaqPenRAG2ftdv X-Received: by 2002:a17:906:6ad7:: with SMTP id q23mr3507537ejs.214.1571321126503; Thu, 17 Oct 2019 07:05:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1571321126; cv=none; d=google.com; s=arc-20160816; b=QIv7bCNnC+UceORXao0OPQu205sqFfcBwWGSYwSZm4/qlyhef2QZLDinNXWPmoEKA0 FjOTCVLxAw8DAlFoICXlWeia13ABhkcfeSySXEajYuoPd7c0o6LQKoNck8h5S5kR25DT qhloA/dvtzO5LaRF+is32KUgGGQGo1vhk4ct/HLrV/rMSnCxadts/BJYbbAF6LuHKqNN 4x7W+4rBu6pz4qrmVFPNVwvYxXScqmxFKM5n1G7Ty9hBVI+0n9XRWf8Oh2K4r87Wxk5V fdF8ckXpwangG1S62r1Q2Nf1+3dyY3R/26y7pxcijWkRkxc1PFppiLAPDKTwR5YVTU3M Uyyw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=NzeCHHGvBxcbX2DpzGdvIt6YgyclVDu/jgvSly8zu9E=; b=uTT+dB9uypSyw8lvc0P2Q4T0IRL1CrRy4h724wGVy/rOoZ+P2ye7RW4OlbtFIMNwZM tl+mpZhwLt1vFN50Oa2BI8w8N1IiLjcyaXJtyae1vN/y5q4N4T9ymhJsdm3HZgq42Rgw OLJ7XlP1AsIrZ7oXEaL1T8m9cGQeP9oPCdSDPz1aq7EmaSJow5dNrrVH1K88NxEKvDzT KlbK7G1y1fsP1nSqjsssZebeVm0JPgmf+yis2q5YiK1Y+mCaeFT+XKVtkxXUvj/0prJE OLwHgBoIRZNPBn2WPmf+cHuW8z9gFcvzlR2qrmbof/btQoKe+ZlcrJnloiQhmZF1biiY iMsA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 4si1649186ejc.382.2019.10.17.07.04.51; Thu, 17 Oct 2019 07:05:26 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730322AbfJPViO (ORCPT + 99 others); Wed, 16 Oct 2019 17:38:14 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42642 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727447AbfJPViO (ORCPT ); Wed, 16 Oct 2019 17:38:14 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7AF2F30832C0; Wed, 16 Oct 2019 21:38:14 +0000 (UTC) Received: from pick.fieldses.org (ovpn-120-208.rdu2.redhat.com [10.10.120.208]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 4DC2060852; Wed, 16 Oct 2019 21:38:14 +0000 (UTC) Received: by pick.fieldses.org (Postfix, from userid 2815) id 6583F120272; Wed, 16 Oct 2019 17:38:13 -0400 (EDT) Date: Wed, 16 Oct 2019 17:38:13 -0400 From: "J. Bruce Fields" To: Trond Myklebust Cc: linux-nfs@vger.kernel.org, Neil Brown , Chuck Lever , Anna Schumaker Subject: Re: [PATCH 1/3] SUNRPC: The TCP back channel mustn't disappear while requests are outstanding Message-ID: <20191016213813.GB1987@pick.fieldses.org> References: <20191016141546.32277-1-trond.myklebust@hammerspace.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191016141546.32277-1-trond.myklebust@hammerspace.com> User-Agent: Mutt/1.12.1 (2019-06-15) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.44]); Wed, 16 Oct 2019 21:38:14 +0000 (UTC) Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org These make sense to me. (But I'll confess I haven't been following the back and forth with Neil.) On Wed, Oct 16, 2019 at 10:15:44AM -0400, Trond Myklebust wrote: > If there are TCP back channel requests either being processed by the In this patch and the next, is the "either" unnecessary, or was there some other condition you meant to mention? --b. > server threads, then we should hold a reference to the transport > to ensure it doesn't get freed from underneath us. > > Reported-by: Neil Brown > Fixes: 2ea24497a1b3 ("SUNRPC: RPC callbacks may be split across several..") > Signed-off-by: Trond Myklebust > --- > net/sunrpc/backchannel_rqst.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/net/sunrpc/backchannel_rqst.c b/net/sunrpc/backchannel_rqst.c > index 339e8c077c2d..7eb251372f94 100644 > --- a/net/sunrpc/backchannel_rqst.c > +++ b/net/sunrpc/backchannel_rqst.c > @@ -307,8 +307,8 @@ void xprt_free_bc_rqst(struct rpc_rqst *req) > */ > dprintk("RPC: Last session removed req=%p\n", req); > xprt_free_allocation(req); > - return; > } > + xprt_put(xprt); > } > > /* > @@ -339,7 +339,7 @@ struct rpc_rqst *xprt_lookup_bc_request(struct rpc_xprt *xprt, __be32 xid) > spin_unlock(&xprt->bc_pa_lock); > if (new) { > if (req != new) > - xprt_free_bc_rqst(new); > + xprt_free_allocation(new); > break; > } else if (req) > break; > @@ -368,6 +368,7 @@ void xprt_complete_bc_request(struct rpc_rqst *req, uint32_t copied) > set_bit(RPC_BC_PA_IN_USE, &req->rq_bc_pa_state); > > dprintk("RPC: add callback request to list\n"); > + xprt_get(xprt); > spin_lock(&bc_serv->sv_cb_lock); > list_add(&req->rq_bc_list, &bc_serv->sv_cb_list); > wake_up(&bc_serv->sv_cb_waitq); > -- > 2.21.0 >