All of lore.kernel.org
 help / color / mirror / Atom feed
From: Olaf Hering <olaf@aepfle.de>
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel@lists.xen.org, konrad.wilk@oracle.com,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] xen/blkback: prevent leak of mode during multiple backend_changed calls
Date: Thu, 6 Dec 2012 20:04:23 +0100	[thread overview]
Message-ID: <20121206190423.GA27952@aepfle.de> (raw)
In-Reply-To: <50C0DDCA02000078000AEBA9@nat28.tlf.novell.com>

On Thu, Dec 06, Jan Beulich wrote:

> >>> On 06.12.12 at 17:23, Olaf Hering <olaf@aepfle.de> wrote:
> > On Wed, Dec 05, Jan Beulich wrote:
> > 
> >> >>> On 05.12.12 at 11:01, Olaf Hering <olaf@aepfle.de> wrote:
> >> > backend_changed might be called multiple times, which will leak
> >> > be->mode. free the previous value before storing the current mode value.
> >> 
> >> As said before - this is one possible route to take. But did you
> >> consider at all the alternative of preventing the function from
> >> getting called more than once for a given device? As also said
> >> before, I think that would have other bad effects, and hence
> >> should be preferred (and would likely also result in a smaller
> >> patch).
> > 
> > Maybe it could be done like this, adding a flag to the backend device
> > and exit early if its called twice.
> 
> Maybe, but it looks odd to me. But then again I had hoped Konrad
> would have an opinion here...

Looking at this some more, if backend_changed is supposed to be called
exactly once then major/minor checks can be removed because they will be
always zero, like this:


 drivers/block/xen-blkback/xenbus.c | 68 ++++++++++++++++++--------------------
 1 file changed, 32 insertions(+), 36 deletions(-)

diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-blkback/xenbus.c
index a6585a4..5ca77c3 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -28,6 +28,7 @@ struct backend_info {
 	unsigned		major;
 	unsigned		minor;
 	char			*mode;
+	unsigned		alive;
 };
 
 static struct kmem_cache *xen_blkif_cachep;
@@ -502,10 +503,14 @@ static void backend_changed(struct xenbus_watch *watch,
 		= container_of(watch, struct backend_info, backend_watch);
 	struct xenbus_device *dev = be->dev;
 	int cdrom = 0;
-	char *device_type;
+	char *device_type, *p;
+	long handle;
 
 	DPRINTK("");
 
+	if (be->alive)
+		return;
+
 	err = xenbus_scanf(XBT_NIL, dev->nodename, "physical-device", "%x:%x",
 			   &major, &minor);
 	if (XENBUS_EXIST_ERR(err)) {
@@ -521,12 +526,7 @@ static void backend_changed(struct xenbus_watch *watch,
 		return;
 	}
 
-	if ((be->major || be->minor) &&
-	    ((be->major != major) || (be->minor != minor))) {
-		pr_warn(DRV_PFX "changing physical device (from %x:%x to %x:%x) not supported.\n",
-			be->major, be->minor, major, minor);
-		return;
-	}
+	be->alive = 1;
 
 	be->mode = xenbus_read(XBT_NIL, dev->nodename, "mode", NULL);
 	if (IS_ERR(be->mode)) {
@@ -542,39 +542,35 @@ static void backend_changed(struct xenbus_watch *watch,
 		kfree(device_type);
 	}
 
-	if (be->major == 0 && be->minor == 0) {
-		/* Front end dir is a number, which is used as the handle. */
-
-		char *p = strrchr(dev->otherend, '/') + 1;
-		long handle;
-		err = strict_strtoul(p, 0, &handle);
-		if (err)
-			return;
-
-		be->major = major;
-		be->minor = minor;
+	/* Front end dir is a number, which is used as the handle. */
+	p = strrchr(dev->otherend, '/') + 1;
+	err = strict_strtoul(p, 0, &handle);
+	if (err)
+		return;
 
-		err = xen_vbd_create(be->blkif, handle, major, minor,
-				 (NULL == strchr(be->mode, 'w')), cdrom);
-		if (err) {
-			be->major = 0;
-			be->minor = 0;
-			xenbus_dev_fatal(dev, err, "creating vbd structure");
-			return;
-		}
+	be->major = major;
+	be->minor = minor;
 
-		err = xenvbd_sysfs_addif(dev);
-		if (err) {
-			xen_vbd_free(&be->blkif->vbd);
-			be->major = 0;
-			be->minor = 0;
-			xenbus_dev_fatal(dev, err, "creating sysfs entries");
-			return;
-		}
+	err = xen_vbd_create(be->blkif, handle, major, minor,
+			 (NULL == strchr(be->mode, 'w')), cdrom);
+	if (err) {
+		be->major = 0;
+		be->minor = 0;
+		xenbus_dev_fatal(dev, err, "creating vbd structure");
+		return;
+	}
 
-		/* We're potentially connected now */
-		xen_update_blkif_status(be->blkif);
+	err = xenvbd_sysfs_addif(dev);
+	if (err) {
+		xen_vbd_free(&be->blkif->vbd);
+		be->major = 0;
+		be->minor = 0;
+		xenbus_dev_fatal(dev, err, "creating sysfs entries");
+		return;
 	}
+
+	/* We're potentially connected now */
+	xen_update_blkif_status(be->blkif);
 }
 
 
-- 
1.8.0.1



  reply	other threads:[~2012-12-06 19:04 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-05 10:01 [PATCH] xen/blkback: prevent leak of mode during multiple backend_changed calls Olaf Hering
2012-12-05 10:21 ` Jan Beulich
2012-12-05 10:21 ` Jan Beulich
2012-12-06 16:23   ` Olaf Hering
2012-12-06 16:23   ` Olaf Hering
2012-12-06 17:02     ` Jan Beulich
2012-12-06 17:02     ` Jan Beulich
2012-12-06 19:04       ` Olaf Hering [this message]
2012-12-06 19:04       ` Olaf Hering
2012-12-07 19:46       ` Konrad Rzeszutek Wilk
2012-12-07 19:46       ` Konrad Rzeszutek Wilk
  -- strict thread matches above, loose matches on Subject: below --
2012-12-05 10:01 Olaf Hering

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=20121206190423.GA27952@aepfle.de \
    --to=olaf@aepfle.de \
    --cc=JBeulich@suse.com \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=xen-devel@lists.xen.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.