From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 406 invoked by alias); 6 Jan 2014 20:38:43 -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 32765 invoked by uid 48); 6 Jan 2014 20:38:38 -0000 From: "triegel at redhat dot com" To: glibc-bugs@sourceware.org Subject: [Bug nptl/13690] pthread_mutex_unlock potentially cause invalid access Date: Mon, 06 Jan 2014 20:38: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: 2014-01/txt/msg00075.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=13690 --- Comment #33 from Torvald Riegel --- (In reply to Pat from comment #32) > (In reply to Torvald Riegel from comment #31) > > > > You can't claim that just one of the semantics is "correct". > > Um, actually, you can... Based on (a) the only sane interpretation and (b) > THE ACTUAL EXAMPLE USAGE GIVEN IN THE POSIX SPEC. You're still saying that you like one semantics better than the other. That doesn't make another *semantics* incorrect. > > Also, because you mentioned conforming applications: those won't be helped > > by glibc implementing something (incl. something stronger) that's not > > guaranteed by POSIX. > > "Hey, POSIX authors, did you actually mean the example code you gave in the, > you know, spec?" > > "Yes, we actually meant it." > > Is that what you are waiting to hear before you fix this bug? Seriously? If you want to know what I'd like to get clarified by the Austin Group, please read the Austin group issue. It should be easy to understand. > Most people writing "conforming applications" are going to expect the > examples in the spec to... let's see... I dunno... work? You can say the same thing about the normative text. Which brings us right back to the clarification request... > > No, it does not need to be a global lock. You just make sure that all > > threads that use the resource you want to destruct have quiesced. > > To "make sure that all threads ... have quiesced", you must do one of two > things: (a) Rely on some synchronization mechanism, all of which are > currently broken due to this bug; No, they aren't "broken". See the examples I gave. > or (b) wait for all threads to exit. Precisely, wait for all threads that use the particular resource to not use it anymore. That's different from "wait[ing] for all threads to exit". > You are arguing for (b): To destroy a mutex -- any mutex -- you must first > wait for every thread that ever touched that mutex to exit. This could be a reasonable semantics. > Is it possible to code against these semantics? Of course. And often, programs will do just that. All that don't do reference counting or similar, for example. > It is also > possible to code without using threads. Or function calls. Or multiplication. > > But the whole point of a primitive is to provide useful semantics across a > variety of applications. And by "a variety", I mean more than one (1). > > There is one nice thing about this bug, though. It provides a quintessential > (and hilarious) example of why people laugh and roll their eyes when they > hear the phrase "glibc maintainer". > > I wonder, what's the over/under on whether this bug gets fixed before 2017? This bug is about a technical issue. I'm not going to respond to off-topic statements like this. -- You are receiving this mail because: You are on the CC list for the bug.