>Moved to tech-kern.

aye aye.  :)

>> does the patch you sent rely on other recent changes?  i tried
>> applying it to my 8/10 source tree and while the kernel compiled
>> happily, it panicked very early on...early enough that it would not
>> generate a kernel dump.
>
>If your kernel configuration has DIAGNOSTIC option, you need following
>change:

nope.  not me.

>Otherwise, please let me know the panic message.

i was getting "panic: free: addr 0xc0896fc0 not within kmem_map"
regardless of the topdown setting.

>> >It is actually a bug in topdown vm code.  It incorrectly re-uses
>> >space already in-use under some condition which began to met
>> >recently.
>> 
>> where?  tell me tell me.  :)
>
>In the uvm_map_findspace(), if topdown and the uvm_map_lookup_enty()
>returns true and tmp->next is &map-header, it returns wrong address.

ah, i think i get it.  okay.

>And on -current, stack and anon just above the stack is merged if
>stack is unlimited.
>
>root@kk-3f-102-222# sh -c 'ulimit -s unlimited; sh -c pmap'
>08048000    104K read/exec         /bin/sh
>08062000     32K read/write          [ anon ]
>9DB20000      4K read/write          [ anon ]
>9DB21000    608K read/exec         /lib/libc.so.12.100
>9DBB9000     24K read/write        /lib/libc.so.12.100
>9DBBF000     76K read/write          [ anon ]
>9DBD2000      8K read/exec         /lib/libtermcap.so.0.5
>9DBD4000      4K read/write        /lib/libtermcap.so.0.5
>9DBD5000     88K read/exec         /lib/libedit.so.2.6
>9DBEB000      8K read/write        /lib/libedit.so.2.6
>9DBED000     32K read/write          [ anon ]
>9DBF5000      4K read/exec           [ uvm_aobj ]
>9DBF6000     36K read/exec         /libexec/ld.elf_so
>9DBFF000  32772K read/write          [ anon ]
> total    33800K
>root@kk-3f-102-222# 

i have a patch that (i think) deals with this.  it implements a
UVM_ET_STACK flag (and adds the transitory VMCMD_STACK and
UVM_FLAG_STACK flags), and then the merge code refuses to merge
"stack" with "non-stack" entries.  it's possible on the alpha (where
the user's stack is not at the top of the user's vmspace) to mmap a
chunk of space and have it merged with the top end of the stack.

>> it also looks like the patch drops some of the required changes to
>> deal with topdown...
>
>where, where? :)

i'm not sure.  i think i was half asleep when i read your code the
first time.  i certainly had not had enough coffee.  lemme try to
absorb it again.  :)

one thing i was considering, though, is pulling the merge code *out*
and stuffing it into a separate function.  that would make uvm_map()
shorter, and merging could be done at other places, too (eg, in stack
allocation/deallocation).

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