From: Alice Ryhl <aliceryhl@google.com>
To: Artem Lytkin <iprintercanon@gmail.com>
Cc: Lorenzo Stoakes <ljs@kernel.org>,
"Liam R . Howlett" <liam@infradead.org>,
Danilo Krummrich <dakr@kernel.org>, Jann Horn <jannh@google.com>,
Carlos Llamas <cmllamas@google.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Daniel Almeida <daniel.almeida@collabora.com>,
Deborah Brouwer <deborah.brouwer@collabora.com>,
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: Tue, 25 Aug 2026 07:32:15 +0000 [thread overview]
Message-ID: <ao1E_6yo9hE17e2E@google.com> (raw)
In-Reply-To: <20260824194808.216021-1-iprintercanon@gmail.com>
On Mon, Aug 24, 2026 at 10:48:08PM +0300, Artem Lytkin wrote:
> 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/
I have a draft for the vm_open callback somewhere and it's still on my
todo-list, but I'm not actively working on it right now. I'd be happy to
let someone else work on it, but it's somewhat nontrivial, so perhaps we
should have a call to discuss the design to work out the details?
> 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?
Lorenzo, where can I learn more about this new mmap_prepare API? What
are the main differences?
Alice
next prev parent reply other threads:[~2026-08-25 7:32 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-18 11:53 [PATCH v2 0/2] Fix VMA confusion in Rust Binder Alice Ryhl
2026-02-18 11:53 ` [PATCH v2 1/2] rust_binder: check ownership before using vma Alice Ryhl
2026-02-18 13:47 ` Danilo Krummrich
2026-02-18 15:54 ` Liam R. Howlett
2026-02-18 16:39 ` Alice Ryhl
2026-03-02 17:18 ` Carlos Llamas
2026-03-02 17:28 ` Jann Horn
2026-03-02 18:36 ` Carlos Llamas
2026-08-24 19:48 ` Artem Lytkin
2026-08-24 20:55 ` Lorenzo Stoakes (ARM)
2026-08-25 7:32 ` Alice Ryhl [this message]
2026-08-25 9:24 ` Artem Lytkin
2026-08-25 10:44 ` Lorenzo Stoakes (ARM)
2026-02-18 11:53 ` [PATCH v2 2/2] rust_binder: avoid reading the written value in offsets array Alice Ryhl
2026-02-18 16:02 ` Liam R. Howlett
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=ao1E_6yo9hE17e2E@google.com \
--to=aliceryhl@google.com \
--cc=cmllamas@google.com \
--cc=dakr@kernel.org \
--cc=daniel.almeida@collabora.com \
--cc=deborah.brouwer@collabora.com \
--cc=gregkh@linuxfoundation.org \
--cc=iprintercanon@gmail.com \
--cc=jannh@google.com \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
/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