Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp6557007imm; Mon, 27 Aug 2018 19:01:02 -0700 (PDT) X-Google-Smtp-Source: ANB0VdZraQMWseo+1NtQaUoF8gYPFlxJWMly7O6A6pgFRGwJAR8cv4SOzhNIAS2YwuSET1Opuu8r X-Received: by 2002:a63:586:: with SMTP id 128-v6mr14530986pgf.169.1535421662481; Mon, 27 Aug 2018 19:01:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1535421662; cv=none; d=google.com; s=arc-20160816; b=JeBoCl9qw4PYkTB00VeCkfF9Dh3nx4Psse8bAzWxsnEkF1BRu41QrKxYcgYmrclOz3 THMHajGZVG+VGt7VF42HzimHM9m6yy1W0qdXdbSjOK2zyncbE9ekzEO8pey88W00S2w5 Q9MTKhaw1Ad+ZQRclJomGYxDe9kxSPLGWalUsBzVZwNGPQih/YZmWkg4i/x21UNGW7ND X6/LymGyfB5Sr/lf4Fg2UiEmLXQOZNMqaLrfYBWWCma1ZIOwaDwGxFt+xaIJZvsm+6zJ ZEy/atR32xBwcXeyxkbqYg4qoADFnArjDTJADln+ndnrPFSC2Ljn2rWP2mPfIpiMTl7O cydw== 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:arc-authentication-results; bh=MzDooZVp6zM07zVf6b75A9usTvwgyWoSTsM9Mxc2m2o=; b=EzoD6UZhrcV0sD6Z0awbiWUr3KKx5NlLr7kFGXFsq1hwuCpgdsZmqb5yzigWL4dLZq sXrLnGxfGcFkQJ9MkDin9VNSEKCQLkqejfhTtRgj8Yj4oCzBoCD7jiE5uZR3WU1YT478 tLdEXqxZmSbkHWAmVR5mTgo/6L4IP0k3lAytzZIXJUMyWXaJhYQ7s5ZM0Q51KzMhVYAh vcAee/QrA4pSJaLVHabYCd1HJoUvPkkvrshpPhWi+arNzxYcYMkYuaT4duZUMAzTilHe zZZDtgvE/cajprIzNuNWD7pPHjCI5a3vU2jCdRqwM54t2BRpA+pLamu9I+U9BSy639IR s6/A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f185-v6si882659pgc.625.2018.08.27.19.00.47; Mon, 27 Aug 2018 19:01:02 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-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-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727518AbeH1Fra (ORCPT + 99 others); Tue, 28 Aug 2018 01:47:30 -0400 Received: from nautica.notk.org ([91.121.71.147]:39116 "EHLO nautica.notk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726909AbeH1Fra (ORCPT ); Tue, 28 Aug 2018 01:47:30 -0400 Received: by nautica.notk.org (Postfix, from userid 1001) id 90974C009; Tue, 28 Aug 2018 03:58:09 +0200 (CEST) Date: Tue, 28 Aug 2018 03:57:54 +0200 From: Dominique Martinet To: piaojun , Greg Kurz Cc: Tomas Bortoli , lucho@ionkov.net, Dominique Martinet , ericvh@gmail.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, syzkaller@googlegroups.com, v9fs-developer@lists.sourceforge.net, rminnich@sandia.gov, davem@davemloft.net Subject: Re: [V9fs-developer] [PATCH v2 2/2] 9p: Add refcount to p9_req_t Message-ID: <20180828015754.GA8117@nautica> References: <20180814174342.11068-1-tomasbortoli@gmail.com> <20180814174342.11068-2-tomasbortoli@gmail.com> <20180827230954.GA21513@nautica> <5B84A051.6070903@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <5B84A051.6070903@huawei.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org piaojun wrote on Tue, Aug 28, 2018: > > (Jun, I think you'll need to ask again to rename 'req' to 'rreq' if you > > think it's important -- I think such a rename should go in a separate > > patch anyway, there's plenty of time until the 4.20 merge window) > > > > I still think such a rename is necessary, and as you said, it will be > better go in another patch. Tomas can you send a patch for that please? It's not very interesting, but might as well finish this properly :) > >> diff --git a/net/9p/client.c b/net/9p/client.c > >> index 7942c0bfcc5b..c9bb5d41afa4 100644 > >> --- a/net/9p/client.c > >> +++ b/net/9p/client.c > >> @@ -716,6 +756,8 @@ p9_client_rpc(struct p9_client *c, int8_t type, const char *fmt, ...) > >> > >> err = c->trans_mod->request(c, req); > >> if (err < 0) { > >> + /* write won't happen */ > >> + p9_req_put(req); > >> if (err != -ERESTARTSYS && err != -EFAULT) > >> c->status = Disconnected; > >> goto recalc_sigpending; > > > > p9_client_zc_rpc needs the same put if zc_request failed, I'm not sure > > why it wasn't here in my draft Ah, I remember a bit better now, this is not as simple as adding the same check after zc_request because the zc_request embeds the wait itself to do its own cleanup after the reply came (unpin pages that were sent to the server). This brings in an interesting race condition that if the wait_event_killable() in the zc_request is interrupted, the user data pages that were pinned get unpinned and could potentially be moved before the server replies... Even if they're not moved the user would be told the read/write failed and could reuse the memory that would be read/written later. I'm not sure how this part works but it's probably not great. Greg, do you have an opinion on this? This is tricky, we cannot even rely on the refcounting for this as the zc pages are likely user pages, so it'll be bad if we return from the syscall and the memory gets accessed later. On the other hand making that wait non-killable isn't a good solution either, and we cannot use flush for virtio, so I don't have any idea for this... Any magic virtio "take-back"? Well, this would be for another patch anyway - for now I'll just do the p9_req_put if it hasn't been kicked so that means something like the following diff.. But my test bed is currently down so I'll wait for tests to push: -------8<---------------- diff --git a/net/9p/trans_virtio.c b/net/9p/trans_virtio.c index 7728b0acde09..36a1401c0722 100644 --- a/net/9p/trans_virtio.c +++ b/net/9p/trans_virtio.c @@ -404,6 +404,7 @@ p9_virtio_zc_request(struct p9_client *client, struct p9_req_t *req, struct scatterlist *sgs[4]; size_t offs; int need_drop = 0; + int kicked = 0; p9_debug(P9_DEBUG_TRANS, "virtio request\n"); @@ -498,6 +499,7 @@ p9_virtio_zc_request(struct p9_client *client, struct p9_req_t *req, } virtqueue_kick(chan->vq); spin_unlock_irqrestore(&chan->lock, flags); + kicked = 1; p9_debug(P9_DEBUG_TRANS, "virtio request kicked\n"); err = wait_event_killable(req->wq, req->status >= REQ_STATUS_RCVD); /* @@ -518,6 +520,10 @@ p9_virtio_zc_request(struct p9_client *client, struct p9_req_t *req, } kvfree(in_pages); kvfree(out_pages); + if (!kicked) { + /* reply won't come */ + p9_req_put(req); + } return err; } -------8<---------------- -- Dominique