From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21297 invoked by alias); 6 Jan 2014 17:46:16 -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 21214 invoked by uid 48); 6 Jan 2014 17:46:12 -0000 From: "lopresti at gmail dot com" To: glibc-bugs@sourceware.org Subject: [Bug nptl/13690] pthread_mutex_unlock potentially cause invalid access Date: Mon, 06 Jan 2014 17:46: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: lopresti at gmail 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/msg00072.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=13690 --- Comment #32 from Pat --- (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. > 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? Most people writing "conforming applications" are going to expect the examples in the spec to... let's see... I dunno... work? > 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; or (b) wait 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. Is it possible to code against these semantics? Of course. 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? -- You are receiving this mail because: You are on the CC list for the bug.