[lkml]   [2013]   [Aug]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Patch in this message
SubjectRe: [PATCH jiffies] Avoid undefined behavior from signed overflow
On Sun, Aug 04, 2013 at 12:16:02PM -0700, Linus Torvalds wrote:
> On Mon, Jul 29, 2013 at 7:28 AM, Paul E. McKenney
> <> wrote:
> >>
> >> Ahh, there's an error in the commit message (it says signed to unsigned).
> >
> > Good catch, fixed!
> .. so I ended up waiting for that fixed version due to this email, but
> it never came. Should I just apply the original and re-fix it myself?
> Or is this queued up for 3.12 as being "not likely to actually
> matter", which is quite possibly true (since we compile with
> "-fno-strict-overflow", and thus gcc should hopefully not ever do any
> transformations that depend on signed integer overflows being
> undefined)

I have it queued up for 3.12, as you say, due to "-fno-strict-overflow".
But if you would rather have it sooner, please let me know and I will send
a pull request. Or, alternatively, please see below for the fixed patch.

Your choice! ;-)

Thanx, Paul


jiffies: Avoid undefined behavior from signed overflow

According to the C standard 3.4.3p3, overflow of a signed integer results
in undefined behavior. This commit therefore changes the definitions
of time_after(), time_after_eq(), time_after64(), and time_after_eq64()
to avoid this undefined behavior. The trick is that the subtraction
is done using unsigned arithmetic, which according to 6.2.5p9 cannot
overflow because it is defined as modulo arithmetic. This has the added
(though admittedly quite small) benefit of shortening two lines of code
by four characters each.

Note that the C standard considers the cast from unsigned to
signed to be implementation-defined, see However, on a
two-complement system, an implementation that defines anything other
than a reinterpretation of the bits is free come to me, and I will be
happy to act as a witness for its being committed to an insane asylum.
(Although I have nothing against saturating arithmetic or signals in
some cases, these things really should not be the default.)

Signed-off-by: Paul E. McKenney <>
Cc: John Stultz <>
Cc: "David S. Miller" <>
Cc: Arnd Bergmann <>
Cc: Ingo Molnar <>
Cc: Linus Torvalds <>
Cc: Eric Dumazet <>
Cc: Kevin Easton <>
[ paulmck: Included time_after64() and time_after_eq64(), as suggested
by Eric Dumazet, also fixed commit message.]

diff --git a/include/linux/jiffies.h b/include/linux/jiffies.h
index 97ba4e7..d235e88 100644
--- a/include/linux/jiffies.h
+++ b/include/linux/jiffies.h
@@ -101,13 +101,13 @@ static inline u64 get_jiffies_64(void)
#define time_after(a,b) \
(typecheck(unsigned long, a) && \
typecheck(unsigned long, b) && \
- ((long)(b) - (long)(a) < 0))
+ ((long)((b) - (a)) < 0))
#define time_before(a,b) time_after(b,a)

#define time_after_eq(a,b) \
(typecheck(unsigned long, a) && \
typecheck(unsigned long, b) && \
- ((long)(a) - (long)(b) >= 0))
+ ((long)((a) - (b)) >= 0))
#define time_before_eq(a,b) time_after_eq(b,a)

@@ -130,13 +130,13 @@ static inline u64 get_jiffies_64(void)
#define time_after64(a,b) \
(typecheck(__u64, a) && \
typecheck(__u64, b) && \
- ((__s64)(b) - (__s64)(a) < 0))
+ ((__s64)((b) - (a)) < 0))
#define time_before64(a,b) time_after64(b,a)

#define time_after_eq64(a,b) \
(typecheck(__u64, a) && \
typecheck(__u64, b) && \
- ((__s64)(a) - (__s64)(b) >= 0))
+ ((__s64)((a) - (b)) >= 0))
#define time_before_eq64(a,b) time_after_eq64(b,a)

#define time_in_range64(a, b, c) \

 \ /
  Last update: 2013-08-04 22:41    [W:0.068 / U:0.104 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site