From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49753) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zvut2-0000cg-2k for qemu-devel@nongnu.org; Mon, 09 Nov 2015 17:26:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zvusx-0000qO-3g for qemu-devel@nongnu.org; Mon, 09 Nov 2015 17:26:04 -0500 Received: from mx1.redhat.com ([209.132.183.28]:57053) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zvusw-0000qE-UT for qemu-devel@nongnu.org; Mon, 09 Nov 2015 17:25:59 -0500 References: <1447080991-24995-1-git-send-email-peter.maydell@linaro.org> From: Laszlo Ersek Message-ID: <56411D73.1030603@redhat.com> Date: Mon, 9 Nov 2015 23:25:55 +0100 MIME-Version: 1.0 In-Reply-To: <1447080991-24995-1-git-send-email-peter.maydell@linaro.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH for-2.5] hw/timer/hpet.c: Avoid signed integer overflow which results in bugs on OSX List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell , qemu-devel@nongnu.org Cc: Aaron Elkins , Paolo Bonzini , patches@linaro.org, "Michael S. Tsirkin" On 11/09/15 15:56, Peter Maydell wrote: > Signed integer overflow in C is undefined behaviour, and the compiler > is at liberty to assume it can never happen and optimize accordingly. > In particular, the subtractions in hpet_time_after() and hpet_time_after64() > were causing OSX clang to optimize the code such that it was prone to > hangs and complaints about the main loop stalling (presumably because > we were spending all our time trying to service very high frequency > HPET timer callbacks). The clang sanitizer confirms the UB: > > hw/timer/hpet.c:119:26: runtime error: signed integer overflow: -2146967296 - 2147003978 cannot be represented in type 'int' > > Fix this by doing the subtraction as an unsigned operation and then > converting to signed for the comparison. > > Reported-by: Aaron Elkins > Signed-off-by: Peter Maydell > --- > hw/timer/hpet.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/hw/timer/hpet.c b/hw/timer/hpet.c > index 3037bef..7f0391c 100644 > --- a/hw/timer/hpet.c > +++ b/hw/timer/hpet.c > @@ -116,12 +116,12 @@ static uint32_t timer_enabled(HPETTimer *t) > > static uint32_t hpet_time_after(uint64_t a, uint64_t b) > { > - return ((int32_t)(b) - (int32_t)(a) < 0); > + return ((int32_t)(b - a) < 0); > } > > static uint32_t hpet_time_after64(uint64_t a, uint64_t b) > { > - return ((int64_t)(b) - (int64_t)(a) < 0); > + return ((int64_t)(b - a) < 0); > } > > static uint64_t ticks_to_ns(uint64_t value) > I'm late to the discussion, but I cannot imagine what would speak against: return (b < a); The post-patch code still converts a uint64_t difference to int32_t. According to the C standard(s), such a conversion (i.e., when the integer value being converted doesn't fit in the target signed integer) results in an implementation-defined value, or an implementation-defined signal is raised. On our platforms, the impl-def value is determined by "truncate to 32 bits, then reinterpret the bit pattern as two's complement signed int32_t". Meaning, if: (b > a) && ((b - a) & (1u << 31)) (that is, "b" is so much larger than "a" that bit#31 is set in the (b-a) difference), then hpet_time_after() will now incorrectly return 1. (Because bit#31 will be interpreted as the sign bit, turned on.) Again, what speaks against return (b < a); ? (The pre-patch code dates back to commit 16b29ae1 (year 2008), which offers precious little justification for the formula.) Thanks Laszlo