>>     ...
>>     bdc00000-bfa00000 ---p 00000000 00:00 0       [ stack ]
>>     bfa00000-bfbe0000 rwxp 00000000 00:00 0       [ stack ]
>>     bfbe0000-bfbf0000 rwxp 00000000 00:00 0       [ stack ]
>>     bfbf0000-bfc00000 rwxp 00000000 00:00 0       [ stack ]
>> 
>> and as you can plainly, see, there is only one area now, [3], into
>> which either of them can grow.  this means (or will mean, ultimately),
>> that your heap can grow larger, or you can mmap() larger objects.
>
>but now, the stack can't grow any longer beyond the first mmap()ed 
>region, right?

the short answer is "we always (and still do) reserve space for the
stack up to the hard limit, but we never could (and now can't) extend
the stack beyond the hard limit".

the long answer goes more like this (using elf as an example).

(1) at exec time, the kernel maps two chunks of stack space, one to
cover the soft stack limit (the "soft" chunk), and one to cover the
difference between that and the hard limit (the "hard" chunk).

(2) as the exec completes and the new process gets its arguments
copied into the top of it's stack, a fault is incurred, which gets
resolved by a 16 slot amap (see UVM_AMAP_CHUNK in uvm/uvm_amap.h)
being attached to a small map entry that gets carved off the "soft"
chunk.

(3) later use of the stack (while the process is running) incurs
another fault, resulting it another chunk being carved off the "soft"
chunk and making another map entry.

the four regions listed above are (in order), the "hard" chunk, the
remainder of the "soft" chunk, and the two separately faulted pieces.
the maximum size of the stack wasn't affected by the topdown stuff.
if you wanna change MAXSSIZ (by putting it in your kernel config or
something), everything should simply shift appropriately.

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
werdna@squooshy.com       * "information is power -- share the wealth."