Re: CVS commit: src/sys/uvm

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

-- 
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 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.