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 09:54:58 -0700 [thread overview]
Message-ID: <e9e196ff-7428-43bd-8e06-dc2cf0628c9e@intel.com> (raw)
In-Reply-To: <CAJuCfpFh60wULMkFc7hzxWNg+qmZ2R_HMw_QZe5CNcDRFuoN6A@mail.gmail.com>
On 6/12/26 09:41, Suren Baghdasaryan wrote:
>> I think the key to distinguishing between:
>>
>> vma==NULL because there's no VMA
>> and
>> vma==NULL because of a trylock failure
>>
>> is binder_alloc_is_mapped(). It won't return false until vm_ops->close()
>> finishes. vm_ops->close() shouldn't be able to happen while
>> lock_vma_under_rcu() is held. So if you've got a non-NULL VMA, you've
>> also got a stable is binder_alloc_is_mapped().
> By "stable binder_alloc_is_mapped()" do you mean it would always be
> true?
By stable, I meant that it can't change.
vma = lock_vma_under_rcu()
mapped = binder_alloc_is_mapped();
<window>
vma_end_read(vma);
During <window> it can't go from true=>false or false=>true.
false=>true never happens from what I can tell. It's just plain
impossible given the current code.
true=>false is locked out because when lock_vma_under_rcu() is held.
> Asking because in your patch you removed this condition:
>
> - if (vma && !binder_alloc_is_mapped(alloc))
> - goto err_invalid_vma;
>
> So, previously if we found the VMA but binder_alloc_is_mapped()==false
> we would bail out and now we don't. Are you reasoning that this
> combination is impossible?
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.
That's why I did:
- if (vma) {
+ if (mapped) {
The question isn't whether a VMA was found. The question is whether the
binder VMA is still mapped at page_addr. *That* is best inferred from
binder_alloc_is_mapped(), not the VMA lookup.
At least that's what I decided after staring at it for far too long.
next prev parent reply other threads:[~2026-06-12 16:55 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 [this message]
2026-06-12 17:07 ` Carlos Llamas
2026-06-12 17:44 ` Suren Baghdasaryan
2026-06-12 18:47 ` Dave Hansen
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=e9e196ff-7428-43bd-8e06-dc2cf0628c9e@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