>> (1) amap_extend() is only called in process context, meaning that we
>> *can* sleep.
>
>Uhm, no. pool_get() was called with PR_NOWAIT set. Doesn't matter if we
>have process around, we can't sleep. :-)

hmm...so malloc() maps to _malloc() which can call uvm_km_kmemalloc()
which can ultimately end up calling pool_get()...

...okay, i'm gonna stop talking for now.  i need to get my head around
this a bit more first.

>> (2) raid autoconfig takes place (correct me if i'm wrong here) at the
>> end of the boot process, but before init is started, so it's *not* a
>> process context.
>
>We do have processes at that point, though. There is some magic so that
>riadframe can spawn processes, yet we get init to still be process 1.
>Jason did it.

okay, but are they gonna be allocating memory (ie, involving mmap) at
the same time that they're holding a lock of the type involved?

>> i was trying to say that the two things are mutually exclusive, and
>> that manuel should not expend the effort to "fix" amap_extend() for a
>> context in which it will never be used.
>
>The problem though is that there are times, even when we're in full
>multi-user, when we make calls that can't sleep.

sure. i just don't think amap_extend() will occur in any of those
paths.  that said, i'm not opposed to the work being done, i kjust
don't think it's necessary.

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