Re: [PATCH v3 1/5] mm: Make per-VMA locks available universally

Suren Baghdasaryan <[email protected]>
Newsgroups gmane.linux.kernel,gmane.linux.kernel.mm,gmane.linux.network
Message-ID <CAJuCfpFCBr127TJEWvanRtYxM2G21h-Y5NYK_hw9y0CrgWQF5g@mail.gmail.com>
On Tue, Aug 4, 2026 at 1:56 AM Lorenzo Stoakes (ARM) <[email protected]> wrote:
>
> 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?

Yes, I think so.
I also need to make sure mmap_lock fallbacks we are removing are not
used in NOMMU, otherwise it will fail to lock_vma_under_rcu() and will
have no fallbacks.
TCP zerocopy and binder are gated on CONFIG_MMU, so that's fine. Need
to check the BPF part...


>
> >
> > > * vm_area_dup() -> vma_lock_init() - no asserts, just sets refcount to 0 (correct).
>
> --
> Cheers, Lorenzo
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.