* Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> [240606 14:09]: ... > > > Liam, any objections to this? The whole point of this patch set is to > > > add a new API, not all the CONFIG_PER_VMA_LOCK gotchas. My > > > implementation is structured in a way that should be easily amenable > > > to CONFIG_PER_VMA_LOCK changes, but if there are a few more subtle > > > things that need to be figured for existing text-based > > > /proc/<pid>/maps anyways, I think it would be best to use mmap_lock > > > for now for this new API, and then adopt the same final > > > CONFIG_PER_VMA_LOCK-aware solution. > > > > The reason I was hoping to have the new interface use the per-vma > > locking from the start is to ensure the guarantees that we provide to > > the users would not change. We'd also avoid shifting to yet another > > mmap_lock users. > > > > Yep, it's completely understandable. And you see that I changed the > structure quite a lot to abstract away mmap_lock vs vm_lock details. > I'm afraid anon_vma_name() is quite an obstacle, unfortunately, and > seems like it should be addressed first, but I'm just not qualified > enough to do this. > > > I also didn't think it would complicate your series too much, so I > > understand why you want to revert to the old locking semantics. I'm > > fine with you continuing with the series on the old lock. Thanks for > > trying to make this work. > > > > I'm happy to keep the existing structure of the code, and > (intentionally) all the CONFIG_PER_VMA_LOCK logic is in separate > patches, so it's easy to do. I'd love to help adopt a per-VMA lock > once all the pieces are figured out. Hopefully anon_vma_name() is the > last one remaining :) So please keep me cc'ed on relevant patches. > > As I mentioned, I just don't feel like I would be able to solve the > anon_vma_name() problem, but of course I wouldn't want to be > completely blocked by it as well. > Absolutely. Thanks for trying. To be clear, I'm fine with you dropping the per-vma locking from this interface as well. Thanks, Liam
