From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: LKML <linux-kernel@vger.kernel.org>, Andi Kleen <ak@suse.de>,
Glauber de Oliveira Costa <glommer@gmail.com>,
Jan Beulich <jbeulich@novell.com>
Subject: Re: [PATCH 00 of 10] x86: unify asm/pgtable.h
Date: Tue, 08 Jan 2008 16:53:29 -0800 [thread overview]
Message-ID: <47841B09.3020507@goop.org> (raw)
In-Reply-To: <20080109003034.GA4658@elte.hu>
Ingo Molnar wrote:
> * Ingo Molnar <mingo@elte.hu> wrote:
>
>
>>>>>> #define __PAGE_KERNEL_EXEC \
>>>>>> - (_PAGE_PRESENT | _PAGE_RW | _PAGE_DIRTY | _PAGE_ACCESSED | _PAGE_GLOBAL)
>>>>>> + (_PAGE_PRESENT | _PAGE_RW | _PAGE_DIRTY | _PAGE_ACCESSED)
>>>>>>
>>>>>>
>>>> This shouldn't be necessary. The old 64-bit code defined everything
>>>> without _PAGE_GLOBAL, but then used a MAKE_GLOBAL() macro to OR it
>>>> in later. This seemed a bit roundabout to me, so I just put it in
>>>> from the outset.
>>>>
>> actually, this is wrong.
>>
>> a couple of places use __PAGE_* values, which you've now changed to
>> include the _PAGE_GLOBAL flag.
>>
>
> yep, fixing this resolves the crash.
>
Bugger. OK.
And I don't see quite how the global flag is causing the BUG bug in
change_page_attr(). The logic is:
if (pgprot_val(prot) != pgprot_val(ref_prot)) {
...
} else {
if (!pte_huge(*kpte)) {
...
} else
BUG();
}
Is _PAGE_GLOBAL causing the first if() to fall through to the second
clause? Because otherwise it shouldn't have any effect on the
pte_huge() test.
But given that ref_prot is set to PAGE_KERNEL or PAGE_KERNEL_EXEC, which
will have _PAGE_GLOBAL in it either way, I don't see where the problem
is coming from.
Gah! This can't be right! I think the original change_page_attr() code
is plain buggy.
The crash call chain is:
[<ffffffff8021db68>] change_page_attr_addr+0x9e/0x119
[<ffffffff8021d44f>] ioremap_change_attr+0x49/0x58
[<ffffffff8021d626>] iounmap+0xbe/0xe0
...
ioremap_change_attr does:
err = change_page_attr_addr(vaddr,npages,__pgprot(__PAGE_KERNEL|flags));
Now, in the current code (ie, before my patch), __PAGE_KERNEL doesn't
have _PAGE_GLOBAL set, but PAGE_KERNEL does. Therefore,
change_page_attr_addr calls
__change_page_attr(address, pfn, prot, PAGE_KERNEL);
which means:
__change_page_attr(address, pfn, pgprot(__PAGE_KERNEL), PAGE_KERNEL);
(iounmap always passes flags of 0) which just happens to fail the test:
if (pgprot_val(prot) != pgprot_val(ref_prot)) {
because prot doesn't contain _PAGE_GLOBAL and ref_prot does.
In other words, prot and ref_prot can never be equal, so this path is
always taken, and the other branch which tests pte_huge() is never run.
Andi? Jan? Is this code just buggy, or is there something else going
on here?
J
next prev parent reply other threads:[~2008-01-09 1:03 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-08 22:00 Jeremy Fitzhardinge
2008-01-08 22:00 ` [PATCH 01 of 10] x86: move all asm/pgtable constants into one place Jeremy Fitzhardinge
2008-01-08 22:00 ` [PATCH 02 of 10] x86: avoid name conflict for Voyager leave_mm Jeremy Fitzhardinge
2008-01-08 22:00 ` [PATCH 03 of 10] x86/pgtable: unify pagetable accessors Jeremy Fitzhardinge
2008-01-08 22:00 ` [PATCH 04 of 10] x86: unify pgtable accessors which use supported_pte_mask Jeremy Fitzhardinge
2008-01-08 22:00 ` [PATCH 05 of 10] x86: page.h: make pte_t a union to always include pte element Jeremy Fitzhardinge
2008-01-08 22:00 ` [PATCH 06 of 10] x86/vmi: fix compilation as a result of pte_t changes Jeremy Fitzhardinge
2008-01-08 22:00 ` [PATCH 07 of 10] x86: pgtable: unify pte accessors Jeremy Fitzhardinge
2008-01-08 22:00 ` [PATCH 08 of 10] x86: unify zero_page definition Jeremy Fitzhardinge
2008-01-08 22:00 ` [PATCH 09 of 10] x86: unify paravirt pagetable accessors Jeremy Fitzhardinge
2008-01-08 22:00 ` [PATCH 10 of 10] xen: mask out PWT too Jeremy Fitzhardinge
2008-01-09 9:17 ` Jan Beulich
2008-01-09 19:04 ` Jeremy Fitzhardinge
2008-01-08 22:42 ` [PATCH 00 of 10] x86: unify asm/pgtable.h Ingo Molnar
2008-01-08 23:12 ` Ingo Molnar
2008-01-08 23:23 ` Jeremy Fitzhardinge
2008-01-08 23:28 ` Ingo Molnar
2008-01-08 23:44 ` Ingo Molnar
2008-01-08 23:51 ` Ingo Molnar
2008-01-09 0:01 ` Ingo Molnar
2008-01-09 0:13 ` Jeremy Fitzhardinge
2008-01-09 0:20 ` Ingo Molnar
2008-01-09 0:28 ` Ingo Molnar
2008-01-09 0:30 ` Ingo Molnar
2008-01-09 0:43 ` Ingo Molnar
2008-01-09 0:55 ` Jeremy Fitzhardinge
2008-01-09 1:09 ` Jeremy Fitzhardinge
2008-01-09 1:16 ` Ingo Molnar
2008-01-09 1:18 ` Andi Kleen
2008-01-09 1:22 ` Ingo Molnar
2008-01-09 1:37 ` Andi Kleen
2008-01-09 1:21 ` Jeremy Fitzhardinge
2008-01-09 1:37 ` Ingo Molnar
2008-01-09 0:53 ` Jeremy Fitzhardinge [this message]
2008-01-09 0:59 ` Ingo Molnar
2008-01-09 1:07 ` Jeremy Fitzhardinge
2008-01-09 1:12 ` Andi Kleen
2008-01-09 1:20 ` Ingo Molnar
2008-01-09 1:35 ` Jeremy Fitzhardinge
2008-01-09 1:42 ` Andi Kleen
2008-01-09 1:56 ` Jeremy Fitzhardinge
2008-01-09 2:11 ` Andi Kleen
2008-01-09 3:22 ` Jeremy Fitzhardinge
2008-01-09 10:48 ` Ingo Molnar
2008-01-09 10:47 ` Ingo Molnar
2008-01-09 14:26 ` Andi Kleen
2008-01-09 9:37 ` Jan Beulich
2008-01-09 1:11 ` Andi Kleen
2008-01-09 0:07 ` 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=47841B09.3020507@goop.org \
--to=jeremy@goop.org \
--cc=ak@suse.de \
--cc=glommer@gmail.com \
--cc=jbeulich@novell.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/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
Powered by JetHome