All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: qemu devel list <qemu-devel@nongnu.org>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
	Alistair Francis <alistair.francis@xilinx.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Peter Maydell <peter.maydell@linaro.org>
Subject: [Qemu-devel] [PATCH for-2.8 2/2] loader: fix undefined behavior in rom_order_compare()
Date: Mon, 28 Nov 2016 20:57:01 +0100	[thread overview]
Message-ID: <20161128195701.24912-3-lersek@redhat.com> (raw)
In-Reply-To: <20161128195701.24912-1-lersek@redhat.com>

According to ISO C99 / N1256 (referenced in HACKING):

> 6.5.8 Relational operators
>
> 4 For the purposes of these operators, a pointer to an object that is
>   not an element of an array behaves the same as a pointer to the first
>   element of an array of length one with the type of the object as its
>   element type.
>
> 5 When two pointers are compared, the result depends on the relative
>   locations in the address space of the objects pointed to. If two
>   pointers to object or incomplete types both point to the same object,
>   or both point one past the last element of the same array object, they
>   compare equal. If the objects pointed to are members of the same
>   aggregate object, pointers to structure members declared later compare
>   greater than pointers to members declared earlier in the structure,
>   and pointers to array elements with larger subscript values compare
>   greater than pointers to elements of the same array with lower
>   subscript values. All pointers to members of the same union object
>   compare equal. If the expression /P/ points to an element of an array
>   object and the expression /Q/ points to the last element of the same
>   array object, the pointer expression /Q+1/ compares greater than /P/.
>   In all other cases, the behavior is undefined.

Our AddressSpace objects are allocated generally individually, and kept in
the "address_spaces" linked list, so we mustn't compare their addresses
with relops.

Convert the pointers subjected to the relop in rom_order_compare() to
"uintptr_t":

> 7.18.1.4 Integer types capable of holding object pointers
>
> 1 [...]
>
>   The following type designates an unsigned integer type with the
>   property that any valid pointer to void can be converted to this type,
>   then converted back to pointer to void, and the result will compare
>   equal to the original pointer:
>
>   /uintptr_t/
>
>   These types are optional.

Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Alistair Francis <alistair.francis@xilinx.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: qemu-devel@nongnu.org
Fixes: 3e76099aacb4dae0d37ebf95305369e03d1491e6
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
 hw/core/loader.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/core/loader.c b/hw/core/loader.c
index c0d645a87134..766e48f2aec2 100644
--- a/hw/core/loader.c
+++ b/hw/core/loader.c
@@ -818,7 +818,7 @@ static QTAILQ_HEAD(, Rom) roms = QTAILQ_HEAD_INITIALIZER(roms);
 
 static inline bool rom_order_compare(Rom *rom, Rom *item)
 {
-    return (rom->as > item->as) ||
+    return ((uintptr_t)(void*)rom->as > (uintptr_t)(void*)item->as) ||
            (rom->as == item->as && rom->addr >= item->addr);
 }
 
-- 
2.9.2

  parent reply	other threads:[~2016-11-28 19:57 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-28 19:56 [Qemu-devel] [PATCH for-2.8 0/2] loader fixes Laszlo Ersek
2016-11-28 19:57 ` [Qemu-devel] [PATCH for-2.8 1/2] loader: fix handling of custom address spaces when adding ROM blobs Laszlo Ersek
2016-11-28 23:07   ` Alistair Francis
2016-11-29 16:31   ` Michael S. Tsirkin
2016-11-28 19:57 ` Laszlo Ersek [this message]
2016-11-28 23:13   ` [Qemu-devel] [PATCH for-2.8 2/2] loader: fix undefined behavior in rom_order_compare() Alistair Francis
2016-11-29 16:29   ` Michael S. Tsirkin
2016-11-29 18:40     ` Laszlo Ersek
2016-11-29 13:37 ` [Qemu-devel] [PATCH for-2.8 0/2] loader fixes no-reply
2016-11-29 16:27   ` Michael S. Tsirkin
2016-11-29 18:41     ` Laszlo Ersek

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=20161128195701.24912-3-lersek@redhat.com \
    --to=lersek@redhat.com \
    --cc=alistair.francis@xilinx.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.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 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.