linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Liang Li <liang.li@windriver.com>
To: Yinghai <yinghai.lu@oracle.com>
Cc: akpm@linux-foundation.org, hpa@zytor.com, mingo@elte.hu,
	tglx@linutronix.de, wangchen@cn.fujitsu.com,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: + x86-fix-handling-of-the-reservetop-boot-option.patch added to -mm tree
Date: Thu, 8 Apr 2010 09:53:53 +0800	[thread overview]
Message-ID: <20100408015353.GB4053@localhost> (raw)
In-Reply-To: <4BBD2DD4.1060101@oracle.com>

On Wed, Apr 07, 2010 at 06:13:56PM -0700, Yinghai wrote:
> On 04/07/2010 06:05 PM, Liang Li wrote:
> > On Wed, Apr 07, 2010 at 04:52:03PM -0700, Yinghai wrote:
> >> On 04/07/2010 03:00 PM, akpm@linux-foundation.org wrote:
> >>> The patch titled
> >>>      x86: fix handling of the 'reservetop' boot option
> >>> has been added to the -mm tree.  Its filename is
> >>>      x86-fix-handling-of-the-reservetop-boot-option.patch
> >>>
> >>> Before you just go and hit "reply", please:
> >>>    a) Consider who else should be cc'ed
> >>>    b) Prefer to cc a suitable mailing list as well
> >>>    c) Ideally: find the original patch on the mailing list and do a
> >>>       reply-to-all to that, adding suitable additional cc's
> >>>
> >>> *** Remember to use Documentation/SubmitChecklist when testing your code ***
> >>>
> >>> See http://userweb.kernel.org/~akpm/stuff/added-to-mm.txt to find
> >>> out what to do about this
> >>>
> >>> The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
> >>>
> >>> ------------------------------------------------------
> >>> Subject: x86: fix handling of the 'reservetop' boot option
> >>> From: Liang Li <liang.li@windriver.com>
> >>>
> >>> When specifying the 'reservetop=0xbadc0de' kernel parameter, the kernel
> >>> will stop booting due to a early_ioremap bug that relate to commit
> >>> 8827247ff ("x86: don't define __this_fixmap_does_not_exist()").
> >>>
> >>> The root cause of boot failure problem is the value of 'slot_virt[i]' was
> >>> initialized in setup_arch->early_ioremap_init.  But later in setup_arch,
> >>> the function 'parse_early_param' will modify 'FIXADDR_TOP' when
> >>> 'reservetop=0xbadc0de' being specified.
> >>>
> >>> The simplest fix might be use __fix_to_virt(idx0) to get updated value
> >>> of 'FIXADDR_TOP' in '__early_ioremap' instead of reference old value
> >>> from slot_virt[slot] directly.
> >>>
> >>> Signed-off-by: Liang Li <liang.li@windriver.com>
> >>> Cc: Wang Chen <wangchen@cn.fujitsu.com>
> >>> Cc: Ingo Molnar <mingo@elte.hu>
> >>> Cc: Thomas Gleixner <tglx@linutronix.de>
> >>> Cc: "H. Peter Anvin" <hpa@zytor.com>
> >>> Cc: Yinghai Lu <yinghai@kernel.org>
> >>> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> >>> ---
> >>>
> >>>  arch/x86/mm/ioremap.c |    4 ++--
> >>>  1 file changed, 2 insertions(+), 2 deletions(-)
> >>>
> >>> diff -puN arch/x86/mm/ioremap.c~x86-fix-handling-of-the-reservetop-boot-option arch/x86/mm/ioremap.c
> >>> --- a/arch/x86/mm/ioremap.c~x86-fix-handling-of-the-reservetop-boot-option
> >>> +++ a/arch/x86/mm/ioremap.c
> >>> @@ -537,9 +537,9 @@ __early_ioremap(resource_size_t phys_add
> >>>  		--nrpages;
> >>>  	}
> >>>  	if (early_ioremap_debug)
> >>> -		printk(KERN_CONT "%08lx + %08lx\n", offset, slot_virt[slot]);
> >>> +		printk(KERN_CONT "%08lx + %08lx\n", offset, __fix_to_virt(idx0));
> >>>  
> >>> -	prev_map[slot] = (void __iomem *)(offset + slot_virt[slot]);
> >>> +	prev_map[slot] = (void __iomem *)(offset + __fix_to_virt(idx0));
> >>>  	return prev_map[slot];
> >>>  }
> >>>  
> >>> _
> >>
> >> not that simple. but it looks like correct direction.
> >>
> >> please consider:
> >> when early_parsing reserve_top, double check if there is left over in prev_map[], and 
> >> reinitialize slot_virt[] and clear old PMD and  setup new PMD if needed.
> > 
> > Hi Yinghai,
> > 
> > Thanks for your reply, its better to have eyes on then being ignored. :)
> > 
> > Your suggestions were considered before the patch to public, let me try
> > to explain:
> > 
> > #1 check/adjust prev_map[]?
> > In my tests, seems early_ioremap is untouched between early_ioremap_init
> > and parse_early_param so I did not check prev_map. Even its get touched,
> > I think we could do nothing to this mapping, since prev_map[i] just
> > record virt addr for clients of early_ioremap. We can check and adjust
> > prev_map but clients of early_ioremap won't realize the fact so nothing
> > being fixed or broken.
> 
> efi related code need them
> 
> dmi 
> 
> you need to add bug_on if there is still have left over, and need the caller to re map it again later.
> 
> > 
> > #2 reinitialize slot_virt and update PMD
> > I actually tried this approach, call early_ioremap_init again after
> > parse_early_param will do that work, it also works but I am not sure
> > that is the better solution or too heavy for solve the problem? So I
> > tend to say 'simplest' solution in git commit log.
> 
> how about PMD? you don't need set PMD again.
> 
> YH

