>> >> ...uvm_map() calls amap_extend() to extend an already existing amap.
>> >> that requires that the process is running (ie, not starting up) and
>> >> has caused the amap to be allocated.  this sounds like something that
>> >> occurs very much after raid autoconfig time.  additionally, since
>> >> we're talking about 1.6, this means the process is extending the amap
>> >...
>> >It's just a question of being consistent with the interface: if we're calling
>> >uvm_map() with UVM_KMF_NOWAIT, then it should not sleep, whatever map it
>> >uses.
>> 
>> if you're calling uvm_map() with UVM_KMF_NOWAIT, then you're
>> manipulating kmem, not usermem.  if uvm_map() calls amap_extend(),
>> it's a userspace mapping being extended, and you can definitely sleep.
>
>Is there something preventing someone from calling, one day, uvm_map() with
>UVM_KMF_NOWAIT for user mem ?

since UVM_KMF_NOWAIT is a flag that's (afaik) only associated with
calls involving kernel memory, i can't say that i'd ever expect to see
it used in a call that involves user memory.

>If someone say me this is forbidden, then fine with me, I'll just
>add a KASSERT() before calling amap_extend()

the only thing i can think of is a rather vague idea of what a proper
swapfs might be like.  that might use an amap, but i don't know such
stuff.

>> otoh, perhaps you mean like this (rather contrived) call path:
>
>No, I'm just looking at it from an interface point of view.

understood.  all i'm trying to do here is talk you out of expending
the effort of reworking the amap_extend() interface.  actually, if you
were to do that, i'd suggest that instead of adding a new argument,
you should alter the "forwards" argument (of which only one bit is
used) to be the flags argument, and put your WAIT/NOWAIT bits in
there.

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