user/sven/linux.git/include/linux/hrtimer.h, branch v2.6.29.2

hrtimer: fix rq->lock inversion (again)

2009-04-27T17:37:00Z

upstream commit: 7f1e2ca9f04b02794597f60e7b1d43f0a1317939 It appears I inadvertly introduced rq->lock recursion to the hrtimer_start() path when I delegated running already expired timers to softirq context. This patch fixes it by introducing a __hrtimer_start_range_ns() method that will not use raise_softirq_irqoff() but __raise_softirq_irqoff() which avoids the wakeup. It then also changes schedule() to check for pending softirqs and do the wakeup then, I'm not quite sure I like this last bit, nor am I convinced its really needed. Signed-off-by: Peter Zijlstra Cc: Peter Zijlstra Cc: paulus@samba.org LKML-Reference: <20090313112301.096138802@chello.nl> Signed-off-by: Ingo Molnar Tested-by: Mikael Pettersson Signed-off-by: Chris Wright

hrtimer: removing all ur callback modes

2008-11-25T14:45:46Z

Impact: cleanup, move all hrtimer processing into hardirq context This is an attempt at removing some of the hrtimer complexity by reducing the number of callback modes to 1. This means that all hrtimer callback functions will be ran from HARD-irq context. I went through all the 30 odd hrtimer callback functions in the kernel and saw only one that I'm not quite sure of, which is the one in net/can/bcm.c - hence I'm CC-ing the folks responsible for that code. Furthermore, the hrtimer core now calls callbacks directly with IRQs disabled in case you try to enqueue an expired timer. If this timer is a periodic timer (which should use hrtimer_forward() to advance its time) then it might be possible to end up in an inf. recursive loop due to the fact that hrtimer_forward() doesn't round up to the next timer granularity, and therefore keeps on calling the callback - obviously this needs a fix. Aside from that, this seems to compile and actually boot on my dual core test box - although I'm sure there are some bugs in, me not hitting any makes me certain :-) Signed-off-by: Peter Zijlstra Signed-off-by: Ingo Molnar

hrtimer: clean up unused callback modes

2008-11-12T08:54:40Z

Impact: cleanup git grep HRTIMER_CB_IRQSAFE revealed half the callback modes are actually unused. Signed-off-by: Peter Zijlstra Signed-off-by: Ingo Molnar

Fix accidental implicit cast in HR-timer conversion

2008-11-06T23:44:19Z

Fix the hrtimer_add_expires_ns() function. It should take a 'u64 ns' argument, but rather takes an 'unsigned long ns' argument - which might only be 32-bits. On FRV, this results in the kernel locking up because hrtimer_forward() passes the result of a 64-bit multiplication to this function, for which the compiler discards the top 32-bits - something that didn't happen when ktime_add_ns() was called directly. Signed-off-by: David Howells Acked-by: Arjan van de Ven Signed-off-by: Linus Torvalds

Merge branch 'timers/range-hrtimers' into v28-range-hrtimers-for-linus-v2

2008-10-22T07:48:06Z

Conflicts: kernel/time/tick-sched.c Signed-off-by: Thomas Gleixner

hrtimers: add missing docbook comments to struct hrtimer

2008-10-20T14:38:19Z

Signed-off-by: Thomas Gleixner

Merge branches 'timers/clocksource', 'timers/hrtimers', 'timers/nohz', 'timers/ntp', 'timers/posixtimers' and 'timers/debug' into v28-timers-for-linus

2008-10-20T11:14:06Z

Merge commit 'linus/master' into merge-linus

2008-10-17T16:20:26Z

Conflicts: arch/x86/kvm/i8254.c

DECLARE_PER_CPU needs linux/percpu.h

2008-10-15T14:11:00Z

Signed-off-by: Stephen Rothwell

rangetimer: fix x86 build failure for the !HRTIMERS case

2008-10-07T17:57:54Z

the timer peek function was on the wrong side of an ifdef, breaking for the !HRTIMERs case. Just provide an empty inline for that case since it doesn't make sense in that scenario. Signed-off-by: Arjan van de Ven