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

[Peter Zijlstra <a.p.zijlstra@chello.nl>]

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. ]