[Top] [All Lists]

Re: [PATCH] MIPS: Fix accessing to per-cpu data when flushing the cache

To: Ralf Baechle <>
Subject: Re: [PATCH] MIPS: Fix accessing to per-cpu data when flushing the cache
From: Markos Chandras <>
Date: Tue, 17 Sep 2013 11:55:55 +0100
Cc: <>
In-reply-to: <>
List-archive: <>
List-help: <>
List-id: linux-mips <>
List-owner: <>
List-post: <>
List-software: Ecartis version 1.0.0
List-subscribe: <>
List-unsubscribe: <>
Original-recipient: rfc822;
References: <> <>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
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.

<Prev in Thread] Current Thread [Next in Thread>