> That sounds like a rather fragile approach to avoiding a minimal amount of
When single-stepping occurs it happens repeatedly many times, and that
doesn't need any more overhead than it already has.
What is the problem with just clearing TIF_DEBUG? It just means that in
the SIGKILL case, the dying thread won't switch in its local debugregs.
The global kernel allocations will already be set in the processor from the
previous context, and old user-address allocations do no harm since we
won't run in user mode again before switching out at the end of do_exit.
That won't necessarily work. There isn't any cheap check that won't also
catch a task preempted on its way to stopping for the debugger.
I'm not clear on what that would mean, but it's probably not an idea I like.
If it's really necessary, but it hasn't proved so for any other switched
per-thread state. As long as you aren't doing per-thread kernel-mode
allocations, I don't see why you need anything other than TIF_DEBUG.
It should be, but there might be some stray wake_up_process calls in the
kernel that can violate [up]trace's supposed monopoly on TASK_TRACED (or
duopoly with SIGKILL, I suppose I should say). If there is no SIGKILL,
then the task will just call schedule again nearly immediately to go back
to blocking, which will switch out unless there is a second wakeup right
then.
PF_EXITING it set after there is no possibility of returning to user mode,
but a while before exit_thread, when you might still want kernel-mode
breakpoints. If the only per-thread allocations you support are for user
mode, then you can certainly refuse to do any when PF_EXITING is set.
Thanks,
Roland
-
