Hugetlb HPTE hashing weirdness

[Adam Litke]

I am seeing strange corruption on recent (eg. 2.6.14-rc1) kernels when
using hugetlb pages.  I have a simple program which does the following:
 1) Mmap a hugetlbfs file
 2) Test that all pages are zero
 3) Write 'A' to every byte of page 0, 'B' to page 1, and so on
 4) Verify that the data was written correctly

Occasionally, the verify step above will fail for the first page of the
mapping.  We'll discover that 'J' is scribbled on the page instead of
the expected 'A'.

It appears that the Hardware page tables are populated with stale
references from previous runs of the program.  I've instrumented
hash_huge_page() to see what is going on and when the program runs
correctly, hash_huge_page() is called once for each time the program
accesses a large page for the first time.  In subsequent runs,
hash_huge_page() is only called once for the first page accessed.  This
tells me that the hardware is using previous/stale hash entries to
provide the virtual to physical address translation for the rest of the
pages, thus potentially using the wrong huge page, leading to
corruption.

I may be mistaken, but it looks like for small pages the vsid is used as
the "key" to the hardware hash table but for huge pages only the virtual
page frame number (vpn) is used.  Could someone explain the difference
between the way huge pages and normal pages are hashed?  Using only the
vpn seems like it would result in false hash hits whenever separate
programs map huge pages at the same virtual address.

At any rate, I think this is a serious bug in hugetlb pages on ppc64 and
I am surprised others haven't hit it yet.  Thanks for any info you can
provide to help me debug this.