linux-kernel - Re: Latest brk patchset

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: <49BC9A3B.1070908@goop.org>
Date:	Sat, 14 Mar 2009 23:03:39 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	"H. Peter Anvin" <hpa@...or.com>
CC:	Yinghai Lu <yinghai@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Latest brk patchset

H. Peter Anvin wrote:
> On this subject, what is the point of the 64 K "slop space", and if it
> is necessary, why not just put it as a RESERVE_BRK() somewhere (*with* a
>  significant comment as to its necessity) instead of putting it as a
> hack in the linker script?
>   

Specifically, its to deal with space taken by alignment constraints.  At 
least some of the extend_brk() calls are page aligned, so that uses up 
to another 4k.  There are other ways to deal with it (pass an alignment 
to RESERVE_BRK and have it add it into the total, or just assume the 
user knows to include alignment overheads), but it seemed more 
straightforward to add some padding in the linker script.  After all, 
anything unused will get freed.  (But, yes, it could probably be 
documented as such, and 64k is a somewhat arbitrary number.)

    J
--
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/