From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22481 invoked by alias); 20 Dec 2013 20:25:21 -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 21947 invoked by uid 48); 20 Dec 2013 20:25:14 -0000 From: "triegel at redhat dot com" To: glibc-bugs@sourceware.org Subject: [Bug nptl/13690] pthread_mutex_unlock potentially cause invalid access Date: Fri, 20 Dec 2013 20:25: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: 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/msg00178.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=13690 --- Comment #29 from Torvald Riegel --- (In reply to Pat from comment #27) > If you have to wait for all calls to mutex_unlock to return before you can > destroy the mutex, how are you supposed to guarantee that, exactly? > > You can only do so by synchronizing the threads in some other way. So every > mutex has to be guarded by another mutex which has to be guarded by another > mutex... > > ...except for the last mutex, which is global or static or whatever and > never gets destroyed. Problem solved! There are other ways to do garbage collection / end-of-lifetime-detection than doing so via mutex-protected reference counts (and I don't mean you should use garbage collection for memory management...). If your mutexes are part of other data structures that you have to destroy, you can destroy the mutexes when destructing the data structure; unless every access to the data structure is protected by the mutex, you'll likely need another mechanism anyway to decide when it's safe to destruct. > Seriously, think about the kind of code you would have to write to deal with > these semantics. I have. This is a trade-off between implementation constraints and guarantees given to users, as I pointed out in the POSIX clarification request. If you have anything to say about that, then please comment on the POSIX issue. > Is that what you think POSIX wanted to put people through > (despite the actual example they give)? That's what the clarification request is for. > Is that what glibc wants to put > people through? As Carlos said, we're approaching issues like this with the care that is needed. This involves making sure that the standards and implementations are in sync. > You do not need "clarification" from anybody to recognize that these are > serious bugs. The only interesting question is how many years it's going to > take. It would be a bug if it is not adhering to the specification of the function. Arguably, the normative text in the standard can be understood to not allow the use you seem to want to have. The POSIX reply will clarify this. If POSIX clarifies that it wants the strong guarantees re destruction, this is a bug compared to a clarified standard. Otherwise, this bug is an enhancement request, which we would then evaluate as well. -- You are receiving this mail because: You are on the CC list for the bug.