Andrew Brown <atatat@atatdot.net> writes:

> currently leads to this vm_map:
> 
>     MAP 0xcf490180: [0x0->0xbfc00000]
> 	    #ent=5, sz=33718272, ref=1, version=9, flags=0x41
> 	    pmap=0xcf491098(resident=7)
>      - 0xcf4cad00: 0x8048000->0x8062000: obj=0xcf4d5004/0x0, amap=0x0/0
> 	    submap=F, cow=T, nc=T, prot(max)=5/7, inh=1, wc=0, adv=0
>      - 0xcf4cadc0: 0x8062000->0x8064000: obj=0x0/0x0, amap=0xcf4cb2f8/0
> 	    submap=F, cow=T, nc=F, prot(max)=3/7, inh=1, wc=0, adv=0
>      - 0xcf4cabc0: 0xbdbf5000->0xbdbff000: obj=0xcf4b05c4/0x0, amap=0x0/0
> 	    submap=F, cow=T, nc=T, prot(max)=5/7, inh=1, wc=0, adv=0
>      - 0xcf4caa40: 0xbdbfe000->0xbdbff000: obj=0xcf4cc000/0x0, amap=0x0/0
> 	    submap=F, cow=F, nc=F, prot(max)=5/5, inh=0, wc=0, adv=1
>      - 0xcf4cac80: 0xbdbff000->0xbfc00000: obj=0x0/0x0, amap=0xcf4cb5a0/0
> 	    submap=F, cow=T, nc=F, prot(max)=3/7, inh=1, wc=0, adv=0
> 
> the problem is the entry at 0xcf4caa40.  it seems to have been both
> merged with the stack (pulling the stack "top" back one page), and
> also allocated (meaning it's still in the map) in the wrong place.  if
> it was one page later (at 0xbdbff000->0xbdc00000 instead), it would be
> in the right place, though it should still not be there.

As I said, this is because uvm_map_findspace() returns 0xbdbfe000 as
free space while it is already in use.

When creating entry 0xcf4caa40 (this is 4096 byte long), there is at
least entry 0xcf4caa80 and 0xcf4cabc0.  And uvm_map_findspace() will
be called with 0xbdbff000 as a hint (this is a value
VM_DEFAULT_ADDRESS() when 4096 byte is requested).  So,
uvm_map_lookup_entry() finds the entry 0xcf4cac80 and hint is updated
to <this entry's start> - <requested size>, which is 0xbdbff000 - 4096
== 0xbdbfe000.  And go in to the loop to search free space.  Since the
variable `next' is NULL on first iteration, `next' is updated to
entry->next even if topdown.  Since the entry is the last entry in the
map, `next' becomes &map->header and loop is teminated.  Finally,
0xbdbfe000 is returned and 0xcf4caa40 is created.

enami.