All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Andreas Färber" <afaerber@suse.de>
To: Michael Roth <mdroth@linux.vnet.ibm.com>
Cc: pbonzini@redhat.com, qemu-devel@nongnu.org,
	Anthony Liguori <anthony@codemonkey.ws>
Subject: Re: [Qemu-devel] [PATCH v2 6/6] qdev: switch property accessors to fixed-width visitor interfaces
Date: Sat, 25 Feb 2012 17:08:37 +0100	[thread overview]
Message-ID: <4F490785.1070603@suse.de> (raw)
In-Reply-To: <20120225154107.GA2725@illuin>

Am 25.02.2012 16:41, schrieb Michael Roth:
> On Fri, Feb 24, 2012 at 11:22:06AM -0600, Anthony Liguori wrote:
>> According to git bisect and qemu-test, this breaks:
>>
>> qemu-system-x86_64 -kernel bin/vmlinuz-3.0 -initrd
>> .tmp-26227/initramfs-26227.img.gz -append console=ttyS0 seed=1498
>> -nographic -enable-kvm -device virtio-balloon-pci,id=balloon0
>> -pidfile .tmp-26227/pidfile-26227.pid -qmp
>> unix:.tmp-26227/qmpsock-26227.sock,server,nowait
>> qemu-system-x86_64: Parameter 'id' expects int8_t
>> Aborted
> 
> Sorry, put way too much faith in the unit tests catching this.
> 
> The issue is we currently use set_int* for both uint* and int*
> properties. In this case the default uint8_t property value was
> (uint8_t)-1 = 255, which we'd stick in a qobject and feed to the
> visitors. Before, we'd just read that back into an int64_t container and
> let it be re-interpreted as -1 or 255 depending on the property type.
> 
> Now, we still fall back to visit_type_int() for QmpInputVisitor, but in
> the case of visit_type_int8() we check that the value falls within the
> signed range, which isn't the case for 255.
> 
> There's a few other places where we hit similar issues. The 2 possible
> solutions are:
> 
> 1) Loosen the range checks in qapi-visit-core.c so that we ignore
> signedness and only check that (uintX_t)value is small enough to fit
> in X bytes, or
> 
> 2) Add set_uint*/get_uint* accessors for uint* qdev properties.
> 
> 1 is less code, and more forgiving of cases were we might use int*/uint*
> interchangeably, but 2 I think is more correct and tightens up the
> bounds checking for qdev and whatever else we use QmpInputVisitor for.

I'm not too deep into visitors yet but 2) sounds better to me.

I've seen a couple of places where command line args are not properly
checked before passing them on (will send patches for those I remember)
so having the checks close to where the values came from sounds good.

Paolo did provide separate object_property_set_[u]int* accessors so we
should be good in QOM land when not fiddling with these things at such a
"deep" level.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

  reply	other threads:[~2012-02-25 16:08 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-23 20:22 [Qemu-devel] [PATCH v2 0/6] add fixed-width visitors and serialization tests Michael Roth
2012-02-23 20:22 ` [Qemu-devel] [PATCH v2 1/6] qapi: add Visitor interfaces for uint*_t and int*_t Michael Roth
2012-02-23 20:22 ` [Qemu-devel] [PATCH v2 2/6] qapi: unit tests for visitor-based serialization Michael Roth
2012-02-23 20:22 ` [Qemu-devel] [PATCH v2 3/6] qapi: QMP input visitor, handle floats parsed as ints Michael Roth
2012-02-23 20:22 ` [Qemu-devel] [PATCH v2 4/6] qapi: add String visitor coverage to serialization unit tests Michael Roth
2012-02-23 20:22 ` [Qemu-devel] [PATCH v2 5/6] qapi: String visitor, use %f represenation for floats Michael Roth
2012-02-23 20:22 ` [Qemu-devel] [PATCH v2 6/6] qdev: switch property accessors to fixed-width visitor interfaces Michael Roth
2012-02-24 17:22   ` Anthony Liguori
2012-02-25 15:41     ` Michael Roth
2012-02-25 16:08       ` Andreas Färber [this message]
2012-02-25 20:33         ` Paolo Bonzini

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=4F490785.1070603@suse.de \
    --to=afaerber@suse.de \
    --cc=anthony@codemonkey.ws \
    --cc=mdroth@linux.vnet.ibm.com \
    --cc=pbonzini@redhat.com \
    --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 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.