> But currently ptrace can wake up the tracee and then later it can be > ptrace_stop()'ed again, in this case we can decrement ->group_stop_count > twice for the same thread.
The behavior or the bookkeeping need to change so they are consistent. > OK, forget about mt issues. Do you really mean PTRACE_CONT/etc must _not_ > wake up SIGNAL_STOP_STOPPED tracee ? This would be nice perhaps, but this > means a serious user-visible change. I'm talking about the UTRACE_STOP/utrace_control behavior here. When we implement ptrace on top and then get to the nasty corners of strange compatibility with old ptrace, we can figure out what the exact user-visible ptrace semantics need to be. We might just do those cleanly on top, or we might need some special-case ptrace fiddling. But what we won't do is have ptrace do anything that confuses the utrace bookkeeping or the signals bookkeeping, like the current wake_up_process() does. > > Let's do it however makes the code taken all together come out cleanest. > > From what you said before, it sounds like tracehook_finish_stop() would > > help with that. > > OK, I'll send the patch. Use tracehook_*_jctl for the name, so it pairs with notify_jctl (and/or change both names). I avoid using "stop" in the tracehook.h names because it's not inherently clear when that means "job control stop semantics" and when that means other kinds of stopping (like utrace_stop/ptrace_stop). jctl keeps it clear that this is only part of the code paths used for POSIX job control stops. > I think it can. Ok! Thanks, Roland
