On Fri, Nov 8, 2024 at 8:01 PM Jann Horn <jannh@xxxxxxxxxx> wrote: > On Thu, Oct 10, 2024 at 2:56 PM Alice Ryhl <aliceryhl@xxxxxxxxxx> wrote: > > These abstractions allow you to manipulate vmas. Rust Binder will uses > > these in a few different ways. > > > > In the mmap implementation, a VmAreaNew will be provided to the mmap > > call which allows it to modify the vma in ways that are only okay during > > initial setup. This is the case where the most methods are available. > > > > However, Rust Binder needs to insert and remove pages from the vma as > > time passes. When incoming messages arrive, pages may need to be > > inserted if space is missing, and in this case that is done by using a > > stashed ARef<Mm> and calling mmget_not_zero followed by mmap_write_lock > > followed by vma_lookup followed by vm_insert_page. In this case, since > > mmap_write_lock is used, the VmAreaMut type will be in use. > > FYI, the way the C binder implementation uses vma_lookup() and > vm_insert_page() is not very idiomatic. The standard way of > implementing binder_alloc_free_page() would be to use something like > unmap_mapping_range() instead of using > vma_lookup()+zap_page_range_single(); though to set that up, you'd > have to create one inode per binder file, maybe with something like > the DRM subsystem's drm_fs_inode_new(). And instead of having > binder_install_single_page(), the standard way would be to let > binder_vm_fault() install PTEs lazily on fault. That way you'd never > have to take mmap locks or grab MM references yourself. Let me know if you think it would be helpful to see a prototype of that in C - I think I can cobble that together, but doing it nicely will require some work to convert at least some of the binder_alloc locking to mutexes, and some more work to switch the ->f_mapping of the binder file or something like that. (I guess modeling that in Rust might be a bit of a pain though...)
