[PATCH] nptl: Use a PI-aware lock for internal pthread_cond-related locking

[Sebastian Andrzej Siewior]

On 2025-09-09 10:09:36 [-0300], Adhemerval Zanella Netto wrote:
> > Okay. Since that one is static, I guess I would have to make my own
> > check in pthread_cond.
> > 
> 
> Or move the prio_inherit_missing to its own TU and use is an internal
> symbol.
okay.

> Right, but at least for glibc we will need to keep the runtime check
> because we still support old kernels.

I see. Is there a minimum old kernel? And will this increased somehow
based on LTS support or y2038 requirements?

Basically we have this due to old ARM machines :)

> >>> --- a/nptl/pthread_cond_common.c
> >>> +++ b/nptl/pthread_cond_common.c
> >>> @@ -106,41 +106,23 @@ __condvar_fetch_xor_wseq_release (pthread_cond_t *cond, unsigned int val)
> > …
> >>>  static void __attribute__ ((unused))
> >>>  __condvar_acquire_lock (pthread_cond_t *cond, int private)
> >>>  {
> > …
> >>> +      int e;
> >>> +
> >>> +      e = __futex_lock_pi64 (&cond->__data.__pi_lock, 0, NULL, private);
> >>> +      if (e != 0)
> >>> +        futex_fatal_error ();
> >>
> >> The __futex_lock_pi64 already issues futex_fatal_error() non-expected return code;
> >> so I think we should only use it futex-internal.{c,h}.
> > 
> > There shouldn't be any error. There might be the case where the lock
> > owner is gone (ESRCH I believe) or the theoretical ENOMEM. ESRCH isn't
> > handled now but it can't be recognized either. It would require to kill
> > the thread owning the lock.
> > So either abort the operation if the futex-op returns an error because
> > "this shouldn't happen" or I don't know.
> > 
> 
> On pthread_mutex_lock we handle ESRCH only for non-robust PI mutexes, and
> we delay the thread indefinitely. I am not sure which is the best approach,
> but I am tending for the delay one for consistency.

As I wrote in my other mail, we should somehow consider this dead-owner
case but can do this loop for consistency.

> >> I am ccing Carlos, he has helped fix some issue on cond vars recently and he
> >> might have some idea if using PI aware locks does make sense here.
> >>
> >> Also, I think we really need regression testcases for this change.
> > 
> > I came up with something to test this. It required a few CPUs and task
> > pinning otherwise the small window didn't trigger.
> 
> Right, I think the idea would to provide a way to over multiples runs from
> multiple developers in multiple machines we can assume that this is triggered.
> I agree that for such problems is really hard to come up with reliable test
> cases without spending a lot of cpu time.

Let me clean this up, follow the testsuite approach. I did verify it in
the with the syscall tracer that the case triggered. So it run a few
times and assume it touched the PI paths.

> > 
> >>>      }
> >>>  }

Sebastian