Skip to content

Commit b1f02b9

Browse files
thejhakpm00
authored andcommitted
mm: fix memory ordering for mm_lock_seq and vm_lock_seq
mm->mm_lock_seq effectively functions as a read/write lock; therefore it must be used with acquire/release semantics. A specific example is the interaction between userfaultfd_register() and lock_vma_under_rcu(). userfaultfd_register() does the following from the point where it changes a VMA's flags to the point where concurrent readers are permitted again (in a simple scenario where only a single private VMA is accessed and no merging/splitting is involved): userfaultfd_register userfaultfd_set_vm_flags vm_flags_reset vma_start_write down_write(&vma->vm_lock->lock) vma->vm_lock_seq = mm_lock_seq [marks VMA as busy] up_write(&vma->vm_lock->lock) vm_flags_init [sets VM_UFFD_* in __vm_flags] vma->vm_userfaultfd_ctx.ctx = ctx mmap_write_unlock vma_end_write_all WRITE_ONCE(mm->mm_lock_seq, mm->mm_lock_seq + 1) [unlocks VMA] There are no memory barriers in between the __vm_flags update and the mm->mm_lock_seq update that unlocks the VMA, so the unlock can be reordered to above the `vm_flags_init()` call, which means from the perspective of a concurrent reader, a VMA can be marked as a userfaultfd VMA while it is not VMA-locked. That's bad, we definitely need a store-release for the unlock operation. The non-atomic write to vma->vm_lock_seq in vma_start_write() is mostly fine because all accesses to vma->vm_lock_seq that matter are always protected by the VMA lock. There is a racy read in vma_start_read() though that can tolerate false-positives, so we should be using WRITE_ONCE() to keep things tidy and data-race-free (including for KCSAN). On the other side, lock_vma_under_rcu() works as follows in the relevant region for locking and userfaultfd check: lock_vma_under_rcu vma_start_read vma->vm_lock_seq == READ_ONCE(vma->vm_mm->mm_lock_seq) [early bailout] down_read_trylock(&vma->vm_lock->lock) vma->vm_lock_seq == READ_ONCE(vma->vm_mm->mm_lock_seq) [main check] userfaultfd_armed checks vma->vm_flags & __VM_UFFD_FLAGS Here, the interesting aspect is how far down the mm->mm_lock_seq read can be reordered - if this read is reordered down below the vma->vm_flags access, this could cause lock_vma_under_rcu() to partly operate on information that was read while the VMA was supposed to be locked. To prevent this kind of downwards bleeding of the mm->mm_lock_seq read, we need to read it with a load-acquire. Some of the comment wording is based on suggestions by Suren. BACKPORT WARNING: One of the functions changed by this patch (which I've written against Linus' tree) is vma_try_start_write(), but this function no longer exists in mm/mm-everything. I don't know whether the merged version of this patch will be ordered before or after the patch that removes vma_try_start_write(). If you're backporting this patch to a tree with vma_try_start_write(), make sure this patch changes that function. Link: https://lkml.kernel.org/r/[email protected] Fixes: 5e31275 ("mm: add per-VMA lock and helper functions to control it") Signed-off-by: Jann Horn <[email protected]> Reviewed-by: Suren Baghdasaryan <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
1 parent 1557127 commit b1f02b9

File tree

3 files changed

+59
-8
lines changed

3 files changed

+59
-8
lines changed

include/linux/mm.h

