Re: Subtle MM bug (really 830MB barrier question)

[Wayne Whitney]

On Tue, 9 Jan 2001, Szabolcs Szakacsits wrote:

> 3) ask kernel developers to get rid of this "brk hits the fixed start
> address of mmapped areas" or the other way around complaints "mmapped
> area should start at lower address" limitation. E.g. Solaris does
> growing up heap, growing down mmap and fixed size stack at the top.

OK, despite knowing nothing of the kernel internals, I looked at doing
this myself :-)

I notice that TASK_UNMAPPED_BASE is only used in get_unmapped_area() in
mm/mmap.c, which is encouraging.  Moreover, get_unmapped_area() is only
called once in mm/mmap.c and once in mm/mremap.c.  So I think I would only
have to change get_unmapped_area() to get the desired effect, and this
change should not affect anything else.

If no address is specified, get_unmapped_area() currently chooses the
first (large enough, unused) region above TASK_UNMAPPED_BASE.  I guess I
would just have to define something like TASK_UNMAPPED_CEILING and arrange
for get_unmapped_area() to allocate the first region below
TASK_UNMAPPED_CEILING.  And I guess TASK_UNMAPPED_CEILING should equal
TASK_SIZE - maximum stack size.  What is the maximum stack size?  I
couldn't quite figure this out myself.

Am I missing something, or should choosing an appropriate value for
TASK_UNMAPPED_CEILING and changing get_unmapped_area() be sufficient?

Cheers,
Wayne