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]

Date:	Wed, 27 Jun 2007 10:01:46 -0700
From:	"Ulrich Drepper" <drepper@...il.com>
To:	"Hugh Dickins" <hugh@...itas.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 6/27/07, Hugh Dickins <hugh@...itas.com> wrote:
> 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.)

mmap return values are randomized.  If they would be mergable
something would be wrong.

> I don't think there's any such reason to prefer brk to mmap.

Talk to the Quadrics people.  Some of their interconnect adapters
incur significant costs with separate VMAs.

> Please let me know if you've a test case which shows more vmas than
> expected.

Not related to this, but we already have "too many" VMAs for some
definition of "too many".  Since we split VMA when the protection
changes each thread stack consists at least of two VMA (three for
ia64).  There was an approach at some point to push the access flags
down and allow VMAs to stretch further.  Why was this deemed
unsuitable?  It could have quite a bit with situations with many
threads (Java).  As I've told back when this came up, we had one
customer where the VMA lookup actually showed up in profiles.
-
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/