Re: CVS commit: src/sys/uvm

["Cherry G. Mathew" <cherry.g.mathew%gmail.com@localhost>]

On 4 September 2012 12:32, Mindaugas Rasiukevicius <rmind%netbsd.org@localhost> 
wrote:
> 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()

-- 
~Cherry