Does ptrace really need to see ignored signals?

[Mike Coleman]

Is there any good reason why the ptrace interface needs to have visibility on
signals that would otherwise get dropped by 'ignored_signal'?  This causes an
annoying divergence in signal behavior.  For example, if a traced process
doing a nanosleep receives a signal that it is SIG_IGN'ing, the call gets
interrupted.  This doesn't happen if it's not being traced.

There might be a certain remote logic to letting gdb/strace see attempted
delivery of ignored signals, but it doesn't get to see *blocked* signals
(until/unless they are unblocked), so this doesn't seem consistent or
particularly useful.

So, if the PF_PTRACED test got dropped from the below, would any existing
programs be harmed?  There are other divergence problems, but at least this
would be a step in the right direction.

--Mike


    static int ignored_signal(int sig, struct task_struct *t)
    {
	    ...
	    /* Don't ignore traced or blocked signals */
	    if ((t->flags & PF_PTRACED) || sigismember(&t->blocked, sig))
		    return 0;

-- 
Any sufficiently adverse technology is indistinguishable from Microsoft.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo en vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/