linux-kernel - Re: Very slow unlockall()

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]

Date:   Wed, 10 Feb 2021 18:40:57 +0100
From:   Michal Hocko <mhocko@...e.com>
To:     Vlastimil Babka <vbabka@...e.cz>
Cc:     Milan Broz <gmazyland@...il.com>, linux-mm@...ck.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Mikulas Patocka <mpatocka@...hat.com>
Subject: Re: Very slow unlockall()

On Wed 10-02-21 17:57:29, Michal Hocko wrote:
> On Wed 10-02-21 16:18:50, Vlastimil Babka wrote:
[...]
> > And the munlock (munlock_vma_pages_range()) is slow, because it uses
> > follow_page_mask() in a loop incrementing addresses by PAGE_SIZE, so that's
> > always traversing all levels of page tables from scratch. Funnily enough,
> > speeding this up was my first linux-mm series years ago. But the speedup only
> > works if pte's are present, which is not the case for unpopulated PROT_NONE
> > areas. That use case was unexpected back then. We should probably convert this
> > code to a proper page table walk. If there are large areas with unpopulated pmd
> > entries (or even higher levels) we would traverse them very quickly.
> 
> Yes, this is a good idea. I suspect it will be little bit tricky without
> duplicating a large part of gup page table walker.

Thinking about it some more, unmap_page_range would be a better model
for this operation.
-- 
Michal Hocko
SUSE Labs