Subject: Re: lock bug in getnewvnode, or uvm_km_kmemalloc/uvm_map ?
To: Bill Studenmund <wrstuden@netbsd.org>
From: Andrew Brown <atatat@atatdot.net>
List: tech-kern
Date: 11/22/2002 17:22:41
>> >> 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.
>
>Can uvm_map() be called with a "don't wait" flag? I thought it was one of
>the routines that needs "don't wait."

let's see...considering the sys_mmap() -> uvm_mmap() -> uvm_map() code
path that i'm thinking of, it seems that...

 * MAP_FIXED gets translated to UVM_FLAG_FIXED
 * MAP_ANON & MAP_SHARED -> UVM_FLAG_COPYONW
 * MAP_ANON & !MAP_SHARED -> UVM_FLAG_OVERLAY
 * !MAP_ANON & !MAP_SHARED -> UVM_FLAG_COPYONW
 * then the protection flags get tossed in, along with either
   UVM_INH_SHARE or UVM_INH_COPY (again depending on MAP_SHARED)

and that's it.  no mention at all of WAITOK or NOWAIT.

>> 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.
>
>If uvm_map() can get told to not sleep (or needs to be told to not sleep),
>then amap_extend() needs to be able to be told not to sleep. While you
>could be 100% correct that the amap_extend() calls would never be made in
>the cases that would want don't wait, that'll look really weird to future
>readers; it will seem we're throwing the flag away.

yes, true.  so far as i can tell from a somewhat cursory perusal of
the code, i don't think uvm_map() *ever* gets called with
WAITOK/NOWAIT information at all.

>Plus things might change in the future. :-)

sure.  people like me come along.  8-)

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