public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Dumazet <dada1@cosmosbay.com>
To: Andi Kleen <ak@suse.de>
Cc: pravin shelar <pravins@calsoftinc.com>,
	Ravikiran G Thirumalai <kiran@scalex86.org>,
	Shai Fultheim <shai@scalex86.org>,
	linux-kernel@vger.kernel.org,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH] garbage values in file /proc/net/sockstat
Date: Mon, 23 Jan 2006 17:28:53 +0100	[thread overview]
Message-ID: <43D50445.1080208@cosmosbay.com> (raw)
In-Reply-To: <200601231611.51326.ak@suse.de>

[-- Attachment #1: Type: text/plain, Size: 1205 bytes --]

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>



[-- Attachment #2: cpudata_red_zone.patch --]
[-- Type: text/plain, Size: 1733 bytes --]

--- 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());

  reply	other threads:[~2006-01-23 16:29 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-23 11:21 [PATCH] garbage values in file /proc/net/sockstat pravin shelar
2006-01-23 11:24 ` Andi Kleen
2006-01-23 13:28   ` Eric Dumazet
2006-01-23 15:11     ` Andi Kleen
2006-01-23 16:28       ` Eric Dumazet [this message]
2006-01-23 16:46         ` Eric Dumazet
2006-01-25 13:31           ` Andi Kleen
2006-01-25 19:59             ` Ravikiran G Thirumalai
2006-01-25 20:47               ` Ravikiran G Thirumalai
2006-01-26  0:32               ` Andi Kleen
2006-01-25 21:45     ` Red zones (was: [PATCH] garbage values in file /proc/net/sockstat) Bernd Eckenfels
2006-01-26  5:28       ` Red zones Eric Dumazet
2006-01-26 10:07         ` Bernd Eckenfels

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=43D50445.1080208@cosmosbay.com \
    --to=dada1@cosmosbay.com \
    --cc=ak@suse.de \
    --cc=davem@davemloft.net \
    --cc=kiran@scalex86.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pravins@calsoftinc.com \
    --cc=shai@scalex86.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox