linux-kernel - Re: [PATCH 4.4 131/160] mm: thp: relax __GFP_THISNODE 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]

Date:   Mon, 19 Nov 2018 14:16:24 -0800 (PST)
From:   David Rientjes <rientjes@...gle.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
cc:     linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        Andrea Arcangeli <aarcange@...hat.com>,
        Michal Hocko <mhocko@...e.com>,
        Stefan Priebe <s.priebe@...fihost.ag>,
        Alex Williamson <alex.williamson@...hat.com>,
        Mel Gorman <mgorman@...hsingularity.net>,
        Zi Yan <zi.yan@...rutgers.edu>,
        Vlastimil Babka <vbabka@...e.cz>,
        "Kirill A. Shutemov" <kirill@...temov.name>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH 4.4 131/160] mm: thp: relax __GFP_THISNODE for MADV_HUGEPAGE
 mappings

On Mon, 19 Nov 2018, Greg Kroah-Hartman wrote:

> 4.4-stable review patch.  If anyone has any objections, please let me know.
> 

As I noted when this patch was originally proposed and when I nacked it[*] 
because it causes a 13.9% increase in remote memory access latency and up 
to 40% increase in remote memory allocation latency on much of our 
software stack that uses MADV_HUGEPAGE after mremapping the text segment 
to memory backed by hugepages, I don't think this is stable material.

The 4.4 kernel is almost three years old and this changes the NUMA 
locality of any user of MADV_HUGEPAGE.

Although the page was merged even after my objection, we must revert it in 
our own kernel because there is no userspace workaround to restore the 
behavior previous to this patch absent using an MPOL_BIND mempolicy which 
would have unwanted side effect of oom killing if the node is out of 
memory for pages of the native size, which would be a non-starter.

 [*] https://marc.info/?l=linux-kernel&m=153868420126775