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

otoh, perhaps you mean like this (rather contrived) call path:

	sys_mmap()
	uvm_mmap()
	uvm_map()
	amap_extend()
	malloc()
	uvm_km_kmemalloc()
	uvm_map()
	...

but the second time into uvm_map(), you won't be manipulating an amap
any more, so you won't be calling amap_extend() again, but as far as i
can tell, that's the only path that will lead you into amap_extend()
in the first place.

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