[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: port-arm/38950 (shark, hpcarm kernels prone to hard hangs on process exit)
The following reply was made to PR port-arm/38950; it has been noted by GNATS.
From: Rafal Boni <rafal%pobox.com@localhost>
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
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.
Main Index |
Thread Index |