linux-kernel - Re: RT signal queue overflow (Was: Q: SEGSEGV && uc_mcontext->ip (Was: Signal delivery order))

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <200903181623.17987.mega@retes.hu>
Date:	Wed, 18 Mar 2009 16:23:17 +0100
From:	Gábor Melis <mega@...es.hu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Roland McGrath <roland@...hat.com>,
	Oleg Nesterov <oleg@...hat.com>,
	Davide Libenzi <davidel@...ilserver.org>,
	Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Chris Friesen <cfriesen@...tel.com>,
	linux-kernel@...r.kernel.org
Subject: Re: RT signal queue overflow (Was: Q: SEGSEGV && uc_mcontext->ip (Was: Signal delivery order))

On Miércoles 18 Marzo 2009, Linus Torvalds wrote:
> On Wed, 18 Mar 2009, Gábor Melis wrote:
> > It was just a month or so ago when I finally made to change to use
> > a non-real-time signal for signalling stop-for-gc.
>
> Ahh, and that is when you noticed the issue with SIGSEGV?

Unfortunately not immediately because another change was needed make 
context frobbing sigsegvs frequent enough for this to be noticed ...

> One thing you might try is to still use a non-real-time signal, but
> simply depend on the fact that signals are basically peeled off the
> signal bitmask in a signal number order (with the exception that
> fatal signals are handled specially).
>
> IOW, on x86, just about the _only_ normal user-generated signal that
> can happen before SIGSEGV is SIGUSR1, because SIGSEGV is 11, and
> SIGUSR1 is 10.
>
> If you were to use SIGUSR2 (signal #12) you'd probably never see
> this.
>
> Of course, there are other signals with numbers < 11, but they are
> generally meant for other synchronous traps (ie signals like
> SIGTRAP/AIGABRT/SIGFPE/SIGBUS), or for killing the process (signals
> SIGHUP/SIGINT/SIGQUIT).
>
> So maybe you'd be happy with just picking another signal? It's not a
> _pretty_ solution, but it should work across most kernel versions.

So I did already. This is the workaround that I referred to before:

"... I'll stick to the SIGUSR2 workaround that's confirmed by Oleg."

So I'm happy enough that it's fixed in my app, but considering how hard 
it was to figure out what's going on, I thought the kernel people may 
be interested.

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