mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Juergen Gross <jgross@suse.com>
To: Stefano Stabellini <sstabellini@kernel.org>,
	xen-devel@lists.xenproject.org
Cc: linux-kernel@vger.kernel.org, boris.ostrovsky@oracle.com,
	Stefano Stabellini <stefano@aporeto.com>,
	Eric Van Hensbergen <ericvh@gmail.com>,
	Ron Minnich <rminnich@sandia.gov>,
	Latchesar Ionkov <lucho@ionkov.net>,
	v9fs-developer@lists.sourceforge.net
Subject: Re: [PATCH v3 4/7] xen/9pfs: connect to the backend
Date: Tue, 14 Mar 2017 07:41:46 +0100	[thread overview]
Message-ID: <cca25001-e2a8-8ccb-8e87-42f152293f35@suse.com> (raw)
In-Reply-To: <1489449019-13343-4-git-send-email-sstabellini@kernel.org>

On 14/03/17 00:50, Stefano Stabellini wrote:
> Implement functions to handle the xenbus handshake. Upon connection,
> allocate the rings according to the protocol specification.
> 
> Initialize a work_struct and a wait_queue. The work_struct will be used
> to schedule work upon receiving an event channel notification from the
> backend. The wait_queue will be used to wait when the ring is full and
> we need to send a new request.
> 
> Signed-off-by: Stefano Stabellini <stefano@aporeto.com>
> CC: boris.ostrovsky@oracle.com
> CC: jgross@suse.com
> CC: Eric Van Hensbergen <ericvh@gmail.com>
> CC: Ron Minnich <rminnich@sandia.gov>
> CC: Latchesar Ionkov <lucho@ionkov.net>
> CC: v9fs-developer@lists.sourceforge.net
> ---
>  net/9p/trans_xen.c | 240 +++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 240 insertions(+)
> 
> diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c
> index f072876..974bac3 100644
> --- a/net/9p/trans_xen.c
> +++ b/net/9p/trans_xen.c
> @@ -41,6 +41,35 @@
>  #include <net/9p/client.h>
>  #include <net/9p/transport.h>
>  
> +#define XEN_9PFS_NUM_RINGS 2
> +
> +/* One per ring, more than one per 9pfs share */
> +struct xen_9pfs_dataring {
> +	struct xen_9pfs_front_priv *priv;
> +
> +	struct xen_9pfs_data_intf *intf;
> +	grant_ref_t ref;
> +	int evtchn;
> +	int irq;
> +	spinlock_t lock;
> +
> +	struct xen_9pfs_data data;
> +	wait_queue_head_t wq;
> +	struct work_struct work;
> +};
> +
> +/* One per 9pfs share */
> +struct xen_9pfs_front_priv {
> +	struct list_head list;
> +	struct xenbus_device *dev;
> +	char *tag;
> +	struct p9_client *client;
> +
> +	int num_rings;
> +	struct xen_9pfs_dataring *rings;
> +};
> +static LIST_HEAD(xen_9pfs_devs);
> +
>  static int p9_xen_cancel(struct p9_client *client, struct p9_req_t *req)
>  {
>  	return 0;
> @@ -60,6 +89,21 @@ static int p9_xen_request(struct p9_client *client, struct p9_req_t *p9_req)
>  	return 0;
>  }
>  
> +static void p9_xen_response(struct work_struct *work)
> +{
> +}
> +
> +static irqreturn_t xen_9pfs_front_event_handler(int irq, void *r)
> +{
> +	struct xen_9pfs_dataring *ring = r;
> +	BUG_ON(!ring || !ring->priv->client);
> +
> +	wake_up_interruptible(&ring->wq);
> +	schedule_work(&ring->work);
> +
> +	return IRQ_HANDLED;
> +}
> +
>  static struct p9_trans_module p9_xen_trans = {
>  	.name = "xen",
>  	.maxsize = (1 << (XEN_9PFS_RING_ORDER + XEN_PAGE_SHIFT)),
> @@ -76,25 +120,221 @@ static int p9_xen_request(struct p9_client *client, struct p9_req_t *p9_req)
>  	{ "" }
>  };
>  
> +static int xen_9pfs_front_free(struct xen_9pfs_front_priv *priv)

Return type void? You are always returning 0.

