[RAMEN9610-11162][COMMON] mremap: properly flush TLB before releasing the page
authorSangkyu Kim <skwith.kim@samsung.com>
Wed, 2 Jan 2019 11:24:08 +0000 (20:24 +0900)
committerhskang <hs1218.kang@samsung.com>
Mon, 21 Jan 2019 16:43:46 +0000 (01:43 +0900)
commita304f597887b60364be2d1cfe1bf59eaa7aaf77c
tree0c0dc8dc4a0ac444f6d586aa2cf7dd0f43070fdf
parentb5ca6007660e0faf3eab7eeec172177bb9012b08
[RAMEN9610-11162][COMMON] mremap: properly flush TLB before releasing the page

from eb66ae030829605d61fbef1909ce310e29f78821 upstream

Jann Horn points out that our TLB flushing was subtly wrong for the
mremap() case.  What makes mremap() special is that we don't follow the
usual "add page to list of pages to be freed, then flush tlb, and then
free pages".  No, mremap() obviously just _moves_ the page from one page
table location to another.

That matters, because mremap() thus doesn't directly control the
lifetime of the moved page with a freelist: instead, the lifetime of the
page is controlled by the page table locking, that serializes access to
the entry.

As a result, we need to flush the TLB not just before releasing the lock
for the source location (to avoid any concurrent accesses to the entry),
but also before we release the destination page table lock (to avoid the
TLB being flushed after somebody else has already done something to that
page).

This also makes the whole "need_flush" logic unnecessary, since we now
always end up flushing the TLB for every valid entry.

Change-Id: I02675325887cf5e1021eef310ac15567a6a21c4b
Reported-and-tested-by: Jann Horn <jannh@google.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Tested-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
include/linux/huge_mm.h
mm/huge_memory.c
mm/mremap.c