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 :) 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. > > This indicates that vma->vm_mm references an mm with non-zero mm_users > whenever it's legal to have a reference to the vma. > > Alice
