From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f46.google.com (mail-ej1-f46.google.com [209.85.218.46]) (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 C0C7037E5C4 for ; Mon, 24 Aug 2026 19:48:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787600906; cv=none; b=BhSslr4/MhDkXHOMClM6zNCp3QtIbdzdptkBH6nZBDJUiJzMp1cBwtfpJfwDTKFhSNJS0CW9MWymDZTVqFQtMrJzAxgWPk7R6zf6zk13vkpu8qLnb4hUoqilhtXrX5HyDkTUBo4xkf2Xs9nALicfupdPcplj8pM2IcFTO5wjIBk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787600906; c=relaxed/simple; bh=hNQJwkNnRZM1onHW6fMZZPv9B0rh1E85+i3frTbTWco=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=izVfPx3gmPY1nxHn2lMw5oU4IgvJWT4X6CfzAW+NnqzkiUUdRiPA/qzCNsxRb2v1iI2JDSFM+jYErmCZb4PC5UwXn1BVREfQVgM4KjTfT0+HVkN/VaqRiDIZbaQqaP8ZJQRXE6gU53ecAncnhBFuPbrU3HQf3hY/2zna0zF7DJI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=Rf8jZuVy; arc=none smtp.client-ip=209.85.218.46 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Rf8jZuVy" Received: by mail-ej1-f46.google.com with SMTP id a640c23a62f3a-c15d111ca99so474041466b.0 for ; Mon, 24 Aug 2026 12:48:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787600903; x=1788205703; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=irfg0xHDxtBcVMGyL6ULAXhB1SaYDLc0s9Lgku2rCW8=; b=Rf8jZuVyj6iImfGSdnlxB78FWH1w8CsWGzOQlYIVoiwNNQ80H1Q9cLyZ7I8Woq40ah pRvWfT3PNz+DJadDv/n7qr93tphQZztI/YiezksQsLV89XcPJ0uVqFhMV/zbZtMNvul2 SH0lmfhHFi3qK0LXI+5zgAsc69nQZS9FYbkfXicmN4JUdYQ3lMrnwLy5ZZxPiZ8fZPcs OXgA9NyFXtnfYgwzQjwZPozzcENzZWEHxLPNur/tNbsWev8z0PM8MC9gRl+WpJP3wd3a CBRKyNv/ph8xJscqi8ZRONeIi0qJDNlrXoodYE51WnfgCZH7y9yZn9QUw50SQ2bMgpTO Zo4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787600903; x=1788205703; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=irfg0xHDxtBcVMGyL6ULAXhB1SaYDLc0s9Lgku2rCW8=; b=oApB+JqdzXUpsYdJ0gCnKTe2z1et0mpnE47HHwDQ31ztwHRIzCg+U5Kq2FLLvqI+LI FlsSvIyDhJ3+uMu/X0vyCJmdoyk4aVsKP41TWRyCp5rzDct21M/y5V85+R/dsDx2olyY 37zxE3t3Rvnfc2ScjvmGRyynDooUkOvDfZgTb8QaTGwFXnF0jlrjlaW1SyYJAwa8AOmT GurdRQhOttq4FCKqIiHmptoIxGUvu6R78Sw46kGsbKKEuzvW2QEjG+dWlt0wHqFktkqZ O6T/W9QFec6vyNtCBLnoPgidDY3h/b2djoG7sIRX4onCcwZ+0dvOE5DeKD8YJ450l5P2 w8OQ== X-Forwarded-Encrypted: i=1; AHgh+RrX75xEy1v65Hxw4M8XUSwuvVrp7yHwSZIUekUC94oz880ogy8N2YoH4j7ol0L2efBl1BwbVWOnE5EkHDM=@vger.kernel.org X-Gm-Message-State: AFuF++nHTHvXtMs7RjZQIcHZ1UtYHfNsvOJo3Zm6aQDGSwC16zmbE3zm BpYoZ+/5Y70zsDfiR2T7SgCYkkofVjh2p5D0brrQtaVFEfZlRtivhz4w X-Gm-Gg: AR+sD13OVUJaGPnWy17xH9gTB4mc8yhzZgQbntB7LyNRgCfF/kgB6khVfiXpf7cATDr pDXCYEe5UxnemZNciYjJQ6tHDl7gQerVV1loTOuoWhIA+7nckXsCkHmbKt3sPvAoqSie+JjxZJZ cnqqKO2iWzPTCuBti+g1ZmavpppAhR+kxgR5kugmr3D9uGS4MPB1KUAeRaT+9Dz2WtWRPeZFbZe TzKdzdv+2u2Fi88Bh5WZyLQptgzBCF+GEntSYqlJuQKl5Ek3jNBGwRClkkGS8qNiH8o7JRIeKhs pjO7REqjOBL0VA3qknGfBhlTgoUeVMX9fMVEHQFxbE0usx83bOfx0hPTlTR7KPRs4ZiYez+/NH2 hMF9Z+wQxmm+lNHSUH90zTk7vhEg+VCqoDhj16K/x5z9DrHuOdip96AkcXh9+zoVX7SZS0FlvSN kE1aMj/6hlAdoxTRX7skoLp2Y/6szkLF1b5EtvtehVXa6vt1dxjYuV52rSukC+x+vv5yFgk31rQ xmBuMLRNVot1PUDfkZasaPkQAPRKQrR6mW6lFSZcPBfrC5zV793 X-Received: by 2002:a17:907:7a8e:b0:c16:9043:7973 with SMTP id a640c23a62f3a-c249257c10amr2243253266b.4.1787600902724; Mon, 24 Aug 2026 12:48:22 -0700 (PDT) Received: from localhost.localdomain (46-138-191-2.dynamic.spd-mgts.ru. [46.138.191.2]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c24966f6ad2sm1426659766b.30.2026.08.24.12.48.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 Aug 2026 12:48:22 -0700 (PDT) From: Artem Lytkin To: Alice Ryhl Cc: Lorenzo Stoakes , "Liam R . Howlett" , Danilo Krummrich , Jann Horn , Carlos Llamas , Greg Kroah-Hartman , Daniel Almeida , Deborah Brouwer , linux-mm@kvack.org, rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 1/2] rust_binder: check ownership before using vma Date: Mon, 24 Aug 2026 22:48:08 +0300 Message-ID: <20260824194808.216021-1-iprintercanon@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260218-binder-vma-check-v2-1-60f9d695a990@google.com> References: <20260218-binder-vma-check-v2-1-60f9d695a990@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit On Wed, Feb 18, 2026, Alice Ryhl wrote: > The plan is to introduce more vma > abstractions to avoid this unsafe access to vm_ops and vm_private_data, > but for now let's start with the simplest possible fix. [...] > (We probably still want to do both, but > the vm_ops->close callback will be added later as part of the follow-up > vma API changes.) Alice, is that follow-up still on your list, or would you rather someone else took it? I'd like to add the missing pieces to kernel::mm::virt: a VmOperations trait with open, close and fault, a typed way to install it together with the private data on a VmaNew, a VmFault wrapper, and a PFN-map typestate next to VmaMixedMap with vmf_insert_pfn_prot() on it. Binder would then drop BINDER_VM_OPS and the raw vm_ops pointer compare and get a close callback like the C driver has. Tyr needs the fault and PFN-map half of that for its user MMIO mmap. The first two patches of Collabora's Tyr series are the pgprot_noncached and pgoff helpers; they have had no replies since 7 May, so I'd build on those rather than duplicate them: https://lore.kernel.org/all/20260507-tyr-mmap-v1-0-eec048a23c25@collabora.com/ One design question first, for you and Lorenzo. f_op->mmap is deprecated in favour of mmap_prepare, where a driver sets desc->vm_ops instead of touching the vma, and the Rust side only has the old mmap path today. Should the vm_ops abstraction be built around mmap_prepare from the start, with a Rust mmap_prepare hook for miscdevice next to it, or is landing it on the existing VmaNew an acceptable first step? Artem