Subject: Re: repear removal fallout in pmap
To: matthew green <mrg@eterna.com.au>
From: john heasley <heas@shrubbery.net>
List: port-sparc64
Date: 02/10/2004 07:02:59
Tue, Feb 10, 2004 at 02:06:20PM +1100, matthew green:
>    
>    btw, a commit to pmap.c of a few days ago suggested that cpu_switch() would
>    re-allocate a ctx if the pmap remove (possibly other things?) were
>    interrupted.  a novice i am, but cpu_switch doesnt appear to do that if
>    the it's using proc0's.
> 
> i haven't looked but doesn't the kernel's context always exist?

yeah, though i'm not sure that i understand your comment.  it was this
commit that did not make sense to me.

revision 1.153
date: 2004/01/09 08:49:42;  author: chs;  state: Exp;  lines: +3 -2
make sure we free the context for the pmap in pmap_destroy().
this usually isn't necessary since we freed it earlier in pmap_remove_all(),
but since uvmspace_free() is now called in the context of the exiting
process, a new context might be allocated if uvm_unmap_detach() decides
to sleep (since cpu_switch() will allocate a new context when it switches
back to the exiting process).