Subject: Re: [PATCH 4/7] xen/9pfs: connect to the backend
To: Stefano Stabellini <sstabellini@kernel.org>
References: <alpine.DEB.2.10.1703061147250.17906@sstabellini-ThinkPad-X260>
 <1488830488-18506-1-git-send-email-sstabellini@kernel.org>
 <1488830488-18506-4-git-send-email-sstabellini@kernel.org>
 <ef22f20a-8930-34d5-9be7-77cebf664aab@oracle.com>
 <alpine.DEB.2.10.1703071557470.17906@sstabellini-ThinkPad-X260>
Cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org,
        Stefano Stabellini <stefano@aporeto.com>, jgross@suse.com,
        Eric Van Hensbergen <ericvh@gmail.com>,
        Ron Minnich <rminnich@sandia.gov>, Latchesar Ionkov <lucho@ionkov.net>,
        v9fs-developer@lists.sourceforge.net
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Message-ID: <7a016728-5a22-6ab0-a34a-4f7354927cf1@oracle.com>
Date: Wed, 8 Mar 2017 08:47:45 -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: <alpine.DEB.2.10.1703071557470.17906@sstabellini-ThinkPad-X260>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2695
Lines: 90


>  
>>> +	ring->bytes = (void*)__get_free_pages(GFP_KERNEL | __GFP_ZERO, XEN_9PFS_RING_ORDER);
>>> +	if (ring->bytes == NULL)
>>> +		goto error;
>>> +	for (i = 0; i < (1 << XEN_9PFS_RING_ORDER); i++)
>>> +		ring->intf->ref[i] = gnttab_grant_foreign_access(dev->otherend_id, pfn_to_gfn(virt_to_pfn((void*)ring->bytes) + i), 0);
>>> +	ring->ref = gnttab_grant_foreign_access(dev->otherend_id, pfn_to_gfn(virt_to_pfn((void*)ring->intf)), 0);
>>> +	ring->ring.in = ring->bytes;
>>> +	ring->ring.out = ring->bytes + XEN_9PFS_RING_SIZE;
>>> +
>>> +	ret = xenbus_alloc_evtchn(dev, &ring->evtchn);
>>> +	if (ret)
>>> +		goto error;
>>> +	ring->irq = bind_evtchn_to_irqhandler(ring->evtchn, xen_9pfs_front_event_handler,
>>> +					0, "xen_9pfs-frontend", ring);
>>> +	if (ring->irq < 0) {
>>> +		xenbus_free_evtchn(dev, ring->evtchn);
>>> +		ret = ring->irq;
>>> +		goto error;
>>> +	}
>>>  	return 0;
>>> +
>>> +error:
>> You may need to gnttab_end_foreign_access().
> Actually this error path is unnecessary because it will be handled by
> xen_9pfs_front_probe, that calls xen_9pfs_front_free on errors. I'll
> remove it.


(It's a matter of personal preference but I think a routine should clean
up its own mess whenever it can.)


>
>
> +
> + again:
> +	ret = xenbus_transaction_start(&xbt);
> +	if (ret) {
> +		xenbus_dev_fatal(dev, ret, "starting transaction");
> +		goto error;
> +	}
> +	ret = xenbus_printf(xbt, dev->nodename, "version", "%u", 1);
> +	if (ret)
> +		goto error_xenbus;
> +	ret = xenbus_printf(xbt, dev->nodename, "num-rings", "%u", priv->num_rings);
> +	if (ret)
> +		goto error_xenbus;
> +	for (i = 0; i < priv->num_rings; i++) {
> +		char str[16];
> +
> +		priv->rings[i].priv = priv;
> +		ret = xen_9pfs_front_alloc_dataring(dev, &priv->rings[i]);
>> Not for -EAGAIN, I think.
> I don't think xen_9pfs_front_alloc_dataring can return EAGAIN. EAGAIN
> can only come from xenbus_transaction_end, the case we handle below.

I didn't mean that xen_9pfs_front_alloc_dataring() can return -EAGAIN. I
was referring to...

>
>
>>> +		if (ret < 0)
>>> +			goto error_xenbus;
>>> +
>>> +		sprintf(str, "ring-ref%u", i);
>>> +		ret = xenbus_printf(xbt, dev->nodename, str, "%d", priv->rings[i].ref);
>>> +		if (ret)
>>> +			goto error_xenbus;
>>> +
>>> +		sprintf(str, "event-channel-%u", i);
>>> +		ret = xenbus_printf(xbt, dev->nodename, str, "%u", priv->rings[i].evtchn);
>>> +		if (ret)
>>> +			goto error_xenbus;
>>> +	}
>>> +	priv->tag = xenbus_read(xbt, dev->nodename, "tag", NULL);
>>> +	if (ret)
>>> +		goto error_xenbus;
>>> +	ret = xenbus_transaction_end(xbt, 0);
>>> +	if (ret) {
>>> +		if (ret == -EAGAIN)
>>> +			goto again;

... this.

Sorry for not being clear.

-boris