linux-kernel - Re: [PATCH v3] mm: use per_vma lock for MADV

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6895af5a-ffc7-4d87-a88b-0ef3914e3572@lucifer.local>
Date: Sat, 7 Jun 2025 07:36:02 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Matthew Wilcox <willy@...radead.org>
Cc: Barry Song <21cnbao@...il.com>, akpm@...ux-foundation.org,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        Barry Song <v-songbaohua@...o.com>,
        "Liam R. Howlett" <Liam.Howlett@...cle.com>,
        David Hildenbrand <david@...hat.com>, Vlastimil Babka <vbabka@...e.cz>,
        Jann Horn <jannh@...gle.com>, Suren Baghdasaryan <surenb@...gle.com>,
        Lokesh Gidra <lokeshgidra@...gle.com>,
        Tangquan Zheng <zhengtangquan@...o.com>,
        Qi Zheng <zhengqi.arch@...edance.com>
Subject: Re: [PATCH v3] mm: use per_vma lock for MADV_DONTNEED

On Sat, Jun 07, 2025 at 05:04:58AM +0100, Matthew Wilcox wrote:
> On Sat, Jun 07, 2025 at 12:46:23PM +1200, Barry Song wrote:
> > To simplify handling, the implementation falls back to the standard
> > mmap_lock if userfaultfd is enabled on the VMA, avoiding the complexity of
> > userfaultfd_remove().
>
> This feels too complex to me.  Why do we defer grabbing the vma lock
> so late, instead of grabbing it at the start like the fault handler does?
>

The VMA lock is at the granularity of VMAs, so we grab it at the point we look
at VMAs.

The other locks are at the granularity of the virtual address space so we grab
them then.

Doing anything else either results in horrible hacks where we have to grab a
VMA, stash it in some state somewhere and pick it up later (and hope we never
screw up with a dangling ptr etc.), or inserting horrible a horrible if () { /*
duplicated code */ } block.

In future we probably want to look at 'grabbing a bunch of VMAs by RCU', but it
felt prudent to implement this for a single VMA at a time.

Also doing it this way allows for us being able to neatly fall back to an mmap
read lock if a VMA lock could not be acquired for whatever reason.