lkml.org 
[lkml]   [2006]   [Jan]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: [PATCH] garbage values in file /proc/net/sockstat
Andi Kleen a écrit :
> On Monday 23 January 2006 14:28, Eric Dumazet wrote:
>
>> Shouldnt we force a page fault for not possible cpus in cpu_data
>> to catch all access to per_cpu(some_object, some_not_possible_cpu) ?
>>
>> We can use a red zone big enough to hold the whole per_cpu data.
>
> Good idea. Can you please send me a tested patch?
>

I did a patch (on top of 2.6.16-rc1-mm2) , but the kernel crashes in
sched_init(void)

for (i = 0; i < NR_CPUS; i++) {
prio_array_t *array;
rq = cpu_rq(i);
spin_lock_init(&rq->lock); <<-CRASH


In my config, NR_CPUS = 8, and I have one only one CPU inside my test box.

So should I send only the patch or all the corrections I have to do to avoid
all possible crashes in my config ?

Thank you
Eric Dumazet

[PATCH] x86_64 : Use a special CPUDATA_RED_ZONE to catch accesses to
per_cpu(some_object, some_not_possible_cpu)

Because cpu_data(cpu)->data_offset may contain garbage, some buggy code may do
random things without notice. If we initialize data_offset so that the
per_cpu() data sits in an unmapped memory area, we should get page faults and
stack traces should help us find the bugs.

Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>


--- linux-2.6.16-rc1/Documentation/x86_64/mm.txt 2006-01-17 08:44:47.000000000 +0100
+++ linux-2.6.16-rc1-mm2-ed/Documentation/x86_64/mm.txt 2006-01-23 16:54:46.000000000 +0100
@@ -5,7 +5,8 @@

0000000000000000 - 00007fffffffffff (=47bits) user space, different per mm
hole caused by [48:63] sign extension
-ffff800000000000 - ffff80ffffffffff (=40bits) guard hole
+ffff800000000000 - ffff807fffffffff (=39bits) guard hole
+ffff808000000000 - ffff80ffffffffff (=39bits) not possible cpus percpudata hole
ffff810000000000 - ffffc0ffffffffff (=46bits) direct mapping of all phys. memory
ffffc10000000000 - ffffc1ffffffffff (=40bits) hole
ffffc20000000000 - ffffe1ffffffffff (=45bits) vmalloc/ioremap space
--- linux-2.6.16-rc1/include/asm-x86_64/pgtable.h 2006-01-17 08:44:47.000000000 +0100
+++ linux-2.6.16-rc1-mm2-ed/include/asm-x86_64/pgtable.h 2006-01-23 16:54:46.000000000 +0100
@@ -136,6 +136,7 @@

#ifndef __ASSEMBLY__
#define MAXMEM 0x3fffffffffffUL
+#define CPUDATA_RED_ZONE 0xffff808000000000UL
#define VMALLOC_START 0xffffc20000000000UL
#define VMALLOC_END 0xffffe1ffffffffffUL
#define MODULES_VADDR 0xffffffff88000000UL
--- linux-2.6.16-rc1/arch/x86_64/kernel/setup64.c 2006-01-23 16:36:38.000000000 +0100
+++ linux-2.6.16-rc1-mm2-ed/arch/x86_64/kernel/setup64.c 2006-01-23 16:58:30.000000000 +0100
@@ -99,9 +99,13 @@
size = PERCPU_ENOUGH_ROOM;
#endif

- for_each_cpu_mask (i, cpu_possible_map) {
+ for (i = 0 ; i < NR_CPUS ; i++) {
char *ptr;

+ cpu_pda(i)->data_offset = (char *)CPUDATA_RED_ZONE - __per_cpu_start;
+ if (!cpu_possible(i))
+ continue;
+
if (!NODE_DATA(cpu_to_node(i))) {
printk("cpu with no node %d, num_online_nodes %d\n",
i, num_online_nodes());
\
 
 \ /
  Last update: 2006-01-23 17:32    [W:0.088 / U:0.116 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site