linux-kernel - [QUESTION] about the maple tree and current status of mmap

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-Id: <EC51CFA7-2BC8-4F72-A7D4-3B1A778EDB37@gmail.com>
Date:   Wed, 28 Dec 2022 21:48:51 +0900
From:   Hyeonggon Yoo <42.hyeyoo@...il.com>
To:     linux-mm@...ck.org, liam.howlett@...cle.com, willy@...radead.org,
        surenb@...gle.com, ldufour@...ux.ibm.com, michel@...pinasse.org,
        vbabka@...e.cz, linux-kernel@...r.kernel.org
Subject: [QUESTION] about the maple tree and current status of mmap_lock scalability

Hello mm folks,

I have a few questions about the current status of mmap_lock scalability.

=============================================================
What is currently causing the kernel to use mmap_lock to protect the maple tree?
=============================================================

I understand that the long-term goal is to remove the need for mmap_lock in readers
while traversing the maple tree, using techniques such as RCU or SPF.
What is the biggest obstacle preventing this from being achieved at this time?

==================================================
How does the maple tree provide RCU-safe manipulation of VMAs?
==================================================

Is it similar to the approach suggested in the RCUVM paper (replacing the original
root node with a new root node that shares most of its nodes and deferring
the freeing of stale nodes using RCU)?

I'm having difficulty understanding the design of the maple tree in this regard.

[RCUVM paper] https://pdos.csail.mit.edu/papers/rcuvm:asplos12.pdf

Thank you for your time.

---
Hyeonggon