[PATCH] Fix unbalanced nwaiters counting in sem_wait (bug 32436)

[Andreas Schwab]

On Dez 09 2024, Carlos O'Donell wrote:

> On 12/9/24 8:03 AM, Andreas Schwab wrote:
>> When __new_sem_wait_slow64 is entered while a token is available on the
>> semaphore it decrements the nwaiters field by one too much (in the
>> __HAVE_64B_ATOMICS case).  The initial increment remembers the value
>> before the increment, so the final decrement will set the counter to one
>> smaller than before entry.
>
> Is it possible to write a test the triggers this reliably?

The probability of the error is extremly low.  The other thread posting
the semaphore must hit the tiny window between the calls to
__new_sem_wait_fast and __new_sem_wait_slow64 in __new_sem_wait.  I've
only found it by code inspection, I don't even know how to observe it.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."