linux-kernel - Re: [PATCH v6 7/8] fs/proc/task_mmu: read proc/pid/maps under per-vma lock

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f60a932f-71c0-448f-9434-547caa630b72@suse.cz>
Date: Wed, 9 Jul 2025 10:57:47 +0200
From: Vlastimil Babka <vbabka@...e.cz>
To: Suren Baghdasaryan <surenb@...gle.com>,
 Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: akpm@...ux-foundation.org, Liam.Howlett@...cle.com, david@...hat.com,
 peterx@...hat.com, jannh@...gle.com, hannes@...xchg.org, mhocko@...nel.org,
 paulmck@...nel.org, shuah@...nel.org, adobriyan@...il.com,
 brauner@...nel.org, josef@...icpanda.com, yebin10@...wei.com,
 linux@...ssschuh.net, willy@...radead.org, osalvador@...e.de,
 andrii@...nel.org, ryan.roberts@....com, christophe.leroy@...roup.eu,
 tjmercier@...gle.com, kaleshsingh@...gle.com, aha310510@...il.com,
 linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
 linux-mm@...ck.org, linux-kselftest@...r.kernel.org
Subject: Re: [PATCH v6 7/8] fs/proc/task_mmu: read proc/pid/maps under per-vma
 lock

On 7/8/25 01:10, Suren Baghdasaryan wrote:
>>> +     rcu_read_unlock();
>>> +     vma = lock_vma_under_mmap_lock(mm, iter, address);
>>> +     rcu_read_lock();
>> OK I guess we hold the RCU lock the whole time as we traverse except when
>> we lock under mmap lock.
> Correct.

I wonder if it's really necessary? Can't it be done just inside
lock_next_vma()? It would also avoid the unlock/lock dance quoted above.

Even if we later manage to extend this approach to smaps and employ rcu
locking to traverse the page tables, I'd think it's best to separate and
fine-grain the rcu lock usage for vma iterator and page tables, if only to
avoid too long time under the lock.