> The problem is, utrace_control(UTRACE_RESUME) can't prevent the stop if
> the tracee has already returned UTRACE_STOP, but utrace_stop() didn't
> take utrace->lock yet.
So you are saying that utrace_barrier does not meet its documented API.
Right? It says "effect ... has been applied". But tha
On 09/14, Oleg Nesterov wrote:
>
> Oh, please take a look at this (untested) patch.
I tried to test the cleanuped version, seems to work.
> But I think I should make another attempt, probably spinlock (->siglock ?)
> would be cleaner.
No. I think more locking buys nothing.
I'll split this patch
On 09/14, Oleg Nesterov wrote:
>
> On 09/13, Roland McGrath wrote:
> >
> > Locks just between the tracer and ptrace_report_signal are not bad.
>
> OK, but let me think a bit more. I'd really like to avoid adding the
> new lock to avoid the very unlikely race with the exiting tracer.
Oh, please tak
On 09/13, Roland McGrath wrote:
>
> > It turns out, ptrace_detach_task() is absolutely wrong if
> > voluntary == F and the tracee didn't report the stop.
> >
> > For example, ptrace_report_signal() does:
> >
> > if (utrace_control(current, engine, UTRACE_INTERRUPT))
> >WARN_ON(1);
> >
> > this
