mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

  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