Skip to contentSkip to conversation

Patch "mm/huge_memory.c: respect FOLL_FORCE/FOLL_COW for thp" has been added to the 4.4-stable tree

PATCH [email protected] 3 participants 9 messages Apr 10, 2017

Subsystems (3)
lore
Share & tools
lore

[email protected]

author maintainer Applied
#0 lore raw

This is a note to let you know that I've just added the patch titled

mm/huge_memory.c: respect FOLL_FORCE/FOLL_COW for thp

to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
mm-huge_memory.c-respect-foll_force-foll_cow-for-thp.patch
and it can be found in the queue-4.4 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.

Quoted 1 line

From 303681d5d538d81b5e23754515202b5b9febd2e9 Mon Sep 17 00:00:00 2001

From: Keno Fischer <[email protected]>
Date: Tue, 24 Jan 2017 15:17:48 -0800
Subject: mm/huge_memory.c: respect FOLL_FORCE/FOLL_COW for thp

From: Keno Fischer <[email protected]>

commit 8310d48b125d19fcd9521d83b8293e63eb1646aa upstream.

In commit 19be0eaffa3a ("mm: remove gup_flags FOLL_WRITE games from __get_user_pages()"), the mm code was changed from unsetting FOLL_WRITE after a COW was resolved to setting the (newly introduced) FOLL_COW instead. Simultaneously, the check in gup.c was updated to still allow writes with FOLL_FORCE set if FOLL_COW had also been set.

However, a similar check in huge_memory.c was forgotten. As a result, remote memory writes to ro regions of memory backed by transparent huge pages cause an infinite loop in the kernel (handle_mm_fault sets FOLL_COW and returns 0 causing a retry, but follow_trans_huge_pmd bails out immidiately because (flags & FOLL_WRITE) && !pmd_write(*pmd) is true.

While in this state the process is stil SIGKILLable, but little else works (e.g. no ptrace attach, no other signals). This is easily reproduced with the following code (assuming thp are set to always):

    #include <assert.h>
    #include <fcntl.h>
    #include <stdint.h>
    #include <stdio.h>
    #include <string.h>
    #include <sys/mman.h>
    #include <sys/stat.h>
    #include <sys/types.h>
    #include <sys/wait.h>
    #include <unistd.h>

    #define TEST_SIZE 5 * 1024 * 1024

    int main(void) {
      int status;
      pid_t child;
      int fd = open("/proc/self/mem", O_RDWR);
      void *addr = mmap(NULL, TEST_SIZE, PROT_READ,
                        MAP_ANONYMOUS | MAP_PRIVATE, 0, 0);
      assert(addr != MAP_FAILED);
      pid_t parent_pid = getpid();
      if ((child = fork()) == 0) {
        void *addr2 = mmap(NULL, TEST_SIZE, PROT_READ | PROT_WRITE,
                           MAP_ANONYMOUS | MAP_PRIVATE, 0, 0);
        assert(addr2 != MAP_FAILED);
        memset(addr2, 'a', TEST_SIZE);
        pwrite(fd, addr2, TEST_SIZE, (uintptr_t)addr);
        return 0;
      }
      assert(child == waitpid(child, &status, 0));
      assert(WIFEXITED(status) && WEXITSTATUS(status) == 0);
      return 0;
    }

Fix this by updating follow_trans_huge_pmd in huge_memory.c analogously to the update in gup.c in the original commit. The same pattern exists in follow_devmap_pmd. However, we should not be able to reach that check with FOLL_COW set, so add WARN_ONCE to make sure we notice if we ever do.

[bwh: Backported to 3.16:
- Drop change to follow_devmap_pmd()
- pmd_dirty() is not available; check the page flags as in older backports of can_follow_write_pte()
- Adjust context]

---
 mm/huge_memory.c |   19 ++++++++++++++++---
 1 file changed, 16 insertions(+), 3 deletions(-)
mm/huge_memory.c +16 -3
@@ -1269,6 +1269,18 @@ out_unlock:
 	return ret;
 }
 
