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: <20171023114210.j7ip75ewoy2tiqs4@dhcp22.suse.cz>
Date:   Mon, 23 Oct 2017 13:42:10 +0200
From:   Michal Hocko <mhocko@...nel.org>
To:     Mike Kravetz <mike.kravetz@...cle.com>
Cc:     "C.Wehrmeyer" <c.wehrmeyer@....de>, 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 Fri 20-10-17 15:42:25, Mike Kravetz wrote:
> On 10/19/2017 12:34 AM, C.Wehrmeyer wrote:
[...]
> > As for the specific use case: I've written my own allocator that is
> > not bound on the same limitations that usual malloc/realloc/free
> > allocators are bound. As such I want to be able to eliminate as many
> > page walks as possible.
> >
> > Just excepting the limitation would put Linux down on the same level
> > as the Windows API, where no VirtualRealloc exists. My allocator
> > needs to work with Linux and Windows; for the latter one I'm already
> > managing a table of consecutive mappings in user-space that, if
> > a relocation has to be made, creates an entirely new mapping
> > into which the data of the previous mappings is copied. This is
> > redundant, because the kernel and the process keep their own copies
> > of the mapping table, and this is slow because the kernel could just
> > re-adjust the position within the address space, whereas the process
> > has to memcpy all the data from the old to the new mappings.
> >
> > Those are the very problems mremap was supposed to remove in the
> > first place. Making the limitation documented is the lazy way that
> > will force implementers to workaround it.
> 
> mremap has never supported moving or growing hugetlb mappings.  Someone
> (before git history) added this explicit check to the mremap code.  Perhaps
> it was done when huge page support was introduced?

yes, that is the case.
 
> I am of the opinion that we should simply document this limitation.  AFAIK,
> this this the first time anyone has asked about it in 15 years.  What is the
> opinion of others?

I do not remember any such a request either. I can see some merit in the
described use case. It is not specific on why hugetlb pages are used for
the allocator memory because that comes with it own issues. If somebody
is really thrilled enough to implement this the remapping feature for
hugetlb I wouldn't be opposed as long as the implementation is clean and
wouldn't add an additional mess to the code base. I suspect that the vma
enlarging might be a hard deal. Anyway starting with a documentation
update sounds like a good thing anyway. In any case such a feature will
be available only for new kernels so people should be aware of the state
on older kernels.

-- 
Michal Hocko
SUSE Labs