On Wed, Nov 20, 2002 at 11:41:35PM -0500, Andrew Brown wrote:
> > > 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

No, I'm talking about current as well. The problem is that pool_get(PR_NOWAIT)
can try to sleep in uvm_map() which is wrong.
The problem has been triggered for me in 1.6, but that doesn't mean it's not
present in current.

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.

--
Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer@lip6.fr
     NetBSD: 23 ans d'experience feront toujours la difference
--