From: Ingo Molnar <mingo@elte.hu>
To: Andi Kleen <ak@suse.de>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
LKML <linux-kernel@vger.kernel.org>,
Glauber de Oliveira Costa <glommer@gmail.com>,
Jan Beulich <jbeulich@novell.com>
Subject: Re: [PATCH 0 of 4] x86: some more patches
Date: Wed, 16 Jan 2008 08:25:59 +0100 [thread overview]
Message-ID: <20080116072559.GC30950@elte.hu> (raw)
In-Reply-To: <200801160144.33140.ak@suse.de>
* Andi Kleen <ak@suse.de> wrote:
> [...] I found that Jan's ioremap fix also causes silent hangs here
> during earlier bisecting (not sure why)
please send a fuller bugreport - all these problems on your testbox
might be interrelated. Jan's patch is undone in a later part of the
series so it's a bisection artifact. I've fixed that up.
Ingo
------------------->
Subject: x86: fix 64-bit ioremap()
From: From: Jan Beulich <jbeulich@novell.com>
> Yeah, that may be true, but this particular tree is weird, and I'm trying
> to understand what's going on here. Specifically, 64-bit ioremap()s
> *don't* set _PAGE_GLOBAL, which appears to be an accident resulting from
> the strange definitions of __PAGE_KERNEL_* vs PAGE_KERNEL_*.
ioremap() should set G agreed.
> For example, ioremap_64.c:__ioremap() creates a vma for the io mapping, and
> explicitly sets _PAGE_GLOBAL in the vma's version of pgprot - but then it
> calls ioremap_page_range() to actually create the mapping, which ends up
> making a non-global mapping, because its rolling its own version of
> PAGE_KERNEL by using pgprot(__PAGE_KERNEL) - which is not the actual
> definition of PAGE_KERNEL.
That should not really matter because ioremap_change_attr()->c_p_a is only called
when flags is != 0 and that means it is already different from PAGE_KERNEL.
>
> I think there's a bug around here, but I think its currently being hidden
There's one Jan pointed out: iounmap does not subtract the guard page size
so it ends up resetting one page too much. That is probably what causes your
problem. But again you should be passing in G in the first place.
Additionally I found it necessary to fix ioremap_64.c's use of
change_page_attr_addr():
[ mingo@elte.hu: fixed coding style errors ]
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
arch/x86/mm/ioremap_64.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
Index: linux-x86.q/arch/x86/mm/ioremap_64.c
===================================================================
--- linux-x86.q.orig/arch/x86/mm/ioremap_64.c
+++ linux-x86.q/arch/x86/mm/ioremap_64.c
@@ -45,10 +45,12 @@ ioremap_change_attr(unsigned long phys_a
unsigned long vaddr = (unsigned long) __va(phys_addr);
/*
- * Must use a address here and not struct page because the phys addr
- * can be a in hole between nodes and not have an memmap entry.
+ * Must use an address here and not struct page because the
+ * phys addr can be a in hole between nodes and not have an
+ * memmap entry:
*/
- err = change_page_attr_addr(vaddr,npages,__pgprot(__PAGE_KERNEL|flags));
+ err = change_page_attr_addr(vaddr, npages,
+ MAKE_GLOBAL(__PAGE_KERNEL|flags));
if (!err)
global_flush_tlb();
}
@@ -181,7 +183,7 @@ void iounmap(volatile void __iomem *addr
/* Reset the direct mapping. Can block */
if (p->flags >> 20)
- ioremap_change_attr(p->phys_addr, p->size, 0);
+ ioremap_change_attr(p->phys_addr, get_vm_area_size(p), 0);
/* Finally remove it */
o = remove_vm_area((void *)addr);
next prev parent reply other threads:[~2008-01-16 7:26 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-15 22:17 [PATCH 0 of 4] x86: some more patches Jeremy Fitzhardinge
2008-01-15 22:17 ` [PATCH 1 of 4] x86: refactor mmu ops in paravirt.h Jeremy Fitzhardinge
2008-01-15 22:17 ` [PATCH 2 of 4] x86: fix warning Jeremy Fitzhardinge
2008-01-15 22:17 ` [PATCH 3 of 4] x86: clean up pte_modify Jeremy Fitzhardinge
2008-01-16 0:43 ` Andi Kleen
2008-01-15 22:17 ` [PATCH 4 of 4] x86: mask NX from pte_pfn Jeremy Fitzhardinge
2008-01-18 13:52 ` Hugh Dickins
2008-01-18 14:01 ` Ingo Molnar
2008-01-18 15:55 ` Jeremy Fitzhardinge
2008-01-15 22:35 ` [PATCH 0 of 4] x86: some more patches Ingo Molnar
2008-01-15 23:28 ` Jeremy Fitzhardinge
2008-01-16 0:44 ` Andi Kleen
2008-01-16 7:25 ` Ingo Molnar [this message]
2008-01-16 14:22 ` Ingo Molnar
2008-01-16 14:44 ` Andi Kleen
2008-01-16 14:54 ` Ingo Molnar
2008-01-16 15:18 ` Ingo Molnar
2008-01-16 15:26 ` Andi Kleen
2008-01-16 15:42 ` Jan Beulich
2008-01-16 15:47 ` Ingo Molnar
2008-01-16 16:06 ` Ingo Molnar
2008-01-16 17:05 ` Jeremy Fitzhardinge
2008-01-16 17:12 ` Andi Kleen
2008-01-16 17:40 ` Andi Kleen
2008-01-16 20:22 ` Ingo Molnar
2008-01-16 20:59 ` Andi Kleen
2008-01-16 21:06 ` Ingo Molnar
2008-01-16 21:35 ` 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=20080116072559.GC30950@elte.hu \
--to=mingo@elte.hu \
--cc=ak@suse.de \
--cc=glommer@gmail.com \
--cc=jbeulich@novell.com \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox