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 SIGKILL.
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(), [...]
It
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 switch to
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
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.
finish_utrace_stop() can check -stopped lockless. It was set by us,
we can't miss it.
Signed-off-by: Oleg Nesterov o...@redhat.com
kernel/utrace.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- __UTRACE/kernel/utrace.c~5_FINISH_STOP 2009-07-31 02:29:32.0
