Re: [PATCH 1/2] itimers: fix racy writes to cpu_itimer fields

[Ingo Molnar <mingo@elte.hu>]

* Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:

> On Thu, 2009-09-24 at 19:57 +0200, Stanislaw Gruszka wrote:
> > On Thu, 24 Sep 2009 16:48:07 +0200
> > Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> > 
> > > On Thu, 2009-09-24 at 16:35 +0200, Stanislaw Gruszka wrote:
> > > > incr_error and error fields of struct cpu_itimer are used when calculating
> > > > next timer tick in check_cpu_itimers() and should not be modified without
> > > > tsk->sighand->siglock taken.
> > > 
> > > Won't it be all-round much better to convert these things to hrtimers
> > > instead of adding more and more fuzz on top to make them deal with
> > > jiffies?
> > 
> > Perhaps it would, but I don't know how to do it :{ . Especially how to
> > precisely account user time. The only idea I have is make something like 
> > microstate accounting (http://lwn.net/Articles/127296/), but this patch
> > and whole idea was rejected long time ago. 
> 
> That patch does look a little painful indeed.
> 
> I was more thinking about about looking if an itimer was to expire less
> than 1 tick away on either sched-in or the tick.
> 
> When we find it is indeed less than 1 tick away, program an hrtimer for
> that cpu to expire at the required moment, see hrtick_start().
> 
> If we happen to de-schedule the task before the timer fires, we clear
> the hrtimer again (or let it pend and ignore the fire), see
> hrtick_clear().
> 
> [ there is no reason to rely on the tick though, we can program the 
> hrtimer on sched in to expire on at the right moment, and do so on 
> each schedule for as long as an itimer is active - re-setting whatever 
> pending timer the cpu still had. ]

we should think about the simplest approach: switching itimers to 
hrtimers.

	Ingo