lkml.org 
[lkml]   [2003]   [Apr]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: TASK_UNMAPPED_BASE & stack location
From
Date
"Martin J. Bligh" <mbligh@aracnet.com> writes:

>>> Is there any good reason we can't remove TASK_UNMAPPED_BASE, and just
>>> shove libraries directly above the program text? Red Hat seems to have
>>> patches to dynamically tune it on a per-processes basis anyway ...
>>
>> Yes. You won't get a continuous sbrk/brk heap then anymore. Not sure it
>> is a big problem though.
>
> Me no understand. I think this *makes* it a contiguous space. The way I see
> it, we currently allocate from TASK_UNMAPPED_BASE up to the top, then start
> again above program text. Which seems a bit silly.

The space for brk is not completely continuous anymore, especially
when you use mmap() too.

Same with mmap.

Basically mmap() and brk/sbrk (=malloc) will fragment each other.

wli's suggestion of making it a personality makes sense.

> I've moved PAGE_OFFSET around a lot (which moves the stack, as you say).
> Haven't seen it break anything yet ... IMHO it was broken anyway if this
> hurts it. Obviously not something one could do in a stable kernel series,
> but 2.5 seems like a perfect time for it to me ... unless I'm missing some
> glibc / linker thing, it seems like a simple change.

It at least broke Sun Java.

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

\
 
 \ /
  Last update: 2005-03-22 13:35    [W:0.359 / U:0.112 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site