From: Eric Dumazet <dada1@cosmosbay.com>
To: Andi Kleen <ak@suse.de>
Cc: Andrew Morton <akpm@osdl.org>, Mikael Starvik <starvik@axis.com>,
David Howells <dhowells@redhat.com>,
Kyle McMartin <kyle@parisc-linux.org>,
Anton Blanchard <anton@samba.org>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
Martin Schwidefsky <schwidefsky@de.ibm.com>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
Paul Mundt <lethal@linux-sh.org>,
"David S. Miller" <davem@davemloft.net>,
William Lee Irwin III <wli@holomorphy.com>,
Andi Kleen <ak@muc.de>, Christian Zankel <chris@zankel.net>,
Philippe Elie <phil.el@wanadoo.fr>,
Nathan Scott <nathans@sgi.com>, Jens Axboe <axboe@suse.de>,
linux-arch@vger.kernel.org
Subject: Re: percpu data changes
Date: Fri, 03 Feb 2006 12:01:22 +0100 [thread overview]
Message-ID: <43E33802.6090502@cosmosbay.com> (raw)
In-Reply-To: <200602031051.49816.ak@suse.de>
[-- Attachment #1: Type: text/plain, Size: 898 bytes --]
Andi Kleen a écrit :
> On Friday 03 February 2006 10:17, Andrew Morton wrote:
>> It seems that powerpc has gone and changed their implementation of percpu
>> data so that there is no memory allocated for not-possible CPUs. To save a
>> bit of RAM.
>>
>> This means that any code which does
>>
>> for (i = 0; i < NR_CPUS; i++)
>> touch(percpudata(i))
>>
>> will explode on powerpc.
>
> It also explodes since some time on x86-64.
>
> But I added a workaround now (or rather sent one and Linus dropped it)
> to point the not possible CPUs to the reference data and not free it.
> With that violating that protocol is mostly harmless.
>
> Later the plan was to point it to unmapped data to catch all users.
Maybe you can port the following i386 patch to x86_64 ? (I dont have a x86_64
test machine at this moment)
(This was sent to Andrew Jan 29th, and is included in 2.6.16-rc1-mm5)
Eric
[-- Attachment #2: i386_mm_init.patch --]
[-- Type: text/plain, Size: 1511 bytes --]
--- a/arch/i386/Kconfig.debug 2006-01-29 22:30:10.000000000 +0100
+++ b/arch/i386/Kconfig.debug 2006-01-29 22:35:54.000000000 +0100
@@ -61,6 +61,18 @@
portion of the kernel code won't be covered by a 2MB TLB anymore.
If in doubt, say "N".
+config DEBUG_INITDATA
+ bool "Read/Write protect kernel init data structures"
+ depends on DEBUG_KERNEL
+ help
+ The init data is normally freed when kernel has booted.
+ Some code may still try to read or write to data in this area.
+ If you say Y here, the kernel will mark this zone as not readable
+ or writeable at all. Buggy code will then fault.
+ This option may have a slight performance impact because a
+ portion of the kernel code won't be covered by a 2MB TLB anymore.
+ If in doubt, say "N".
+
config 4KSTACKS
bool "Use 4Kb + 4Kb for kernel stacks instead of 8Kb" if DEBUG_KERNEL
default y
--- a/arch/i386/mm/init.c 2006-01-25 10:17:24.000000000 +0100
+++ b/arch/i386/mm/init.c 2006-01-29 22:38:53.000000000 +0100
@@ -750,11 +750,18 @@
for (addr = begin; addr < end; addr += PAGE_SIZE) {
ClearPageReserved(virt_to_page(addr));
set_page_count(virt_to_page(addr), 1);
+#ifdef CONFIG_DEBUG_INITDATA
+ change_page_attr(virt_to_page(addr), 1, __pgprot(0));
+#else
memset((void *)addr, 0xcc, PAGE_SIZE);
+#endif
free_page(addr);
totalram_pages++;
}
printk(KERN_INFO "Freeing %s: %ldk freed\n", what, (end - begin) >> 10);
+#ifdef CONFIG_DEBUG_INITDATA
+ global_flush_tlb();
+#endif
}
void free_initmem(void)
next prev parent reply other threads:[~2006-02-03 11:03 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-03 9:17 percpu data changes Andrew Morton
2006-02-03 9:18 ` Andrew Morton
2006-02-03 9:35 ` Andrew Morton
2006-02-03 9:38 ` David S. Miller
2006-02-03 9:36 ` William Lee Irwin III
2006-02-03 9:40 ` David S. Miller
2006-02-03 9:51 ` Andi Kleen
2006-02-03 11:01 ` Eric Dumazet [this message]
2006-02-03 11:07 ` Andi Kleen
2006-02-03 15:36 ` Kyle McMartin
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=43E33802.6090502@cosmosbay.com \
--to=dada1@cosmosbay.com \
--cc=ak@muc.de \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=anton@samba.org \
--cc=axboe@suse.de \
--cc=benh@kernel.crashing.org \
--cc=chris@zankel.net \
--cc=davem@davemloft.net \
--cc=dhowells@redhat.com \
--cc=heiko.carstens@de.ibm.com \
--cc=kyle@parisc-linux.org \
--cc=lethal@linux-sh.org \
--cc=linux-arch@vger.kernel.org \
--cc=nathans@sgi.com \
--cc=paulus@samba.org \
--cc=phil.el@wanadoo.fr \
--cc=schwidefsky@de.ibm.com \
--cc=starvik@axis.com \
--cc=wli@holomorphy.com \
/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.