[RFC v2 00/19] utrace for 3.0 kernel

Another attempt. This version tries to decouple utrace and ptrace. This way it is much simpler to follow the upstream changes, afaics. TODO: - The single-stepping updates in ptrace_resume() can race with utrace_reset()-user_disable_single_step(). This was fixed by

[PATCH 06/19] wait_task_inactive: treat task-state and match_state as bitmasks

Change wait_task_inactive() to check state match_state instead of state == match_state. This should not make any difference, but this allows us to add more stopped bits which can be set or cleared independently. IOW. wait_task_inactive() assumes that if task-state != 0, it can only be changed to

[PATCH 04/19] introduce wake_up_quiescent()

No functional changes. Add the new helper, wake_up_quiescent(task, state), which simply returns wake_up_state(task, state). Change all callers which do wake_up_state(STOPPED/TRACED) to use the new helper. ptrace_stop() is a bit special, it does __set_current_state(RUNNING) in the very unlikely

[PATCH 09/19] tracehooks: kill tracehook_finish_jctl(), add tracehook_finish_stop()

tracehook_finish_jctl() is needed to avoid the races with SIGKILL which wakes up UTRACED task, and thus it should be called every time after the STOPPED/TRACED/UTRACED returns from schedule(), remember that TASK_UTRACED can be added while the task is STOPPED/UTRACED. - rename it to

[PATCH 10/19] teach wake_up_quiescent() to do selective wake_up

Both utrace and ptrace can want the same thread to be quiescent, in this case its state is TASK_TRACED | TASK_UTRACED. And this also means that this task must not run unless both utrace and ptrace resume it. Change wake_up_quiescent(p, state) to do p-state = ~state and return false unless there

[PATCH 11/19] ptrace_stop: do not assume the task is running after wake_up_quiescent()

If ptrace_stop() sets TASK_TRACED and then detects we should not stop, it can race with utrace_do_stop() which can see TASK_TRACED and add TASK_UTRACED. In this case we should stop for utrace needs. Signed-off-by: Oleg Nesterov o...@redhat.com --- kernel/signal.c |8 1 files

[PATCH 17/19] teach ptrace_set_syscall_trace() to play well with utrace

1. ptrace_set_syscall_trace(true)-set_tsk_thread_flag(TIF_SYSCALL_TRACE) can race with utrace_control()-utrace_reset() path which can miss PT_SYSCALL_TRACE and clear TIF_SYSCALL_TRACE after it was already set. 2. ptrace_set_syscall_trace(false) clears TIF_SYSCALL_TRACE and this is not

[PATCH 18/19] introduce PT_SINGLE_STEP and PT_SINGLE_BLOCK

Add the new internal ptrace flags, PT_SINGLE_STEP and PT_SINGLE_BLOCK. Like PT_SYSCALL_TRACE, this is needed to avoid the unnecessary ptrace reports when TIF_SINGLESTEP was set by another engine, not by ptrace. Also, we need these bits to coordinate the user_*_single_step() calls from ptrace and

[PATCH 12/19] get_signal_to_deliver: restructure utrace/ptrace signal reporting

get_signal_to_deliver() assumes that either tracehook_get_signal() does nothing (without CONFIG_UTRACE), or it also reports the signal to ptrace engine implemented on top of utrace. Now that ptrace works independently this doesn't work. Change the code to call ptrace_signal() after

Re: [PATCH 1/4] ptrace: temporary revert the recent ptrace/jobctl rework

On 06/21, Roland McGrath wrote: OK, so here's my (hacky) idea: (1) Forget ptrace-via-utrace. Have utrace be a separate thing. This way the recent ptrace changes won't matter. This is what V2 does. (2) But, what about ptrace co-existing well with utrace? Make them mutually exclusive