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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20180924130852.12996-1-ynorov@caviumnetworks.com>
Date:   Mon, 24 Sep 2018 16:08:52 +0300
From:   Yury Norov <ynorov@...iumnetworks.com>
To:     Andrew Morton <akpm@...ux-foundation.org>,
        Al Viro <viro@...iv.linux.org.uk>,
        Dan Williams <dan.j.williams@...el.com>,
        Huang Ying <ying.huang@...el.com>,
        "Michael S . Tsirkin" <mst@...hat.com>,
        Michel Lespinasse <walken@...gle.com>,
        Souptick Joarder <jrdr.linux@...il.com>,
        Willy Tarreau <w@....eu>, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org
Cc:     Yury Norov <ynorov@...iumnetworks.com>
Subject: [PATCH] mm: fix COW faults after mlock()

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@...iumnetworks.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