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

[Carlos O'Donell]

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?

> ---
>  nptl/sem_waitcommon.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/nptl/sem_waitcommon.c b/nptl/sem_waitcommon.c
> index 75fb26b6f1..22f6ab22c1 100644
> --- a/nptl/sem_waitcommon.c
> +++ b/nptl/sem_waitcommon.c
> @@ -170,7 +170,8 @@ __new_sem_wait_slow64 (struct new_sem *sem, clockid_t clockid,
>    /* Add a waiter.  Relaxed MO is sufficient because we can rely on the
>       ordering provided by the RMW operations we use.  */
>    uint64_t d = atomic_fetch_add_relaxed (&sem->data,
> -      (uint64_t) 1 << SEM_NWAITERS_SHIFT);
> +      (uint64_t) 1 << SEM_NWAITERS_SHIFT)
> +    + ((uint64_t) 1 << SEM_NWAITERS_SHIFT);
>  
>    pthread_cleanup_push (__sem_wait_cleanup, sem);
>  


-- 
Cheers,
Carlos.