Re: [PATCH 2/3] posix_timers: Defer per process timer stop after timers processing

[Olivier Langlois <olivier@trillion01.com>]

On Fri, 2013-04-19 at 14:47 +0200, Frederic Weisbecker wrote:

> 
> >
> > I might be mistaken but I believe that firing timers are not rescheduled
> > in the current interrupt context. They are going to be rescheduled later
> > from the task context handling the timer generated signal.
> 
> No, when the timer fires, it might generate a signal. But it won't
> execute that signal right away in the same code path. Instead, after
> signal generation, it may reschedule the timer if necessary then look
> at the next firing timer in the list. This is all made from the same
> timer interrupt context from the same call to run_posix_cpu_timers().
> The signal itself is executed asynchronously. Either by interrupting a
> syscall, or from the irq return path.
> 
Frederic, be careful with the interpretation, there are 2 locations from
where posix_cpu_timer_schedule() can be called.

Call to posix_cpu_timer_schedule() from cpu_timer_fire() only happens if
the signal isn't sent because it is ignored by the recipient.

Maybe the condition around the posix_cpu_timer_schedule() block inside
cpu_timer_fire() could even be a good candidate for 'unlikely'
qualifier.

IMO, a more likely scenario, posix_cpu_timer_schedule() will be called
from dequeue_signal() which will be from from a different context than
the interrupt context.

At best, you have an interesting race!

dequeue_signal() is called when delivering a signal, not when it is
generated, right?

If you have a different understanding then please explain when call to
posix_cpu_timer_schedule() from dequeue_signal() will happen.