mm: Unconditional per-VMA locks and cleanups

[kernel-patches-daemon-bpf]

Pull request for series with
subject: mm: Unconditional per-VMA locks and cleanups
version: 2
url: https://patchwork.kernel.org/project/netdevbpf/list/?series=1109563

[kernel-patches-daemon-bpf]

Upstream branch: 2e8ad1f
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=1109563
version: 2

[kernel-patches-daemon-bpf]

Upstream branch: 30dee2c
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=1109563
version: 2

[kernel-patches-review-bot]

commit b687b1a163de1cfd4e91b9f8f9537d2782de82a0
Author: Dave Hansen <dave.hansen@linux.intel.com>

mm: Add RCU-based VMA lookup helper that waits for writers

This adds vma_start_read_unlocked(), a VMA lookup that uses the RCU-based
per-VMA lock on its fast path and falls back to taking mmap_lock for read
to wait out writers on its slow path. The intent is to let callers avoid
maintaining their own mmap_lock fallback path.

> diff --git a/include/linux/mmap_lock.h b/include/linux/mmap_lock.h
> index 68489dbef0c4..924dd3e865fc 100644
> --- a/include/linux/mmap_lock.h
> +++ b/include/linux/mmap_lock.h
> @@ -257,6 +257,9 @@ static inline bool vma_start_read_locked(struct vm_area_struct *vma)
>  	return vma_start_read_locked_nested(vma, 0);
>  }
>
> +struct vm_area_struct *vma_start_read_unlocked(struct mm_struct *mm,
> +					       unsigned long address);
> +

