[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CVS commit: src/sys/uvm
On 4 September 2012 12:32, Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>
> Matt Thomas <matt%3am-software.com@localhost> wrote:
>> On Sep 3, 2012, at 3:33 PM, Mindaugas Rasiukevicius wrote:
>> > "Matt Thomas" <matt%netbsd.org@localhost> 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()
Main Index |
Thread Index |