From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-hacker-return-9165-listarch-libc-hacker=sources.redhat.com@sourceware.org>
Received: (qmail 17243 invoked by alias); 26 Feb 2007 15:30:25 -0000
Received: (qmail 17225 invoked by uid 22791); 26 Feb 2007 15:30:23 -0000
X-Spam-Check-By: sourceware.org
Received: from e6.ny.us.ibm.com (HELO e6.ny.us.ibm.com) (32.97.182.146)
    by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 26 Feb 2007 15:30:12 +0000
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236])
	by e6.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l1QFUq4W019294
	for <libc-hacker@sources.redhat.com>; Mon, 26 Feb 2007 10:30:52 -0500
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216])
	by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l1QFU7f0298578
	for <libc-hacker@sources.redhat.com>; Mon, 26 Feb 2007 10:30:08 -0500
Received: from d01av02.pok.ibm.com (loopback [127.0.0.1])
	by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l1QFU7Vo007874
	for <libc-hacker@sources.redhat.com>; Mon, 26 Feb 2007 10:30:07 -0500
Received: from [9.10.86.122] (spokane1.rchland.ibm.com [9.10.86.122])
	by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l1QFU7nW007754;
	Mon, 26 Feb 2007 10:30:07 -0500
Message-ID: <45E30061.3070402@us.ibm.com>
Date: Mon, 26 Feb 2007 15:30:00 -0000
From: Steven Munroe <munroesj@us.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux ppc64; en-US; rv:1.8.0.9) Gecko/20060906 SUSE/1.8_seamonkey_1.0.7-1.1 SeaMonkey/1.0.7
MIME-Version: 1.0
To: Ulrich Drepper <drepper@redhat.com>
CC: GNU libc hacker <libc-hacker@sources.redhat.com>
Subject: Re: Timing window in NPTL fork.c causes hangs.
References: <45DA0AD6.5060107@us.ibm.com> <45E203C8.50600@redhat.com>
In-Reply-To: <45E203C8.50600@redhat.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Mailing-List: contact libc-hacker-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <libc-hacker.sourceware.org>
List-Subscribe: <mailto:libc-hacker-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/libc-hacker/>
List-Post: <mailto:libc-hacker@sourceware.org>
List-Help: <mailto:libc-hacker-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: libc-hacker-owner@sourceware.org
X-SW-Source: 2007-02/txt/msg00011.txt.bz2

Ulrich Drepper wrote:
> I assume this is the same issue fixed by the patch I just applied!?
>
>   
No this is a different hang. Suzuki's bug caused hangs in the child
process. This bug causes hangs (in malloc) in multithreaded parent
processes.

The NPTL implementation of fork is not atomic relative to glibc's
internal (i.e. malloc's) atfork() handling. If the forking thread takes
a signal after atfork prepare and before atfork parent processing AND
the signal handler blocks for any reason, any other thread attempting a
malloc will hang. If the forking threads signal handler is dependent in
any way on other threads to complete then we can see a deadlock.

One way to resolve this is to mask signals from before atfork prepare
until after atfork parent/child processing.