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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
