> Agreed, "bool sig_locked" is awful. But we can avoid it. The real problem > is how to figure out the correct "notify" argument. I'll try to think more, > but I am not sure I will find the clean solution :(
It does not seem hard if we move tracehook_notify_jctl inside siglock. > Just in case. We can introduce PF_SIGCONTED flag and change > prepare_signal(SIGCONT) and signal_wake_up(resume => 1) to set this flag. > Since the task never changes its ->flags in finish_stop() path, it is safe > to do this under ->siglock. This way utrace_report_jctl() can drop > TASK_STOPPED before REPORT() and then check !PF_SIGCONTED before restoring > the ->state. But yes sure, this is very, very ugly. Very! No need for this at all. It's OK to change the tracehook definition. I did this on the new git branch tracehook, then utrace branch commit 7b0be6e4 merges that and uses it. This drops all the JCTL bit kludgery and utrace_report_jctl just backs out of TASK_STOPPED before dropping the siglock in the first place. I think the bookkeeping covers all the angles, but please check it in the new code. Also please verify if you think all ->stopped bookkeeping is bulletproof now. I fiddled utrace_get_signal() a little because I wasn't quite sure that all possibly paths there after TASK_STOPPED were resetting it. With that, please tell me if the current code fixes all the issues (not just this one) you've noticed or what I've still missed. I want to post it to LKML in the next day or two so it has aired before the 2.6.30 merge window. If we've covered things that would hold up review and initial merge now, many follow-on changes will probably go in easily as we have them. Thanks, Roland
