On Fri, 22 Nov 2002, Andrew Brown wrote:

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

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

Plus things might change in the future. :-)

Take care,

Bill