From: Ingo Molnar <mingo@elte.hu>
To: Yinghai Lu <Yinghai.Lu@Sun.COM>
Cc: Mike Travis <travis@sgi.com>,
Christoph Lameter <clameter@sgi.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Sam Ravnborg <sam@ravnborg.org>
Subject: Re: [PATCH] x86_64: mark x86_cpu_to_node_map_init to __initdata like other xx_init
Date: Mon, 28 Jan 2008 11:34:39 +0100 [thread overview]
Message-ID: <20080128103439.GC24010@elte.hu> (raw)
In-Reply-To: <200801280116.54810.yinghai.lu@sun.com>
* Yinghai Lu <Yinghai.Lu@Sun.COM> wrote:
> -int x86_cpu_to_node_map_init[NR_CPUS] = {
> +int x86_cpu_to_node_map_init[NR_CPUS] __initdata = {
> [0 ... NR_CPUS-1] = NUMA_NO_NODE
> };
i remember some linker warning here. While this array should indeed only
be used in early init, that decision is dynamic and our linker warnings
do not notice it. There's a special marker for such cases:
__initdata_refok. But ... i'm slightly nervous about turning off a vital
warning like that.
Sam, it would be nice to have a DEBUG_INITDATA mode of operation: in
this case free_initmem() would not truly free those pages but would
unmap them via:
kernel_map_pages(page, nrpages, 0);
could be made dependent on DEBUG_PAGEALLOC.
If this debugging is enabled then if any code references it, we get a
hard page fault. If we had a debug mode like that then bugs in this area
would not go unnoticed.
Or perhaps just make this part of normal DEBUG_PAGEALLOC. Like the patch
below on top of latest x86.git. Hm?
Ingo
------------------->
Subject: x86: init memory debugging
From: Ingo Molnar <mingo@elte.hu>
debug incorrect/late access to init memory, by permanently unmapping
the init memory ranges. Depends on CONFIG_DEBUG_PAGEALLOC=y.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
arch/x86/mm/init_32.c | 12 ++++++++++++
arch/x86/mm/init_64.c | 11 +++++++++++
2 files changed, 23 insertions(+)
Index: linux-x86.q/arch/x86/mm/init_32.c
===================================================================
--- linux-x86.q.orig/arch/x86/mm/init_32.c
+++ linux-x86.q/arch/x86/mm/init_32.c
@@ -794,6 +794,18 @@ void free_init_pages(char *what, unsigne
unsigned long addr;
/*
+ * If debugging page accesses then do not free this memory but
+ * mark them not present - any buggy init-section access will
+ * create a kernel page fault:
+ */
+#ifdef CONFIG_DEBUG_PAGEALLOC
+ printk(KERN_INFO "debug: unmapping init memory %08lx..%08lx\n",
+ begin, PAGE_ALIGN(end));
+ set_memory_np(begin, (end - begin) >> PAGE_SHIFT);
+ return;
+#endif
+ set_memory_rw(begin, (end - begin) >> PAGE_SHIFT);
+ /*
* We just marked the kernel text read only above, now that
* we are going to free part of that, we need to make that
* writeable first.
Index: linux-x86.q/arch/x86/mm/init_64.c
===================================================================
--- linux-x86.q.orig/arch/x86/mm/init_64.c
+++ linux-x86.q/arch/x86/mm/init_64.c
@@ -580,6 +580,17 @@ void free_init_pages(char *what, unsigne
if (begin >= end)
return;
+ /*
+ * If debugging page accesses then do not free this memory but
+ * mark them not present - any buggy init-section access will
+ * create a kernel page fault:
+ */
+#ifdef CONFIG_DEBUG_PAGEALLOC
+ printk(KERN_INFO "debug: unmapping init memory %08lx..%08lx\n",
+ begin, PAGE_ALIGN(end));
+ set_memory_np(begin, (end - begin) >> PAGE_SHIFT);
+ return;
+#endif
printk(KERN_INFO "Freeing %s: %luk freed\n", what, (end - begin) >> 10);
for (addr = begin; addr < end; addr += PAGE_SIZE) {
next prev parent reply other threads:[~2008-01-28 10:35 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-28 9:16 [PATCH] x86_64: mark x86_cpu_to_node_map_init to __initdata like other xx_init Yinghai Lu
2008-01-28 10:34 ` Ingo Molnar [this message]
[not found] <200801290053.45776.yinghai.lu@sun.com>
2008-01-29 9:05 ` [PATCH 1/2] print out node_data addr and bootmap_start addr Yinghai Lu
[not found] ` <20080201170908.GB2159@elte.hu>
2008-02-01 21:29 ` [PATCH] x86_64: mark x86_cpu_to_node_map_init to __initdata like other xx_init Yinghai Lu
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=20080128103439.GC24010@elte.hu \
--to=mingo@elte.hu \
--cc=Yinghai.Lu@Sun.COM \
--cc=clameter@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sam@ravnborg.org \
--cc=travis@sgi.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.