[Bug nptl/12674] sem_post/sem_wait race causing sem_post to return EINVAL

["bugdal at aerifal dot cx" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=12674

--- Comment #16 from Rich Felker <bugdal at aerifal dot cx> ---
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.