Re: heap-stack-gap for 2.6

[Arjan van de Ven <arjanv@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2564 bytes --]

On Wed, Sep 29, 2004 at 04:11:51PM +0200, Andrea Arcangeli wrote:
> On Wed, Sep 29, 2004 at 08:05:21AM +0200, Arjan van de Ven wrote:
> > oh? you mean that 1Mb gap between stack and topdown? Every ISV I talked to
> > said they could get more VA space with topdown than with the suse
> > mmaped_base hack... :)
> 
> /*
>  * Top of mmap area (just below the process stack).
>  *
>  * Leave an at least ~128 MB hole.
>  */
> #define MIN_GAP (128*1024*1024)
> #define MAX_GAP (TASK_SIZE/6*5)
> 
> where does your 1M comes from? it's a minimum 128Mbytes.

the patch posted recently on this list reduced it to 1Mb.

> > MAP_FIXED is to be used only on things YOU mmaped before. 
> 
> where is that written?

it's basic common sence 

> > wrong; brk() is there which is also used by malloc() and internally by the C
> > library.
> 
> that's malloc, but mmaps don't fit into it.

MAP_FIXED happily will go over an malloc(), it's both just vma's


> > do you have proof for that?
> 
> do I need to write the exploited testcase? just let me know, it'll take
> only a few minutes.

your claim was that existing apps would break.
I know you can write a testcase, one can write a testcase even for your
proposed patch showing breakage.

> small malloc works below the 1G area, but it's the application that has
> to use malloc. 

the application, the C library, the dynamic linker, all shared libs it links
against.

> now the best thing is the ADDR_COMPAT_LAYOUT personality, that is what
> can make it safe, and I hope it's enabled by default on all apps, but
> I'm afraid it's the other way around, i.e. that the application will be
> marked "compatible" after it breaks at runtime. Plus the testing will be
> decreased since most people runs with unlimited stack (which defaults to
> bottomup beahviour).

You are wrong; the default is 8Mb stack limit in the kernel; I absolutely do
not see where you claim from "most people run with unlimited stack" comes
from.

> the single fact you added ADDR_COMPAT_LAYOUT means you're very well
> aware there are apps that will break, or there would be no point for a
> "COMPAT" option, if it was really backwards compatible by default, or do
> I misunderstand the semantics of ADDR_COMPAT_LAYOUT personality?

I am aware of 2 applications breaking. Both did

int ptr;

ptr=malloc(bigchunk);
if (ptr < 0)
	assume_alloc_failure();

Both are open source and since long fixed. Still it made sense to add a
safety net (akpm asked for it; for example in rhel3 or FC2 we do not have one at
all, nor do those kernels have mmaped_base hack). 

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]