Bug 113522

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030611

Description of problem:

As reported by Joel Becker on oracle-list: 

> Folks,
>	Some time ago, a customer (NASA) started experiencing
> crashes.  The offending process was always sshd, and the trace
> always showed the BUG() in mm/page_alloc.c:__free_pages_ok():
>
>	if (BigPage(page))
>	        BUG();
>
> Some furthur examination shows that __free_pages_ok() is called
> down from zap_pte_range, which is called by zap_pmd_range().  In
> zap_pmd_range() there is this snippet:
>
>    if (pmd_bigpage(*pmd))
>	    pmd_clear(pmd);
>    else
>	    freed += zap_pte_range(tlb, pmd, address, end - address);
>
> Because zap_pte_range() eventually calls __free_pages_ok(), and
> that function explicitly asserts that BigPage() is false, it thus
> follows that if pmd_bigpage() is false, BigPage() MUST be false.
> However, when the BUG() is seen by the customer, it is obvious
> that pmd_bigpage() is false but  BigPage() is true.

The last sentence narrows down the problem -- a 4K page from within
a 2MB bigpage is being mapped in an incorrect manner.  Instead of
using a single PMD entry with the PAE bit set in order to map a
2MB bigpage, a single 4k page from a 2MB bigpage is being allocated
and mapped in a third-level page table PTE entry.  As a result, when
freeing the address space, pmd_bigpage() is false, but BigPage() is true.

As it turns out, this anomoly occurs when mapping anonymous shared
memory when /proc/sys/kernel/shm-use-bigpages is set to 1.  This
should only be acceptable when the shared memory segment is exactly
the size of a bigpage, as is the case when using bigpages to map
segments of a file.  However, for example, the following mmap()
call, while only requesting a 4k shared anomymous page, will end up
taking a single 4k page (the first one) from the next available
2MB bigpage:

  addr = mmap(0, 4096, PROT_WRITE|PROT_READ, MAP_ANON|MAP_SHARED,
              -1, 0);

It leaves a state such that, for the address in which it's mapped,
pmd_bigpage() is false, but BigPage() is true.

with the single PMD entry. 


Version-Release number of selected component (if applicable):
kernel-enterprise-2.4.9-e.34

How reproducible:
Always

Steps to Reproduce:
1. Set /proc/sys/kernel/shm-use-bigpages to 1.
2. Allocate some number of bigpages on the boot command line.
3. Write a C program with the mmap() call above.
4. Touch the address returned by the mmap() call.
5. Note the drop in nr_bigpages with crash utility, or by the
   BigPagesFree value in /proc/meminfo.
    

Actual Results:  
A bigpage will be allocated to each instance of the test program,
until they are all used (at which time subsequent mmap'ers do the
right thing).

Expected Results:  
Bigpages should not be used for mmaps unless the request is the
same size as a bigpage.

Additional info: