On Thu, 21 Nov 2002, Andrew Brown wrote:

> >> (1) amap_extend() is only called in process context, meaning that we
> >> *can* sleep.
> >
> >Uhm, no. pool_get() was called with PR_NOWAIT set. Doesn't matter if we
> >have process around, we can't sleep. :-)
>
> hmm...so malloc() maps to _malloc() which can call uvm_km_kmemalloc()
> which can ultimately end up calling pool_get()...
>
> ...okay, i'm gonna stop talking for now.  i need to get my head around
> this a bit more first.
>
> >> (2) raid autoconfig takes place (correct me if i'm wrong here) at the
> >> end of the boot process, but before init is started, so it's *not* a
> >> process context.
> >
> >We do have processes at that point, though. There is some magic so that
> >riadframe can spawn processes, yet we get init to still be process 1.
> >Jason did it.
>
> okay, but are they gonna be allocating memory (ie, involving mmap) at
> the same time that they're holding a lock of the type involved?

No idea.

Actually it seems getnewvnode() does. Well, it has a lock in one vnode
while doing other stuff.

Note though that it doesn't matter where the lock is. If you have ANY
locks, you shouldn't sleep.

> >> i was trying to say that the two things are mutually exclusive, and
> >> that manuel should not expend the effort to "fix" amap_extend() for a
> >> context in which it will never be used.
> >
> >The problem though is that there are times, even when we're in full
> >multi-user, when we make calls that can't sleep.
>
> sure. i just don't think amap_extend() will occur in any of those
> paths.  that said, i'm not opposed to the work being done, i kjust
> don't think it's necessary.

Hmmm.. I'm not sure of all of the callers of amap_extended(), so I'm not
sure about it specicically. Probably what would work best is look at the
calls that can be called with an equivalent of NOWAIT, and make sure all
their callees won't wait, or get that flag passed down.

Take care,

Bill