if the pool can be used from interrupt context, it shouldn't
be using the "nointr" alloc/free routines.  whichever pool
this is should be changed to use the default alloc/free.

which pool is it?  the only pool_get() in dev/scsipi/* uses
scsipi_xfer_pool, which uses the default alloc routine.

about the NOWAIT flag being dropped when calling uvm_map(),
uvm_map() doesn't have a NOWAIT case, so the flag doesn't matter.

-Chuck



Manuel Bouyer writes:
> I looked a bit more at this, and I may have found the problem.
> If I understood things properly, pmap_zero_page() is not supposed to be called
> with IRQs blocked, and it turns out that it's oftem called with cpl set to 0
> (a simple printf/call to Debugger() confirmed this).
> But pmap_zero_page() can also be called from the pool allocator: here's a stack
> trace I've written by hand (cpl in pmap_zero_page() was set to splhigth, which
> is the same as splclock).
> pmap_zero_page()
> pmap_growkernel()
> uvm_map()
> uvm_km_kmemalloc()
> uvm_kmemalloc_poolpage1()
> pool_page_alloc_nointr()
> pool_get()
> 
> Now a quick look shows that uvm_kmemalloc_poolpage1() calls uvm_km_kmemalloc()
> with the NOWAIT/WAITOK flag properly propagated. uvm_km_kmemalloc() will call
> uvm_map() with the flags trimmed down to UVM_KMF_TRYLOCK (this means that
> we have lost the WAITOK/NOWAIT info). uvm_map() can call pmap_growkernel()
> which can calls pmap_zero_page().
> pool_get() is called from interrupt context in the scsipi system (there may be
> other places too, I didn't look closely at network boards drivers, but they
> are suspect as well). This is probably the reason why not much persons have
> been hit by this yet.
> 
> Comments ? Did I miss somthething ?
> 
> --
> Manuel Bouyer <bouyer@antioche.eu.org>
> --