From: Kevin Wolf <kwolf@redhat.com>
To: Alberto Garcia <berto@igalia.com>
Cc: qemu-block@nongnu.org, qemu-devel@nongnu.org, mreitz@redhat.com
Subject: Re: [Qemu-devel] [Qemu-block] [PATCH v3 01/11] block: Accept node-name for block-stream
Date: Thu, 7 Jul 2016 16:49:55 +0200 [thread overview]
Message-ID: <20160707144955.GD6488@noname.redhat.com> (raw)
In-Reply-To: <w51r3b55x7o.fsf@maestria.local.igalia.com>
Am 07.07.2016 um 16:39 hat Alberto Garcia geschrieben:
> On Thu 07 Jul 2016 04:17:21 PM CEST, Kevin Wolf wrote:
> >> > +static BlockDriverState *qmp_get_root_bs(const char *name, Error **errp)
> >> > +{
> >> > + BlockDriverState *bs;
> >> > +
> >> > + bs = bdrv_lookup_bs(name, name, errp);
> >> > + if (bs == NULL) {
> >> > + return NULL;
> >> > + }
> >> > +
> >> > + if (!bdrv_has_blk(bs)) {
> >> > + error_setg(errp, "Need a root block node");
> >> > + return NULL;
> >> > + }
> >>
> >> Since b6d2e59995f when you create a block job a new BlockBackend is
> >> created on top of the BDS. What happens with this check if we allow
> >> creating jobs in a non-root BDS?
> >
> > Hm, you mean I'd start first an intermediate streaming job and then I
> > can call commands on the target node that I shouldn't be able to call?
> > It's a good point, but I think op blockers would prevent that this
> > actually works.
>
> Yes, they would but
>
> a) the user would get a misleading error message ("you cannot start that
> job because the device is temporarily being used" rather than "you
> cannot start that block job there at all"). Probably not so
> important.
>
> b) all the code after the qmp_get_root_bs() call would run under the
> (incorrect) assumption that the node is a root BDS. This probably
> doesn't break anything at the moment but leaves a door open for
> surprises.
Yes, I understand that. The truth is that our current op blockers just
don't quite cut it and we need to move away from them so that we can
finally allow jobs on every node without giving up safety.
> > Another option - and maybe that makes more sense than the old rule
> > anyway because you already can have a BB anywhere in the middle of the
> > graph - would be to check that the node doesn't have any non-BB
> > parent. This would restrict some cases that are possible today.
>
> Which ones?
-drive if=none,file=backing.qcow2,id=backing
-drive if=virtio,file=overlay.qcow2,backing=backing
You got a BB name for the backing file node, so can run any command that
wants a root node on it. The backing file blocker will still prevent
most actions, but that's the same situation as with node names.
So I guess the new surprises won't be any worse. :-)
Kevin
next prev parent reply other threads:[~2016-07-07 14:50 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-07 12:11 [Qemu-devel] [PATCH v3 00/11] block: Accept node-name in all node level QMP commands Kevin Wolf
2016-07-07 12:11 ` [Qemu-devel] [PATCH v3 01/11] block: Accept node-name for block-stream Kevin Wolf
2016-07-07 12:59 ` [Qemu-devel] [Qemu-block] " Alberto Garcia
2016-07-07 14:17 ` Kevin Wolf
2016-07-07 14:39 ` Alberto Garcia
2016-07-07 14:49 ` Kevin Wolf [this message]
2016-07-13 9:46 ` Kevin Wolf
2016-07-07 22:45 ` [Qemu-devel] " Eric Blake
2016-07-08 10:01 ` Kevin Wolf
2016-07-08 14:30 ` Eric Blake
2016-07-07 12:11 ` [Qemu-devel] [PATCH v3 02/11] block: Accept node-name for block-commit Kevin Wolf
2016-07-07 22:52 ` Eric Blake
2016-07-07 12:11 ` [Qemu-devel] [PATCH v3 03/11] block: Accept node-name for blockdev-backup Kevin Wolf
2016-07-07 12:11 ` [Qemu-devel] [PATCH v3 04/11] block: Accept node-name for blockdev-mirror Kevin Wolf
2016-07-07 12:11 ` [Qemu-devel] [PATCH v3 05/11] block: Accept node-name for blockdev-snapshot-delete-internal-sync Kevin Wolf
2016-07-07 12:11 ` [Qemu-devel] [PATCH v3 06/11] block: Accept node-name for blockdev-snapshot-internal-sync Kevin Wolf
2016-07-07 12:11 ` [Qemu-devel] [PATCH v3 07/11] block: Accept node-name for change-backing-file Kevin Wolf
2016-07-07 12:11 ` [Qemu-devel] [PATCH v3 08/11] block: Accept node-name for drive-backup Kevin Wolf
2016-07-07 12:11 ` [Qemu-devel] [PATCH v3 09/11] block: Accept node-name for drive-mirror Kevin Wolf
2016-07-07 12:11 ` [Qemu-devel] [PATCH v3 10/11] nbd-server: Use a separate BlockBackend Kevin Wolf
2016-07-07 12:11 ` [Qemu-devel] [PATCH v3 11/11] nbd-server: Allow node name for nbd-server-add Kevin Wolf
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=20160707144955.GD6488@noname.redhat.com \
--to=kwolf@redhat.com \
--cc=berto@igalia.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.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;
as well as URLs for NNTP newsgroup(s).