<feed xmlns='http://www.w3.org/2005/Atom'>
<title>xavi/android_kernel_m2note/mm/huge_memory.c, branch o-8.1</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<id>https://gitea.privatedns.org/xavi/android_kernel_m2note/atom?h=o-8.1</id>
<link rel='self' href='https://gitea.privatedns.org/xavi/android_kernel_m2note/atom?h=o-8.1'/>
<link rel='alternate' type='text/html' href='https://gitea.privatedns.org/xavi/android_kernel_m2note/'/>
<updated>2019-05-02T15:32:35+00:00</updated>
<entry>
<title>mremap: properly flush TLB before releasing the page</title>
<updated>2019-05-02T15:32:35+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2018-11-02T19:40:55+00:00</published>
<link rel='alternate' type='text/html' href='https://gitea.privatedns.org/xavi/android_kernel_m2note/commit/?id=98af89f450a8f9bbab58d550a8b2d4a050af63a1'/>
<id>urn:sha1:98af89f450a8f9bbab58d550a8b2d4a050af63a1</id>
<content type='text'>
Commit eb66ae030829605d61fbef1909ce310e29f78821 upstream.

This is a backport to stable 3.18.y, based on Will Deacon's 4.4.y
backport.

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.

Bug: 118836219

Reported-and-tested-by: Jann Horn &lt;jannh@google.com&gt;
Acked-by: Will Deacon &lt;will.deacon@arm.com&gt;
Tested-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Acked-by: Peter Zijlstra (Intel) &lt;peterz@infradead.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
[will: backport to 4.4 stable]
Signed-off-by: Will Deacon &lt;will.deacon@arm.com&gt;
[ghackmann@google.com: adjust context]
Signed-off-by: Greg Hackmann &lt;ghackmann@google.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

Change-Id: I653b28b6c2fd6ec00e4b0be2b3289dcab1dcc4b1
Signed-off-by: Greg Hackmann &lt;ghackmann@google.com&gt;
</content>
</entry>
<entry>
<title>mm/huge_memory.c: respect FOLL_FORCE/FOLL_COW for thp</title>
<updated>2017-06-17T14:12:40+00:00</updated>
<author>
<name>Keno Fischer</name>
<email>keno@juliacomputing.com</email>
</author>
<published>2017-01-24T23:17:48+00:00</published>
<link rel='alternate' type='text/html' href='https://gitea.privatedns.org/xavi/android_kernel_m2note/commit/?id=0c95d3e1a799979a63b5cc469382d90a664c6aaa'/>
<id>urn:sha1:0c95d3e1a799979a63b5cc469382d90a664c6aaa</id>
<content type='text'>
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 &amp; FOLL_WRITE) &amp;&amp; !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 &lt;assert.h&gt;
    #include &lt;fcntl.h&gt;
    #include &lt;stdint.h&gt;
    #include &lt;stdio.h&gt;
    #include &lt;string.h&gt;
    #include &lt;sys/mman.h&gt;
    #include &lt;sys/stat.h&gt;
    #include &lt;sys/types.h&gt;
    #include &lt;sys/wait.h&gt;
    #include &lt;unistd.h&gt;

    #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, &amp;status, 0));
      assert(WIFEXITED(status) &amp;&amp; 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.

[akpm@linux-foundation.org: coding-style fixes]
Link: http://lkml.kernel.org/r/20170106015025.GA38411@juliacomputing.com
Signed-off-by: Keno Fischer &lt;keno@juliacomputing.com&gt;
Acked-by: Kirill A. Shutemov &lt;kirill.shutemov@linux.intel.com&gt;
Cc: Greg Thelen &lt;gthelen@google.com&gt;
Cc: Nicholas Piggin &lt;npiggin@gmail.com&gt;
Cc: Willy Tarreau &lt;w@1wt.eu&gt;
Cc: Oleg Nesterov &lt;oleg@redhat.com&gt;
Cc: Kees Cook &lt;keescook@chromium.org&gt;
Cc: Andy Lutomirski &lt;luto@kernel.org&gt;
Cc: Michal Hocko &lt;mhocko@suse.com&gt;
Cc: Hugh Dickins &lt;hughd@google.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
[bwh: Backported to 3.2:
 - Drop change to follow_devmap_pmd()
 - pmd_dirty() is not available; check the page flags as in
   can_follow_write_pte()
 - Adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
[mhocko:
  This has been forward ported from the 3.2 stable tree.
  And fixed to return NULL.]
Reviewed-by: Michal Hocko &lt;mhocko@suse.cz&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
Signed-off-by: Willy Tarreau &lt;w@1wt.eu&gt;
</content>
</entry>
<entry>
<title>mm: replace strict_strtoul() with kstrtoul()</title>
<updated>2016-09-28T13:12:50+00:00</updated>
<author>
<name>Jingoo Han</name>
<email>jg1.han@samsung.com</email>
</author>
<published>2013-09-11T21:20:25+00:00</published>
<link rel='alternate' type='text/html' href='https://gitea.privatedns.org/xavi/android_kernel_m2note/commit/?id=f15affdb9e19db7535acce8514b5852782732f19'/>
<id>urn:sha1:f15affdb9e19db7535acce8514b5852782732f19</id>
<content type='text'>
The use of strict_strtoul() is not preferred, because strict_strtoul() is
obsolete.  Thus, kstrtoul() should be used.

Signed-off-by: Jingoo Han &lt;jg1.han@samsung.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: W4TCH0UT &lt;ateekujjawal@gmail.com&gt;
</content>
</entry>
<entry>
<title>first commit</title>
<updated>2016-08-15T02:19:42+00:00</updated>
<author>
<name>Meizu OpenSource</name>
<email>patchwork@meizu.com</email>
</author>
<published>2016-08-15T02:19:42+00:00</published>
<link rel='alternate' type='text/html' href='https://gitea.privatedns.org/xavi/android_kernel_m2note/commit/?id=d2e1446d81725c351dc73a03b397ce043fb18452'/>
<id>urn:sha1:d2e1446d81725c351dc73a03b397ce043fb18452</id>
<content type='text'>
</content>
</entry>
</feed>
