Matt Thomas <m...@3am-software.com> wrote: > > On Sep 3, 2012, at 3:33 PM, Mindaugas Rasiukevicius wrote: > > > "Matt Thomas" <m...@netbsd.org> wrote: > >> Module Name: src > >> Committed By: matt > >> Date: Mon Sep 3 19:53:43 UTC 2012 > >> > >> Modified Files: > >> src/sys/uvm: uvm_km.c uvm_map.c > >> > >> Log Message: > >> Switch to a spin lock (uvm_kentry_lock) which, fortunately, was sitting > >> there unused. > > > > - pmap_growkernel() may use adaptive locks, which cannot be acquired > > with the spin lock held; so the change breaks at least x86 and alpha. > > > > - Why in the caller? I think it would be better do leave it for the > > pmaps, e.g. they may re-use the locks which already provide the > > necessary protection and which need to be taken anyway (like in x86 > > pmap). > > uvm_maxkaddr need a lock for its updating > > growkernel can be called uvm_km_mem_alloc which might be called > at interrupt level.
The second point stands, but I see you already fixed it - thanks! As for pmap_growkernel() being called from interrupt context - right, then it seems Xen is broken, as its path in pmap_growkernel() acquires adaptive pmaps_lock and might call pool_cache_invalidate() which can block.. -- Mindaugas
