From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4416 invoked by alias); 23 Jun 2004 08:23:37 -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 4391 invoked from network); 23 Jun 2004 08:23:36 -0000 Received: from unknown (HELO sunsite.ms.mff.cuni.cz) (195.113.15.26) by sourceware.org with SMTP; 23 Jun 2004 08:23:36 -0000 Received: from sunsite.ms.mff.cuni.cz (sunsite.mff.cuni.cz [127.0.0.1]) by sunsite.ms.mff.cuni.cz (8.12.8/8.12.8) with ESMTP id i5N68w3j012639; Wed, 23 Jun 2004 08:08:58 +0200 Received: (from jakub@localhost) by sunsite.ms.mff.cuni.cz (8.12.8/8.12.8/Submit) id i5N68smb012623; Wed, 23 Jun 2004 08:08:54 +0200 Date: Wed, 23 Jun 2004 08:23:00 -0000 From: Jakub Jelinek To: Thorsten Kukuk Cc: Steve Munroe , libc-hacker@sources.redhat.com Subject: Re: deadlock in signal handler with NPTL Message-ID: <20040623060853.GL5191@sunsite.ms.mff.cuni.cz> Reply-To: Jakub Jelinek References: <20040623042256.GA6177@suse.de> <20040623065635.GA21813@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040623065635.GA21813@suse.de> User-Agent: Mutt/1.4i X-SW-Source: 2004-06/txt/msg00048.txt.bz2 On Wed, Jun 23, 2004 at 08:56:35AM +0200, Thorsten Kukuk wrote: > > I have reviewed all the changes to > > lowlevellock.h since and I do not see any change that would effect this. In > > fact your test case should show that same hang there. > > The difference is: glibc with linuxthreads compiled only uses the > locking, if the program is linked against pthread. > > glibc with NPTL compiled always uses locking (__libc_lock_lock always > calls lll_lock). > > Uli, Jakub, is this really necessary? Wouldn't it be better to add the > one extra compare? This is done on purpose. We are not going to sacrifice speed for the sake of a few broken apps which work with linuxthreads by pure luck. The reasons are actually both speed and being able to dlopen libpthread.so. When syslog enters its critical section by __libc_lock_lock (syslog_lock);, it really assumes that it is alone there, if it knew it can handle the critical section being entered recursively, it could use __libc_lock_lock_recursive instead (at which point your testcase would probably work, unless there are other problem places). But the code is clearly not prepared for that. So, when the locks are nop in linuxthreads, e.g. openlog might be done twice, or the outer syslog might believe it is connected while the inner syslog closed it and similar problems. Jakub