Hi Yinghai,

Does this similar modification like this is more preferred?

diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index a1dcfa3..30a3e97 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -347,6 +347,7 @@ extern void __iomem *early_ioremap(resource_size_t phys_addr,
 extern void __iomem *early_memremap(resource_size_t phys_addr,
 				    unsigned long size);
 extern void early_iounmap(void __iomem *addr, unsigned long size);
+extern void fixup_early_ioremap(void);
 
 #define IO_SPACE_LIMIT 0xffff
 
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index ea82ef0..fe06296 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -448,6 +448,23 @@ static inline void __init early_clear_fixmap(enum fixed_addresses idx)
 static void __iomem *prev_map[FIX_BTMAPS_SLOTS] __initdata;
 static unsigned long prev_size[FIX_BTMAPS_SLOTS] __initdata;
 
+void __init fixup_early_ioremap(void)
+{
+	int i;
+	for (i = 0; i < FIX_BTMAPS_SLOTS; i++) {
+		if (prev_map[i])
+			break;
+	}
+
+	if (i == FIX_BTMAPS_SLOTS)
+		WARN_ON(1);
+
+	for (i = 0; i < FIX_BTMAPS_SLOTS; i++)
+		slot_virt[i] = __fix_to_virt(FIX_BTMAP_BEGIN - NR_FIX_BTMAPS * i);
+
+	return;
+}
+
 static int __init check_early_ioremap_leak(void)
 {
 	int count = 0;
diff --git a/arch/x86/mm/pgtable.c b/arch/x86/mm/pgtable.c
index 5c4ee42..ea4d54c 100644
--- a/arch/x86/mm/pgtable.c
+++ b/arch/x86/mm/pgtable.c
@@ -4,6 +4,7 @@
 #include <asm/pgtable.h>
 #include <asm/tlb.h>
 #include <asm/fixmap.h>
+#include <asm/io.h>
 
 #define PGALLOC_GFP GFP_KERNEL | __GFP_NOTRACK | __GFP_REPEAT | __GFP_ZERO
 
@@ -351,6 +352,7 @@ void __init reserve_top_address(unsigned long reserve)
 	printk(KERN_INFO "Reserving virtual address space above 0x%08x\n",
 	       (int)-reserve);
 	__FIXADDR_TOP = -reserve - PAGE_SIZE;
+	fixup_early_ioremap();
 #endif
 }
 

Thanks,
	-Liang Li


  reply	other threads:[~2010-04-08  1:55 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <201004072200.o37M0d19009878@imap1.linux-foundation.org>
2010-04-07 23:52 ` + x86-fix-handling-of-the-reservetop-boot-option.patch added to -mm tree Yinghai
2010-04-08  1:05   ` Liang Li
2010-04-08  1:13     ` Yinghai
2010-04-08  1:53       ` Liang Li [this message]
2010-04-08  2:18         ` Liang Li
2010-04-08  4:30         ` Yinghai
2010-04-08  4:59           ` Liang Li
2010-04-08  6:57             ` Yinghai
2010-04-08  8:58               ` Liang Li
2010-04-08 17:12                 ` Jeremy Fitzhardinge
2010-04-08 18:03                   ` Yinghai
2010-04-08 18:38                     ` [LKML] " Konrad Rzeszutek Wilk
2010-04-09  0:28                       ` Liang Li
2010-04-08 17:10               ` Jeremy Fitzhardinge

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=20100408015353.GB4053@localhost \
    --to=liang.li@windriver.com \
    --cc=akpm@linux-foundation.org \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    --cc=wangchen@cn.fujitsu.com \
    --cc=yinghai.lu@oracle.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).