From: Ryan Harper <ryanh@us.ibm.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
Stefan Hajnoczi <stefan.hajnoczi@uk.ibm.com>,
Ryan Harper <ryanh@us.ibm.com>,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v3] Do not delete BlockDriverState when deleting the drive
Date: Tue, 29 Mar 2011 10:41:37 -0500 [thread overview]
Message-ID: <20110329154137.GD5445@us.ibm.com> (raw)
In-Reply-To: <m3ei5qv0fp.fsf@blackfin.pond.sub.org>
* Markus Armbruster <armbru@redhat.com> [2011-03-29 02:44]:
> Ryan Harper <ryanh@us.ibm.com> writes:
>
> > When removing a drive from the host-side via drive_del we currently have the
> > following path:
> >
> > drive_del
> > qemu_aio_flush()
> > bdrv_close() // zaps bs->drv, which makes any subsequent I/O get
> > // dropped. Works as designed
> > drive_uninit()
> > bdrv_delete() // frees the bs. Since the device is still connected to
> > // bs, any subsequent I/O is a use-after-free.
> >
> > The value of bs->drv becomes unpredictable on free. As long as it
> > remains null, I/O still gets dropped, however it could become non-null at any
> > point after the free resulting SEGVs or other QEMU state corruption.
> >
> > To resolve this issue as simply as possible, we can chose to not actually
> > delete the BlockDriverState pointer. Since bdrv_close() handles setting the drv
> > pointer to NULL, we just need to remove the BlockDriverState from the QLIST
> > that is used to enumerate the block devices. This is currently handled within
> > bdrv_delete, so move this into its own function, bdrv_make_anon().
> >
> > The result is that we can now invoke drive_del, this closes the file descriptors
> > and sets BlockDriverState->drv to NULL which prevents futher IO to the device,
> > and since we do not free BlockDriverState, we don't have to worry about the copy
> > retained in the block devices.
> >
> > We also don't attempt to remove the qdev property since we are no longer deleting
> > the BlockDriverState on drives with associated drives. This also allows for
> > removing Drives with no devices associated either.
> >
> > Reported-by: Markus Armbruster <armbru@redhat.com>
> > Signed-off-by: Ryan Harper <ryanh@us.ibm.com>
> > ---
> > v2->v3
> > - Update drive_del use after free description
> > - s/bdrv_remove/bdrv_make_anon/g
> > - Don't remove qdev property since we don't delete bs any more
> > - If (bs->peer) bdrv_make_anon else bdrv_delete to handle removing
> > drives with no device.
> > v1->v2
> > - NULL bs->device_name after removing from list to prevent
> > second removal.
> >
> > block.c | 13 ++++++++++---
> > block.h | 1 +
> > blockdev.c | 25 ++++++++-----------------
> > 3 files changed, 19 insertions(+), 20 deletions(-)
> >
> > diff --git a/block.c b/block.c
> > index c8e2f97..6a5d3f2 100644
> > --- a/block.c
> > +++ b/block.c
> > @@ -697,14 +697,21 @@ void bdrv_close_all(void)
> > }
> > }
> >
> > +/* make a BlockDriverState anonymous by removing from bdrv_state list.
> > + Also, NULL terminate the device_name to prevent double remove */
> > +void bdrv_make_anon(BlockDriverState *bs)
> > +{
> > + if (bs->device_name[0] != '\0') {
> > + QTAILQ_REMOVE(&bdrv_states, bs, list);
> > + }
>
> You lost
>
> + bs->device_name[0] = '\0';
>
> since v2. Oops.
Crap.
>
> > +}
> > +
> > void bdrv_delete(BlockDriverState *bs)
> > {
> > assert(!bs->peer);
> >
> > /* remove from list, if necessary */
> > - if (bs->device_name[0] != '\0') {
> > - QTAILQ_REMOVE(&bdrv_states, bs, list);
> > - }
> > + bdrv_make_anon(bs);
> >
> > bdrv_close(bs);
> > if (bs->file != NULL) {
> > diff --git a/block.h b/block.h
> > index 5d78fc0..52e9cad 100644
> > --- a/block.h
> > +++ b/block.h
> > @@ -66,6 +66,7 @@ int bdrv_create(BlockDriver *drv, const char* filename,
> > QEMUOptionParameter *options);
> > int bdrv_create_file(const char* filename, QEMUOptionParameter *options);
> > BlockDriverState *bdrv_new(const char *device_name);
> > +void bdrv_make_anon(BlockDriverState *bs);
> > void bdrv_delete(BlockDriverState *bs);
> > int bdrv_file_open(BlockDriverState **pbs, const char *filename, int flags);
> > int bdrv_open(BlockDriverState *bs, const char *filename, int flags,
> > diff --git a/blockdev.c b/blockdev.c
> > index ecf2252..2c0eb06 100644
> > --- a/blockdev.c
> > +++ b/blockdev.c
> > @@ -737,8 +737,6 @@ int do_drive_del(Monitor *mon, const QDict *qdict, QObject **ret_data)
> > {
> > const char *id = qdict_get_str(qdict, "id");
> > BlockDriverState *bs;
> > - BlockDriverState **ptr;
> > - Property *prop;
> >
> > bs = bdrv_find(id);
> > if (!bs) {
> > @@ -755,24 +753,17 @@ int do_drive_del(Monitor *mon, const QDict *qdict, QObject **ret_data)
> > bdrv_flush(bs);
> > bdrv_close(bs);
> >
> > - /* clean up guest state from pointing to host resource by
> > - * finding and removing DeviceState "drive" property */
> > + /* if we have a device associated with this BlockDriverState (bs->peer)
> > + * then we need to make the drive anonymous until the device
> > + * can be removed. If this is a drive with no device backing
> > + * then we can just get rid of the block driver state right here.
> > + */
> > if (bs->peer) {
> > - for (prop = bs->peer->info->props; prop && prop->name; prop++) {
> > - if (prop->info->type == PROP_TYPE_DRIVE) {
> > - ptr = qdev_get_prop_ptr(bs->peer, prop);
> > - if (*ptr == bs) {
> > - bdrv_detach(bs, bs->peer);
> > - *ptr = NULL;
> > - break;
> > - }
> > - }
> > - }
> > + bdrv_make_anon(bs);
> > + } else {
> > + bdrv_delete(bs);
>
> Don't you need drive_uninit() here?
You're right. We don't need it if we have a device associated since the
qdev cleanup code on device removal will remove it (via auto_delete).
I'll fix that up as well.
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ryanh@us.ibm.com
prev parent reply other threads:[~2011-03-29 15:41 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-28 18:46 [Qemu-devel] [PATCH v3] Do not delete BlockDriverState when deleting the drive Ryan Harper
2011-03-29 7:40 ` Markus Armbruster
2011-03-29 9:01 ` Markus Armbruster
2011-03-29 15:41 ` Ryan Harper
2011-03-29 15:41 ` Ryan Harper [this message]
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=20110329154137.GD5445@us.ibm.com \
--to=ryanh@us.ibm.com \
--cc=armbru@redhat.com \
--cc=kwolf@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefan.hajnoczi@uk.ibm.com \
/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.