Lines changed: 23 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -641,8 +641,14 @@ static inline void vma_numab_state_free(struct vm_area_struct *vma) {}
641641
*/
642642
static inline bool vma_start_read(struct vm_area_struct *vma)
643643
{
644-
/* Check before locking. A race might cause false locked result. */
645-
if (vma->vm_lock_seq == READ_ONCE(vma->vm_mm->mm_lock_seq))
644+
/*
645+
* Check before locking. A race might cause false locked result.
646+
* We can use READ_ONCE() for the mm_lock_seq here, and don't need
647+
* ACQUIRE semantics, because this is just a lockless check whose result
648+
* we don't rely on for anything - the mm_lock_seq read against which we
649+
* need ordering is below.
650+
*/
651+
if (READ_ONCE(vma->vm_lock_seq) == READ_ONCE(vma->vm_mm->mm_lock_seq))
646652
return false;
647653

648654
if (unlikely(down_read_trylock(&vma->vm_lock->lock) == 0))
@@ -653,8 +659,13 @@ static inline bool vma_start_read(struct vm_area_struct *vma)
653659
* False unlocked result is impossible because we modify and check
654660
* vma->vm_lock_seq under vma->vm_lock protection and mm->mm_lock_seq
655661
* modification invalidates all existing locks.
662+
*
663+
* We must use ACQUIRE semantics for the mm_lock_seq so that if we are
664+
* racing with vma_end_write_all(), we only start reading from the VMA
665+
* after it has been unlocked.
666+
* This pairs with RELEASE semantics in vma_end_write_all().
656667
*/
657-
if (unlikely(vma->vm_lock_seq == READ_ONCE(vma->vm_mm->mm_lock_seq))) {
668+
if (unlikely(vma->vm_lock_seq == smp_load_acquire(&vma->vm_mm->mm_lock_seq))) {
658669
up_read(&vma->vm_lock->lock);
659670
return false;
660671
}
@@ -676,7 +687,7 @@ static bool __is_vma_write_locked(struct vm_area_struct *vma, int *mm_lock_seq)
676687
* current task is holding mmap_write_lock, both vma->vm_lock_seq and
677688
* mm->mm_lock_seq can't be concurrently modified.
678689
*/
679-
*mm_lock_seq = READ_ONCE(vma->vm_mm->mm_lock_seq);
690+
*mm_lock_seq = vma->vm_mm->mm_lock_seq;
680691
return (vma->vm_lock_seq == *mm_lock_seq);
681692
}
682693

@@ -688,7 +699,13 @@ static inline void vma_start_write(struct vm_area_struct *vma)
688699
return;
689700

690701
down_write(&vma->vm_lock->lock);
691-
vma->vm_lock_seq = mm_lock_seq;
702+
/*
703+
* We should use WRITE_ONCE() here because we can have concurrent reads
704+
* from the early lockless pessimistic check in vma_start_read().
705+
* We don't really care about the correctness of that early check, but
706+
* we should use WRITE_ONCE() for cleanliness and to keep KCSAN happy.
707+
*/
708+
WRITE_ONCE(vma->vm_lock_seq, mm_lock_seq);
692709
up_write(&vma->vm_lock->lock);
693710
}
694711

@@ -702,7 +719,7 @@ static inline bool vma_try_start_write(struct vm_area_struct *vma)
702719
if (!down_write_trylock(&vma->vm_lock->lock))
703720
return false;
704721

705-
vma->vm_lock_seq = mm_lock_seq;
722+
WRITE_ONCE(vma->vm_lock_seq, mm_lock_seq);
706723
up_write(&vma->vm_lock->lock);
707724
return true;
708725
}

include/linux/mm_types.h

Lines changed: 28 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -514,6 +514,20 @@ struct vm_area_struct {
514514
};
515515

516516
#ifdef CONFIG_PER_VMA_LOCK
517+
/*
518+
* Can only be written (using WRITE_ONCE()) while holding both:
519+
* - mmap_lock (in write mode)
520+
* - vm_lock->lock (in write mode)
521+
* Can be read reliably while holding one of:
522+
* - mmap_lock (in read or write mode)
523+
* - vm_lock->lock (in read or write mode)
524+
* Can be read unreliably (using READ_ONCE()) for pessimistic bailout
525+
* while holding nothing (except RCU to keep the VMA struct allocated).
526+
*
527+
* This sequence counter is explicitly allowed to overflow; sequence
528+
* counter reuse can only lead to occasional unnecessary use of the
529+
* slowpath.
530+
*/
517531
int vm_lock_seq;
518532
struct vma_lock *vm_lock;
519533

@@ -679,6 +693,20 @@ struct mm_struct {
679693
* by mmlist_lock
680694
*/
681695
#ifdef CONFIG_PER_VMA_LOCK
696+
/*
697+
* This field has lock-like semantics, meaning it is sometimes
698+
* accessed with ACQUIRE/RELEASE semantics.
699+
* Roughly speaking, incrementing the sequence number is
700+
* equivalent to releasing locks on VMAs; reading the sequence
701+
* number can be part of taking a read lock on a VMA.
702+
*
703+
* Can be modified under write mmap_lock using RELEASE
704+
* semantics.
705+
* Can be read with no other protection when holding write
706+
* mmap_lock.
707+
* Can be read with ACQUIRE semantics if not holding write
708+
* mmap_lock.
709+
*/
682710
int mm_lock_seq;
683711
#endif
684712

include/linux/mmap_lock.h

Lines changed: 8 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -76,8 +76,14 @@ static inline void mmap_assert_write_locked(struct mm_struct *mm)
7676
static inline void vma_end_write_all(struct mm_struct *mm)
7777
{
7878
mmap_assert_write_locked(mm);
79-
/* No races during update due to exclusive mmap_lock being held */
80-
WRITE_ONCE(mm->mm_lock_seq, mm->mm_lock_seq + 1);
79+
/*
80+
* Nobody can concurrently modify mm->mm_lock_seq due to exclusive
81+
* mmap_lock being held.
82+
* We need RELEASE semantics here to ensure that preceding stores into
83+
* the VMA take effect before we unlock it with this store.
84+
* Pairs with ACQUIRE semantics in vma_start_read().
85+
*/
86+
smp_store_release(&mm->mm_lock_seq, mm->mm_lock_seq + 1);
8187
}
8288
#else
8389
static inline void vma_end_write_all(struct mm_struct *mm) {}

0 commit comments

Comments
 (0)