> +{
> +	int i, j;
> +
> +	list_del(&priv->list);
> +
> +	for (i = 0; i < priv->num_rings; i++) {
> +		if (priv->rings[i].intf == NULL)
> +			break;
> +		if (priv->rings[i].irq > 0)
> +			unbind_from_irqhandler(priv->rings[i].irq, priv->dev);
> +		if (priv->rings[i].data.in != NULL) {
> +			for (j = 0; j < (1 << XEN_9PFS_RING_ORDER); j++)
> +				gnttab_end_foreign_access(priv->rings[i].intf->ref[j], 0, 0);
> +			free_pages((unsigned long)priv->rings[i].data.in,
> +					XEN_9PFS_RING_ORDER - (PAGE_SHIFT - XEN_PAGE_SHIFT));
> +		}
> +		gnttab_end_foreign_access(priv->rings[i].ref, 0, 0);
> +		free_page((unsigned long)priv->rings[i].intf);
> +	}
> +	kfree(priv->rings);
> +	kfree(priv);
> +
> +	return 0;
> +}
> +
>  static int xen_9pfs_front_remove(struct xenbus_device *dev)
>  {
> +	int ret;
> +	struct xen_9pfs_front_priv *priv = dev_get_drvdata(&dev->dev);
> +
> +	dev_set_drvdata(&dev->dev, NULL);
> +	ret = xen_9pfs_front_free(priv);
> +	return ret;
> +}
> +
> +static int xen_9pfs_front_alloc_dataring(struct xenbus_device *dev,
> +		struct xen_9pfs_dataring *ring)
> +{
> +	int i = 0;
> +	int ret = -ENOMEM;
> +	void *bytes = NULL;
> +
> +	init_waitqueue_head(&ring->wq);
> +	spin_lock_init(&ring->lock);
> +	INIT_WORK(&ring->work, p9_xen_response);
> +
> +	ring->intf = (struct xen_9pfs_data_intf *) get_zeroed_page(GFP_KERNEL | __GFP_ZERO);

I don't think you need __GFP_ZERO here.

> +	if (!ring->intf)
> +		return ret;
> +	ret = ring->ref = gnttab_grant_foreign_access(dev->otherend_id,
> +			virt_to_gfn(ring->intf), 0);
> +	if (ret < 0)
> +		goto out;
> +	bytes = (void*)__get_free_pages(GFP_KERNEL | __GFP_ZERO,

Coding style: (void *)

> +			XEN_9PFS_RING_ORDER - (PAGE_SHIFT - XEN_PAGE_SHIFT));
> +	if (bytes == NULL)
> +		goto out;
> +	for (; i < (1 << XEN_9PFS_RING_ORDER); i++) {
> +		ret = ring->intf->ref[i] = gnttab_grant_foreign_access(
> +				dev->otherend_id, virt_to_gfn(bytes) + i, 0);
> +		if (ret < 0)
> +			goto out;
> +	}
> +	ring->data.in = bytes;
> +	ring->data.out = bytes + XEN_9PFS_RING_SIZE;
> +
> +	ret = xenbus_alloc_evtchn(dev, &ring->evtchn);
> +	if (ret)
> +		goto out;
> +	ring->irq = bind_evtchn_to_irqhandler(ring->evtchn, xen_9pfs_front_event_handler,
> +					0, "xen_9pfs-frontend", ring);

Did you think about using request_threaded_irq() instead of a workqueue?
For an example see e.g. drivers/scsi/xen-scsifront.c

> +	if (ring->irq < 0) {
> +		xenbus_free_evtchn(dev, ring->evtchn);
> +		ret = ring->irq;
> +		goto out;
> +	}
>  	return 0;
> +
> +out:
> +	if (bytes != NULL) {
> +		for (i--; i >= 0; i--)
> +			gnttab_end_foreign_access(ring->intf->ref[i], 0, 0);
> +		free_pages((unsigned long)bytes,
> +				XEN_9PFS_RING_ORDER - (PAGE_SHIFT - XEN_PAGE_SHIFT));
> +	}
> +	gnttab_end_foreign_access(ring->ref, 0, 0);
> +	free_page((unsigned long)ring->intf);
> +	return ret;
>  }
>  
>  static int xen_9pfs_front_probe(struct xenbus_device *dev,
>  		const struct xenbus_device_id *id)
>  {
> +	int ret, i;
> +	struct xenbus_transaction xbt;
> +	struct xen_9pfs_front_priv *priv = NULL;
> +	char *versions;
> +	unsigned int max_rings, max_ring_order, len;
> +
> +	versions = xenbus_read(XBT_NIL, dev->otherend, "versions", &len);
> +	if (!len || strcmp(versions, "1"))

You are leaking versions in case of not being "1".

Can't you use xenbus_read_unsigned() instead of xenbus_read()?

> +		return -EINVAL;
> +	kfree(versions);
> +	ret = xenbus_scanf(XBT_NIL, dev->otherend, "max-rings", "%u", &max_rings);

xenbus_read_unsigned()?

> +	if (ret < 0 || max_rings < XEN_9PFS_NUM_RINGS)
> +		return -EINVAL;
> +	ret = xenbus_scanf(XBT_NIL, dev->otherend, "max-ring-page-order", "%u", &max_ring_order);

xenbus_read_unsigned()

> +	if (ret < 0|| max_ring_order < XEN_9PFS_RING_ORDER)

Coding style (missing space before ||)

> +		return -EINVAL;
> +
> +
> +	priv = kzalloc(sizeof(struct xen_9pfs_front_priv), GFP_KERNEL);
> +	if (!priv)
> +		return -ENOMEM;
> +
> +	priv->dev = dev;
> +	priv->num_rings = XEN_9PFS_NUM_RINGS;
> +	priv->rings = kzalloc(sizeof(struct xen_9pfs_dataring) * priv->num_rings,
> +						GFP_KERNEL);

Coding style: please align the second line to the first parameter of
kzalloc().

> +	if (!priv->rings) {
> +		kfree(priv);
> +		return -ENOMEM;
> +	}
> +
> +	for (i = 0; i < priv->num_rings; i++) {
> +		priv->rings[i].priv = priv;
> +		ret = xen_9pfs_front_alloc_dataring(dev, &priv->rings[i]);
> +		if (ret < 0)
> +			goto error;
> +	}
> +
> + 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];
> +
> +		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);

