From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20975 invoked by alias); 18 Dec 2013 20:13:46 -0000 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 Received: (qmail 20904 invoked by uid 48); 18 Dec 2013 20:13:42 -0000 From: "triegel at redhat dot com" To: glibc-bugs@sourceware.org Subject: [Bug nptl/13690] pthread_mutex_unlock potentially cause invalid access Date: Wed, 18 Dec 2013 20:13:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: nptl X-Bugzilla-Version: 2.15 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: triegel at redhat dot com X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: carlos at redhat dot com X-Bugzilla-Target-Milestone: 2.18 X-Bugzilla-Flags: review? X-Bugzilla-Changed-Fields: bug_status cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2013-12/txt/msg00151.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=13690 Torvald Riegel changed: What |Removed |Added ---------------------------------------------------------------------------- Status|WAITING |ASSIGNED CC| |triegel at redhat dot com --- Comment #24 from Torvald Riegel --- I agree that after release of a mutex (i.e., atomic_exchange_rel (__futex, 0)), we have both (1) a pending load from mutex->__data.__kind and (2) a pending futex_wake call. However, I think it is an open question whether POSIX actually allows destruction of the mutex just based on having obtained ownership of the lock. The example given in the standard and reproduced in Comment #1 is in an informative section, and it conflicts with a statement in the normative section: "Attempting to destroy a locked mutex or a mutex that is referenced [...] by another thread results in undefined behavior." Arguably, a mutex could still be considered "referenced" as long as a call to mutex_unlock has not yet returned. This would make the example in the normative text incorrect. OTOH, the intended semantics could also be that if a program ensures that (1) a thread is the last one to lock a mutex, and (2) this thread is able to lock and unlock a mutex, then this thread is also allowed to destroy the mutex; IOW, being able to doing the last lock and unlock of the mutex could be the defining constraint for when destruction is allowed. (That is what C++11 seems to require based on a quick read. C11 isn't very verbose but requires just that no thread is blocked on the mutex when it is destructed; nonetheless, it also mentions that all resources of the mutex are claimed, which could be understood to mean the same as the "referenced" constraint in POSIX.) I've asked the Austin Group for clarification: http://austingroupbugs.net/view.php?id=811 Depending on how they decide, this is either not a bug, or we'll have to avoid the pending load and futex_wake call, or make them harmless. The proposed patch should be right for the pending load, but the futex_wake needs more investigation: A futex_wake to a futex without waiters (or even to a futex not mapped anymore) should be harmless, but it could be different with PI futexes. -- You are receiving this mail because: You are on the CC list for the bug.