All of lore.kernel.org
 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 [PATCH 00 of 10] x86: unify asm/pgtable.h 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 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.