arch/arm/Kconfig | 1 - arch/arm64/Kconfig | 1 - arch/loongarch/Kconfig | 1 - arch/powerpc/platforms/powernv/Kconfig | 1 - arch/powerpc/platforms/pseries/Kconfig | 1 - arch/riscv/Kconfig | 1 - arch/s390/Kconfig | 1 - arch/x86/Kconfig | 2 - drivers/android/binder/page_range.rs | 19 +----- drivers/android/binder_alloc.c | 63 +++++++---------- fs/proc/internal.h | 2 - fs/proc/task_mmu.c | 93 ------------------------- include/linux/mm.h | 12 ---- include/linux/mm_types.h | 8 +-- include/linux/mmap_lock.h | 94 +++++++++++--------------- kernel/bpf/stackmap.c | 17 ++--- kernel/bpf/task_iter.c | 2 +- kernel/fork.c | 2 - mm/Kconfig | 12 ---- mm/Kconfig.debug | 1 - mm/debug.c | 4 -- mm/init-mm.c | 2 - mm/memory.c | 2 - mm/mmap_lock.c | 61 ++++++++++------- mm/pagewalk.c | 2 - mm/rmap.c | 2 - mm/userfaultfd.c | 61 ++--------------- net/ipv4/tcp.c | 31 +++------ rust/kernel/mm.rs | 57 ++++++++++------ tools/testing/vma/include/dup.h | 5 +- tools/testing/vma/vma_internal.h | 1 - 31 files changed, 166 insertions(+), 396 deletions(-)
v2 version of this patchset [1] was written by Dave Hansen and per his request, I'm taking over this series. tl;dr: Make per-VMA locks available in all configs. Simplify some of the per-VMA lock users now that they can rely on them being always available. Binder and networking folks: Your code is the target of the cleanups. I'm cc'ing you now on v2 because there's emerging consensus on the mm side that the approach here is sane. I'm not quite sure how this pile would get merged, but ack/review tags would be appreciated if this looks good to you. Longer version: When working on some x86 shadow stack code, it was a real pain to avoid causing recursive locking problems with mmap_lock. One way to avoid those was to avoid mmap_lock and use per-VMA locks instead. They are great, but they are not available in all configs which makes them unusable in generic code, or if you want to completely avoid mmap_lock. Make per-VMA locks available in all configs. Right now, they are only available on select architectures when SMP and MMU are enabled. But all of the primitives that per-VMA locks are built on (RCU, maple trees, refcounts) work just fine without SMP or MMU. The only real downside is that making VMAs a wee bit bigger on !MMU and !SMP builds. The upside is much cleaner code, lower complexity and less #ifdeffery. Clean up a binder VMA locking site now that it can rely on per-VMA locks. Building on top of universally-available per-VMA locks, introduce a new helper. Since the new API does not require callers to have a fallback to mmap_lock, it's much easier to use. Callers can potentially replace this very common kernel idiom: mmap_read_lock(mm); vma = vma_lookup() // fiddle with vma mmap_read_unlock(mm); with: vma = vma_start_read_unlocked(mm, address); // fiddle with vma vma_end_read(vma); Which avoids mmap_lock entirely in the fast path. Use that new API for another binder site and one in the TCP code. 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: Jann Horn <jannh@google.com> Cc: Shakeel Butt <shakeel.butt@linux.dev> Cc: linux-mm@kvack.org Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Arve Hjønnevåg <arve@android.com> Cc: Todd Kjos <tkjos@android.com> Cc: Christian Brauner <christian@brauner.io> Cc: Carlos Llamas <cmllamas@google.com> Cc: Alice Ryhl <aliceryhl@google.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: David Ahern <dsahern@kernel.org> Cc: netdev@vger.kernel.org Changes since v5 [2]: Patch 2: - Removed dead code, per Alice Ryhl - Rebased over mm-unstable Applies cleanly over mm-unstable [1] https://lore.kernel.org/all/20260610230409.A44D29FA@davehans-spike.ostc.intel.com/ [2] https://lore.kernel.org/all/20260812011056.902771-1-surenb@google.com/ Dave Hansen (5): mm: Make per-VMA locks available universally binder: Make shrinker rely solely on per-VMA lock mm: Add RCU-based VMA lookup helper that waits for writers binder: Remove mmap_lock fallback tcp: Remove mmap_lock fallback path arch/arm/Kconfig | 1 - arch/arm64/Kconfig | 1 - arch/loongarch/Kconfig | 1 - arch/powerpc/platforms/powernv/Kconfig | 1 - arch/powerpc/platforms/pseries/Kconfig | 1 - arch/riscv/Kconfig | 1 - arch/s390/Kconfig | 1 - arch/x86/Kconfig | 2 - drivers/android/binder/page_range.rs | 19 +----- drivers/android/binder_alloc.c | 63 +++++++---------- fs/proc/internal.h | 2 - fs/proc/task_mmu.c | 93 ------------------------- include/linux/mm.h | 12 ---- include/linux/mm_types.h | 8 +-- include/linux/mmap_lock.h | 94 +++++++++++--------------- kernel/bpf/stackmap.c | 17 ++--- kernel/bpf/task_iter.c | 2 +- kernel/fork.c | 2 - mm/Kconfig | 12 ---- mm/Kconfig.debug | 1 - mm/debug.c | 4 -- mm/init-mm.c | 2 - mm/memory.c | 2 - mm/mmap_lock.c | 61 ++++++++++------- mm/pagewalk.c | 2 - mm/rmap.c | 2 - mm/userfaultfd.c | 61 ++--------------- net/ipv4/tcp.c | 31 +++------ rust/kernel/mm.rs | 57 ++++++++++------ tools/testing/vma/include/dup.h | 5 +- tools/testing/vma/vma_internal.h | 1 - 31 files changed, 166 insertions(+), 396 deletions(-) base-commit: f9ca2fa9ef7e9b39ec79a0596929d1a1f8704c5f -- 2.55.0.691.gc56d675ccc-goog
On Thu, 13 Aug 2026 12:34:28 -0700 Suren Baghdasaryan <surenb@google.com> wrote: > v2 version of this patchset [1] was written by Dave Hansen and per his > request, I'm taking over this series. > > tl;dr: Make per-VMA locks available in all configs. Simplify some > of the per-VMA lock users now that they can rely on them being > always available. It's been 2+ weeks so perhaps a refresh-and-remind would be helpful. But it applies well enough and is adequately reviewed so I put it in there for testing, thanks. AI review might have found a couple of pre-existing binder bugs: https://sashiko.dev/#/patchset/20260813193433.3318288-1-surenb@google.com and a small rusty thing which you might wish to attend to. > Binder and networking folks: Your code is the target of the cleanups. > I'm cc'ing you now on v2 because there's emerging consensus on the mm > side that the approach here is sane. I'm not quite sure how this pile > would get merged, but ack/review tags would be appreciated if this > looks good to you. As said, a resend might help with this. More binder/net acks would be helpful, please.
On Sat, Aug 29, 2026 at 06:56:25PM -0700, Andrew Morton wrote: > On Thu, 13 Aug 2026 12:34:28 -0700 Suren Baghdasaryan <surenb@google.com> wrote: > > > v2 version of this patchset [1] was written by Dave Hansen and per his > > request, I'm taking over this series. > > > > tl;dr: Make per-VMA locks available in all configs. Simplify some > > of the per-VMA lock users now that they can rely on them being > > always available. > > It's been 2+ weeks so perhaps a refresh-and-remind would be helpful. > > But it applies well enough and is adequately reviewed so I put it in > there for testing, thanks. > > AI review might have found a couple of pre-existing binder bugs: > > https://sashiko.dev/#/patchset/20260813193433.3318288-1-surenb@google.com > > and a small rusty thing which you might wish to attend to. The binder bug is not actually a bug. When using VM_MIXEDMAP and vm_insert_page(), the vma takes a refcount on the page, so there is no use-after-free even if free_page() is invoked without removing it from the vma. Adding an INVARIANT: comment to the Rust code SGTM. Alice
On 26/08/31 11:13AM, Alice Ryhl wrote: > On Sat, Aug 29, 2026 at 06:56:25PM -0700, Andrew Morton wrote: > > On Thu, 13 Aug 2026 12:34:28 -0700 Suren Baghdasaryan <surenb@google.com> wrote: > > > > > v2 version of this patchset [1] was written by Dave Hansen and per his > > > request, I'm taking over this series. > > > > > > tl;dr: Make per-VMA locks available in all configs. Simplify some > > > of the per-VMA lock users now that they can rely on them being > > > always available. > > > > It's been 2+ weeks so perhaps a refresh-and-remind would be helpful. > > > > But it applies well enough and is adequately reviewed so I put it in > > there for testing, thanks. > > > > AI review might have found a couple of pre-existing binder bugs: > > > > https://sashiko.dev/#/patchset/20260813193433.3318288-1-surenb@google.com > > > > and a small rusty thing which you might wish to attend to. > > The binder bug is not actually a bug. When using VM_MIXEDMAP and > vm_insert_page(), the vma takes a refcount on the page, so there is no > use-after-free even if free_page() is invoked without removing it from > the vma. > > Adding an INVARIANT: comment to the Rust code SGTM. > I think you are correct about no UAF here, but the page isn't exactly pinned to the vma - which is what I thought you were saying when I first read your reply. It's sort of misplaced in another vma by an mremap(). vm_insert_page() will increment the ref count, but if the vma is mremap()'ed with the same size vma (ie, not expanding), then move_vma() will relocate the pte and the old vma will be closed and set the binder's mapped = false without a change to alloc->vm_start. Binder now thinks there is no mapping but the mapping has an address so it can't map anything new. You could get around it by replacing the vma, but I don't think that leads to anything interesting. So we still have a ref count that's okay, but now binder has an alloc->vm_start that's stale and a mapped = false which leaves binder in a bad state (one might say a bind). Thanks, Liam
On Thu, Sep 03, 2026 at 04:48:31PM -0400, Liam R. Howlett wrote: > On 26/08/31 11:13AM, Alice Ryhl wrote: > > On Sat, Aug 29, 2026 at 06:56:25PM -0700, Andrew Morton wrote: > > > On Thu, 13 Aug 2026 12:34:28 -0700 Suren Baghdasaryan <surenb@google.com> wrote: > > > > > > > v2 version of this patchset [1] was written by Dave Hansen and per his > > > > request, I'm taking over this series. > > > > > > > > tl;dr: Make per-VMA locks available in all configs. Simplify some > > > > of the per-VMA lock users now that they can rely on them being > > > > always available. > > > > > > It's been 2+ weeks so perhaps a refresh-and-remind would be helpful. > > > > > > But it applies well enough and is adequately reviewed so I put it in > > > there for testing, thanks. > > > > > > AI review might have found a couple of pre-existing binder bugs: > > > > > > https://sashiko.dev/#/patchset/20260813193433.3318288-1-surenb@google.com > > > > > > and a small rusty thing which you might wish to attend to. > > > > The binder bug is not actually a bug. When using VM_MIXEDMAP and > > vm_insert_page(), the vma takes a refcount on the page, so there is no > > use-after-free even if free_page() is invoked without removing it from > > the vma. > > > > Adding an INVARIANT: comment to the Rust code SGTM. > > > > I think you are correct about no UAF here, but the page isn't exactly > pinned to the vma - which is what I thought you were saying when I first > read your reply. It's sort of misplaced in another vma by an mremap(). > > vm_insert_page() will increment the ref count, but if the vma is > mremap()'ed with the same size vma (ie, not expanding), then move_vma() > will relocate the pte and the old vma will be closed and set the > binder's mapped = false without a change to alloc->vm_start. > > Binder now thinks there is no mapping but the mapping has an address so > it can't map anything new. You could get around it by replacing the > vma, but I don't think that leads to anything interesting. > > So we still have a ref count that's okay, but now binder has an > alloc->vm_start that's stale and a mapped = false which leaves binder in > a bad state (one might say a bind). Right, binder should really reject mremap(). And partial munmap() too. The is no use case for them in binder and it only brings problems such as the stale alloc->vm_start you mention. I sent out fixes for these issues here: https://lore.kernel.org/all/20260901205250.1638304-1-cmllamas@google.com/ I'll Cc you on the next round if needed. Thanks Liam. -- Carlos Llamas
On Mon, Aug 31, 2026 at 11:13:16AM +0000, Alice Ryhl wrote: > On Sat, Aug 29, 2026 at 06:56:25PM -0700, Andrew Morton wrote: > > On Thu, 13 Aug 2026 12:34:28 -0700 Suren Baghdasaryan <surenb@google.com> wrote: > > > > > v2 version of this patchset [1] was written by Dave Hansen and per his > > > request, I'm taking over this series. > > > > > > tl;dr: Make per-VMA locks available in all configs. Simplify some > > > of the per-VMA lock users now that they can rely on them being > > > always available. > > > > It's been 2+ weeks so perhaps a refresh-and-remind would be helpful. > > > > But it applies well enough and is adequately reviewed so I put it in > > there for testing, thanks. > > > > AI review might have found a couple of pre-existing binder bugs: > > > > https://sashiko.dev/#/patchset/20260813193433.3318288-1-surenb@google.com > > > > and a small rusty thing which you might wish to attend to. > > The binder bug is not actually a bug. When using VM_MIXEDMAP and > vm_insert_page(), the vma takes a refcount on the page, so there is no > use-after-free even if free_page() is invoked without removing it from > the vma. Exactly! I agree the refcount on the page would prevent the UAF. However, we should still reject mremap() because this leaves the page in limbo since it is not given back to the shrinker and also binder can't make use of it anymore. I'll send out a patch to fix this. Thanks, -- Carlos Llamas
On Mon, Aug 31, 2026 at 3:27 PM Carlos Llamas <cmllamas@google.com> wrote: > > On Mon, Aug 31, 2026 at 11:13:16AM +0000, Alice Ryhl wrote: > > On Sat, Aug 29, 2026 at 06:56:25PM -0700, Andrew Morton wrote: > > > On Thu, 13 Aug 2026 12:34:28 -0700 Suren Baghdasaryan <surenb@google.com> wrote: > > > > > > > v2 version of this patchset [1] was written by Dave Hansen and per his > > > > request, I'm taking over this series. > > > > > > > > tl;dr: Make per-VMA locks available in all configs. Simplify some > > > > of the per-VMA lock users now that they can rely on them being > > > > always available. > > > > > > It's been 2+ weeks so perhaps a refresh-and-remind would be helpful. > > > > > > But it applies well enough and is adequately reviewed so I put it in > > > there for testing, thanks. > > > > > > AI review might have found a couple of pre-existing binder bugs: > > > > > > https://sashiko.dev/#/patchset/20260813193433.3318288-1-surenb@google.com > > > > > > and a small rusty thing which you might wish to attend to. > > > > The binder bug is not actually a bug. When using VM_MIXEDMAP and > > vm_insert_page(), the vma takes a refcount on the page, so there is no > > use-after-free even if free_page() is invoked without removing it from > > the vma. > > Exactly! I agree the refcount on the page would prevent the UAF. > > However, we should still reject mremap() because this leaves the page in > limbo since it is not given back to the shrinker and also binder can't > make use of it anymore. I'll send out a patch to fix this. Ok. Should that block this series or it will apply over it? > > Thanks, > -- > Carlos Llamas
On Mon, Aug 31, 2026 at 04:19:39PM -0700, Suren Baghdasaryan wrote: > On Mon, Aug 31, 2026 at 3:27 PM Carlos Llamas <cmllamas@google.com> wrote: > > > > On Mon, Aug 31, 2026 at 11:13:16AM +0000, Alice Ryhl wrote: > > > On Sat, Aug 29, 2026 at 06:56:25PM -0700, Andrew Morton wrote: > > > > On Thu, 13 Aug 2026 12:34:28 -0700 Suren Baghdasaryan <surenb@google.com> wrote: > > > > > > > > > v2 version of this patchset [1] was written by Dave Hansen and per his > > > > > request, I'm taking over this series. > > > > > > > > > > tl;dr: Make per-VMA locks available in all configs. Simplify some > > > > > of the per-VMA lock users now that they can rely on them being > > > > > always available. > > > > > > > > It's been 2+ weeks so perhaps a refresh-and-remind would be helpful. > > > > > > > > But it applies well enough and is adequately reviewed so I put it in > > > > there for testing, thanks. > > > > > > > > AI review might have found a couple of pre-existing binder bugs: > > > > > > > > https://sashiko.dev/#/patchset/20260813193433.3318288-1-surenb@google.com > > > > > > > > and a small rusty thing which you might wish to attend to. > > > > > > The binder bug is not actually a bug. When using VM_MIXEDMAP and > > > vm_insert_page(), the vma takes a refcount on the page, so there is no > > > use-after-free even if free_page() is invoked without removing it from > > > the vma. > > > > Exactly! I agree the refcount on the page would prevent the UAF. > > > > However, we should still reject mremap() because this leaves the page in > > limbo since it is not given back to the shrinker and also binder can't > > make use of it anymore. I'll send out a patch to fix this. > > Ok. Should that block this series or it will apply over it? The issue is pre-exiting and unrelated to this series. So I'll take care of this separately. Thanks!
On Mon, Aug 31, 2026 at 4:29 PM Carlos Llamas <cmllamas@google.com> wrote: > > On Mon, Aug 31, 2026 at 04:19:39PM -0700, Suren Baghdasaryan wrote: > > On Mon, Aug 31, 2026 at 3:27 PM Carlos Llamas <cmllamas@google.com> wrote: > > > > > > On Mon, Aug 31, 2026 at 11:13:16AM +0000, Alice Ryhl wrote: > > > > On Sat, Aug 29, 2026 at 06:56:25PM -0700, Andrew Morton wrote: > > > > > On Thu, 13 Aug 2026 12:34:28 -0700 Suren Baghdasaryan <surenb@google.com> wrote: > > > > > > > > > > > v2 version of this patchset [1] was written by Dave Hansen and per his > > > > > > request, I'm taking over this series. > > > > > > > > > > > > tl;dr: Make per-VMA locks available in all configs. Simplify some > > > > > > of the per-VMA lock users now that they can rely on them being > > > > > > always available. > > > > > > > > > > It's been 2+ weeks so perhaps a refresh-and-remind would be helpful. > > > > > > > > > > But it applies well enough and is adequately reviewed so I put it in > > > > > there for testing, thanks. > > > > > > > > > > AI review might have found a couple of pre-existing binder bugs: > > > > > > > > > > https://sashiko.dev/#/patchset/20260813193433.3318288-1-surenb@google.com > > > > > > > > > > and a small rusty thing which you might wish to attend to. > > > > > > > > The binder bug is not actually a bug. When using VM_MIXEDMAP and > > > > vm_insert_page(), the vma takes a refcount on the page, so there is no > > > > use-after-free even if free_page() is invoked without removing it from > > > > the vma. > > > > > > Exactly! I agree the refcount on the page would prevent the UAF. > > > > > > However, we should still reject mremap() because this leaves the page in > > > limbo since it is not given back to the shrinker and also binder can't > > > make use of it anymore. I'll send out a patch to fix this. > > > > Ok. Should that block this series or it will apply over it? > > The issue is pre-exiting and unrelated to this series. So I'll take care > of this separately. Thanks! Perfect. Thanks! >
On Mon, Aug 31, 2026 at 4:13 AM Alice Ryhl <aliceryhl@google.com> wrote: > > On Sat, Aug 29, 2026 at 06:56:25PM -0700, Andrew Morton wrote: > > On Thu, 13 Aug 2026 12:34:28 -0700 Suren Baghdasaryan <surenb@google.com> wrote: > > > > > v2 version of this patchset [1] was written by Dave Hansen and per his > > > request, I'm taking over this series. > > > > > > tl;dr: Make per-VMA locks available in all configs. Simplify some > > > of the per-VMA lock users now that they can rely on them being > > > always available. > > > > It's been 2+ weeks so perhaps a refresh-and-remind would be helpful. > > > > But it applies well enough and is adequately reviewed so I put it in > > there for testing, thanks. > > > > AI review might have found a couple of pre-existing binder bugs: > > > > https://sashiko.dev/#/patchset/20260813193433.3318288-1-surenb@google.com > > > > and a small rusty thing which you might wish to attend to. > > The binder bug is not actually a bug. When using VM_MIXEDMAP and > vm_insert_page(), the vma takes a refcount on the page, so there is no > use-after-free even if free_page() is invoked without removing it from > the vma. > > Adding an INVARIANT: comment to the Rust code SGTM. Posted v7 with these fixups at: https://lore.kernel.org/all/20260831203056.838265-1-surenb@google.com/ Thanks! > > Alice
On Sat, Aug 29, 2026 at 6:56 PM Andrew Morton <akpm@linux-foundation.org> wrote: > > On Thu, 13 Aug 2026 12:34:28 -0700 Suren Baghdasaryan <surenb@google.com> wrote: > > > v2 version of this patchset [1] was written by Dave Hansen and per his > > request, I'm taking over this series. > > > > tl;dr: Make per-VMA locks available in all configs. Simplify some > > of the per-VMA lock users now that they can rely on them being > > always available. > > It's been 2+ weeks so perhaps a refresh-and-remind would be helpful. > > But it applies well enough and is adequately reviewed so I put it in > there for testing, thanks. > > AI review might have found a couple of pre-existing binder bugs: > > https://sashiko.dev/#/patchset/20260813193433.3318288-1-surenb@google.com > > and a small rusty thing which you might wish to attend to. Ack. > > > Binder and networking folks: Your code is the target of the cleanups. > > I'm cc'ing you now on v2 because there's emerging consensus on the mm > > side that the approach here is sane. I'm not quite sure how this pile > > would get merged, but ack/review tags would be appreciated if this > > looks good to you. > > As said, a resend might help with this. Will send an update on Monday. > > More binder/net acks would be helpful, please.
© 2016 - 2026 Red Hat, Inc.