From: Lorenzo Stoakes <ljs@kernel.org>
To: Dave Hansen <dave.hansen@linux.intel.com>
Cc: linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
linux-mm@kvack.org, Shakeel Butt <shakeel.butt@linux.dev>,
Suren Baghdasaryan <surenb@google.com>,
Vlastimil Babka <vbabka@kernel.org>
Subject: Re: [PATCH 2/6] binder: Make shrinker rely solely on per-VMA lock
Date: Fri, 8 May 2026 18:06:59 +0100 [thread overview]
Message-ID: <af4V7pP4qdIsB0yA@lucifer> (raw)
In-Reply-To: <20260429181957.7511C256@davehans-spike.ostc.intel.com>
On Wed, Apr 29, 2026 at 11:19:57AM -0700, Dave Hansen wrote:
>
> From: Dave Hansen <dave.hansen@linux.intel.com>
>
> tl;dr: lock_vma_under_rcu() is already a trylock. No need to do both
> it and mmap_read_trylock().
>
> Long Version:
>
> == Background ==
>
> Historically, binder used an mmap_read_trylock() in its shrinker code.
> This ensures that reclaim is not blocked on an mmap_lock. Commit
> 95bc2d4a9020 ("binder: use per-vma lock in page reclaiming") added
> support for the per-VMA lock, but but left mmap_read_trylock() as a
> fallback.
>
> This was presumably because the per-VMA locking can fail for several
> reasons and most (all?) lock_vma_under_rcu() callers have a fallback
> to mmap_read_trylock().
>
> == Problem ==
>
> The fallback is not worth the complexity here. lock_vma_under_rcu() is
> essentially already a non-blocking trylock. The main reason it fails
> is also the reason mmap_read_trylock() fails: something is holding
> mmap_write_lock().
>
> The only remedy for a collision with mmap_write_lock() is to wait,
> which this code can not do. So the "fallback" after
> lock_vma_under_rcu() failure is not really a fallback: it is really
> likely to just be retrying in vain. That retry in an of itself isn't
> horrible. But it adds complexity.
>
> == Solution ==
>
> Now that per-VMA locks are universally available, lock_vma_under_rcu()
> will not persistently fail. Rely on it alone and simplify the code.
>
> Full disclosure: I originally tried to do this with
> lock_vma_under_rcu_wait(), but it did not fit well with the mmap_lock
> trylock semantics. Claude caught this in a review and suggested the
> approach in this path. It seemed sane to me. So, Suggesed-by: Claude,
> I guess.
>
> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
I mean this seems reasonable to me, I don't really understand why we'd fall back
to mmap... try lock :)
If semantically you're trylocking then as you say, lock_vma_under_rcu() already
does that.
Honestly I feel this could be submitted separate from the series.
I'm not a binder guy, but this looks right to me so:
Acked-by: Lorenzo Stoakes <ljs@kernel.org> with nit below addressed.
> Cc: Suren Baghdasaryan <surenb@google.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: "Liam R. Howlett" <Liam.Howlett@oracle.com>
> Cc: Lorenzo Stoakes <ljs@kernel.org>
> Cc: Vlastimil Babka <vbabka@kernel.org>
> Cc: Shakeel Butt <shakeel.butt@linux.dev>
> Cc: linux-mm@kvack.org
> ---
>
> b/drivers/android/binder_alloc.c | 22 +++++-----------------
> 1 file changed, 5 insertions(+), 17 deletions(-)
>
> diff -puN drivers/android/binder_alloc.c~binder-try-vma-lock drivers/android/binder_alloc.c
> --- a/drivers/android/binder_alloc.c~binder-try-vma-lock 2026-04-29 11:18:50.066607065 -0700
> +++ b/drivers/android/binder_alloc.c 2026-04-29 11:18:50.069607180 -0700
> @@ -1142,7 +1142,6 @@ enum lru_status binder_alloc_free_page(s
> struct vm_area_struct *vma;
> struct page *page_to_free;
> unsigned long page_addr;
> - int mm_locked = 0;
Man why are we using int instead of a bool in 2026 in the first place :P
> size_t index;
>
> if (!mmget_not_zero(mm))
> @@ -1151,15 +1150,10 @@ enum lru_status binder_alloc_free_page(s
> index = mdata->page_index;
> page_addr = alloc->vm_start + index * PAGE_SIZE;
>
> - /* attempt per-vma lock first */
> + /* attempt per-vma lock */
> vma = lock_vma_under_rcu(mm, page_addr);
> - if (!vma) {
> - /* fall back to mmap_lock */
> - if (!mmap_read_trylock(mm))
> - goto err_mmap_read_lock_failed;
> - mm_locked = 1;
> - vma = vma_lookup(mm, page_addr);
> - }
> + if (!vma)
> + goto err_mmap_read_lock_failed;
Nit, but we probably want to rename that to err_vma_lock_failed or something!
>
> if (!mutex_trylock(&alloc->mutex))
> goto err_get_alloc_mutex_failed;
> @@ -1191,10 +1185,7 @@ enum lru_status binder_alloc_free_page(s
> }
>
> mutex_unlock(&alloc->mutex);
> - if (mm_locked)
> - mmap_read_unlock(mm);
> - else
> - vma_end_read(vma);
> + vma_end_read(vma);
> mmput_async(mm);
> binder_free_page(page_to_free);
>
> @@ -1203,10 +1194,7 @@ enum lru_status binder_alloc_free_page(s
> err_invalid_vma:
> mutex_unlock(&alloc->mutex);
> err_get_alloc_mutex_failed:
> - if (mm_locked)
> - mmap_read_unlock(mm);
> - else
> - vma_end_read(vma);
> + vma_end_read(vma);
> err_mmap_read_lock_failed:
> mmput_async(mm);
> err_mmget:
> _
next prev parent reply other threads:[~2026-05-08 17:07 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-29 18:19 [PATCH 0/6] mm: Make per-VMA locks available in all builds Dave Hansen
2026-04-29 18:19 ` [PATCH 1/6] mm: Make per-VMA locks available universally Dave Hansen
2026-05-08 10:12 ` David Hildenbrand (Arm)
2026-05-08 10:58 ` David Hildenbrand (Arm)
2026-05-08 16:55 ` Lorenzo Stoakes
2026-05-13 21:03 ` Suren Baghdasaryan
2026-04-29 18:19 ` [PATCH 2/6] binder: Make shrinker rely solely on per-VMA lock Dave Hansen
2026-05-08 17:06 ` Lorenzo Stoakes [this message]
2026-05-14 0:15 ` Suren Baghdasaryan
2026-04-29 18:19 ` [PATCH 3/6] mm: Add RCU-based VMA lookup that waits for writers Dave Hansen
2026-05-08 17:26 ` Lorenzo Stoakes
2026-05-08 20:15 ` Lorenzo Stoakes
2026-05-14 0:47 ` Suren Baghdasaryan
2026-04-29 18:20 ` [PATCH 4/6] binder: Remove mmap_lock fallback Dave Hansen
2026-05-08 17:29 ` Lorenzo Stoakes
2026-05-14 0:57 ` Suren Baghdasaryan
2026-05-14 1:01 ` Suren Baghdasaryan
2026-04-29 18:20 ` [PATCH 5/6] tcp: Remove mmap_lock fallback path Dave Hansen
2026-05-08 17:32 ` Lorenzo Stoakes
2026-05-14 1:05 ` Suren Baghdasaryan
2026-04-29 18:20 ` [PATCH 6/6] x86/mm: Avoid mmap lock for shadow stack pop fast path Dave Hansen
2026-05-04 23:15 ` Edgecombe, Rick P
2026-05-05 16:39 ` Dave Hansen
2026-05-08 20:39 ` Lorenzo Stoakes
2026-05-14 1:49 ` Suren Baghdasaryan
2026-05-14 1:44 ` Suren Baghdasaryan
2026-05-14 2:03 ` Suren Baghdasaryan
2026-04-29 18:22 ` [PATCH 0/6] mm: Make per-VMA locks available in all builds Dave Hansen
2026-04-30 8:11 ` Lorenzo Stoakes
2026-04-30 17:17 ` Suren Baghdasaryan
2026-04-30 17:20 ` Dave Hansen
2026-04-30 7:55 ` [syzbot ci] " syzbot ci
2026-04-30 16:59 ` Dave Hansen
[not found] ` <20260430072053.e0be1b431bcff02831f07e9d@linux-foundation.org>
2026-04-30 16:52 ` [PATCH 0/6] " Dave Hansen
2026-05-08 16:52 ` Lorenzo Stoakes
2026-05-08 17:01 ` Dave Hansen
2026-05-13 4:30 ` Suren Baghdasaryan
2026-05-13 4:19 ` Suren Baghdasaryan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=af4V7pP4qdIsB0yA@lucifer \
--to=ljs@kernel.org \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=dave.hansen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=shakeel.butt@linux.dev \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.