> Yes. But, with this patch, in this case
> utrace_barrier()->get_utrace_lock(attached => false) returns success
> and then we check utrace->reporting == engine.
I guess that's OK if ->reporting == engine is always set when any kind of
callback might be in progress.
> (Hmm. Probably utrace->reap = T case needs more attention,
> utrace_maybe_reap() doesn't set utrace->reporting).
That would be a problem.
> But, unfortunately, this signal_pending() check assumes the caller can
> always handle this ERESTARTSYS. But this is not true, one example is
> the exiting debugger doing exit_ptrace().
I understand it's a problem. Perhaps we need to have a flag argument or
(probably better) a new utrace_barrier_uninterruptible call. But, for
this particular situation with exit_ptrace, it could be kludged around.
The caller is never going to dequeue another signal once it's as far
into death as exit_ptrace anyway. So, it could do a loop of:
ret = utrace_barrier(task, engine);
if (ret == -ERESTARTSYS) {
clear_thread_flag(TIF_SIGPENDING);
continue;
}
Not that I'm suggesting this isn't a dismal kludge. But it seems like
it would close the hole we have today in practice.
Thanks,
Roland
