| Message ID | 20170322144525.18964-3-eblake@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 22/03/2017 15:45, Eric Blake wrote: > A regression in commit 15c2f669e caused us to silently ignore > excess input to the QemuOpts visitor. Later, commit ea4641 > accidentally abused that situation, by removing "qom-type" and > "id" from the corresponding QDict but leaving them defined in > the QemuOpts, when using the pair of containers to create a > user-defined object. Note that since we are already traversing > two separate items (a QDict and a QemuOpts), we are already > able to flag bogus arguments, as in: > > $ ./x86_64-softmmu/qemu-system-x86_64 -nodefaults -nographic -qmp stdio -object memory-backend-ram,id=mem1,size=4k,bogus=huh > qemu-system-x86_64: -object memory-backend-ram,id=mem1,size=4k,bogus=huh: Property '.bogus' not found > > So the only real concern is that when we re-enable strict checking > in the QemuOpts visitor, we do not want to start flagging the two > leftover keys as unvisited. Rearrange the code to clean out the > QemuOpts listing in advance, rather than removing items from the > QDict. Since "qom-type" is usually an automatic implicit default, > we don't have to restore it (this does mean that once instantiated, > QemuOpts is not necessarily an accurate representation of the > original command line - but this is not the first place to do that); > however "id" has to be put back (requiring us to cast away a const). > > [As a side note, hmp_object_add() turns a QDict into a QemuOpts, > then calls user_creatable_add_opts() which converts QemuOpts into > a new QDict. There are probably a lot of wasteful conversions like > this, but cleaning them up is a much bigger task than the immediate > regression fix.] > > CC: qemu-stable@nongnu.org > Signed-off-by: Eric Blake <eblake@redhat.com> Tested-by: Laurent Vivier <lvivier@redhat.com> > > --- > v3: enhance commit message > v2: new patch > --- > qom/object_interfaces.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/qom/object_interfaces.c b/qom/object_interfaces.c > index 03a95c3..cc9a694 100644 > --- a/qom/object_interfaces.c > +++ b/qom/object_interfaces.c > @@ -114,7 +114,7 @@ Object *user_creatable_add_opts(QemuOpts *opts, Error **errp) > QDict *pdict; > Object *obj; > const char *id = qemu_opts_id(opts); > - const char *type = qemu_opt_get(opts, "qom-type"); > + char *type = qemu_opt_get_del(opts, "qom-type"); > > if (!type) { > error_setg(errp, QERR_MISSING_PARAMETER, "qom-type"); > @@ -125,14 +125,15 @@ Object *user_creatable_add_opts(QemuOpts *opts, Error **errp) > return NULL; > } > > + qemu_opts_set_id(opts, NULL); > pdict = qemu_opts_to_qdict(opts, NULL); > - qdict_del(pdict, "qom-type"); > - qdict_del(pdict, "id"); > > v = opts_visitor_new(opts); > obj = user_creatable_add_type(type, id, pdict, v, errp); > visit_free(v); > > + qemu_opts_set_id(opts, (char *) id); > + g_free(type); > QDECREF(pdict); > return obj; > } >
On Wed, Mar 22, 2017 at 09:45:24AM -0500, Eric Blake wrote: > A regression in commit 15c2f669e caused us to silently ignore > excess input to the QemuOpts visitor. Later, commit ea4641 > accidentally abused that situation, by removing "qom-type" and > "id" from the corresponding QDict but leaving them defined in > the QemuOpts, when using the pair of containers to create a > user-defined object. Note that since we are already traversing > two separate items (a QDict and a QemuOpts), we are already > able to flag bogus arguments, as in: > > $ ./x86_64-softmmu/qemu-system-x86_64 -nodefaults -nographic -qmp stdio -object memory-backend-ram,id=mem1,size=4k,bogus=huh > qemu-system-x86_64: -object memory-backend-ram,id=mem1,size=4k,bogus=huh: Property '.bogus' not found > > So the only real concern is that when we re-enable strict checking > in the QemuOpts visitor, we do not want to start flagging the two > leftover keys as unvisited. Rearrange the code to clean out the > QemuOpts listing in advance, rather than removing items from the > QDict. Since "qom-type" is usually an automatic implicit default, > we don't have to restore it (this does mean that once instantiated, > QemuOpts is not necessarily an accurate representation of the > original command line - but this is not the first place to do that); > however "id" has to be put back (requiring us to cast away a const). > > [As a side note, hmp_object_add() turns a QDict into a QemuOpts, > then calls user_creatable_add_opts() which converts QemuOpts into > a new QDict. There are probably a lot of wasteful conversions like > this, but cleaning them up is a much bigger task than the immediate > regression fix.] > > CC: qemu-stable@nongnu.org > Signed-off-by: Eric Blake <eblake@redhat.com> This commit causes a problem for libguestfs: [02192ms] /home/rjones/d/qemu/x86_64-softmmu/qemu-system-x86_64 \ [...] -object rng-random,filename=/dev/urandom,id=rng0 \ -device virtio-rng-pci,rng=rng0 \ [...] qemu-system-x86_64: -object rng-random,filename=/dev/urandom,id=rng0: Parameter 'qom-type' is missing (The full log is attached). I don't know if we should be including the qom-type parameter here, and if we should what it should be set to. Rich.
On 03/23/2017 10:37 AM, Richard W.M. Jones wrote: > On Wed, Mar 22, 2017 at 09:45:24AM -0500, Eric Blake wrote: >> A regression in commit 15c2f669e caused us to silently ignore >> excess input to the QemuOpts visitor. Later, commit ea4641 >> accidentally abused that situation, by removing "qom-type" and >> "id" from the corresponding QDict but leaving them defined in >> the QemuOpts, when using the pair of containers to create a >> user-defined object. Note that since we are already traversing >> two separate items (a QDict and a QemuOpts), we are already >> able to flag bogus arguments, as in: >> >> $ ./x86_64-softmmu/qemu-system-x86_64 -nodefaults -nographic -qmp stdio -object memory-backend-ram,id=mem1,size=4k,bogus=huh >> qemu-system-x86_64: -object memory-backend-ram,id=mem1,size=4k,bogus=huh: Property '.bogus' not found >> >> So the only real concern is that when we re-enable strict checking >> in the QemuOpts visitor, we do not want to start flagging the two >> leftover keys as unvisited. Rearrange the code to clean out the >> QemuOpts listing in advance, rather than removing items from the >> QDict. Since "qom-type" is usually an automatic implicit default, >> we don't have to restore it (this does mean that once instantiated, >> QemuOpts is not necessarily an accurate representation of the >> original command line - but this is not the first place to do that); Well, my assumption that qom-type was not necessary to restore... > This commit causes a problem for libguestfs: > > [02192ms] /home/rjones/d/qemu/x86_64-softmmu/qemu-system-x86_64 \ > [...] > -object rng-random,filename=/dev/urandom,id=rng0 \ > -device virtio-rng-pci,rng=rng0 \ > [...] > qemu-system-x86_64: -object rng-random,filename=/dev/urandom,id=rng0: Parameter 'qom-type' is missing ...was just proven false :( I should have been more conservative. I'll post the obvious follow-up patch that restores qom-type after the temporary removal from the QemuOpts that is necessary for the duration of the user_creatable_add.
diff --git a/qom/object_interfaces.c b/qom/object_interfaces.c index 03a95c3..cc9a694 100644 --- a/qom/object_interfaces.c +++ b/qom/object_interfaces.c @@ -114,7 +114,7 @@ Object *user_creatable_add_opts(QemuOpts *opts, Error **errp) QDict *pdict; Object *obj; const char *id = qemu_opts_id(opts); - const char *type = qemu_opt_get(opts, "qom-type"); + char *type = qemu_opt_get_del(opts, "qom-type"); if (!type) { error_setg(errp, QERR_MISSING_PARAMETER, "qom-type"); @@ -125,14 +125,15 @@ Object *user_creatable_add_opts(QemuOpts *opts, Error **errp) return NULL; } + qemu_opts_set_id(opts, NULL); pdict = qemu_opts_to_qdict(opts, NULL); - qdict_del(pdict, "qom-type"); - qdict_del(pdict, "id"); v = opts_visitor_new(opts); obj = user_creatable_add_type(type, id, pdict, v, errp); visit_free(v); + qemu_opts_set_id(opts, (char *) id); + g_free(type); QDECREF(pdict); return obj; }
A regression in commit 15c2f669e caused us to silently ignore excess input to the QemuOpts visitor. Later, commit ea4641 accidentally abused that situation, by removing "qom-type" and "id" from the corresponding QDict but leaving them defined in the QemuOpts, when using the pair of containers to create a user-defined object. Note that since we are already traversing two separate items (a QDict and a QemuOpts), we are already able to flag bogus arguments, as in: $ ./x86_64-softmmu/qemu-system-x86_64 -nodefaults -nographic -qmp stdio -object memory-backend-ram,id=mem1,size=4k,bogus=huh qemu-system-x86_64: -object memory-backend-ram,id=mem1,size=4k,bogus=huh: Property '.bogus' not found So the only real concern is that when we re-enable strict checking in the QemuOpts visitor, we do not want to start flagging the two leftover keys as unvisited. Rearrange the code to clean out the QemuOpts listing in advance, rather than removing items from the QDict. Since "qom-type" is usually an automatic implicit default, we don't have to restore it (this does mean that once instantiated, QemuOpts is not necessarily an accurate representation of the original command line - but this is not the first place to do that); however "id" has to be put back (requiring us to cast away a const). [As a side note, hmp_object_add() turns a QDict into a QemuOpts, then calls user_creatable_add_opts() which converts QemuOpts into a new QDict. There are probably a lot of wasteful conversions like this, but cleaning them up is a much bigger task than the immediate regression fix.] CC: qemu-stable@nongnu.org Signed-off-by: Eric Blake <eblake@redhat.com> --- v3: enhance commit message v2: new patch --- qom/object_interfaces.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)