On Mon, Jan 07, 2008 at 09:53:34PM +0100, Martin Husemann wrote: > On Mon, Jan 07, 2008 at 09:15:55PM +0100, Tobias Nygren wrote: > > The problem is that the pmap refcount is set to zero in > > pmap_remove_all(). No other ports I checked do this. Nice catch. > pmap_remove_all() is an optimization to avoid a lot of work updating > mapping only to throw them all away later. So when we know the pmap > is going away (process exiting), pmap_remove_all() invalidated the > context, and any further pmap_remove()/pmap_page_protect()/pmap_update() > calls will avoid heavy work. > > > A working solution is to cast the return value from atomic_dec_uint_nv > > in pmap_destroy into a signed value. This restores the previous > > (broken) behaviour. Maybe you guys have a better idea? :-) > > Since pm_refs is an int I think this is the correct solution and the > previous behaviour is not broken at all. Andrew, what do you think? pmap_remove_all() will only be called by the last LWP in a process so the refcount trick is fine, casting the return to (int) seems the best thing to do. I will make the change shortly. Thanks, Andrew