[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Q: utrace->stopped && utrace_report_jctl()

> 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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]