Bug 61117

Summary: Race condition between nss/dlopen/thread
Product: [Retired] Red Hat Linux Reporter: hjl
Component: glibcAssignee: Jakub Jelinek <jakub>
Status: CLOSED WONTFIX QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.3CC: fweimer
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2002-03-26 16:51:47 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 61590    
Attachments:
Description Flags
A testcase none

Description hjl 2002-03-13 20:52:51 UTC 
There is a race condition between nss/dlopen/thread. The problem is

1. Thread A has called dlopen, and the global static initialiser inside
the shared object that's being dlopened is trying to call getservbyname
It's holding the dlopen lock, and trying to acquire the NSS lock.
2. Thread B also calls getservbyname, so we're holding the NSS lock 
(which thread A is trying to acquire), and NSS is trying to dlopen a
shared library. 

Now. We're deadlocked, because we're trying to acquire the dlopen lock,
which is held by thread A. This is obviously quite sensitive to timing.

Since NSS also does dlopen, I think it should share locks with dlopen.
Comment 1 hjl 2002-03-13 20:53:32 UTC 
Created attachment 48424 [details]
A testcase
Comment 2 Jakub Jelinek 2002-04-08 13:31:49 UTC 
See http://sources.redhat.com/ml/libc-alpha/2002-03/msg00053.html
I agree with Ulrich here, so WONTFIX.