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:   Tue, 17 May 2022 19:44:03 +0300
From:   "Kirill A. Shutemov" <kirill@...temov.name>
To:     Jakub Matěna <matenajakub@...il.com>
Cc:     linux-mm@...ck.org, patches@...ts.linux.dev,
        linux-kernel@...r.kernel.org, vbabka@...e.cz, mhocko@...nel.org,
        mgorman@...hsingularity.net, willy@...radead.org,
        liam.howlett@...cle.com, hughd@...gle.com, riel@...riel.com,
        rostedt@...dmis.org, peterz@...radead.org, david@...hat.com
Subject: Re: [RFC PATCH v3 0/6] Removing limitations of merging anonymous VMAs

On Mon, May 16, 2022 at 02:53:59PM +0200, Jakub Matěna wrote:
> This is a series of patches that try to improve merge success rate when
> VMAs are being moved, resized or otherwise modified.
> 
> Motivation
> In the current kernel it is impossible to merge two anonymous VMAs
> if one of them was moved. That is because VMA's page offset is
> set according to the virtual address where it was created and in
> order to merge two VMAs page offsets need to follow up.
> Another problem when merging two faulted VMA's is their anon_vma. In
> current kernel these anon_vmas have to be the one and the same.
> Otherwise merge is again not allowed.
> There are several places from which vma_merge() is called and therefore
> several use cases that might profit from this upgrade. These include
> mmap (that fills a hole between two VMAs), mremap (that moves VMA next
> to another one or again perfectly fills a hole), mprotect (that modifies
> protection and allows merging with a neighbor) and brk (that expands VMA
> so that it is adjacent to a neighbor).
> Missed merge opportunities increase the number of VMAs of a process
> and in some cases can cause problems when a max count is reached.

Hm. You are talking about missed opportunities, but do you know any
workload that would measurably benefit from the change?

The changes are not trivial. And rmap code is complex enough as it is.

I expect common cases to get slower due to additional checks that do not
result in more merges. I donno, the effort looks dubious to me as of now.

-- 
 Kirill A. Shutemov

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