Re: [PATCHSET] ptrace,signal: Improve ptrace and job control interaction

[Tejun Heo <tj@kernel.org>]

Hi,

On Mon, Mar 28, 2011 at 02:14:01PM +0200, Oleg Nesterov wrote:
> > Hmmm... setting TIF_SIGPENDING and kicking the task to enter signal
> > delivery path doesn't have any side effect when it's running in
> > userland,
> 
> Yes. We should avoid the spurious TIF_SIGPENDING, if possible. But in
> this case we don't care.
> 
> But, unless the thread is ptraced, it can't be running in userland,
> why should we set TIF_SIGPENDING?

It goes both ways.  If we need it for ptrace path, the overhead for
!ptrace case is negligible && it makes the code less finicky, why not?

It's much cleaner to say "it sets notification condition and
guarantees that tasks travel signal delivery path" than "if !ptraced,
at least one task should already be in signal delivery path for such
and such reasons; however, while ptraced, because of the interaction
with PTRACE_CONT, there's a case we need to call in the task
explicitly."  The code becomes less prone to subtle bugs when the
surrounding code changes too.

> > We set SIGNAL_CLD_STOPPED if group_stop_count wasn't zero, ie. if
> > group stop has initiated, which will be delivered as soon as any task
> > enters signal delivery path.
> 
> Yes. And that task T has already called do_signal_stop() and it is
> TASK_STOPPED.

Ah, right, this is where I got confused.  signal_stop_count wouldn't
be set unless at least one task is already in signal delivery path.

> No?

You're right.  I was confused.  But if we're gonna call in a task,
let's do it regardless of ptrace.  It's not like splitting that
condition will buy us anything.

Thanks.

-- 
tejun