Re: Fix signalfd interaction with thread-private signals

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Thu, 2007-06-21 at 22:58 +0400, Oleg Nesterov wrote:
> 
> > No "stealing". No signalfd, no *nothing*. Just normal signal
> behaviour.
> 
> _Another_ thread could steal SIGSEGV via read(signalfd) without Ben's patch.
> This is what Ben and Davide are worried about. I think we should not worry,
> we have the same situation if this "another" thread does
> 
>         for (;;)
>                 signal(SIGSEGV, SIG_IGN);
> 
> do_sigaction() does rm_from_queue_full().

Yeah well... I wanted to have the least surprise path... that is,
without my patch, signalfd will "sometimes" steal the SIGSEGV depending
on who races to the lock first, thus causing the target thread to
re-execute the faulting instruction and taking another SIGSEGV, and
sometimes not. It's bad from both the faulting thread point of view and
the signalfd use who gets signals "sometimes" without any guarantee.

I like the current code that at least implement a precise semantic for
all thread local signals -> they are only ever delivered to that thread,
period. If you really want to do funky things from outside, you can
still do ptrace ;-)

Ben.


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