From: Dave Hansen <dave.hansen@intel.com>
To: Suren Baghdasaryan <surenb@google.com>
Cc: "Vlastimil Babka (SUSE)" <vbabka@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"Dave Hansen" <dave.hansen@linux.intel.com>,
linux-kernel@vger.kernel.org,
"Andrew Morton" <akpm@linux-foundation.org>,
"Arve Hjønnevåg" <arve@android.com>,
"Carlos Llamas" <cmllamas@google.com>,
"Christian Brauner" <christian@brauner.io>,
"David Ahern" <dsahern@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
linux-mm@kvack.org, "Lorenzo Stoakes" <ljs@kernel.org>,
netdev@vger.kernel.org, "Shakeel Butt" <shakeel.butt@linux.dev>,
"Todd Kjos" <tkjos@android.com>
Subject: Re: [PATCH v2 2/5] binder: Make shrinker rely solely on per-VMA lock
Date: Fri, 12 Jun 2026 11:47:59 -0700 [thread overview]
Message-ID: <2da031dd-4442-45b7-9515-72ffc60e8d8c@intel.com> (raw)
In-Reply-To: <CAJuCfpFo_avdhpOviX7EsPqLgDJ3DfeGpth+yu1-ahfawqaSzw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 728 bytes --]
On 6/12/26 10:44, Suren Baghdasaryan wrote:
>> It's not impossible, but I do think it is irrelevant. Or at least that
>> the *VMA* is irrelevant in this case. binder_alloc_is_mapped()==false
>> means that the binder VMA is gone. It's not in the maple tree, and it's
>> not coming back. If a VMA is found, it's an impostor.
> Right, but before your change we were bailing out early. With your
> change we would be generating the traces and freeing the page. I think
> that's a functional change. Was that your intention?
Yeah, it was intentional.
I think the existing behavior is buggy. It also complicates the goal of
removing the mmap lock fallback. I've broken that behavior change out
into a separate patch. (attached here)
[-- Attachment #2: binder-impostor-fix.patch --]
[-- Type: text/x-patch, Size: 2462 bytes --]
tl;dr: Stop relying on VMA lookups to determine when to reclaim
pages. Instead, use binder-internal metadata.
== Background ==
Each 'struct binder_alloc' has one and only one place where it is
recorded as having been mapped. It can be munmap()'d. But after that,
binder_alloc_mmap_handler() will return errors for it being "already
mapped". So, binder mmap()s are a one-shot thing.
But, the original mmap() location is special even after munmap(). It
is still recorded in alloc->vm_start and never cleared out.
binder_alloc_free_page() continues to look up VMAs at that address.
== Problem ==
That leads to some suboptimal behavior. The moment an "impostor" VMA
is created at the old binder address, the shrinker function will
always hit the:
if (vma && !binder_alloc_is_mapped(alloc))
case and LRU_SKIP all pages.
== Solution ==
Stop using the VMA to drive zapping decisions. Instead, use
binder_alloc_is_mapped().
== Discussion ==
Here's some pseudocode for how this behavior could be triggered:
addr = mmap(..., len, binder_fd);
// pages can be reclaimed
munmap(addr, len);
// pages can still be reclaimed
mmap(addr, len, MAP_ANONYMOUS|MAP_PRIVATE, -1, ...);
// Pages can no longer be reclaimed
There are plenty of ways the code could be restructured now
that it is less dependent on VMAs. But I've left that for future
patches.
---
b/drivers/android/binder_alloc.c | 10 +---------
1 file changed, 1 insertion(+), 9 deletions(-)
diff -puN drivers/android/binder_alloc.c~binder-impostor-fix drivers/android/binder_alloc.c
--- a/drivers/android/binder_alloc.c~binder-impostor-fix 2026-06-12 10:46:06.704707233 -0700
+++ b/drivers/android/binder_alloc.c 2026-06-12 11:34:15.304460520 -0700
@@ -1164,14 +1164,6 @@ enum lru_status binder_alloc_free_page(s
if (!mutex_trylock(&alloc->mutex))
goto err_get_alloc_mutex_failed;
- /*
- * Since a binder_alloc can only be mapped once, we ensure
- * the vma corresponds to this mapping by checking whether
- * the binder_alloc is still mapped.
- */
- if (vma && !binder_alloc_is_mapped(alloc))
- goto err_invalid_vma;
-
trace_binder_unmap_kernel_start(alloc, index);
page_to_free = alloc->pages[index];
@@ -1182,7 +1174,7 @@ enum lru_status binder_alloc_free_page(s
list_lru_isolate(lru, item);
spin_unlock(&lru->lock);
- if (vma) {
+ if (binder_alloc_is_mapped(alloc)) {
trace_binder_unmap_user_start(alloc, index);
zap_vma_range(vma, page_addr, PAGE_SIZE);
_
next prev parent reply other threads:[~2026-06-12 18:48 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-10 23:04 [PATCH v2 0/5] mm: Unconditional per-VMA locks and cleanups Dave Hansen
2026-06-10 23:04 ` [PATCH v2 1/5] mm: Make per-VMA locks available universally Dave Hansen
2026-06-11 19:29 ` Suren Baghdasaryan
2026-06-12 14:09 ` Vlastimil Babka (SUSE)
2026-06-12 14:12 ` Vlastimil Babka (SUSE)
2026-06-10 23:04 ` [PATCH v2 2/5] binder: Make shrinker rely solely on per-VMA lock Dave Hansen
2026-06-11 7:53 ` Alice Ryhl
2026-06-11 19:59 ` Suren Baghdasaryan
2026-06-12 15:41 ` Vlastimil Babka (SUSE)
2026-06-12 16:01 ` Suren Baghdasaryan
2026-06-12 16:04 ` Dave Hansen
2026-06-12 16:41 ` Suren Baghdasaryan
2026-06-12 16:54 ` Dave Hansen
2026-06-12 17:07 ` Carlos Llamas
2026-06-12 17:44 ` Suren Baghdasaryan
2026-06-12 18:47 ` Dave Hansen [this message]
2026-06-12 19:50 ` Alice Ryhl
2026-06-10 23:04 ` [PATCH v2 3/5] mm: Add RCU-based VMA lookup helper that waits for writers Dave Hansen
2026-06-10 23:40 ` Dave Hansen
2026-06-11 20:35 ` Suren Baghdasaryan
2026-06-11 21:04 ` Dave Hansen
2026-06-12 18:00 ` Vlastimil Babka (SUSE)
2026-06-10 23:04 ` [PATCH v2 4/5] binder: Remove mmap_lock fallback Dave Hansen
2026-06-11 20:40 ` Suren Baghdasaryan
2026-06-12 18:07 ` Vlastimil Babka (SUSE)
2026-06-10 23:04 ` [PATCH v2 5/5] tcp: Remove mmap_lock fallback path Dave Hansen
2026-06-11 20:44 ` Suren Baghdasaryan
2026-06-12 18:13 ` Vlastimil Babka (SUSE)
2026-06-11 20:24 ` [syzbot ci] Re: mm: Unconditional per-VMA locks and cleanups syzbot ci
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=2da031dd-4442-45b7-9515-72ffc60e8d8c@intel.com \
--to=dave.hansen@intel.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=aliceryhl@google.com \
--cc=arve@android.com \
--cc=christian@brauner.io \
--cc=cmllamas@google.com \
--cc=dave.hansen@linux.intel.com \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=shakeel.butt@linux.dev \
--cc=surenb@google.com \
--cc=tkjos@android.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox