From: "Vlastimil Babka (SUSE)" <vbabka@kernel.org>
To: Suren Baghdasaryan <surenb@google.com>,
Alice Ryhl <aliceryhl@google.com>
Cc: "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 17:41:11 +0200 [thread overview]
Message-ID: <131c6a49-9177-418b-a653-8f13942fb8d3@kernel.org> (raw)
In-Reply-To: <CAJuCfpHmem_g7mEoic7O56LVSLkbftgWYgzexPWy7VSwp7_SiA@mail.gmail.com>
On 6/11/26 21:59, Suren Baghdasaryan wrote:
> On Thu, Jun 11, 2026 at 12:53 AM Alice Ryhl <aliceryhl@google.com> wrote:
>>
>> > b/drivers/android/binder_alloc.c | 26 +++++++++-----------------
>> > 1 file changed, 9 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-06-10 15:57:55.274412018 -0700
>> > +++ b/drivers/android/binder_alloc.c 2026-06-10 15:57:55.277412124 -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;
>> > size_t index;
>> >
>> > if (!mmget_not_zero(mm))
>> > @@ -1151,15 +1150,12 @@ 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. This is essentially a
>> > + * "trylock". It can fail even if the VMA exists
>> > + * for 'page_addr'.
>> > + */
>> > 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 (!mutex_trylock(&alloc->mutex))
>> > goto err_get_alloc_mutex_failed;
>> > @@ -1188,13 +1184,11 @@ enum lru_status binder_alloc_free_page(s
>> > zap_vma_range(vma, page_addr, PAGE_SIZE);
>> >
>> > trace_binder_unmap_user_end(alloc, index);
>> > +
>> > + vma_end_read(vma);
>> > }
>> >
>> > mutex_unlock(&alloc->mutex);
>> > - if (mm_locked)
>> > - mmap_read_unlock(mm);
>> > - else
>> > - vma_end_read(vma);
>> > mmput_async(mm);
>> > binder_free_page(page_to_free);
>> >
>> > @@ -1203,11 +1197,9 @@ 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
>> > + if (vma)
>> > vma_end_read(vma);
>> > -err_mmap_read_lock_failed:
>> > +err_vma_lock_failed:
This label is unused btw, which is related to Alice's point.
>> > mmput_async(mm);
>>
>> If the vma lookup fails because the mmap write lock is held, but the vma
>> actually exists (has not been unmapped), then this code might "successfully"
>> remove the page without invoking zap_vma_range(). This means that the
>> page does not actually get freed and will just hang around forever until
>> the process owning the vma exits or Binder needs this page and maps a
>> new page on top of the page.
>
> Yeah, I think if lock_vma_under_rcu() returns NULL you just need to
> jump to err_mmap_read_lock_failed, like we currently do if
> mmap_read_trylock() fails.
I don't think that will be enough as well, as the current code AFAICS does
something meaninfgul when mmap_read_trylock() suceeds but vma_lookup returns
NULL because there's no vma at that address. Now we would just assume the
trylock failed even if the reason was that vma lookup found nothing for the
address. The problem is that lock_vma_under_rcu() can't distinguish those
two outcomes, so we would need something that does?
next prev parent reply other threads:[~2026-06-12 15:41 UTC|newest]
Thread overview: 28+ 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) [this message]
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
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=131c6a49-9177-418b-a653-8f13942fb8d3@kernel.org \
--to=vbabka@kernel.org \
--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 \
/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