> What I meant, we can rely on the fact that any wakeup (try_to_wakeup()
> actually) must be a barrier wrt schedule().
Ok.
> But what if the tracee is woken by CONT/KILL? Should the tracee
> see the last change in ->stopped? The signal can race with
> utrace_wakeup() or utrace_do_stop(), [...]
On 08/03, Roland McGrath wrote:
>
> > But I think we do not care. What we do care is: ->stopped must be F
> > after finish_utrace_stop(), whoever checks it under utrace->lock.
>
> We do care about a false positive if it makes finish_utrace_stop() hit its
> WARN_ON and return true when there was no
> Of course, we can have the false positive. Even simpler: by the time
> finish_utrace_stop() takes utrace->lock the tracer can clear ->stopped
> even if it was really set after schedule().
Right. It didn't even occur to me that the only scenario I thought of was
a false positive. I was just thi
On 08/01, Roland McGrath wrote:
>
> > finish_utrace_stop() can check ->stopped lockless. It was set by us,
> > we can't miss it.
>
> We enter utrace_stop() for some stop. Either then or later, a group jctl
> stop finishes and sets SIGNAL_STOP_STOPPED. Later, utrace_wakeup() sees
> that and we swi
> finish_utrace_stop() can check ->stopped lockless. It was set by us,
> we can't miss it.
We enter utrace_stop() for some stop. Either then or later, a group jctl
stop finishes and sets SIGNAL_STOP_STOPPED. Later, utrace_wakeup() sees
that and we switch to TASK_STOPPED after clearing ->stopped.
