> In the code path mentioned above, I see only ia64 has chance to let > ptraced thread deliver those pending signals before TASK_TRACED is This is the key thing that makes no sense to me. What do you mean by "deliver" here? The normal meaning of to "deliver" a signal means that get_signal_to_deliver() dequeues and processes it. This can never happen inside any other kernel code path. It certainly can never happen inside ptrace_stop or ptrace_notify. The difference between ia64 and others is that inside ptrace_stop(), it can release the siglock and then can block (in page faults, or by preemption). No signal delivery can happen. What perhaps can happen is that TIF_SIGPENDING being set can cause a TASK_INTERRUPTIBLE wait in the page fault path to return early and ia64_sync_user_rbs will bail out before doing all its work. But you haven't described any problem like that. Please tell us the exact code path you think is happening in the error case you can reproduce. Describe the actual code path, not high-level notions like "deliver those pending signals". Thanks, Roland -- To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|