This bug affects at least s390, Xen, and occurred during testing of 
NO_IDLE_HZ with our VMI patches.  The bug is rather subtle and rare.  
Jiffies can be advanced by other CPUs, but if the current CPU has not 
processed timer softirqs in a while, the timer wheel can be behind 
jiffies, causing an overflow when comparing the next timer wheel 
expiration with the default high resolution timeout (no timeout), which 
is relative to jiffies.

It also looks like s390 has another bug.  When compiling the 32-bit 
kernel, doesn't this computation overflow:

arch/s390/kernel/time.c, stop_hz_timer:274

        /*
         * This cpu is going really idle. Set up the clock comparator
         * for the next event.
         */
        next = next_timer_interrupt();
        do {
                seq = read_seqbegin_irqsave(&xtime_lock, flags);
                timer = (__u64)(next - jiffies) + jiffies_64;
        } while (read_seqretry_irqrestore(&xtime_lock, seq, flags));


Since jiffies can advance between next_timer_interrupt and the read 
under xtime lock, next-jiffies could be negative.  I would think you 
want to cast that to signed long instead of __u64, but I'm not totally 
qualified to talk about s390.

Zach