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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 04 Mar 2007 06:14:41 -0500
From:	Andres Salomon <dilinger@...ian.org>
To:	tglx@...utronix.de
CC:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] dynticks: don't unlock spinlock twice

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?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/