[PATCH] mm: fix COW faults after mlock()

[Yury Norov <ynorov@caviumnetworks.com>]

After mlock() on newly mmap()ed shared memory I observe page faults.

The problem is that populate_vma_page_range() doesn't set FOLL_WRITE
flag for writable shared memory in mlock() path, arguing that like:
/*
 * We want to touch writable mappings with a write fault in order
 * to break COW, except for shared mappings because these don't COW
 * and we would not want to dirty them for nothing.
 */

But they are actually COWed. The most straightforward way to avoid it
is to set FOLL_WRITE flag for shared mappings as well as for private ones.

This is the partial revert of commit 5ecfda041e4b4 ("mlock: avoid
dirtying pages and triggering writeback"). So it re-enables dirtying.

The fix works for me (arm64, kernel v4.19-rc4 and v4.9), but after digging
into the code I still don't understand why we need to do copy-on-write on
shared memory. If comment above was correct when 5ecfda041e4b4 became
upstreamed (2011), shared mappings were not COWed back in 2011, but are
COWed now. If so, this is another issue to be fixed.

Signed-off-by: Yury Norov <ynorov@caviumnetworks.com>
---
 mm/gup.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/mm/gup.c b/mm/gup.c
index 1abc8b4afff6..1899e8bac06b 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -1202,10 +1202,9 @@ long populate_vma_page_range(struct vm_area_struct *vma,
 		gup_flags &= ~FOLL_POPULATE;
 	/*
 	 * We want to touch writable mappings with a write fault in order
-	 * to break COW, except for shared mappings because these don't COW
-	 * and we would not want to dirty them for nothing.
+	 * to break COW.
 	 */
-	if ((vma->vm_flags & (VM_WRITE | VM_SHARED)) == VM_WRITE)
+	if (vma->vm_flags & VM_WRITE)
 		gup_flags |= FOLL_WRITE;
 
 	/*
-- 
2.17.1