The Linux Kernel Mailing List
 help / color / mirror / Atom feed
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

  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