linux-kernel - Re: [PATCH] deflate inflate

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:	Mon, 07 May 2007 13:29:22 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	"H. Peter Anvin" <hpa@...or.com>
CC:	Andrew Morton <akpm@...ux-foundation.org>, Andi Kleen <ak@...e.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Matt Mackall <mpm@...enic.com>
Subject: Re: [PATCH] deflate inflate_dynamic too

H. Peter Anvin wrote:
> It might be worth reverting some of the code back to the zlib original.
>  The use of stack allocations here is actually a Linux divergence from
> zlib (done by Linus), in order to reduce the number of dynamic allocations.
>
> In general, the use of dynamic allocations is highly dangerous, because
> any time you have dynamic allocations you have the choice of either
> sleeping or failing, unless you have a pre-reserved memory pool.
>   

Well, every time this code is instantiated, it gets its own malloc/free
definitions, so they can decide how to handle the dynamic allocations. 
Seems better than assuming that every caller will have enough stack
space.  If you want to approximate that, it would be easy enough to have
a stack-like malloc/free, in which freeing the last allocation will
always release space.

    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/