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