+/*
+ * FOLL_FORCE can write to even unwritable pmd's, but only
+ * after we've gone through a COW cycle and they are dirty.
+ */
+static inline bool can_follow_write_pmd(pmd_t pmd, struct page *page,
+					unsigned int flags)
+{
+	return pmd_write(pmd) ||
+		((flags & FOLL_FORCE) && (flags & FOLL_COW) &&
+		 page && PageAnon(page));
+}
+
 struct page *follow_trans_huge_pmd(struct vm_area_struct *vma,
 				   unsigned long addr,
 				   pmd_t *pmd,
@@ -1279,9 +1291,6 @@ struct page *follow_trans_huge_pmd(struc
 
 	assert_spin_locked(pmd_lockptr(mm, pmd));
 
-	if (flags & FOLL_WRITE && !pmd_write(*pmd))
-		goto out;
-
 	/* Avoid dumping huge zero page */
 	if ((flags & FOLL_DUMP) && is_huge_zero_pmd(*pmd))
 		return ERR_PTR(-EFAULT);
@@ -1292,6 +1301,10 @@ struct page *follow_trans_huge_pmd(struc
 
 	page = pmd_page(*pmd);
 	VM_BUG_ON_PAGE(!PageHead(page), page);
+
+	if (flags & FOLL_WRITE && !can_follow_write_pmd(*pmd, page, flags))
+		goto out;
+
 	if (flags & FOLL_TOUCH) {
 		pmd_t _pmd;
 		/*

Patches currently in stable-queue which might be from [email protected] are

queue-4.4/mm-huge_memory.c-respect-foll_force-foll_cow-for-thp.patch

#1 lore raw

On Mon 10-04-17 17:09:17, Greg KH wrote:
[...]

Quoted 8 lines
Quoted 1 line

From 303681d5d538d81b5e23754515202b5b9febd2e9 Mon Sep 17 00:00:00 2001

From: Keno Fischer <[email protected]>
Date: Tue, 24 Jan 2017 15:17:48 -0800
Subject: mm/huge_memory.c: respect FOLL_FORCE/FOLL_COW for thp

From: Keno Fischer <[email protected]>

commit 8310d48b125d19fcd9521d83b8293e63eb1646aa upstream.

This backport is wrong. See
http://lkml.kernel.org/r/[email protected]

Quoted 131 lines

In commit 19be0eaffa3a ("mm: remove gup_flags FOLL_WRITE games from __get_user_pages()"), the mm code was changed from unsetting FOLL_WRITE after a COW was resolved to setting the (newly introduced) FOLL_COW instead. Simultaneously, the check in gup.c was updated to still allow writes with FOLL_FORCE set if FOLL_COW had also been set.

However, a similar check in huge_memory.c was forgotten. As a result, remote memory writes to ro regions of memory backed by transparent huge pages cause an infinite loop in the kernel (handle_mm_fault sets FOLL_COW and returns 0 causing a retry, but follow_trans_huge_pmd bails out immidiately because (flags & FOLL_WRITE) && !pmd_write(*pmd) is true.

While in this state the process is stil SIGKILLable, but little else works (e.g. no ptrace attach, no other signals). This is easily reproduced with the following code (assuming thp are set to always):

    #include <assert.h>
    #include <fcntl.h>
    #include <stdint.h>
    #include <stdio.h>
    #include <string.h>
    #include <sys/mman.h>
    #include <sys/stat.h>
    #include <sys/types.h>
    #include <sys/wait.h>
    #include <unistd.h>

    #define TEST_SIZE 5 * 1024 * 1024

    int main(void) {
      int status;
      pid_t child;
      int fd = open("/proc/self/mem", O_RDWR);
      void *addr = mmap(NULL, TEST_SIZE, PROT_READ,
                        MAP_ANONYMOUS | MAP_PRIVATE, 0, 0);
      assert(addr != MAP_FAILED);
      pid_t parent_pid = getpid();
      if ((child = fork()) == 0) {
        void *addr2 = mmap(NULL, TEST_SIZE, PROT_READ | PROT_WRITE,
                           MAP_ANONYMOUS | MAP_PRIVATE, 0, 0);
        assert(addr2 != MAP_FAILED);
        memset(addr2, 'a', TEST_SIZE);
        pwrite(fd, addr2, TEST_SIZE, (uintptr_t)addr);
        return 0;
      }
      assert(child == waitpid(child, &status, 0));
      assert(WIFEXITED(status) && WEXITSTATUS(status) == 0);
      return 0;
    }

Fix this by updating follow_trans_huge_pmd in huge_memory.c analogously to the update in gup.c in the original commit. The same pattern exists in follow_devmap_pmd. However, we should not be able to reach that check with FOLL_COW set, so add WARN_ONCE to make sure we notice if we ever do.

[bwh: Backported to 3.16:
- Drop change to follow_devmap_pmd()
- pmd_dirty() is not available; check the page flags as in older backports of can_follow_write_pte()
- Adjust context]

---
 mm/huge_memory.c |   19 ++++++++++++++++---
 1 file changed, 16 insertions(+), 3 deletions(-)
mm/huge_memory.c +16 -3
@@ -1269,6 +1269,18 @@ out_unlock:
 	return ret;
 }
 
+/*
+ * FOLL_FORCE can write to even unwritable pmd's, but only
+ * after we've gone through a COW cycle and they are dirty.
+ */
+static inline bool can_follow_write_pmd(pmd_t pmd, struct page *page,
+					unsigned int flags)
+{
+	return pmd_write(pmd) ||
+		((flags & FOLL_FORCE) && (flags & FOLL_COW) &&
+		 page && PageAnon(page));
+}
+
 struct page *follow_trans_huge_pmd(struct vm_area_struct *vma,
 				   unsigned long addr,
 				   pmd_t *pmd,
@@ -1279,9 +1291,6 @@ struct page *follow_trans_huge_pmd(struc
 
 	assert_spin_locked(pmd_lockptr(mm, pmd));
 
-	if (flags & FOLL_WRITE && !pmd_write(*pmd))
-		goto out;
-
 	/* Avoid dumping huge zero page */
 	if ((flags & FOLL_DUMP) && is_huge_zero_pmd(*pmd))
 		return ERR_PTR(-EFAULT);
@@ -1292,6 +1301,10 @@ struct page *follow_trans_huge_pmd(struc
 
 	page = pmd_page(*pmd);
 	VM_BUG_ON_PAGE(!PageHead(page), page);
+
+	if (flags & FOLL_WRITE && !can_follow_write_pmd(*pmd, page, flags))
+		goto out;
+
 	if (flags & FOLL_TOUCH) {
 		pmd_t _pmd;
 		/*

Patches currently in stable-queue which might be from [email protected] are

queue-4.4/mm-huge_memory.c-respect-foll_force-foll_cow-for-thp.patch

Signature · 2 lines
Michal Hocko
SUSE Labs
author maintainer
#2 lore raw
Quoted 7 lines · Michal Hocko

On Mon 10-04-17 17:09:17, Greg KH wrote:
[...]

Quoted 5 lines
Quoted 1 line

From 303681d5d538d81b5e23754515202b5b9febd2e9 Mon Sep 17 00:00:00 2001

From: Keno Fischer <[email protected]>
Date: Tue, 24 Jan 2017 15:17:48 -0800
Subject: mm/huge_memory.c: respect FOLL_FORCE/FOLL_COW for thp

Quoted 6 lines
Quoted 3 lines

From: Keno Fischer <[email protected]>

commit 8310d48b125d19fcd9521d83b8293e63eb1646aa upstream.

This backport is wrong. See
http://lkml.kernel.org/r/[email protected]

No such Message-ID known.

:(

#3 lore raw
Quoted 8 lines · Greg KH
Quoted 7 lines · Michal Hocko

On Mon 10-04-17 17:09:17, Greg KH wrote:
[...]

Quoted 5 lines
Quoted 1 line

From 303681d5d538d81b5e23754515202b5b9febd2e9 Mon Sep 17 00:00:00 2001

From: Keno Fischer <[email protected]>
Date: Tue, 24 Jan 2017 15:17:48 -0800
Subject: mm/huge_memory.c: respect FOLL_FORCE/FOLL_COW for thp

Quoted 8 lines
Quoted 6 lines
Quoted 3 lines

From: Keno Fischer <[email protected]>

commit 8310d48b125d19fcd9521d83b8293e63eb1646aa upstream.

This backport is wrong. See
http://lkml.kernel.org/r/[email protected]

No such Message-ID known.

https://www.spinics.net/lists/stable/msg165118.html

Signature · 2 lines
Michal Hocko
SUSE Labs
#4 lore raw
In reply to [email protected]
Quoted 23 lines · On Mon, 2017-04-10 at 17:09 +0200, [email protected] wrote:

This is a note to let you know that I've just added the patch titled

    mm/huge_memory.c: respect FOLL_FORCE/FOLL_COW for thp

to the 4.4-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     mm-huge_memory.c-respect-foll_force-foll_cow-for-thp.patch and it can be found in the queue-4.4 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.

From 303681d5d538d81b5e23754515202b5b9febd2e9 Mon Sep 17 00:00:00 2001
From: Keno Fischer <[email protected]>
Date: Tue, 24 Jan 2017 15:17:48 -0800
Subject: mm/huge_memory.c: respect FOLL_FORCE/FOLL_COW for thp

From: Keno Fischer <[email protected]>

commit 8310d48b125d19fcd9521d83b8293e63eb1646aa upstream.

[...]

Quoted 4 lines

 - Drop change to follow_devmap_pmd()
 - pmd_dirty() is not available; check the page flags as in older backports of can_follow_write_pte()
 - Adjust context]

[...]

Aside from the fact that I got this backport wrong, I don't think you need the main change here. In 4.4, all arches that define CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE also define pmd_dirty().

Ben.

Signature · 2 lines
Ben Hutchings
73.46% of all statistics are made up.
author maintainer
#5 lore raw
Quoted 29 lines · Ben Hutchings
Quoted 23 lines · On Mon, 2017-04-10 at 17:09 +0200, [email protected] wrote:

This is a note to let you know that I've just added the patch titled

����mm/huge_memory.c: respect FOLL_FORCE/FOLL_COW for thp

to the 4.4-stable tree which can be found at:
����http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
�����mm-huge_memory.c-respect-foll_force-foll_cow-for-thp.patch and it can be found in the queue-4.4 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.

From 303681d5d538d81b5e23754515202b5b9febd2e9 Mon Sep 17 00:00:00 2001
From: Keno Fischer <[email protected]>
Date: Tue, 24 Jan 2017 15:17:48 -0800
Subject: mm/huge_memory.c: respect FOLL_FORCE/FOLL_COW for thp

From: Keno Fischer <[email protected]>

commit 8310d48b125d19fcd9521d83b8293e63eb1646aa upstream.

[...]

Quoted 4 lines

�- Drop change to follow_devmap_pmd()
�- pmd_dirty() is not available; check the page flags as in older ���backports of can_follow_write_pte()
�- Adjust context]

Quoted 5 lines

[...]

Aside from the fact that I got this backport wrong, I don't think you need the main change here. In 4.4, all arches that define CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE also define pmd_dirty().

Hm, ok, but Keno said people are still hitting this issue on 4.4-stable.

So, what should I do? I'll go drop this from my queue for now, but as I don't know what to do to test this, I'm at a loss...

thanks,

greg k-h

#6 lore raw
Quoted 32 lines · Greg KH
Quoted 31 lines · Ben Hutchings
Quoted 23 lines · On Mon, 2017-04-10 at 17:09 +0200, [email protected] wrote:

This is a note to let you know that I've just added the patch titled

����mm/huge_memory.c: respect FOLL_FORCE/FOLL_COW for thp

to the 4.4-stable tree which can be found at:
����http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
�����mm-huge_memory.c-respect-foll_force-foll_cow-for-thp.patch and it can be found in the queue-4.4 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.

From 303681d5d538d81b5e23754515202b5b9febd2e9 Mon Sep 17 00:00:00 2001
From: Keno Fischer <[email protected]>
Date: Tue, 24 Jan 2017 15:17:48 -0800
Subject: mm/huge_memory.c: respect FOLL_FORCE/FOLL_COW for thp

From: Keno Fischer <[email protected]>

commit 8310d48b125d19fcd9521d83b8293e63eb1646aa upstream.

[...]

Quoted 4 lines

�- Drop change to follow_devmap_pmd()
�- pmd_dirty() is not available; check the page flags as in older ���backports of can_follow_write_pte()
�- Adjust context]

[...]

Quoted 8 lines
Quoted 3 lines

Aside from the fact that I got this backport wrong, I don't think you need the main change here. In 4.4, all arches that define CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE also define pmd_dirty().

Hm, ok, but Keno said people are still hitting this issue on 4.4-stable.

So, what should I do? I'll go drop this from my queue for now, but as I don't know what to do to test this, I'm at a loss...

The changelog of the said patch contains the reproducer...

Signature · 2 lines
Michal Hocko
SUSE Labs
author maintainer
#7 lore raw
Quoted 37 lines · Michal Hocko
Quoted 36 lines · Greg KH
Quoted 34 lines · Ben Hutchings
Quoted 23 lines · On Mon, 2017-04-10 at 17:09 +0200, [email protected] wrote:

This is a note to let you know that I've just added the patch titled

����mm/huge_memory.c: respect FOLL_FORCE/FOLL_COW for thp

to the 4.4-stable tree which can be found at:
����http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
�����mm-huge_memory.c-respect-foll_force-foll_cow-for-thp.patch and it can be found in the queue-4.4 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.

From 303681d5d538d81b5e23754515202b5b9febd2e9 Mon Sep 17 00:00:00 2001
From: Keno Fischer <[email protected]>
Date: Tue, 24 Jan 2017 15:17:48 -0800
Subject: mm/huge_memory.c: respect FOLL_FORCE/FOLL_COW for thp

From: Keno Fischer <[email protected]>

commit 8310d48b125d19fcd9521d83b8293e63eb1646aa upstream.

[...]

Quoted 4 lines

�- Drop change to follow_devmap_pmd()
�- pmd_dirty() is not available; check the page flags as in older ���backports of can_follow_write_pte()
�- Adjust context]

[...]

Aside from the fact that I got this backport wrong, I don't think you need the main change here. In 4.4, all arches that define CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE also define pmd_dirty().

Quoted 6 lines
Quoted 4 lines

Hm, ok, but Keno said people are still hitting this issue on 4.4-stable.

So, what should I do? I'll go drop this from my queue for now, but as I don't know what to do to test this, I'm at a loss...

The changelog of the said patch contains the reproducer...

Hah, I should have seen that :)

I'll wait a bit for this one, if I get some time later this week, I'll work on the fixed up backport. Unless Keno wants to provide it? (hint...)

thanks,

greg k-h

#8 lore raw
In reply to Greg KH
Quoted 34 lines · Greg KH
Quoted 33 lines · Ben Hutchings
Quoted 24 lines
Quoted 1 line · On Mon, 2017-04-10 at 17:09 +0200, [email protected] wrote:

This is a note to let you know that I've just added the patch titled

    mm/huge_memory.c: respect FOLL_FORCE/FOLL_COW for thp

to the 4.4-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     mm-huge_memory.c-respect-foll_force-foll_cow-for-thp.patch and it can be found in the queue-4.4 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.

From 303681d5d538d81b5e23754515202b5b9febd2e9 Mon Sep 17 00:00:00 2001
From: Keno Fischer <[email protected]>
Date: Tue, 24 Jan 2017 15:17:48 -0800
Subject: mm/huge_memory.c: respect FOLL_FORCE/FOLL_COW for thp

From: Keno Fischer <[email protected]>

commit 8310d48b125d19fcd9521d83b8293e63eb1646aa upstream.

[...]

Quoted 4 lines

 - Drop change to follow_devmap_pmd()
 - pmd_dirty() is not available; check the page flags as in older backports of can_follow_write_pte()
 - Adjust context]

[...]

Quoted 8 lines
Quoted 3 lines

Aside from the fact that I got this backport wrong, I don't think you need the main change here.  In 4.4, all arches that define CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE also define pmd_dirty().

Hm, ok, but Keno said people are still hitting this issue on 4.4-stable.

So, what should I do?  I'll go drop this from my queue for now, but as I don't know what to do to test this, I'm at a loss...

I don't mean the fix isn't needed; I mean that I don't think you should use this backport. You should only need to drop the change to follow_devmap_pmd().

Ben.

Signature · 2 lines
Ben Hutchings
73.46% of all statistics are made up.