On Sat, 5 July 2003 10:16:26 -0700, Linus Torvalds wrote:
>
> Hmm? I tried it, and for me it does:
>
> torvalds@home:~> ./a.out
> SIGNAL .... 11
> Segmentation fault
Weird. I've fixed the bracket stuff, but that's about it.
> but I have to admit that I didn't even try it before my kernel change, so
> maybe it worked for me before too ;)
>
> There could easily be glibc version issues here, ie maybe your library
> sets SA_NOMASK and mine doesn't.
Hopefully not.
But all that doesn't matter, as your change appears to be worse for
threading libraries, than mine. Imagine a thread that almost busted
it's stack limit. The signal code tries to add the extra stack
frames, fails, and calls force_sig(SIGSEGV). Shooting through the
signal mask, the SIGSEGV can be handled by killing off one thread, or
maby even recovering. With your patch, it will always get killed.
My current best idea is to check, whether the stack pointer is valid
before going to the signal stack. As long as it points to memory that
is writable for the current process, things are not completely
hopeless. When the stack is totally broken, kill that cancer cell.
Working on a translation to diff -u right now.
Jörn
-- Invincibility is in oneself, vulnerability is in the opponent. -- Sun Tzu - 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/
This archive was generated by hypermail 2b29 : Mon Jul 07 2003 - 22:00:26 EST