summaryrefslogtreecommitdiff
path: root/drivers/mxc
diff options
context:
space:
mode:
authorHugh Dickins <hughd@google.com>2011-12-31 11:44:01 -0800
committerHuang Shijie <b32955@freescale.com>2012-02-28 19:14:45 +0800
commit7f8a9d1c563bb27197ee980a26f717a3e97b5f35 (patch)
tree737afdb5dffaba15a18a70d893ac76fdd0daf82d /drivers/mxc
parent898220ae8baab09aa1e9f1039be7bbee573d5bd7 (diff)
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>
Diffstat (limited to 'drivers/mxc')
0 files changed, 0 insertions, 0 deletions