[PATCH v2] mm: Respect FOLL_FORCE/FOLL_COW for thp

[PATCH v2] mm: Respect FOLL_FORCE/FOLL_COW for thp

[Keno Fischer]

In 19be0eaff ("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.

Signed-off-by: Keno Fischer <keno@juliacomputing.com>
---
Changes since v1:
 * In follow_devmap_pmd, WARN_ONCE if FOLL_COW is encountered, rather
   than allowing it, since that situation should not happen.
   As suggested by Kirill A. Shutemov

 mm/huge_memory.c | 18 +++++++++++++++++-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 10eedbf..f7ec01d 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -783,6 +783,12 @@ struct page *follow_devmap_pmd(struct vm_area_struct *vma, unsigned long addr,
 
 	assert_spin_locked(pmd_lockptr(mm, pmd));
 
+	/*
+	 * When we COW a devmap PMD entry, we split it into PTEs, so we should
+	 * not be in this function with `flags & FOLL_COW` set.
+	 */
+	WARN_ONCE(flags & FOLL_COW, "mm: In follow_devmap_pmd with FOLL_COW set");
+
 	if (flags & FOLL_WRITE && !pmd_write(*pmd))
 		return NULL;
 
@@ -1127,6 +1133,16 @@ int do_huge_pmd_wp_page(struct vm_fault *vmf, pmd_t orig_pmd)
 	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, unsigned int flags)
+{
+       return pmd_write(pmd) ||
+               ((flags & FOLL_FORCE) && (flags & FOLL_COW) && pmd_dirty(pmd));
+}
+
 struct page *follow_trans_huge_pmd(struct vm_area_struct *vma,
 				   unsigned long addr,
 				   pmd_t *pmd,
@@ -1137,7 +1153,7 @@ struct page *follow_trans_huge_pmd(struct vm_area_struct *vma,
 
 	assert_spin_locked(pmd_lockptr(mm, pmd));
 
-	if (flags & FOLL_WRITE && !pmd_write(*pmd))
+	if (flags & FOLL_WRITE && !can_follow_write_pmd(*pmd, flags))
 		goto out;
 
 	/* Avoid dumping huge zero page */
-- 
2.9.3

[PATCH v2] mm: Respect FOLL_FORCE/FOLL_COW for thp

[Keno Fischer]

In 19be0eaff ("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.

Signed-off-by: Keno Fischer <keno@juliacomputing.com>
---
Changes since v1:
 * In follow_devmap_pmd, WARN_ONCE if FOLL_COW is encountered, rather
   than allowing it, since that situation should not happen.
   As suggested by Kirill A. Shutemov

 mm/huge_memory.c | 18 +++++++++++++++++-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 10eedbf..f7ec01d 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -783,6 +783,12 @@ struct page *follow_devmap_pmd(struct vm_area_struct *vma, unsigned long addr,
 
 	assert_spin_locked(pmd_lockptr(mm, pmd));
 
+	/*
+	 * When we COW a devmap PMD entry, we split it into PTEs, so we should
+	 * not be in this function with `flags & FOLL_COW` set.
+	 */
+	WARN_ONCE(flags & FOLL_COW, "mm: In follow_devmap_pmd with FOLL_COW set");
+
 	if (flags & FOLL_WRITE && !pmd_write(*pmd))
 		return NULL;
 
@@ -1127,6 +1133,16 @@ int do_huge_pmd_wp_page(struct vm_fault *vmf, pmd_t orig_pmd)
 	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, unsigned int flags)
+{
+       return pmd_write(pmd) ||
+               ((flags & FOLL_FORCE) && (flags & FOLL_COW) && pmd_dirty(pmd));
+}
+
 struct page *follow_trans_huge_pmd(struct vm_area_struct *vma,
 				   unsigned long addr,
 				   pmd_t *pmd,
@@ -1137,7 +1153,7 @@ struct page *follow_trans_huge_pmd(struct vm_area_struct *vma,
 
 	assert_spin_locked(pmd_lockptr(mm, pmd));
 
-	if (flags & FOLL_WRITE && !pmd_write(*pmd))
+	if (flags & FOLL_WRITE && !can_follow_write_pmd(*pmd, flags))
 		goto out;
 
 	/* Avoid dumping huge zero page */
-- 
2.9.3

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v2] mm: Respect FOLL_FORCE/FOLL_COW for thp

[Kirill A. Shutemov]

On Thu, Jan 05, 2017 at 08:50:25PM -0500, Keno Fischer wrote:
> In 19be0eaff ("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.
> 
> Signed-off-by: Keno Fischer <keno@juliacomputing.com>

Cc: stable@ ?

Acke-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>

-- 
 Kirill A. Shutemov

Re: [PATCH v2] mm: Respect FOLL_FORCE/FOLL_COW for thp

[Kirill A. Shutemov]

On Thu, Jan 05, 2017 at 08:50:25PM -0500, Keno Fischer wrote:
> In 19be0eaff ("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.
> 
> Signed-off-by: Keno Fischer <keno@juliacomputing.com>

Cc: stable@ ?

Acke-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>

-- 
 Kirill A. Shutemov

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v2] mm: Respect FOLL_FORCE/FOLL_COW for thp

[Michal Hocko]

On Fri 06-01-17 11:18:44, Kirill A. Shutemov wrote:
> On Thu, Jan 05, 2017 at 08:50:25PM -0500, Keno Fischer wrote:
> > In 19be0eaff ("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.
> > 
> > Signed-off-by: Keno Fischer <keno@juliacomputing.com>
> 
> Cc: stable@ ?

Yes, please! I am just wondering how far do we have to go. I was under
impression that we split THP in the past in the gup path but I cannot
find the respective code now. Many things have changed after your
refcount rework. Could you clarify this part Kirill, please?

> Acke-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>

The patch looks good to me.
Acked-by: Michal Hocko <mhocko@suse.com>

Thanks!

-- 
Michal Hocko
SUSE Labs

Re: [PATCH v2] mm: Respect FOLL_FORCE/FOLL_COW for thp

[Michal Hocko]

On Fri 06-01-17 11:18:44, Kirill A. Shutemov wrote:
> On Thu, Jan 05, 2017 at 08:50:25PM -0500, Keno Fischer wrote:
> > In 19be0eaff ("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.
> > 
> > Signed-off-by: Keno Fischer <keno@juliacomputing.com>
> 
> Cc: stable@ ?

Yes, please! I am just wondering how far do we have to go. I was under
impression that we split THP in the past in the gup path but I cannot
find the respective code now. Many things have changed after your
refcount rework. Could you clarify this part Kirill, please?

> Acke-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>

The patch looks good to me.
Acked-by: Michal Hocko <mhocko@suse.com>

Thanks!

-- 
Michal Hocko
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v2] mm: Respect FOLL_FORCE/FOLL_COW for thp

[Kirill A. Shutemov]

On Tue, Jan 10, 2017 at 10:29:10AM +0100, Michal Hocko wrote:
> On Fri 06-01-17 11:18:44, Kirill A. Shutemov wrote:
> > On Thu, Jan 05, 2017 at 08:50:25PM -0500, Keno Fischer wrote:
> > > In 19be0eaff ("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.
> > > 
> > > Signed-off-by: Keno Fischer <keno@juliacomputing.com>
> > 
> > Cc: stable@ ?
> 
> Yes, please! I am just wondering how far do we have to go. I was under
> impression that we split THP in the past in the gup path but I cannot
> find the respective code now. Many things have changed after your
> refcount rework. Could you clarify this part Kirill, please?

No, we didn't split THP before, unless it's asked specifically with
FOLL_SPLIT. Otherwise we just pin whole huge page.

I think we need to port it all active stable trees as we do with
19be0eaff. The race was there since beginning of THP, I believe.

-- 
 Kirill A. Shutemov

Re: [PATCH v2] mm: Respect FOLL_FORCE/FOLL_COW for thp

[Kirill A. Shutemov]

On Tue, Jan 10, 2017 at 10:29:10AM +0100, Michal Hocko wrote:
> On Fri 06-01-17 11:18:44, Kirill A. Shutemov wrote:
> > On Thu, Jan 05, 2017 at 08:50:25PM -0500, Keno Fischer wrote:
> > > In 19be0eaff ("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.
> > > 
> > > Signed-off-by: Keno Fischer <keno@juliacomputing.com>
> > 
> > Cc: stable@ ?
> 
> Yes, please! I am just wondering how far do we have to go. I was under
> impression that we split THP in the past in the gup path but I cannot
> find the respective code now. Many things have changed after your
> refcount rework. Could you clarify this part Kirill, please?

No, we didn't split THP before, unless it's asked specifically with
FOLL_SPLIT. Otherwise we just pin whole huge page.

I think we need to port it all active stable trees as we do with
19be0eaff. The race was there since beginning of THP, I believe.

-- 
 Kirill A. Shutemov

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v2] mm: Respect FOLL_FORCE/FOLL_COW for thp

[Michal Hocko]

On Tue 10-01-17 15:20:45, Kirill A. Shutemov wrote:
> On Tue, Jan 10, 2017 at 10:29:10AM +0100, Michal Hocko wrote:
> > On Fri 06-01-17 11:18:44, Kirill A. Shutemov wrote:
> > > On Thu, Jan 05, 2017 at 08:50:25PM -0500, Keno Fischer wrote:
> > > > In 19be0eaff ("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.
> > > > 
> > > > Signed-off-by: Keno Fischer <keno@juliacomputing.com>
> > > 
> > > Cc: stable@ ?
> > 
> > Yes, please! I am just wondering how far do we have to go. I was under
> > impression that we split THP in the past in the gup path but I cannot
> > find the respective code now. Many things have changed after your
> > refcount rework. Could you clarify this part Kirill, please?
> 
> No, we didn't split THP before, unless it's asked specifically with
> FOLL_SPLIT. Otherwise we just pin whole huge page.

Yeah, I've tried to find the FOLL_SPLIT but couldn't...
 
> I think we need to port it all active stable trees as we do with
> 19be0eaff. The race was there since beginning of THP, I believe.

thanks for double checking!
-- 
Michal Hocko
SUSE Labs

Re: [PATCH v2] mm: Respect FOLL_FORCE/FOLL_COW for thp

[Michal Hocko]

On Tue 10-01-17 15:20:45, Kirill A. Shutemov wrote:
> On Tue, Jan 10, 2017 at 10:29:10AM +0100, Michal Hocko wrote:
> > On Fri 06-01-17 11:18:44, Kirill A. Shutemov wrote:
> > > On Thu, Jan 05, 2017 at 08:50:25PM -0500, Keno Fischer wrote:
> > > > In 19be0eaff ("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.
> > > > 
> > > > Signed-off-by: Keno Fischer <keno@juliacomputing.com>
> > > 
> > > Cc: stable@ ?
> > 
> > Yes, please! I am just wondering how far do we have to go. I was under
> > impression that we split THP in the past in the gup path but I cannot
> > find the respective code now. Many things have changed after your
> > refcount rework. Could you clarify this part Kirill, please?
> 
> No, we didn't split THP before, unless it's asked specifically with
> FOLL_SPLIT. Otherwise we just pin whole huge page.

Yeah, I've tried to find the FOLL_SPLIT but couldn't...
 
> I think we need to port it all active stable trees as we do with
> 19be0eaff. The race was there since beginning of THP, I believe.

thanks for double checking!
-- 
Michal Hocko
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v2] mm: Respect FOLL_FORCE/FOLL_COW for thp

[David Rientjes]

On Thu, 5 Jan 2017, Keno Fischer wrote:

> In 19be0eaff ("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.
> 
> Signed-off-by: Keno Fischer <keno@juliacomputing.com>

Tested-by: David Rientjes <rientjes@google.com>

Re: [PATCH v2] mm: Respect FOLL_FORCE/FOLL_COW for thp

[David Rientjes]

On Thu, 5 Jan 2017, Keno Fischer wrote:

> In 19be0eaff ("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.
> 
> Signed-off-by: Keno Fischer <keno@juliacomputing.com>

Tested-by: David Rientjes <rientjes@google.com>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>