]> git.baikalelectronics.ru Git - kernel.git/commit
acpi-cpufreq: fix 'smp_call_function_many()' confusion
authorLinus Torvalds <torvalds@linux-foundation.org>
Wed, 15 Apr 2009 15:05:13 +0000 (08:05 -0700)
committerLinus Torvalds <torvalds@linux-foundation.org>
Wed, 15 Apr 2009 15:41:16 +0000 (08:41 -0700)
commit0f96baa3fc639b865f886871e56d9066179b7472
tree59f9ec1258941d37b893290da46cac1a30e65bd9
parent2afdd9f0aa5ee2c7a3b216eda59631d209092a7a
acpi-cpufreq: fix 'smp_call_function_many()' confusion

It turns out that 'smp_call_function_many()' doesn't work at all like
'smp_call_function_single()', and my change to Andrew's patch to use it
rather than a loop over all CPU's acpi-cpufreq doesn't work.

My bad.

'smp_call_function_many()' has two "features" (aka "documented bugs"):

 (a) it needs to be called with preemption disabled, because it uses
     smp_processor_id() without guarding the CPU lookup with 'get_cpu()'
     and 'put_cpu()' like the 'single' variant does.

 (b) even if the current CPU is part of the CPU mask, it won't do the
     call on that CPU.

Still, we're better off trying to use 'smp_call_function_many()' than
looping over CPU's, since it at least in theory allows us to use a
broadcast IPI and do it all in parallel.  So let's just work around the
silly semantic bugs in that function.

Reported-and-tested-by: Ali Gholami Rudi <ali@rudi.ir>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Dave Jones <davej@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c