From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14286 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: Conditional signal safety? Date: Sat, 29 Jun 2019 11:33:47 +0200 Message-ID: <20190629093347.GQ16415@port70.net> References: <20190629055405.GA22788@voyager> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="234304"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) To: musl@lists.openwall.com Original-X-From: musl-return-14302-gllmg-musl=m.gmane.org@lists.openwall.com Sat Jun 29 11:34:02 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1hh9kA-000yqN-AA for gllmg-musl@m.gmane.org; Sat, 29 Jun 2019 11:34:02 +0200 Original-Received: (qmail 3604 invoked by uid 550); 29 Jun 2019 09:33:59 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 3583 invoked from network); 29 Jun 2019 09:33:59 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: <20190629055405.GA22788@voyager> Xref: news.gmane.org gmane.linux.lib.musl.general:14286 Archived-At: * Markus Wichmann [2019-06-29 07:54:05 +0200]: > Hi all, > > at work yesterday I had to build an exception handler (a signal handler > for SIGSEGV, SIGBUS, SIGILL, and SIGFPE). For my purposes, it was really > convenient to just use dladdr() to find out at least what module and > function PC and LR were pointing to when the exception happened, so I > used that function. > > Now, dladdr() is not on the list of signal safe functions, but then, > dladdr() is a GNU extension. I wondered if it is signal safe and noticed > that at least musl's implementation is, provided that dlopen() was not > the function that was pre-empted. That got me thinking: Is there such a > thing as "conditional signal safety"? > > dladdr() takes a rwlock in read mode. At the moment, this means it can > only block if the lock is write locked, which only dlopen() will ever > do. dladdr() does nothing else that would impede signal safety. But of > course, these are implementation details. What is actually defined about > the interface? note that the signals you handle (SIGSEGV, SIGBUS, SIGILL, SIGFPE) are usually not asynchronous but happen at particular instructions. dlopen does not hold locks while it runs user code, so you only have issues if the dlopen code itself faults (which can happen e.g. when invalid arguments are passed to it) so indeed in practice you may get away with dladdr in the signal handler (e.g. if you know dlopen won't fault). in theory this does not help: the only concept the libc defines and guarantees is async-signal-safety and dladdr is not as-safe so it may do arbitrary non-as-safe operations, not just taking a dlopen lock, and conversely arbitrary non-as-safe libc apis may take the dlopen lock internally. (btw this is why unwinding from a signal handler does not work reliably even if there are async unwind tables in the binary: the unwinder has to look up those tables for a particular elf module the pc is in and this mechanism needs to synchronize with dlopen which is currently not lock free and thus can deadlock.) > > Ciao, > Markus