On Mon, Apr 16, 2012 at 09:45:28PM +0200, Peter Zijlstra wrote: > On Mon, 2012-04-16 at 11:58 -0700, [email protected] wrote: > > This is a note to let you know that I've just added the patch titled > > > > ARM: 7359/2: smp_twd: Only wait for reprogramming on active cpus > > > > to the 3.3-stable tree which can be found at: > > > > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary > > > > The filename of the patch is: > > arm-7359-2-smp_twd-only-wait-for-reprogramming-on-active-cpus.patch > > and it can be found in the queue-3.3 subdirectory. > > > > If you, or anyone else, feels it should not be added to the stable tree, > > please let <[email protected]> know about it. > > > > > > From 9f85550347f51c79a917b2aec04c90691c11e20a Mon Sep 17 00:00:00 2001 > > From: Linus Walleij <[email protected]> > > Date: Tue, 10 Apr 2012 12:37:42 +0100 > > Subject: ARM: 7359/2: smp_twd: Only wait for reprogramming on active cpus > > > > From: Linus Walleij <[email protected]> > > > > commit 9f85550347f51c79a917b2aec04c90691c11e20a upstream. > > > > During booting of cpu1, there is a short window where cpu1 > > is online, but not active where cpu1 is occupied by waiting > > to become active. If cpu0 then decides to schedule something > > on cpu1 and wait for it to complete, before cpu0 has set > > cpu1 active, we have a deadlock. > > > > Typically it's this CPU frequency transition that happens at > > this time, so let's just not wait for it to happen, it will > > happen whenever the CPU eventually comes online instead. > > > > Cc: Peter Zijlstra <[email protected]> > > Signed-off-by: Jonas Aaberg <[email protected]> > > Reviewed-by: Rickard Andersson <[email protected]> > > Signed-off-by: Linus Walleij <[email protected]> > > Signed-off-by: Russell King <[email protected]> > > Signed-off-by: Greg Kroah-Hartman <[email protected]> > > > > --- > > arch/arm/kernel/smp_twd.c | 6 +++++- > > 1 file changed, 5 insertions(+), 1 deletion(-) > > > > --- a/arch/arm/kernel/smp_twd.c > > +++ b/arch/arm/kernel/smp_twd.c > > @@ -115,10 +115,14 @@ static int twd_cpufreq_transition(struct > > * The twd clock events must be reprogrammed to account for the new > > * frequency. The timer is local to a cpu, so cross-call to the > > * changing cpu. > > + * > > + * Only wait for it to finish, if the cpu is active to avoid > > + * deadlock when cpu1 is spinning on while(!cpu_active(cpu1)) during > > + * booting of that cpu. > > */ > > if (state == CPUFREQ_POSTCHANGE || state == CPUFREQ_RESUMECHANGE) > > smp_call_function_single(freqs->cpu, twd_update_frequency, > > - NULL, 1); > > + NULL, cpu_active(freqs->cpu)); > > > > return NOTIFY_OK; > > } > > Argh, how did that ever make it upstream, please drop. > > Russell, please make that go away upstream. > > Like I said, this is both completely the wrong way to solve, and you're > so not paying attention, see: > > 5fbd036b552f633abb394a319f7c62a5c86a9cd7 > 2baab4e90495ebc9826c93f79d74d6e60a828d24 > e3831edd59edf57ca11fc289f08961b20baf5146
To be honest, I've given up caring about the hotplug paths because they're just a total pile of absolute bollocks. The sooner someone can come up with a sane way of bringing up secondary CPUs so that we don't have every arch dealing with shite issues like this the better. And given that you were cc'd on the patch and said nothing about it... sorry not my problem. -- Russell King -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
