https://bugzilla.novell.com/show_bug.cgi?id=824046 https://bugzilla.novell.com/show_bug.cgi?id=824046#c0 Summary: glibc: blacklist code in bindresvport doesn't release lock, results in double-lock Classification: openSUSE Product: openSUSE 12.3 Version: Final Platform: Other OS/Version: Other Status: NEW Severity: Major Priority: P5 - None Component: Basesystem AssignedTo: aj@suse.com ReportedBy: jeffm@suse.com QAContact: qa-bugs@suse.de Found By: Development Blocker: --- Created an attachment (id=543388) --> (http://bugzilla.novell.com/attachment.cgi?id=543388) [PATCH] Updated glibc-2.3.90-bindresvport.blacklist.diff This issue was originally reported in bnc#799496, but I incorrectly diagnosed it as a bug in the linuxrc open-coded NFS routines. It turns out that the bindresvport() futex hang was the issue all along. The issue is that in glibc 2.17 (http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=f6da27e53695ad1cc0e2a9...) introduced a lock to make bindresvport() threadsafe. The blacklist code was altered to handle it, but the locking was only added at the beginning and end of the function and it returns from two other places. As a result, the lock wasn't released and when bindresvport takes the lock itself, it hangs due to the double locking condition. I have a fix already worked up. It also handles a race condition in the original patch where the blacklist_read variable could be set to 1 between the test and the lock acquisition, producing undesired results. I would have just issued a submit request with the fix but OBS seems to be unresponsive tonight. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.