Messages in this thread | | | Date | Fri, 15 Sep 2023 15:15:11 +0200 | From | Sebastian Andrzej Siewior <> | Subject | Re: [PATCH v3 7/7] locking/rtmutex: Acquire the hb lock via trylock after wait-proxylock. |
| |
On 2023-09-15 14:58:35 [+0200], Thomas Gleixner wrote: > > + * is leaving and the uncontended path is safe to take. > > + */ > > + rt_waiter = rt_mutex_top_waiter(&pi_state->pi_mutex); > > + if (!rt_waiter) > > + goto do_uncontended; > > Leaks pi_mutex.wait_lock
and pi_state.
> Plus you need: > > diff --git a/kernel/futex/requeue.c b/kernel/futex/requeue.c > index cba8b1a6a4cc..af1427689414 100644 > --- a/kernel/futex/requeue.c > +++ b/kernel/futex/requeue.c > @@ -850,11 +850,11 @@ int futex_wait_requeue_pi(u32 __user *uaddr, unsigned int flags, > pi_mutex = &q.pi_state->pi_mutex; > ret = rt_mutex_wait_proxy_lock(pi_mutex, to, &rt_waiter); > > - /* Current is not longer pi_blocked_on */ > - spin_lock(q.lock_ptr); > + /* Add a proper comment */ > if (ret && !rt_mutex_cleanup_proxy_lock(pi_mutex, &rt_waiter)) > ret = 0; > > + spin_lock(q.lock_ptr); > debug_rt_mutex_free_waiter(&rt_waiter); > /* > * Fixup the pi_state owner and possibly acquire the lock if we
Yes, if we do this.
> > I spent quite some time to convince myself that this is correct. I was > not able to poke a hole into it. So that really should be safe to > do. Famous last words ...
Okay. Then let me collect the pieces and post a new round then.
> Thanks, > > tglx
Sebastian
| |