[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140513170942.GC5226@laptop.programming.kicks-ass.net>
Date: Tue, 13 May 2014 19:09:42 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Frederic Weisbecker <fweisbec@...il.com>
Cc: LKML <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Ingo Molnar <mingo@...nel.org>,
Kevin Hilman <khilman@...aro.org>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Thomas Gleixner <tglx@...utronix.de>,
Viresh Kumar <viresh.kumar@...aro.org>
Subject: Re: [PATCH 1/5] irq_work: Let arch tell us if it can raise irq work
On Tue, May 13, 2014 at 04:38:37PM +0200, Frederic Weisbecker wrote:
> We prepare for executing the full nohz kick through an irq work. But
> if we do this as is, we'll run into conflicting tick locking: the tick
> holds the hrtimer lock and the nohz kick may do so too.
It does? How does the tick end up holding that lock?
Normal hrtimer callbacks run without holding the hrtimer lock -- I made
it so.
This means tick_sched_timer() is called without hrtimer lock, and I
don't see it taking it anywhere in tick_sched_do_timer() or
tick_sched_handle().
--
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/
Powered by blists - more mailing lists