linux-kernel - Re: [RFC PATCH] mm: align anon mmap for THP

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: <MWHPR06MB2896124A4B2B7C9F38383817EE800@MWHPR06MB2896.namprd06.prod.outlook.com>
Date:   Mon, 14 Jan 2019 16:40:16 +0000
From:   "Harrosh, Boaz" <Boaz.Harrosh@...app.com>
To:     Steven Sistare <steven.sistare@...cle.com>,
        Mike Kravetz <mike.kravetz@...cle.com>,
        "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        "linux_lkml_grp@...cle.com" <linux_lkml_grp@...cle.com>
CC:     "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Hugh Dickins <hughd@...gle.com>,
        Michal Hocko <mhocko@...nel.org>,
        Dan Williams <dan.j.williams@...el.com>,
        Matthew Wilcox <willy@...radead.org>,
        Toshi Kani <toshi.kani@....com>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [RFC PATCH] mm: align anon mmap for THP

Sistare <steven.sistare@...cle.com> wrote:
> 
> A better heuristic would be to return an aligned address if the length
> is a multiple of the huge page size.  The gap (if any) between the end of
> the previous VMA and the start of this VMA would be filled by subsequent
> smaller mmap requests.  The new behavior would need to become part of the
> mmap interface definition so apps can rely on it and omit their hoop-jumping
> code.
> 

Yes that was my original request

> Personally I would like to see a new MAP_ALIGN flag and treat the addr
> argument as the alignment (like Solaris), 

Yes I would like that. So app can know when to do the old thing ...

> but I am told that adding flags
> is problematic because old kernels accept undefined flag bits from userland
> without complaint, so their behavior would change.
> 

There is already a mechanism in place since 4.14 I think or even before on
how to add new MMAP_XXX flags. This is done by combining MMAP_SHARED & MMAP_PRIVATE
flags together with the new set of flags. If there are present new flags this is allowed and means
requesting some new flag. Else and in old Kernels the combination above is not allowed in POSIX
and would fail in old Kernels.

Cheers
Boaz

> - Steve