BUG: using smp_processor_id() in preemptible code

BUG: using smp_processor_id() in preemptible code

[Pavel Kiryukhin]

I get the following bug running 2.6.18 on malta34Kc .

Freeing prom memory: 956kb freed
Freeing firmware memory: 978944k freed
Freeing unused kernel memory: 180k freed
BUG: using smp_processor_id() in preemptible [00000000] code: swapper/1
caller is r4k_dma_cache_wback_inv+0x144/0x2a0
Call Trace:
 [<80117af8>] r4k_dma_cache_wback_inv+0x144/0x2a0
 [<802e4b84>] debug_smp_processor_id+0xd4/0xf0
 [<802e4b7c>] debug_smp_processor_id+0xcc/0xf0
...
CONFIG_DEBUG_PREEMPT is enabled.
--
Bug cause is blast_dcache_range() in preemptible code [in
r4k_dma_cache_wback_inv()].
blast_dcache_range() is constructed via __BUILD_BLAST_CACHE_RANGE that
uses cpu_dcache_line_size(). It uses current_cpu_data that use
smp_processor_id() in turn. In case of CONFIG_DEBUG_PREEMPT
smp_processor_id emits BUG if we are executing with preemption
enabled.

Cpu options of cpu0 are assumed to be the superset of all processors.

Can I make the same assumptions for cache line size  and fix this
issue the following way:

Index: linux-2.6.18/include/asm-mips/cpu-features.h
===================================================================
--- linux-2.6.18.orig/include/asm-mips/cpu-features.h
+++ linux-2.6.18/include/asm-mips/cpu-features.h
@@ -200,10 +200,10 @@
 #endif

 #ifndef cpu_dcache_line_size
-#define cpu_dcache_line_size() current_cpu_data.dcache.linesz
+#define cpu_dcache_line_size() cpu_data[0].dcache.linesz
 #endif
 #ifndef cpu_icache_line_size
-#define cpu_icache_line_size() current_cpu_data.icache.linesz
+#define cpu_icache_line_size() cpu_data[0].icache.linesz
 #endif
 #ifndef cpu_scache_line_size
 #define cpu_scache_line_size() current_cpu_data.scache.linesz

Any suggestions would be greatly appreciated.
---
Thanks,
Pavel

Re: BUG: using smp_processor_id() in preemptible code

[Ralf Baechle]

On Tue, Nov 27, 2007 at 07:20:47PM +0300, Pavel Kiryukhin wrote:

> I get the following bug running 2.6.18 on malta34Kc .
> 
> Freeing prom memory: 956kb freed
> Freeing firmware memory: 978944k freed
> Freeing unused kernel memory: 180k freed
> BUG: using smp_processor_id() in preemptible [00000000] code: swapper/1
> caller is r4k_dma_cache_wback_inv+0x144/0x2a0
> Call Trace:
>  [<80117af8>] r4k_dma_cache_wback_inv+0x144/0x2a0
>  [<802e4b84>] debug_smp_processor_id+0xd4/0xf0
>  [<802e4b7c>] debug_smp_processor_id+0xcc/0xf0
> ...
> CONFIG_DEBUG_PREEMPT is enabled.
> --
> Bug cause is blast_dcache_range() in preemptible code [in
> r4k_dma_cache_wback_inv()].
> blast_dcache_range() is constructed via __BUILD_BLAST_CACHE_RANGE that
> uses cpu_dcache_line_size(). It uses current_cpu_data that use
> smp_processor_id() in turn. In case of CONFIG_DEBUG_PREEMPT
> smp_processor_id emits BUG if we are executing with preemption
> enabled.
> 
> Cpu options of cpu0 are assumed to be the superset of all processors.
> 
> Can I make the same assumptions for cache line size  and fix this
> issue the following way:

That's safe and probably saner than littlering preempt_disable /
preempt_enable calls over the code.

  Ralf