[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [Qemu-devel] [PATCH] xen: use qdev_unplug() insteda of g_free() in xen_pv_find_xendev()
On 30 January 2017 at 15:14, Juergen Gross <jgross@xxxxxxxx> wrote: > The error exits of xen_pv_find_xendev() free the new xen-device via > g_free() which is wrong. > > As the xen-device has been initialized as qdev it must be removed > via qdev_unplug(). > > This bug has been introduced with commit 3a6c9172ac5951e6dac2b3f6 > ("xen: create qdev for each backend device"). > > Reported-by: Roger Pau Monné <roger.pau@xxxxxxxxxx> > Tested-by: Roger Pau Monné <roger.pau@xxxxxxxxxx> > Signed-off-by: Juergen Gross <jgross@xxxxxxxx> > --- > hw/xen/xen_backend.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c > index d119004..030772b 100644 > --- a/hw/xen/xen_backend.c > +++ b/hw/xen/xen_backend.c > @@ -145,7 +145,7 @@ static struct XenDevice *xen_be_get_xendev(const char > *type, int dom, int dev, > xendev->evtchndev = xenevtchn_open(NULL, 0); > if (xendev->evtchndev == NULL) { > xen_pv_printf(NULL, 0, "can't open evtchn device\n"); > - g_free(xendev); > + qdev_unplug(&xendev->qdev, NULL); > return NULL; > } > fcntl(xenevtchn_fd(xendev->evtchndev), F_SETFD, FD_CLOEXEC); > @@ -155,7 +155,7 @@ static struct XenDevice *xen_be_get_xendev(const char > *type, int dom, int dev, > if (xendev->gnttabdev == NULL) { > xen_pv_printf(NULL, 0, "can't open gnttab device\n"); > xenevtchn_close(xendev->evtchndev); > - g_free(xendev); > + qdev_unplug(&xendev->qdev, NULL); > return NULL; > } > } else { I think this will leak memory (and that we're already leaking memory), because the code is creating the xendev with xendev = g_malloc0(ops->size); object_initialize(&xendev->qdev, ops->size, TYPE_XENBACKEND); This is saying "I own and am responsible for freeing the memory that the device object lives in". If you want the object system to handle freeing the memory for you when the reference count goes to zero, then you need to create it with xendev = object_new() which we can't do here because we're allocating ops->size bytes rather than just the size of the object type. Two options I think: (1) have your code do OBJECT(xendev)->free = g_free; after the object_initialize (to tell the object system how to free this object) (2) call both qdev_unplug and g_free I think (1) is better because it will definitely work even if the qdev bus system is holding on to an object reference after it returns from qdev_unplug() for some reason, and it will also mean we free the memory when we do a qdev_unplug in xen_pv_del_xendev(), rather than leaking it. Side note: Using DEVICE(xendev) is better QOM style than &xendev->qdev. (The weirdness with doing a g_malloc0(ops->size) appears to be because Xen backends have their own setup for saying "allocate this many bytes for my data", rather than having XenBlkDev, XenConsole, etc be QOM subclasses of XenDevice. Presumably that code all predates QEMU's QOMification.) We also do OBJECT(thing)->free = something in hw/core/sysbus.c; maybe we should have a function to abstract this away? Not sure. thanks -- PMM _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |