Re: port-arm/38950 (shark, hpcarm kernels prone to hard hangs on process exit)

[Rafal Boni <rafal%pobox.com@localhost>]

The following reply was made to PR port-arm/38950; it has been noted by GNATS.

From: Rafal Boni <rafal%pobox.com@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: port-arm/38950 (shark,
 hpcarm kernels prone to hard hangs on process exit)
Date: Tue, 17 Jun 2008 03:24:56 -0400

 It looks like the following sequence of events causes the badness:
        1. kernel calls exit1() on behalf of process A
        2. exit1() in turn calls uvm_proc_exit().
                2a. If 'pmap_previous_active_lwp' is a system thread
                    (e.g., the idle thread, one of the softint threads),
                    the following sequence of events happens:
 
                        1. uvm_proc_exit() borrows proc0's address space
                           (and thus pmap) for the proc A, this stomps
                           any trace of the actual vmspace / pmap used
                           by the exiting process.
                        2. uvm_proc_exit sets and activates the new pmap
                        3. pmap_activate decides no TLB/cache reset is
                           not needed since new pmap (proc0's pmap, ie
                           the kernel pmap) is the same as the previous
                           active LWP's pmap (also kernel pmap).
                        4. exiting process is still using VM mappings as
                           set up in it's own pmap since pmap_activate()
                           did not reset them.
                        5. The proc A's old vmspace is now destroyed.
 BOOM --->              6. Next interrupt presumably hits an unmapped
                           vector page, causes the machine to jump into
                           space.
 
 The assumption in pmap_activate() is that it will be called with a NULL
 pmap_previous_active_lwp on process/thread exit, but that doesn't get
 set until the very end of exit1() after we've reached the end of the 
 exit1() path and call 'lwp_exit_switchaway'.
 
 What I'm not sure is a good way to indicate to pmap_activate() that in 
 this case it *does* need to do the full switch since the (no-longer-
 attached-to-the-process) pmap is about to get destroyed.