On 07/24, Roland McGrath wrote:
Roland, can we just remove all code which plays with -stopped in
utrace_report_jctl() and utrace_get_signal(), and do something like
[...]
@@ -1602,6 +1602,16 @@ static int do_signal_stop(int signr)
do {
schedule();
Good. In any case I believe utrace_get_signal() and utrace_report_jctl()
should not play with -stopped. This really simplifies the code and
what -stopped == T means.
I am open to any such sort of clean-up. If you change something that had a
special rationale, I'll explain what it was so we
utrace_wakeup:
if (likely(task_is_stopped_or_traced(target))) {
if (target-signal-flags SIGNAL_STOP_STOPPED)
target-state = TASK_STOPPED;
else
wake_up_state(target, __TASK_STOPPED | __TASK_TRACED);
}
On 07/27, Oleg Nesterov wrote:
On 07/24, Roland McGrath wrote:
I recall you wanted to rework something about tracehook_notify_jctl earlier
too. Now is the time to revisit all that and clean the code up however
seems best. It shouldn't be a problem to rewrite the last half of
I meant ptrace_resume()-task_is_stopped() check in ptrace_utrace.patch.
Oh. I think that was an attempt at ptrace bug-compatibility.
Like I keep saying, don't take any code in that patch seriously.
Yes, the whole-process stop will be delayed until the debugger
wakes up the tracee and it sees
utrace_wakeup:
if (likely(task_is_stopped_or_traced(target))) {
if (target-signal-flags SIGNAL_STOP_STOPPED)
target-state = TASK_STOPPED;
else
wake_up_state(target, __TASK_STOPPED | __TASK_TRACED);
}
Assuming you agree with this change... I don't know how it should be merged.
Probably the change in signal.c should be sent separately, but this breaks
-mm tree.
The relevant -mm differences are just in one patch that folds finish_stop
into do_signal_stop, right? If I can apply just that one
On 07/27, Roland McGrath wrote:
No, it can't. That's what get the bookkeeping right means.
It the debugger uses UTRACE_RESUME et al, then that thread moves
from TASK_TRACED into TASK_STOPPED and still never runs.
Ah. In that case yes, we can make this all consistent.
But I am not sure I
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
On 07/27, Roland McGrath wrote:
utrace_wakeup:
if (likely(task_is_stopped_or_traced(target))) {
if (target-signal-flags SIGNAL_STOP_STOPPED)
target-state = TASK_STOPPED;
else
wake_up_state(target, __TASK_STOPPED |
On 07/27, Roland McGrath wrote:
Assuming you agree with this change... I don't know how it should be merged.
Probably the change in signal.c should be sent separately, but this breaks
-mm tree.
The relevant -mm differences are just in one patch that folds finish_stop
into do_signal_stop,
Ah. I forgot signals-tracehook_notify_jctl-change.patch is still pending in
-mm.
Perhaps we should just rejigger all these together into one new patch (or
two, whatever) before akpm submits any of them.
Or you can just merge these 2 patches, perhaps this would be better.
As long as we have
12 matches
Mail list logo
