On Thu, Dec 5, 2024 at 11:45 AM Lorenzo Stoakes <lorenzo.stoakes@xxxxxxxxxx> wrote: > > On Thu, Dec 05, 2024 at 11:40:03AM +0100, Alice Ryhl wrote: > > On Fri, Nov 29, 2024 at 5:32 PM Alice Ryhl <aliceryhl@xxxxxxxxxx> wrote: > > > > > > This adds a type called VmAreaRef which is used when referencing a vma > > > that you have read access to. Here, read access means that you hold > > > either the mmap read lock or the vma read lock (or stronger). > > > > > > Additionally, a vma_lookup method is added to the mmap read guard, which > > > enables you to obtain a &VmAreaRef in safe Rust code. > > > > > > This patch only provides a way to lock the mmap read lock, but a > > > follow-up patch also provides a way to just lock the vma read lock. > > > > > > Acked-by: Lorenzo Stoakes <lorenzo.stoakes@xxxxxxxxxx> (for mm bits) > > > Reviewed-by: Jann Horn <jannh@xxxxxxxxxx> > > > Signed-off-by: Alice Ryhl <aliceryhl@xxxxxxxxxx> > > > > It looks like binder needs a way to check whether a given vma is > > associated with a given mm. I guess we can do that by adding a method > > to VmAreaRef that returns a &MmWithUser. > > Presumably this would be with a lock held to ensure the VMA doesn't > disappear from under us? > > I guess that's implied by possessing a VmAreaRef in the first place. > > I also suppoes that the mm having users is implied by you having the VMA > that implies a lock held on it :) That was what I was thinking. > So that's probably fine then, as long as you can implement some sensible > means of comparison between a known 'given mm' vs. the &MmWithUser. We can use the stdlib function core::ptr::eq to compare the address. Alice
