Re: [PATCH] prevent timespec/timeval to ktime_t overflow

From: Thomas Gleixner
Date: Sat Sep 02 2006 - 14:35:00 EST


On Fri, 2006-09-01 at 20:13 -0700, Andrew Morton wrote:
> > Fun, here is a version with a bigabyte blocker.
>
> Your patch triggers waaaaaaay early.
>
> netconsole: remote IP 192.168.2.33
> netconsole: remote ethernet address 00:0d:56:c6:c6:cc
> Initializing CPU#0
> PID hash table entries: 4096 (order: 12, 32768 bytes)
> time.c: Using 14.318180 MHz WALL HPET GTOD HPET/TSC timer.
> time.c: Detected 3400.238 MHz processor.
> ktime_set: -1157140842 : 0

-------------^ !!!!!!!

> BUG: warning at include/linux/ktime.h:84/ktime_set()
>
> Call Trace:
> <IRQ> [<ffffffff80247021>] hrtimer_run_queues+0x10e/0x211

This seems to happen inside hrtimer_get_softirq_time().
wall_to_monotonic is negative.

Why does the check trigger ? We compare a "long", which contains a
negative value against some positive constant.

ktime_t ktime_set(const long secs, const unsigned long nsecs)
{
if (unlikely(secs >= KTIME_SEC_MAX)) {

where KTIME_SEC_MAX is 0x7FFFFFFFFFFFFFFF / 1000 000 000 =

9223372036 == 0x225C17D04,

which is compared against

-1157140842 == 0xFFFFFFFFBB076E96

This smells like gcc magic. Can you please disassemble the code in
question ?

> I wonder if this is related to the occasional hrtimr_run_queues() lockup
> which Andi is encountering.

Hmm, not sure.

tglx



--
VGER BF report: H 1.60283e-12
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/