All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.