hugetlb: fix infinite loop in get_futex_key() when backed by huge pages

If a futex key happens to be located within a huge page mapped
MAP_PRIVATE, get_futex_key() can go into an infinite loop waiting for a
page->mapping that will never exist.

See https://bugzilla.redhat.com/show_bug.cgi?id=552257 for more details
about the problem.

This patch makes page->mapping a poisoned value that includes
PAGE_MAPPING_ANON mapped MAP_PRIVATE.  This is enough for futex to
continue but because of PAGE_MAPPING_ANON, the poisoned value is not
dereferenced or used by futex.  No other part of the VM should be
dereferencing the page->mapping of a hugetlbfs page as its page cache is
not on the LRU.

This patch fixes the problem with the test case described in the bugzilla.

[ upstream commit: 23be7468e8802a2ac1de6ee3eecb3ec7f14dc703 ]

[akpm@linux-foundation.org: mel cant spel]
Signed-off-by: Mel Gorman <mel@csn.ul.ie>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Acked-by: Darren Hart <darren@dvhart.com>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

1 files changed, 4 insertions, 1 deletions

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 2d16fa6b8c2d..fd9ba95f06fc 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -546,6 +546,7 @@ static void free_huge_page(struct page *page)
 
         mapping = (struct address_space *) page_private(page);
         set_page_private(page, 0);
+        page->mapping = NULL;
         BUG_ON(page_count(page));
         INIT_LIST_HEAD(&page->lru);
 
@@ -2447,8 +2448,10 @@ retry:
                         spin_lock(&inode->i_lock);
                         inode->i_blocks += blocks_per_huge_page(h);
                         spin_unlock(&inode->i_lock);
-                } else
+                } else {
                         lock_page(page);
+                        page->mapping = HUGETLB_POISON;
+                }
         }
 
         /*