From: Ingo Molnar <mingo@elte.hu>
To: Yinghai Lu <yinghai@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
"H. Peter Anvin" <hpa@zytor.com>,
Andrew Morton <akpm@linux-foundation.org>,
Shaohua Li <shaohua.li@intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Yasunori Goto <y-goto@jp.fujitsu.com>
Subject: Re: [PATCH] x86: remove wrong -1 in calling init_memory_mapping
Date: Tue, 28 Oct 2008 09:42:55 +0100 [thread overview]
Message-ID: <20081028084255.GM15734@elte.hu> (raw)
In-Reply-To: <49061E86.6080408@kernel.org>
* Yinghai Lu <yinghai@kernel.org> wrote:
> From: Shaohua Li <shaohua.li@intel.com>
>
> impact: make memory hot plug got last page mapped.
>
> Shuahua Li found:
> Round up address to a page, otherwise the last page isn't mapped.
>
> No, I just did some experiments on a desktop for memory hotplug and this bug
> triggered a crash in my test.
> Yinghai's suggestion also fixed the bug. I just want to have safer method. Anyway, either approach is ok to me.
>
> So acctually we don't need to round it.
> just remove that extra -1
>
> Signed-off-by: Yinghai <yinghai@kernel.org>
applied to tip/x86/urgent, thanks guys!
Note, i changed the "Impact:" line. We try to use it to provide a
single-line description of what practical impact a patch has. For
example if it's a bugfix, we try to describe what type of bug effect
it fixes. If it's a cleanup, we mark it as a cleanup. If it introduces
a new feature or changes existing behavior to improve the code, we
describe that.
There's no hard rules, so here are a few common examples:
Impact: fix crash with memory hotplug
Impact: cleanup
Impact: fix bootup crash on certain types of hardware
Impact: improve printk output
Impact: add (default-off) debug feature
Impact: make the implementation faster
Impact: cleanup (no object code changed)
Impact: change the implementation to be more robust
Impact: fix bootup hang on certain systems
Impact: add new system call
Impact: enable hardware feature and make use of it
Impact: fix rare crash under high DB load
etc. etc.
"Wrong" impact lines are the ones which just describe the change
itself, not the general impact:
Impact: add +1 to condition
Impact: change foo() to call bar() as well
Impact: flush the TLB when tearing down a mapping
Impact: check for NULL
these are less useful because they just duplicate the information
already available in the patch itself.
Ingo
----------------->
>From 60817c9b31ef7897d60bca2f384cbc316a3fdd8b Mon Sep 17 00:00:00 2001
From: Shaohua Li <shaohua.li@intel.com>
Date: Mon, 27 Oct 2008 13:03:18 -0700
Subject: [PATCH] x86, memory hotplug: remove wrong -1 in calling init_memory_mapping()
Impact: fix crash with memory hotplug
Shuahua Li found:
| I just did some experiments on a desktop for memory hotplug and this bug
| triggered a crash in my test.
|
| Yinghai's suggestion also fixed the bug.
We don't need to round it, just remove that extra -1
Signed-off-by: Yinghai <yinghai@kernel.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
arch/x86/mm/init_64.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index c7a4c5a..f79a02f 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -837,7 +837,7 @@ int arch_add_memory(int nid, u64 start, u64 size)
unsigned long nr_pages = size >> PAGE_SHIFT;
int ret;
- last_mapped_pfn = init_memory_mapping(start, start + size-1);
+ last_mapped_pfn = init_memory_mapping(start, start + size);
if (last_mapped_pfn > max_pfn_mapped)
max_pfn_mapped = last_mapped_pfn;
prev parent reply other threads:[~2008-10-28 8:43 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-27 20:03 [PATCH] x86: remove wrong -1 in calling init_memory_mapping Yinghai Lu
2008-10-28 8:42 ` Ingo Molnar [this message]
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=20081028084255.GM15734@elte.hu \
--to=mingo@elte.hu \
--cc=akpm@linux-foundation.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=shaohua.li@intel.com \
--cc=tglx@linutronix.de \
--cc=y-goto@jp.fujitsu.com \
--cc=yinghai@kernel.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.