Hugh Dickins aeed5fce37 x86: fix PAE pmd_bad bootup warning
Fix warning from pmd_bad() at bootup on a HIGHMEM64G HIGHPTE x86_32.

That came from 9fc34113f6880b215cbea4e7017fc818700384c2 x86: debug pmd_bad();
but we understand now that the typecasting was wrong for PAE in the previous
version: pagetable pages above 4GB looked bad and stopped Arjan from booting.

And revert that cded932b75ab0a5f9181ee3da34a0a488d1a14fd x86: fix pmd_bad
and pud_bad to support huge pages.  It was the wrong way round: we shouldn't
weaken every pmd_bad and pud_bad check to let huge pages slip through - in
part they check that we _don't_ have a huge page where it's not expected.

Put the x86 pmd_bad() and pud_bad() definitions back to what they have long
been: they can be improved (x86_32 should use PTE_MASK, to stop PAE thinking
junk in the upper word is good; and x86_64 should follow x86_32's stricter
comparison, to stop thinking any subset of required bits is good); but that
should be a later patch.

Fix Hans' good observation that follow_page() will never find pmd_huge()
because that would have already failed the pmd_bad test: test pmd_huge in
between the pmd_none and pmd_bad tests.  Tighten x86's pmd_huge() check?
No, once it's a hugepage entry, it can get quite far from a good pmd: for
example, PROT_NONE leaves it with only ACCESSED of the KERN_PGTABLE bits.

However... though follow_page() contains this and another test for huge
pages, so it's nice to keep it working on them, where does it actually get
called on a huge page?  get_user_pages() checks is_vm_hugetlb_page(vma) to
to call alternative hugetlb processing, as does unmap_vmas() and others.

Signed-off-by: Hugh Dickins <hugh@veritas.com>
Earlier-version-tested-by: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jeff Chua <jeff.chua.linux@gmail.com>
Cc: Hans Rosenfeld <hans.rosenfeld@amd.com>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-05-06 13:08:58 -07:00
..
2008-04-17 17:41:07 +02:00
2008-01-30 13:34:07 +01:00
2008-04-17 17:41:33 +02:00
2007-10-17 20:17:13 +02:00
2008-04-19 19:19:54 +02:00
2008-02-04 16:48:04 +01:00
2007-10-17 20:17:15 +02:00
2008-04-17 17:41:19 +02:00
2007-10-17 20:17:08 +02:00
2008-05-01 08:03:58 -07:00
2008-05-01 08:04:01 -07:00
2007-10-17 20:17:08 +02:00
2007-10-17 20:17:21 +02:00
2008-01-30 13:33:09 +01:00
2008-04-19 19:19:58 +02:00
2008-04-17 17:41:33 +02:00
2008-01-30 13:33:35 +01:00
2008-02-04 16:48:03 +01:00
2008-04-19 19:19:55 +02:00
2008-01-30 13:33:14 +01:00
2008-04-18 00:46:35 +02:00
2008-01-30 13:30:28 +01:00
2008-05-01 08:04:01 -07:00
2007-10-30 00:22:22 +01:00
2008-01-30 13:30:16 +01:00
2008-04-17 20:05:37 +02:00
2008-04-27 12:01:19 +03:00
2007-10-17 20:16:47 +02:00
2008-01-30 13:31:55 +01:00
2007-10-17 20:26:15 +02:00
2008-01-30 13:31:43 +01:00
2007-10-23 22:37:24 +02:00
2008-04-17 17:41:30 +02:00
2008-04-17 17:41:01 +02:00
2008-04-17 17:40:58 +02:00
2008-01-30 13:34:10 +01:00
2008-04-17 17:41:19 +02:00
2008-04-19 19:19:55 +02:00
2008-04-26 23:41:04 +02:00
2008-04-24 23:57:31 +02:00
2008-04-28 08:58:23 -07:00
2008-04-30 23:15:34 +02:00
2008-04-30 23:15:34 +02:00
2007-10-17 20:17:08 +02:00
2007-10-17 20:17:08 +02:00
2008-04-19 19:19:57 +02:00
2007-10-17 20:17:08 +02:00
2008-04-17 10:42:34 -04:00
2007-10-23 22:37:24 +02:00
2008-04-24 23:15:44 +02:00
2008-01-30 13:31:21 +01:00
2007-10-23 22:37:24 +02:00
2007-10-23 22:37:24 +02:00
2008-04-19 19:19:55 +02:00
2008-04-29 08:06:03 -07:00
2008-02-06 10:41:02 -08:00
2007-10-17 20:26:18 +02:00
2008-04-29 13:45:24 +02:00
2008-04-26 17:35:46 +02:00
2007-10-17 20:32:38 +02:00
2008-01-30 13:32:39 +01:00