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 78AA23D6CDC 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=1773244902; cv=none; b=hfObg9FYoESb4f6WB8ZS37QxirExKBbJZKQPFY648vnrORwCSja4fHwE0JEJxJy45QL3A6rUqLPmLkegWgtBs6w74He9a1C3CjFJg51piYrDUKi7Sfw3a7o8PrhWVI7YJ2YyBpKQ17164U7l7wMWI6Ab8TJTcHhNK8LTtiHF81M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773244902; c=relaxed/simple; bh=alZSKgg1lU1wQh0A0HBF21ufoC8erK4cgoNEO+IVhhg=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=fX6j0vAmb1oJ9q0GzvEBix6+0UJKGUswaqgGT7eJANxh0vC+IlBQMvFqUCeRpVlHCyV9VJMq7+QJJbWshdhPlw0NjlaqJdgkabIMND+lK0+P0bhwOWMkfWXYKxJomb1DzhZa5xRGfUrx1p1j0GUIdAd0t/K+ZSahDJ0dG6dFt5w= 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=rgP3KJaq; 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="rgP3KJaq" Received: by mail-ej1-f73.google.com with SMTP id a640c23a62f3a-b844098869cso1293345566b.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=1773244899; x=1773849699; 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=rgP3KJaqF2BlecOpPvT5kKAcfsza44TQB2S2rx00vuamlvPC3PCFQtN7iBBVErQ0kT 4WdJtxceJIxgfEoqrKiMSBM220p/tm52QxQ+p/Vm9qhMEQGFaHmneuWDzyXc37rR6IvX j5BlJPNzE5lVxK7VrA572ygi0hpBk5fcEnP2yH7V3Q+z+BLO1dy4fVpi0jRKEMeOTip2 HIDkQduGaTUGLYmL2Eky5xA41gFzkVV4qEEUwksw40H4w8eZCk0GeALUIDP+Gr7DNvF1 2+wUJnKujEB5WM6EYBJBnq343bDJzOoB3ZqK8V5pehsfNWev2da3jY31l4UTLmX5NLQo YIPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773244899; x=1773849699; 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=vmT967hRf4rNUyFDGawVo9kj9WuVwVcmNJxyflU9XM7T+QKbR+Thnz1c9SHhBmOA7c xDhMsgUCdJG0zBgfGPgR8qMzWMFnX7zDPs99Qb5pFTMtc/og5dLy7A6UIOtifgz7E2Oz 27+fdbC+nL2Z4A0zfORZzYHlHHeXN+8ipvsFXEl2ccRGYkHyqjAa9TbrqRCcV6/Jyflk Gf4xZDp0sv0d1lrKidHmvjnlaovrEBHgw87vag4Q/uliuPkFENaTrdjv5BcV+gbggd97 g1WE0ArA3CLvp+fvAvjLnYTLxGVZLmTkQwLNN/zN4/aD6u0E82bv8kau/HHn9mdqFNBW rxmA== X-Forwarded-Encrypted: i=1; AJvYcCXgO6deBrFGt0kKRQAQxrLJAC6M55XmMANDif/LsxkHGmeRQaNNK1iVFRZNqZQQ4Yl/ph0G1suCdYx+pfv8@vger.kernel.org X-Gm-Message-State: AOJu0YzvyNsAqa1KGJdgIsjOFaZqjNjH0wPjC/mbli2WQMFbC41Xz2DS BIQX7dc39L60tTUDXc1kdnxnmPfcckgGORBMmDKZ7wAp40hMf1ViLkMLf6woOUYGi2UAfW8eOIN WQnKRL99rw77D2lbXHg== 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-fsdevel@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