On Tue, 30 Mar 1999 22:57:43 +0200 
 Manuel Bouyer <bouyer@antioche.eu.org> wrote:

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

If you're using the nointr allocator, it should never be called in interrupt
context.

If you're using the default allocator, kmem_map is used instead.  This
should NOT call pmap_growkernel() to be called, since the KVA space is
already reserved for kmem_map.

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

        -- Jason R. Thorpe <thorpej@nas.nasa.gov>