> > yes, amap_extend() uses malloc, but at the same time, it will only get
> > called from a process context when extending an amap.  kernel map
> > entries don't use amaps.
>
>Yah, but you don't want it to sleep while the caller is holding locks.

okay, maybe i'm not as well versed in this as some, but...

...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
forwards to cover a new allocation (since the backwards extension code
is new), so the process is already well under way (ie, past
sys_execve() and past the initial runtime of the dynamic linker).  for
1.6, that sounds well into multi-user.

then again, i'm only looking at current code, not 1.6, in which case
back-porting the amap_extend() changes will be difficult anyway,
because i recently changed it (to add the third argument) in current.

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