On Thu, Nov 21, 2002 at 11:35:20AM -0500, Andrew Brown wrote:
> >> ...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 ?
If someone say me this is forbidden, then fine with me, I'll just
add a KASSERT() before calling amap_extend()

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

No, I'm just looking at it from an interface point of view.

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