Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932526AbdCGPvX (ORCPT ); Tue, 7 Mar 2017 10:51:23 -0500 Received: from userp1050.oracle.com ([156.151.31.82]:16389 "EHLO userp1050.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752573AbdCGPvO (ORCPT ); Tue, 7 Mar 2017 10:51:14 -0500 Subject: Re: [PATCH 6/7] xen/9pfs: receive responses To: Stefano Stabellini , xen-devel@lists.xenproject.org References: <1488830488-18506-1-git-send-email-sstabellini@kernel.org> <1488830488-18506-6-git-send-email-sstabellini@kernel.org> Cc: linux-kernel@vger.kernel.org, Stefano Stabellini , jgross@suse.com, Eric Van Hensbergen , Ron Minnich , Latchesar Ionkov , v9fs-developer@lists.sourceforge.net From: Boris Ostrovsky Message-ID: Date: Tue, 7 Mar 2017 10:49:59 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <1488830488-18506-6-git-send-email-sstabellini@kernel.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Source-IP: userp1040.oracle.com [156.151.31.81] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2978 Lines: 101 On 03/06/2017 03:01 PM, Stefano Stabellini wrote: > Upon receiving a notification from the backend, schedule the > p9_xen_response work_struct. p9_xen_response checks if any responses are > available, if so, it reads them one by one, calling p9_client_cb to send > them up to the 9p layer (p9_client_cb completes the request). Handle the > ring following the Xen 9pfs specification. > > Signed-off-by: Stefano Stabellini > CC: boris.ostrovsky@oracle.com > CC: jgross@suse.com > CC: Eric Van Hensbergen > CC: Ron Minnich > CC: Latchesar Ionkov > CC: v9fs-developer@lists.sourceforge.net > --- > net/9p/trans_xen.c | 53 +++++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 53 insertions(+) > > diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c > index 4e26556..1ca9246 100644 > --- a/net/9p/trans_xen.c > +++ b/net/9p/trans_xen.c > @@ -149,6 +149,59 @@ static int p9_xen_request(struct p9_client *client, struct p9_req_t *p9_req) > > static void p9_xen_response(struct work_struct *work) > { > + struct xen_9pfs_front_priv *priv; > + struct xen_9pfs_dataring *ring; > + RING_IDX cons, prod, masked_cons, masked_prod; > + struct xen_9pfs_header h; > + struct p9_req_t *req; > + int status = REQ_STATUS_ERROR; Doesn't this need to go inside the loop? > + > + ring = container_of(work, struct xen_9pfs_dataring, work); > + priv = ring->priv; > + > + while (1) { > + cons = ring->intf->in_cons; > + prod = ring->intf->in_prod; > + rmb(); Is this rmb() or mb()? (Or, in fact, virt_XXX()?) You used mb() in the previous patch. > + > + if (xen_9pfs_queued(prod, cons, XEN_9PFS_RING_SIZE) < sizeof(h)) { > + notify_remote_via_irq(ring->irq); > + return; > + } > + > + masked_prod = xen_9pfs_mask(prod, XEN_9PFS_RING_SIZE); > + masked_cons = xen_9pfs_mask(cons, XEN_9PFS_RING_SIZE); > + > + xen_9pfs_read_packet(ring->ring.in, > + masked_prod, &masked_cons, > + XEN_9PFS_RING_SIZE, &h, sizeof(h)); > + > + req = p9_tag_lookup(priv->client, h.tag); > + if (!req || req->status != REQ_STATUS_SENT) { > + dev_warn(&priv->dev->dev, "Wrong req tag=%x\n", h.tag); > + cons += h.size; > + mb(); > + ring->intf->in_cons = cons; > + continue; I don't know what xen_9pfs_read_packet() does so perhaps it's done there but shouldn't the pointers be updated regardless of the 'if' condition? -boris > + } > + > + memcpy(req->rc, &h, sizeof(h)); > + req->rc->offset = 0; > + > + masked_cons = xen_9pfs_mask(cons, XEN_9PFS_RING_SIZE); > + xen_9pfs_read_packet(ring->ring.in, > + masked_prod, &masked_cons, > + XEN_9PFS_RING_SIZE, req->rc->sdata, h.size); > + > + mb(); > + cons += h.size; > + ring->intf->in_cons = cons; > + > + if (req->status != REQ_STATUS_ERROR) > + status = REQ_STATUS_RCVD; > + > + p9_client_cb(priv->client, req, status); > + } > } > > static irqreturn_t xen_9pfs_front_event_handler(int irq, void *r) >