From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30676 invoked by alias); 2 Apr 2004 00:09:01 -0000 Mailing-List: contact libc-hacker-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-hacker-owner@sources.redhat.com Received: (qmail 30655 invoked from network); 2 Apr 2004 00:09:01 -0000 Received: from unknown (HELO palrel11.hp.com) (156.153.255.246) by sources.redhat.com with SMTP; 2 Apr 2004 00:09:01 -0000 Received: from hplms2.hpl.hp.com (hplms2.hpl.hp.com [15.0.152.33]) by palrel11.hp.com (Postfix) with ESMTP id 58C2D1C0176B; Thu, 1 Apr 2004 16:08:59 -0800 (PST) Received: from napali.hpl.hp.com (napali.hpl.hp.com [15.4.89.123]) by hplms2.hpl.hp.com (8.12.10/8.12.10/HPL-PA Hub) with ESMTP id i3208vcb002686; Thu, 1 Apr 2004 16:08:57 -0800 (PST) Received: from napali.hpl.hp.com (napali [127.0.0.1]) by napali.hpl.hp.com (8.12.11/8.12.11/Debian-1) with ESMTP id i3208uFB014359; Thu, 1 Apr 2004 16:08:56 -0800 Received: (from davidm@localhost) by napali.hpl.hp.com (8.12.11/8.12.11/Debian-1) id i3208uE6014355; Thu, 1 Apr 2004 16:08:56 -0800 From: David Mosberger MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16492.44824.546092.273252@napali.hpl.hp.com> Date: Fri, 02 Apr 2004 00:09:00 -0000 To: Roland McGrath Cc: davidm@hpl.hp.com, libc-hacker@sources.redhat.com Subject: Re: is dl_iterate_phdr() supposed to be async-signal safe? In-Reply-To: <200404012122.i31LM3sg027149@magilla.sf.frob.com> References: <16491.51649.225477.81600@napali.hpl.hp.com> <200404012122.i31LM3sg027149@magilla.sf.frob.com> Reply-To: davidm@hpl.hp.com X-URL: http://www.hpl.hp.com/personal/David_Mosberger/ X-SW-Source: 2004-04/txt/msg00006.txt.bz2 >>>>> On Thu, 1 Apr 2004 13:22:03 -0800, Roland McGrath said: Roland> Why would you have thought that it was? It is Roland> well-specified that no interface is async-signal-safe unless Roland> explicitly listed as such. No such claim was ever made Roland> about dl_iterate_phdr. Because otherwise there is no way to unwind from a signal handler and I was mislead by the fact that it was using a recursive lock (and it was only indirectly calling pthread_mutex_lock(), which is defined not to be async-signal safe). Can this please be fixed? Wouldn't it be sufficient to disable signal delivery during lock acquisition/release and while modifying the ELF object list? --david