linux-kernel - Re: [patch 2/3] MAP_NOZERO

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: <Pine.LNX.4.64.0706271309500.26951@blonde.wat.veritas.com>
Date:	Wed, 27 Jun 2007 13:32:35 +0100 (BST)
From:	Hugh Dickins <hugh@...itas.com>
To:	Ulrich Drepper <drepper@...il.com>
cc:	Davide Libenzi <davidel@...ilserver.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [patch 2/3] MAP_NOZERO - implement sys_brk2()

On Tue, 26 Jun 2007, Ulrich Drepper wrote:
> On 6/26/07, Davide Libenzi <davidel@...ilserver.org> wrote:
> 
> > OTOH glibc could implement __morecore using mmap(MAP_NOZERO), and hence
> > brk2() would not be needed, no?
> 
> No.  mmap calls create individual VMAs which gets expensive.  There
> are also some hardware drivers which get more expensive the more VMAs
> there are.  I want to go away as much as possible from mmap for
> malloc.

Not so: if an mmap can be done by extending either adjacent vma (prot
and flags and file and offset all match up), that's what's done and no
separate vma is created.  (And adjacent vmas get merged when mprotect
removes the difference in protection.)

I don't think there's any such reason to prefer brk to mmap.  But you
may have encountered something which we in the kernel are thinking of
as an insignificant corner case, which is actually breaking things up
badly in practice (I recall the kernel's internal VM_ACCOUNT flag,
relating to non-overcommit accounting, which might get turned on at
any time, sometimes preventing a vma merge you'd otherwise expect).
Please let me know if you've a test case which shows more vmas than
expected.

Hugh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/