futex: requeue_pi lock steal deadlock fixes
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest2 patches 7 repliesIn review
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/2 | Update woken requeued futex_q lock_ptrkernel/ | +4 | 7 replies | |
| 2/2 | Avoid deadlock in rt_mutex_start_proxy_lock()kernel/ | +0 | 0 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH 0/2] futex: requeue_pi lock steal deadlock fixes
[resend: quilt mail wasn't making it to the lists for some reason]
The following patch series addresses a deadlock and a race related to the newly introduced requeue_pi futex op codes. I discovered this while running I modified version of pthread_cond_many from ltp/testcases/realtime (with a PI aware mutex) and a patched glibc (for new futex op codes). These patches fix the deadlock and close the race window considerably - but not 100%. My test case, however, now runs to completion without deadlock, and without triggering the pi_state related WARN_ON()'s.
Signature · 3 lines
Darren Hart IBM Linux Technology Center Real-Time Linux Team