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

enami.