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

hrm.  :-/

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

right, but that's not at all related to amaps.

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

okay, sure.  i just can't conceive of a code path that would cause you
to acquire a vnode lock (or anything like that) and then extend an amap.

amaps get extended when a new area is mmap'ed by the process that's
adjacent to another area that's already backed by an amap.

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

uvm_map() is the sole caller of amap_extend(), in four places.

granted, uvm_map() gets called from a lot of places, but i still
highly doubt that a userspace mapping would get added that would cause
an amap to get extended at the same time that some other lock was
held.

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