Re: CVS commit: src/sys/uvm

2012-09-03 Thread Mindaugas Rasiukevicius
"Matt Thomas"  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).

-- 
Mindaugas


Re: CVS commit: src/sys/uvm

2012-09-03 Thread Matt Thomas

On Sep 3, 2012, at 3:33 PM, Mindaugas Rasiukevicius wrote:

> "Matt Thomas"  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.