From: Andi Kleen <ak@suse.de>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: ying.huang@intel.com, mingo@elte.hu, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] [7/8] Implement true end_pfn_mapped for 32bit
Date: Tue, 12 Feb 2008 20:49:41 +0100 [thread overview]
Message-ID: <200802122049.41477.ak@suse.de> (raw)
In-Reply-To: <alpine.LFD.1.00.0802122035270.12988@apollo.tec.linutronix.de>
On Tuesday 12 February 2008 20:39:48 Thomas Gleixner wrote:
> On Mon, 11 Feb 2008, Andi Kleen wrote:
> > Even on 32bit 2MB pages can map more memory than is in the true
> > max_low_pfn if end_pfn is not highmem and not aligned to 2MB.
> > Add a end_pfn_map similar to x86-64 that accounts for this
> > fact. This is important for code that really needs to know about
> > all mapping aliases. Needed for followup patches (in this case EFI)
>
> It's not only necessary for followup patches, it is a question of
> general correctness.
True. ioremap already requires it.
> > @@ -36,7 +36,7 @@
> > #define max_pfn_mapped end_pfn_map
> > #else
> > #include <asm/page_32.h>
> > -#define max_pfn_mapped max_low_pfn
> > +#define max_pfn_mapped end_pfn_map
>
> We can nuke either max_pfn_mapped or end_pfn_map completely. I don't
> care about which one, but keeping both makes no sense at all.
I didn't want to bundle such a clean up into the bug fix
because my experience is that you usually reject that categorically.
I can send the removal of max_pfn_mapped as a follow up patch
if you apply this one.
-Andi
next prev parent reply other threads:[~2008-02-12 19:50 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-11 9:34 [PATCH] [0/8] Various kernel mapping bug fixes Andi Kleen
2008-02-11 9:34 ` [PATCH] [1/8] CPA: Fix gbpages support in try_preserve_lage_page Andi Kleen
2008-02-11 9:45 ` Thomas Gleixner
2008-02-11 10:12 ` Ingo Molnar
2008-02-11 11:01 ` Andi Kleen
2008-02-11 9:34 ` [PATCH] [2/8] CPA: Flush the caches when setting pages not present Andi Kleen
2008-02-11 11:00 ` Ingo Molnar
2008-02-11 12:26 ` Andi Kleen
2008-02-11 9:34 ` [PATCH] [3/8] CPA: Test the correct mapping alias on x86-64 Andi Kleen
2008-02-11 11:49 ` Ingo Molnar
2008-02-11 9:34 ` [PATCH] [4/8] CPA: Fix set_memory_x for ioremap Andi Kleen
2008-02-11 12:27 ` Ingo Molnar
2008-02-11 12:45 ` Andi Kleen
2008-02-11 9:34 ` [PATCH] [5/8] Fix logic error in 64bit memory hotadd Andi Kleen
2008-02-11 12:46 ` Ingo Molnar
2008-02-11 13:05 ` Andi Kleen
2008-02-11 13:33 ` Ingo Molnar
2008-02-11 13:44 ` Andi Kleen
2008-02-12 10:35 ` Yasunori Goto
2008-02-12 11:20 ` Andi Kleen
2008-02-11 9:34 ` [PATCH] [6/8] Account overlapped mappings in end_pfn_map Andi Kleen
2008-02-11 13:08 ` Ingo Molnar
2008-02-11 13:27 ` Andi Kleen
2008-02-11 13:55 ` Ingo Molnar
2008-02-11 14:16 ` Peter Zijlstra
2008-02-11 14:24 ` Andi Kleen
2008-02-11 14:41 ` Sam Ravnborg
2008-02-11 15:12 ` Arjan van de Ven
2008-02-11 9:34 ` [PATCH] [7/8] Implement true end_pfn_mapped for 32bit Andi Kleen
2008-02-12 19:39 ` Thomas Gleixner
2008-02-12 19:49 ` Andi Kleen [this message]
2008-02-12 20:25 ` Thomas Gleixner
2008-02-11 9:34 ` [PATCH] [8/8] RFC: Fix some EFI problems Andi Kleen
2008-02-12 20:04 ` Thomas Gleixner
2008-02-12 20:23 ` Andi Kleen
2008-02-12 20:48 ` Thomas Gleixner
2008-02-13 11:05 ` Andi Kleen
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=200802122049.41477.ak@suse.de \
--to=ak@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
--cc=ying.huang@intel.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.