>> since the permissions of the stack changed (from rwx to rw- when we
>> got the w^x code), there's a greater possibility of things getting
>> merged with the stack (the merge code is eager to merge stuff that can
>> be merged), but with the way that stack faults (ie, attempts to write
>> to unmapped pages) are handled, attempting to write to something at
>> the "top" (ie, the lowest address) of the stack, not incurring page
>> faults in an orderly manner makes you die.
>> 
>> enami-san, your change makes sense in a general case, which handles
>> running up against the header entry in the circular list much more
>> sensible, but there's still the "merge with stack" problem.
>
>What my patch solves is that it prevents uvm_map_findspace() from
>returning not a free free as a free space.  "merge with stack" is a
>different matter (just a trigger of bug in this case), and I don't
>think it is a problem.

whether it's a problem or not is a problem in and of itself.  no one
can say.  i think it's probably not, but i know i like it more when
it's not merged.  it just looks cleaner.

>Whether vm map entrys are merged or not isn't visible from outside of
>vm system (except pmap(1) output :-), is it?  I.e., if adjacent vm map
>entry to stack looks equivalent, touching around the boundary will
>cause same behaviour.

that should be the case, yes, but i'll have to go back and re-verify
my results.  i could have sworn it came up different, but i've just
realized ther are a lot more little hacks in my tree that i initially
thought.

-- 
|-----< "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."