linux-kernel - Re: PROBLEM: Remapping hugepages mappings causes kernel to return EINVAL

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: <64606243-e770-f5f6-e9dc-6495ce1cb0bd@gmx.de>
Date:   Tue, 24 Oct 2017 10:09:19 +0200
From:   "C.Wehrmeyer" <c.wehrmeyer@....de>
To:     Mike Kravetz <mike.kravetz@...cle.com>
Cc:     Michal Hocko <mhocko@...nel.org>, linux-mm@...ck.org,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Andrea Arcangeli <aarcange@...hat.com>,
        "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        Vlastimil Babka <vbabka@...e.cz>
Subject: Re: PROBLEM: Remapping hugepages mappings causes kernel to return
 EINVAL

On 2017-10-23 20:51, Mike Kravetz wrote:
 > [...]
> Well at least this has a built in fall back mechanism.  When using hugetlb(fs)
> pages, you would need to handle the case where mremap fails due to lack of
> configured huge pages.

You're missing the point. I never asked for a fall-back mechanism, even 
though it certainly has its use cases. It just isn't mine. In such a 
situation it wouldn't be hard to detect if the user requested huger 
pages, and then fall back to a smaller size. The only difference is that 
I'd have to implement it myself.

But all of that does not change the fact that it's not transparent.

> I assume your allocator will be for somewhat general application usage.

Define "general purpose" first. The allocator itself isn't transparent 
to typical malloc/realloc/free-based approaches, and it isn't so very 
deliberately.

> Yet,
> for the most reliability the user/admin will need to know at boot time how
> many huge pages will be needed and set that up.
That's what I'm trying to argue. With how much memory were typical 386s 
equipped back then? 16 MiBs? With a page size of 4 KiBs that leaves 4096 
pages to map the entirety of RAM.

My current testing box has 8 GiBs. If I were to map the entirety of my 
RAM with 2-MiB pages that would still require 4096 pages. Did anyone set 
up pages pools with Linux in the 90s? Did anyone complain that 4096 
bytes are too much of a page size to effectively use memory?