[PATCH 0/2] fix vma->anon_vma check for per-VMA locking; fix anon_vma memory ordering

[Jann Horn <jannh@google.com>]

Hi!

Patch 1 here is a straightforward fix for a race in per-VMA locking code
that can lead to use-after-free; I hope we can get this one into
mainline and stable quickly.

Patch 2 is a fix for what I believe is a longstanding memory ordering
issue in how vma->anon_vma is used across the MM subsystem; I expect
that this one will have to go through a few iterations of review and
potentially rewrites, because memory ordering is tricky.
(If someone else wants to take over patch 2, I would be very happy.)

These patches don't really belong together all that much, I'm just
sending them as a series because they'd otherwise conflict.

I am CCing:

 - Suren because patch 1 touches his code
 - Matthew Wilcox because he is also currently working on per-VMA
   locking stuff
 - all the maintainers/reviewers for the Kernel Memory Consistency Model
   so they can help figure out the READ_ONCE() vs smp_load_acquire()
   thing
 - people involved in the previous discussion on the security list


Jann Horn (2):
  mm: lock_vma_under_rcu() must check vma->anon_vma under vma lock
  mm: Fix anon_vma memory ordering

 include/linux/rmap.h | 15 ++++++++++++++-
 mm/huge_memory.c     |  4 +++-
 mm/khugepaged.c      |  2 +-
 mm/ksm.c             | 16 +++++++++++-----
 mm/memory.c          | 32 ++++++++++++++++++++------------
 mm/mmap.c            | 13 ++++++++++---
 mm/rmap.c            |  6 ++++--
 mm/swapfile.c        |  3 ++-
 8 files changed, 65 insertions(+), 26 deletions(-)


base-commit: 20ea1e7d13c1b544fe67c4a8dc3943bb1ab33e6f
-- 
2.41.0.487.g6d72f3e995-goog