> diff --git a/mm/mmap_lock.c b/mm/mmap_lock.c
> index e20d01e8d38f..441d2beb325d 100644
> --- a/mm/mmap_lock.c
> +++ b/mm/mmap_lock.c
> @@ -338,6 +338,33 @@ struct vm_area_struct *lock_vma_under_rcu(struct mm_struct *mm,
> +struct vm_area_struct *vma_start_read_unlocked(struct mm_struct *mm,
> +					       unsigned long address)
> +{
> +	struct vm_area_struct *vma;
> +
> +	/* Fast path: return stable VMA covering 'address': */
> +	vma = lock_vma_under_rcu(mm, address);
> +	if (vma)
> +		return vma;
> +
> +	/* Slow path: preclude VMA writers by getting mmap read lock. */
> +	guard(rwsem_read)(&mm->mmap_lock);
> +	if (!vma_start_read_locked(vma))
> +		return NULL;
> +
> +	return vma;
> +}

Can the slow path here dereference a NULL vma?

The slow path is only reached when lock_vma_under_rcu() returned NULL, since
the 'if (vma) return vma;' branch was not taken. So 'vma' is NULL at the point
vma_start_read_locked(vma) is called.

vma_start_read_locked() forwards to vma_start_read_locked_nested(vma, 0), which
starts with mmap_assert_locked(vma->vm_mm) and then operates on vma->vm_refcnt,
both of which dereference 'vma':

  static inline bool vma_start_read_locked(struct vm_area_struct *vma)
  {
  	return vma_start_read_locked_nested(vma, 0);
  }

This looks reachable on normal runtime paths: lock_vma_under_rcu() returns NULL
when no VMA covers the address, on a writer collision, or when the address
falls outside the locked VMA's range.

Separately, should the slow path perform its own lookup before locking? The
comment says the function should "Find the VMA covering 'address' and lock it
for reading," but the slow path never calls vma_lookup()/find_vma() and instead
reuses the stale 'vma' local. Would something like the following be the intent?

  vma = vma_lookup(mm, address);
  if (!vma)
  	return NULL;
  if (!vma_start_read_locked(vma))
  	return NULL;
  return vma;

Callers are wired up later in this series ('tcp: Remove mmap_lock fallback
path' and 'binder: Remove mmap_lock fallback'), so the path appears reachable
once those land, and no later fix for vma_start_read_unlocked() shows up in
between.

---

AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

In-Reply-To-Subject: mm: Add RCU-based VMA lookup helper that waits for writers
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/27312528837

[kernel-patches-review-bot]

commit 3e3467afd8b4d369ea7e4532b91f259416b5bc9c
Author: Dave Hansen <dave.hansen@linux.intel.com>

binder: Make shrinker rely solely on per-VMA lock

This drops the mmap_read_trylock() fallback in binder_alloc_free_page()
and relies only on lock_vma_under_rcu(), removing the mm_locked tracking
and the associated cleanup branches.

> diff --git a/drivers/android/binder_alloc.c b/drivers/android/binder_alloc.c
> index e4488ad86a65..9d8239b2640e 100644
> --- a/drivers/android/binder_alloc.c
> +++ b/drivers/android/binder_alloc.c

[ ... ]

> @@ -1203,11 +1197,9 @@ enum lru_status binder_alloc_free_page(struct list_head *item,
>  err_invalid_vma:
>  	mutex_unlock(&alloc->mutex);
>  err_get_alloc_mutex_failed:
> -	if (mm_locked)
> -		mmap_read_unlock(mm);
> -	else
> +	if (vma)
>  		vma_end_read(vma);
> -err_mmap_read_lock_failed:
> +err_vma_lock_failed:
>  	mmput_async(mm);
>  err_mmget:
>  	return LRU_SKIP;

The old err_mmap_read_lock_failed: label was reached by a goto from the
mmap_read_trylock() fallback that this patch removes. After renaming it to
err_vma_lock_failed:, is there any remaining goto that targets it?

Grepping the file, err_vma_lock_failed appears only at the label definition
and nowhere as a goto target, so the label is now reached only by fall-through
from err_get_alloc_mutex_failed:.

A label reached purely by fall-through is not considered "used", so wouldn't
-Wunused-label (enabled via -Wall) warn here, and turn into a build failure
under the default CONFIG_WERROR=y?

Would dropping the err_vma_lock_failed: label and letting mmput_async(mm) fall
through avoid that?

---

AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

In-Reply-To-Subject: binder: Make shrinker rely solely on per-VMA lock
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/27312528837

[kernel-patches-daemon-bpf]

Forwarding comment 4675691780 via email
In-Reply-To: 20260610230415.C0521C88@davehans-spike.ostc.intel.com
Patch: https://patchwork.kernel.org/project/netdevbpf/patch/20260610230415.C0521C88@davehans-spike.ostc.intel.com/

[kernel-patches-daemon-bpf]

Forwarding comment 4675700241 via email
In-Reply-To: 20260610230413.D68967BC@davehans-spike.ostc.intel.com
Patch: https://patchwork.kernel.org/project/netdevbpf/patch/20260610230413.D68967BC@davehans-spike.ostc.intel.com/

[kernel-patches-review-bot]

commit c4e197dd47640d9ed0b93394ce249569f60dce76
Author: Dave Hansen <dave.hansen@linux.intel.com>

mm: Make per-VMA locks available universally

The per-VMA locks have been around for several years. They've had some
bugs worked out of them and have seen quite wide use. However, they
are still only available when architectures explicitly enable them.
Remove the conditional compilation around the per-VMA locks, making
them available on all architectures and configs.

> diff --git a/mm/Kconfig b/mm/Kconfig
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -1394,19 +1394,6 @@
>  config LRU_GEN_WALKS_MMU
>  	def_bool y
>  	depends on LRU_GEN && ARCH_HAS_HW_PTE_YOUNG
> -# }
> -
> -config ARCH_SUPPORTS_PER_VMA_LOCK
> -       def_bool n
> -
> -config PER_VMA_LOCK
> -	def_bool y
> -	depends on ARCH_SUPPORTS_PER_VMA_LOCK && MMU && SMP
> -	help
> -	  Allow per-vma locking during page fault handling.
> -
> -	  This feature allows locking each virtual memory area separately when
> -	  handling page faults instead of taking mmap_lock.
>
>  config LOCK_MM_AND_FIND_VMA
>  	bool

Removing the CONFIG_PER_VMA_LOCK config symbol makes it permanently
undefined, but kernel/bpf/stackmap.c (not modified in this commit) still
keys its locking protocol on it. This creates a lock imbalance in the BPF
stack build-id collection path.

In stack_map_lock_vma(), lock_vma_under_rcu() now always executes the real
implementation (not a no-op stub). When it succeeds, it returns a VMA
holding a per-VMA read lock, with mmap_lock NOT held:

kernel/bpf/stackmap.c:stack_map_lock_vma() {
    ...
    vma = lock_vma_under_rcu(mm, ip);
    if (vma) {
        lock->vma = vma;
        return vma;
    }
    ...
}

But stack_map_unlock_vma() still has the #ifdef CONFIG_PER_VMA_LOCK around
its cleanup:

kernel/bpf/stackmap.c:stack_map_unlock_vma() {
#ifdef CONFIG_PER_VMA_LOCK
    vma_end_read(lock->vma);
#else
    mmap_read_unlock(lock->mm);
#endif
    lock->vma = NULL;
}

With CONFIG_PER_VMA_LOCK now undefined, the #else branch executes
mmap_read_unlock(lock->mm) on an mmap_lock rwsem that was never acquired.

This corrupts the rwsem state, and also leaks the per-VMA read lock (never
released via vma_end_read), permanently blocking VMA detach/free. Should
kernel/bpf/stackmap.c be updated to remove these #ifdef guards as well?

[ ... ]

> diff --git a/rust/kernel/mm.rs b/rust/kernel/mm.rs
> --- a/rust/kernel/mm.rs
> +++ b/rust/kernel/mm.rs
> @@ -174,7 +174,6 @@
>      /// When per-vma locks are disabled, this always returns `None`.
>      #[inline]
>      pub fn lock_vma_under_rcu(&self, vma_addr: usize) -> Option<VmaReadGuard<'_>> {
> -        #[cfg(CONFIG_PER_VMA_LOCK)]
>          {
>              // SAFETY: Calling `bindings::lock_vma_under_rcu` is always okay given an mm where
>              // `mm_users` is non-zero.
> @@ -188,12 +187,6 @@
>                  });
>              }
>          }
> -
> -        // Silence warnings about unused variables.
> -        #[cfg(not(CONFIG_PER_VMA_LOCK))]
> -        let _ = vma_addr;
> -
> -        None
>      }

Removing the trailing None here breaks compilation. The function signature
is pub fn lock_vma_under_rcu(&self, vma_addr: usize) ->
Option<VmaReadGuard<'_>>. The return Some(...) only executes when
!vma.is_null(). On the vma.is_null() path (lookup miss or lock contention)
the if has no else, so the inner block evaluates to (), and the function's
tail expression is (). This is a type mismatch (rustc E0308: expected
Option<VmaReadGuard<'_>>, found ()).

Shouldn't the trailing None be kept to serve as the return value for the
null/contention path?

---

AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

In-Reply-To-Subject: mm: Make per-VMA locks available universally
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/27312528837

[kernel-patches-daemon-bpf]

Forwarding comment 4675724775 via email
In-Reply-To: 20260610230411.617DD5E7@davehans-spike.ostc.intel.com
Patch: https://patchwork.kernel.org/project/netdevbpf/patch/20260610230411.617DD5E7@davehans-spike.ostc.intel.com/