From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25862 invoked by alias); 14 Sep 2013 16:47:18 -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 25767 invoked by uid 48); 14 Sep 2013 16:47:14 -0000 From: "bugdal at aerifal dot cx" To: glibc-bugs@sourceware.org Subject: [Bug nptl/12674] sem_post/sem_wait race causing sem_post to return EINVAL Date: Sat, 14 Sep 2013 16:47: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: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: critical X-Bugzilla-Who: bugdal at aerifal dot cx X-Bugzilla-Status: REOPENED X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: 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-09/txt/msg00094.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=12674 --- Comment #16 from Rich Felker --- The cause of the EINVAL is that orl PRIVATE(%rdi), %esi is being performed after the semaphore value is changed. To be correct, nothing can be read from the semaphore value after the atomic instruction which changes the semaphore value. Moving the check for number of waiters to before the atomic operation, however, introduces a race condition which is even worse. There are ways around this, such as the approach we use in musl (having both a waiters counter and a new-waiter flag on the atomic so that the waiters count can be read first), but such approaches would be fairly invasive and would require careful review. I think we could fix the most common manifestation of this bug simply by moving the load of the PRIVATE field to take place before the atomic instruction. With that change, the only observably incorrect behavior possible would be invalid memory access (SIGSEGV or SIGBUS) if the storage for the semaphore was actually unmapped (munmap or negative sbrk). This is still a possibility, and thus still a bug which should be fixed, but it's much less likely/common than the EINVAL issue that was actually reported. -- You are receiving this mail because: You are on the CC list for the bug.