| commit | e473f7766f04bbc8db8b5f3762586fbaf2e18215 | |
| author | Simon Schubert <corecode@dragonflybsd.org> | |
| Sat, 7 Mar 2009 17:09:13 +0000 (7 18:09 +0100) | ||
| committer | Simon Schubert <simon.schubert@epfl.ch> | |
| Mon, 9 Mar 2009 17:00:03 +0000 (9 18:00 +0100) | ||
| tree | 0c2250395588da2b8f2bcda0a814523db928891b | treesnapshot (tar.gz zip) |
| parent | 6acb4ed8e75e72485a7d174d6366a227b1879805 | commitdiff |
signals: rework when CURSIG/issignal can stop a thread for tracing
When tracing a process, it can happen that the thread would get stopped
due to the signal and its tracing. In this case the tracing parent
would get notified and it might choose to let the process to serve the
signal.
However if this stop+trace is happening somewhere deep in the kernel due
to a call to CURSIG(), it might happen that the same signal again is the
cause for a stop+trace cycle because of another call to CURSIG() while
the call stack is unwinding.
Introduce CURSIG_TRACE(), which explicitly allows stopping for tracing
signal delivery. This is only called from userret().
All other instances of CURSIG() may still block/sleep because of SA_STOP
signals, but these invocations may not trace + repost signals.
As such, the only place where trace + repost of signals can happen now
is userret(). Nevertheless, CURSIG() still decides not to ignore a
currently ignored signal and rather lets the kernel unwind until this
signal arrives in the CURSIG_TRACE() called from userret().
When tracing a process, it can happen that the thread would get stopped
due to the signal and its tracing. In this case the tracing parent
would get notified and it might choose to let the process to serve the
signal.
However if this stop+trace is happening somewhere deep in the kernel due
to a call to CURSIG(), it might happen that the same signal again is the
cause for a stop+trace cycle because of another call to CURSIG() while
the call stack is unwinding.
Introduce CURSIG_TRACE(), which explicitly allows stopping for tracing
signal delivery. This is only called from userret().
All other instances of CURSIG() may still block/sleep because of SA_STOP
signals, but these invocations may not trace + repost signals.
As such, the only place where trace + repost of signals can happen now
is userret(). Nevertheless, CURSIG() still decides not to ignore a
currently ignored signal and rather lets the kernel unwind until this
signal arrives in the CURSIG_TRACE() called from userret().