This is dangerous: you are hard coding num_rings always being less than
10 here. Otherwise str[] isn't large enough. Mind adding
BUILD_BUG_ON(XEN_9PFS_NUM_RINGS > 9)?

> +		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;
> +		xenbus_dev_fatal(dev, ret, "completing transaction");
> +		goto error;
> +	}
> +
> +	list_add_tail(&priv->list, &xen_9pfs_devs);

Don't you need some kind of lock protecting the list?

> +	dev_set_drvdata(&dev->dev, priv);
> +	xenbus_switch_state(dev, XenbusStateInitialised);
> +
>  	return 0;
> +
> + error_xenbus:
> +	xenbus_transaction_end(xbt, 1);
> +	xenbus_dev_fatal(dev, ret, "writing xenstore");
> + error:
> +	dev_set_drvdata(&dev->dev, NULL);
> +	xen_9pfs_front_free(priv);
> +	return ret;
>  }
>  
>  static int xen_9pfs_front_resume(struct xenbus_device *dev)
>  {
> +	dev_warn(&dev->dev, "suspsend/resume unsupported\n");
>  	return 0;
>  }
>  
>  static void xen_9pfs_front_changed(struct xenbus_device *dev,
>  			    enum xenbus_state backend_state)
>  {
> +	switch (backend_state) {
> +	case XenbusStateReconfiguring:
> +	case XenbusStateReconfigured:
> +	case XenbusStateInitialising:
> +	case XenbusStateInitialised:
> +	case XenbusStateUnknown:
> +		break;
> +
> +	case XenbusStateInitWait:
> +		break;
> +
> +	case XenbusStateConnected:
> +		xenbus_switch_state(dev, XenbusStateConnected);
> +		break;
> +
> +	case XenbusStateClosed:
> +		if (dev->state == XenbusStateClosed)
> +			break;
> +		/* Missed the backend's CLOSING state -- fallthrough */
> +	case XenbusStateClosing:
> +		xenbus_frontend_closed(dev);
> +		break;
> +	}
>  }
>  
>  static struct xenbus_driver xen_9pfs_front_driver = {
> 


Juergen

  reply	other threads:[~2017-03-14  6:41 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-13 23:50 [PATCH v3 0/7] Xen transport for 9pfs frontend driver Stefano Stabellini
2017-03-13 23:50 ` [PATCH v3 1/7] xen: import new ring macros in ring.h Stefano Stabellini
2017-03-13 23:50   ` [PATCH v3 2/7] xen: introduce the header file for the Xen 9pfs transport protocol Stefano Stabellini
2017-03-13 23:50   ` [PATCH v3 3/7] xen/9pfs: introduce Xen 9pfs transport driver Stefano Stabellini
2017-03-14  6:24     ` Juergen Gross
2017-03-14 20:26       ` Stefano Stabellini
2017-03-13 23:50   ` [PATCH v3 4/7] xen/9pfs: connect to the backend Stefano Stabellini
2017-03-14  6:41     ` Juergen Gross [this message]
2017-03-14 21:22       ` Stefano Stabellini
2017-03-15  5:08         ` Juergen Gross
2017-03-15 18:44           ` Stefano Stabellini
2017-03-16  5:54             ` Juergen Gross
2017-03-16 18:03               ` Stefano Stabellini
2017-03-17  4:54                 ` Juergen Gross
2017-03-17 15:13                   ` [Xen-devel] " Konrad Rzeszutek Wilk
2017-03-17 20:55                     ` Stefano Stabellini
2017-03-13 23:50   ` [PATCH v3 5/7] xen/9pfs: send requests " Stefano Stabellini
2017-03-13 23:50   ` [PATCH v3 6/7] xen/9pfs: receive responses Stefano Stabellini
2017-03-14  7:04     ` Juergen Gross
2017-03-14 20:32       ` Stefano Stabellini
2017-03-13 23:50   ` [PATCH v3 7/7] xen/9pfs: build 9pfs Xen transport driver Stefano Stabellini
2017-03-14  7:05     ` Juergen Gross
2017-03-15 16:30 ` [PATCH v3 0/7] Xen transport for 9pfs frontend driver Greg Kurz
2017-03-15 19:12   ` Stefano Stabellini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cca25001-e2a8-8ccb-8e87-42f152293f35@suse.com \
    --to=jgross@suse.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=ericvh@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lucho@ionkov.net \
    --cc=rminnich@sandia.gov \
    --cc=sstabellini@kernel.org \
    --cc=stefano@aporeto.com \
    --cc=v9fs-developer@lists.sourceforge.net \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®