Re: [PATCH v3 1/5] mm: Make per-VMA locks available universally
"Lorenzo Stoakes (ARM)" <[email protected]> Tue, 4 Aug 2026 09:56:34 +0100
| Newsgroups | gmane.linux.network,gmane.linux.kernel,gmane.linux.kernel.mm |
|---|---|
| Message-ID | <anGnOHgOd1q1jYXK@lucifer> |
On Mon, Aug 03, 2026 at 11:12:01PM +0200, Jann Horn wrote: > On Mon, Aug 3, 2026 at 6:08 PM Lorenzo Stoakes (ARM) <[email protected]> wrote: > > On Mon, Aug 03, 2026 at 08:24:44AM -0700, Suren Baghdasaryan wrote: > > > On Sun, Aug 2, 2026 at 2:55 PM Suren Baghdasaryan <[email protected]> wrote: > > > > -#endif /* CONFIG_PER_VMA_LOCK */ > > > > > > Now that I'm looking closer into this, I think we would break NOMMU > > > case because nommu.c does not take VMA write locks at all. So, > > > lock_vma_under_rcu() for example would always succeed. > > > > I don't think anything's broken actually. > > > > Per-VMA locks was gated on CONFIG_MMU so nothing there assumes per-VMA flags, > > but now you have stuff that happens that didn't before but: > > > > * vm_area_free() -> vma_assert_detached() - fine - it's always detached in nommu. > > I don't think that's true, AFAICS vma_mark_attached() is called from > vma_iter_store_new() which is called from the nommu version of > do_mmap(). But I think you're right that one blunt workaround for this > would be to add a hack that prevents ever marking VMAs in nommu as > attached... Thanks Jann, though also ugh god at that :) (Really the ideal solution for nommu would be a 'virtual' MMU with noops for everything IMO.) Anyway, I think we could fix this with a: static inline void vma_mark_attached(struct vm_area_struct *vma) { + if (!IS_ENBLED(CONFIG_MMU)) + return; vma_assert_write_locked(vma); vma_assert_detached(vma); refcount_set_release(&vma->vm_refcnt, 1); } Here? > > > * vm_area_dup() -> vma_lock_init() - no asserts, just sets refcount to 0 (correct).