Re: [PATCH] dynticks: don't unlock spinlock twice

[Andres Salomon <dilinger@debian.org>]

Thomas Gleixner wrote:
> On Fri, 2007-03-02 at 21:52 -0500, Andres Salomon wrote:
[...]
> 
> The BUG is somewhere else. the tick timer should never be seen in
> hrtimer_run_queues. The tick timer is operated solely from the timer
> interrupt. 
> 
> The question is, how the tick timer gets enqueued in the softirq queue.
> Can you isolate the codepath, where this happens ?
> 

Only 4 functions call timer->function; hrtimer_enequeue_reprogram,
hrtimer_interrupt, run_hrtimer_softirq, and run_hrtimer_queue.

- hrtimer_enqueue_reprogram will not call CB_IRQSAFE_NO_SOFTIRQ; this
function is not the culprit.  It does move CB_SOFTIRQs onto the
cb_pending list.

- hrtimer_interrupt is called from a hardirq context, and only runs
CB_IRQSAFE*.  CB_SOFTIRQs are moved onto the cb_pending list.  Since
irqs are disabled, this function is not the culprit.

- run_hrtimer_softirq is called from the HRTIMER_SOFTIRQ, and only
operates on softirqs (via the cb_pending list).  CB_IRQSAFE_NO_SOFTIRQ
callbacks are never added to the cb_pending list, so this function is
not the culprit.

- run_hrtimer_queue is called from TIMER_SOFTIRQ, and runs on all
timers.  This function is what shows up in the backtrace, and should not
be calling tick_sched_timer.

Now, the question is; what *should* it be doing?  Since it is only ever
run from a softirq context, should it be checking for
!CB_IRQSAFE_NO_SOFTIRQ before running the timers?  Should it only be
processing timers that have been added to cb_pending (which are
guaranteed to be softirq-friendly)?   Is there even a reason why we have
a run_hrtimer_softirq that processes cb_pending, as well as a
run_timer_softirq that calls hrtimer_run_queues?  Why should the timer
softirq (which is raised by, amongst other things, update_process_times,
which is called by our friend tick_sched_timer) care about the hrtimer
queues?