On 4 September 2012 12:32, Mindaugas Rasiukevicius <rm...@netbsd.org> wrote: > 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.. >
I don't see a xen specific lock being taken in pmap_growkernel() -- ~Cherry