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 What's even worse: git describe --contains 9f85550347f51c79a917b2aec04c90691c11e20a --match "v*" v3.4-rc3~1^2~3 that nonsense got merged long after those other commits. -- 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
