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
next prev parent reply other threads:[~2012-12-06 19:04 UTC|newest]
Thread overview: 6+ 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-06 16:23 ` Olaf Hering
2012-12-06 17:02 ` Jan Beulich
2012-12-06 19:04 ` Olaf Hering [this message]
2012-12-07 19:46 ` Konrad Rzeszutek Wilk
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox