Not sure I read this patch correctly, but at first glance it looks
suspicious..
On 07/11, Peter Zijlstra wrote:
>
> +static void return_instance_timer(struct timer_list *timer)
> +{
> + struct uprobe_task *utask = container_of(timer, struct uprobe_task,
> ri_timer);
> + task_work_add(utask->task, &utask->ri_task_work, TWA_SIGNAL);
> +}
What if utask->task sleeps in TASK_STOPPED/TASK_TRACED state before
return from the ret-probed function?
In this case it won't react to TWA_SIGNAL until debugger or SIGCONT
wakes it up.
---------------------------------------------------------------------------
And it seems that even task_work_add() itself is not safe...
Suppose we have 2 ret-probed functions
void f2() { ... }
void f1() { ...; f2(); }
A task T calls f1(), hits the bp, and calls prepare_uretprobe() which does
mod_timer(&utask->ri_timer, jiffies + HZ);
Then later it calls f2() and the pending timer expires after it enters the
kernel, but before the next prepare_uretprobe() -> mod_timer().
In this case ri_task_work is already queued and the timer is pending again.
Now. Even if T goes to the exit_to_user_mode_loop() path immediately, in
theory nothing can guarantee that it will call get_signal/task_work_run
in less than 1 second, it can be preempted.
But T can sleep in xol_take_insn_slot() before return from handle_swbp(),
and this is not so theoretical.
Oleg.
