From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1441 invoked by alias); 18 Nov 2008 23:45:32 -0000 Received: (qmail 27578 invoked by uid 48); 18 Nov 2008 23:44:08 -0000 Date: Tue, 18 Nov 2008 23:45:00 -0000 Message-ID: <20081118234408.27575.qmail@sourceware.org> From: "rsa at us dot ibm dot com" To: glibc-bugs@sources.redhat.com In-Reply-To: <20070704013541.4737.nmiell@comcast.net> References: <20070704013541.4737.nmiell@comcast.net> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug libc/4737] fork is not async-signal-safe X-Bugzilla-Reason: CC Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org X-SW-Source: 2008-11/txt/msg00053.txt.bz2 ------- Additional Comments From rsa at us dot ibm dot com 2008-11-18 23:44 ------- A hole was introduced in the concept of fork being async signal safe with the introduction of at_fork handlers. The following IEEE interpretation should be very enlightening: http://standards.ieee.org/reading/ieee/interp/1003-1c-95_int/pasc-1003.1c-37.html Per the ieee interpretation: "The implementation must also be required to protect itself across a fork, for this to occur. But it should NOT be required to protect itself against a fork from a signal handler, because this may be impossible to accomplish." Support for at_fork handlers introduces an window of vulnerability. "The rationale is very specific that the handlers should be designed so they **can't** be used when fork is called in a signal handler which under normal programming practices meant that they should 'acquire' the mutexes, but the standard does not require that mutex operations be async safe. This is being referred to the sponsor for consideration." There doesn't seem to have been a follow up to the recommendation. The following discussion held on libc-hacker is pertinent to the implementation in GLIBC. http://www.sourceware.org/ml/libc-hacker/2007-02/msg00009.html The problem is the lock that may be held by both the at_fork handlers and malloc. I'm not sure if there is _any_ usage of recursive locks in GLIBC. -- http://sourceware.org/bugzilla/show_bug.cgi?id=4737 ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.