On 09/17/13 11:44, Ralf Baechle wrote:
On Tue, Sep 17, 2013 at 10:43:25AM +0100, Markos Chandras wrote:
The cache flushing code uses the current_cpu_data macro which
may cause problems in preemptive kernels because it relies on
smp_processor_id() to get the current cpu number. Per cpu-data
needs to be protected so we disable preemption around the flush
caching code. We enable it back when we are about to return.
Fixes the following problem:
BUG: using smp_processor_id() in preemptible [00000000] code: kjournald/1761
caller is blast_dcache32+0x30/0x254
Just what I feared - these messages popping out from all over the tree.
I'd prefer if we change the caller otherwise depending on the platform
a single cache flush might involve several preempt_disable/-enable
invocations. Something like below.
And it also keeps the header file more usable outside the core kernel
which Florian's recent zboot a little easier.
Hi Ralf,
Changing the caller instead of the function in the header file looks
good to me. Thanks for fixing it.
