From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f73.google.com (mail-ej1-f73.google.com [209.85.218.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 41D1A3CEBA4 for ; Wed, 11 Mar 2026 16:01:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.73 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773244901; cv=none; b=VsWtXf3KvYmfC160lLDiIENJ+jNbulkmVaLv+sIJ1lSzXB9V6srq1umcD/TL9pYrkOjxDRZOvOyhcOfrGLdHNu6oZN3zZm2cZp28KdK871llofZOj1RgC7OGX5AXTN1/xyCbY/gz/gTTeVKWO39JxTIU5Hsve2gex9q26AQbl2U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773244901; c=relaxed/simple; bh=alZSKgg1lU1wQh0A0HBF21ufoC8erK4cgoNEO+IVhhg=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=Cerz5r7SaaPSsudYg+mQl5ltVhjraWL2EqGOpqxe+MlV3Cu/3PbYxOI4LwdA9epVWfbIdHGXcyo8dcFkjq4/eOGqWsRg79KddicgPja6XokhbpKcWkNvHD5djoc2kbboE8gx9ZfSPGsno0A8xSFVbbfClXmRH9IFF2/ohkT+mBM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--aliceryhl.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=Ip7tHToa; arc=none smtp.client-ip=209.85.218.73 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--aliceryhl.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="Ip7tHToa" Received: by mail-ej1-f73.google.com with SMTP id a640c23a62f3a-b844098869cso1293343966b.2 for ; Wed, 11 Mar 2026 09:01:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1773244898; x=1773849698; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=FZ9wJHN98p2eqW+aluFwwdS4VIjV0bOaQ4w+79zBhNs=; b=Ip7tHToa0/Tgk2U4OPsSH4Bieqlotlh0Ye1GJ75X+u++I0OTXhB8dZPuBGir9fSi0s yxnh3Bf4JDKyGOqI9vSxiDFqrZY/oUai4FKgWyIqDvZxWYSXtz4UTuCcDdpkLvl5O0/4 /zXXAdz91McQcF0K7o28qDbivjdg7jnd5TBB7HXaA2TtwsDB8U07pa0Qu1EtKZ38a5fO Dmmbavj+xEyrZnxzYsJYFDfm90jCovOUuT+sKHSCZIPgz7rpBfyP2g5cDLsTcLFLQKqb KI3l7N1vCLhDBDPYZAeKX6qTuytYEoyCS4FAjDD4rWhjD3p1bOjeSw1z9HOA9RnToVvM Ah5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773244898; x=1773849698; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=FZ9wJHN98p2eqW+aluFwwdS4VIjV0bOaQ4w+79zBhNs=; b=JZGqAxozk/glJy8AOr2FF1tETHC52nl0LQjSM3nGQ5WwCvzKEWSFXuQIWbZBHGYW5v PUKfOB9ipKM3wbyMM8PHqmHEAisdBwicuYbNXKS+HSnBvuG5J+LnZVDJTQ/WBJswuujo AH78dR/DQC/vVKQQ+M/7Q04SmrooKq1jbhRAwmtwFaS8sbt0HddeNlaaf57KQJCcx/WT iGr6RhM0mlIyOTV1DeOQ9STL/VhLdjn8ho+8R5u5BjuVWPgdUZBHMEyobvSBEJPvd+ip KyZDlvRD4Nl25AOTItcApOQEWPjjVPzRUfjH366ia5NehLQC47HdSZWivgVUyQonzhQ5 yDWQ== X-Forwarded-Encrypted: i=1; AJvYcCVGsNtHShsRgWFeityvgmwej4GVqnZDwFv8kzXaXJV9stJWCuOk+dcRRud8E4WsR+YK8RK+AL3qGOLbY4E=@vger.kernel.org X-Gm-Message-State: AOJu0Yx985ovPeZ4t63UUh+/mPZqYL/jiiU5RdDBT1PjofgKRHiMuVvz 2xnff5zIfYv9FVLCbLrGugsqtUzu/ujQ1LoJVIl6fDoXHyaWk6wE+44aYiStdIPgwVn6Tn1YVY3 s+jBwVpKiWOUnSbqJJQ== X-Received: from wrbgw30.prod.google.com ([2002:a05:6000:40de:b0:439:ac29:98cb]) (user=aliceryhl job=prod-delivery.src-stubby-dispatcher) by 2002:a17:907:6d22:b0:b93:3792:4b03 with SMTP id a640c23a62f3a-b972e4f775amr187595066b.32.1773244898034; Wed, 11 Mar 2026 09:01:38 -0700 (PDT) Date: Wed, 11 Mar 2026 16:01:36 +0000 In-Reply-To: <20260311120418.GU1687929@ziepe.ca> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260227200848.114019-1-david@kernel.org> <20260227200848.114019-17-david@kernel.org> <20260309142954.GM1687929@ziepe.ca> <61df6369-333c-430a-bd18-c5b1acae68ea@kernel.org> <20260311120418.GU1687929@ziepe.ca> Message-ID: Subject: Re: [PATCH v1 16/16] mm/memory: support VM_MIXEDMAP in zap_special_vma_range() From: Alice Ryhl To: Jason Gunthorpe Cc: "David Hildenbrand (Arm)" , linux-kernel@vger.kernel.org, "linux-mm @ kvack . org" , Andrew Morton , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Jann Horn , Pedro Falcato , David Rientjes , Shakeel Butt , "Matthew Wilcox (Oracle)" , Madhavan Srinivasan , Michael Ellerman , Christian Borntraeger , Janosch Frank , Claudio Imbrenda , Alexander Gordeev , Gerald Schaefer , Heiko Carstens , Vasily Gorbik , Jarkko Sakkinen , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Greg Kroah-Hartman , "Arve =?utf-8?B?SGrDuG5uZXbDpWc=?=" , Todd Kjos , Christian Brauner , Carlos Llamas , Ian Abbott , H Hartley Sweeten , Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , David Airlie , Simona Vetter , Leon Romanovsky , Dimitri Sivanich , Arnd Bergmann , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Peter Zijlstra , Arnaldo Carvalho de Melo , Namhyung Kim , Andy Lutomirski , Vincenzo Frascino , Eric Dumazet , Neal Cardwell , "David S. Miller" , David Ahern , Jakub Kicinski , Paolo Abeni , Miguel Ojeda , linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org, linux-s390@vger.kernel.org, linux-sgx@vger.kernel.org, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-rdma@vger.kernel.org, bpf@vger.kernel.org, linux-perf-users@vger.kernel.org, linux-fsdevel@vger.kernel.org, netdev@vger.kernel.org, rust-for-linux@vger.kernel.org, x86@kernel.org Content-Type: text/plain; charset="utf-8" On Wed, Mar 11, 2026 at 09:04:18AM -0300, Jason Gunthorpe wrote: > On Wed, Mar 11, 2026 at 09:38:45AM +0000, Alice Ryhl wrote: > > It doesn't really make sense to have multiple binder VMAs. What happens > > with Rust Binder is that process A is receiving transactions and has the > > VMA mapped once. > > IIRC the problem is the kernel doesn't guarentee singleton VMAs, > userspace can always clone them with fork or something. Did binder > solve this somehow? The Binder VMA is DONTCOPY, so it will not be present after fork. > Since you can't assume there is only one VMA the locking becomes a > mess to cover all the cases where userspace can trigger a VMA clone. > > address space deals with this internally. > > Thus, zap_special_vma_range() is extremely hard to use. I mean, the hard part about the locking is keeping them in sync. Binder just doesn't do that. Only the original VMA gets pages inserted or zapped. If you create a second VMA, you just get a useless read-only VMA that you can't do anything with. Alice