Hugh Dickins e6780f7243 futex: Fix uninterruptible loop due to gate_area
It was found (by Sasha) that if you use a futex located in the gate
area we get stuck in an uninterruptible infinite loop, much like the
ZERO_PAGE issue.

While looking at this problem, PeterZ realized you'll get into similar
trouble when hitting any install_special_pages() mapping.  And are there
still drivers setting up their own special mmaps without page->mapping,
and without special VM or pte flags to make get_user_pages fail?

In most cases, if page->mapping is NULL, we do not need to retry at all:
Linus points out that even /proc/sys/vm/drop_caches poses no problem,
because it ends up using remove_mapping(), which takes care not to
interfere when the page reference count is raised.

But there is still one case which does need a retry: if memory pressure
called shmem_writepage in between get_user_pages_fast dropping page
table lock and our acquiring page lock, then the page gets switched from
filecache to swapcache (and ->mapping set to NULL) whatever the refcount.
Fault it back in to get the page->mapping needed for key->shared.inode.

Reported-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Hugh Dickins <hughd@google.com>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-12-31 11:48:28 -08:00
..
2011-07-26 16:49:45 -07:00
2010-08-09 16:48:42 -04:00
2011-03-14 09:15:23 -04:00
2010-10-30 01:42:19 -04:00
2011-09-23 12:05:29 +05:30
2011-07-14 12:59:14 +03:00
2011-10-31 17:30:45 -07:00
2011-12-09 07:50:28 -08:00
2011-03-31 11:26:23 -03:00
2011-04-24 13:18:38 +02:00
2011-10-31 17:30:44 -07:00
2011-08-12 16:21:35 -05:00
2011-09-19 17:04:37 -07:00