Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1496579
| From | Peter Zijlstra <peterz@infradead.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RFC][PATCH 4/4] futex: Rewrite FUTEX_UNLOCK_PI |
| Date | 2016-10-06 12:30 +0200 |
| Message-ID | <spe66-7jB-25@gated-at.bofh.it> (permalink) |
| References | <so7Jo-32K-13@gated-at.bofh.it> <so7Jo-32K-15@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Mon, Oct 03, 2016 at 11:12:38AM +0200, Peter Zijlstra wrote: > There's a number of 'interesting' problems with FUTEX_UNLOCK_PI, all > caused by holding hb->lock while doing the rt_mutex_unlock() > equivalient. > > This patch doesn't attempt to fix any of the actual problems, but > instead reworks the code to not hold hb->lock across the unlock, > paving the way to actually fix the problems later. > > The current reason we hold hb->lock over unlock is that it serializes > against FUTEX_LOCK_PI and avoids new waiters from coming in, this then > ensures the rt_mutex_next_owner() value is stable and can be written > into the user-space futex value before doing the unlock. Such that the > unlock will indeed end up at new_owner. > > This patch recognises that holding rt_mutex::wait_lock results in the > very same guarantee, no new waiters can come in while we hold that > lock -- after all, waiters would need this lock to queue themselves. > > It therefore restructures the code to keep rt_mutex::wait_lock held. > > This (of course) is not entirely straight forward either, see the > comment in rt_mutex_slowunlock(), doing the unlock itself might drop > wait_lock, letting new waiters in. To cure this > rt_mutex_futex_unlock() becomes a variant of rt_mutex_slowunlock() > that return -EAGAIN instead. This ensures the FUTEX_UNLOCK_PI code > aborts and restarts the entire operation. Urgh, I missed a bunch :/ So there's the !new_owner case in wake_futex_pi() which can happen if futex_lock_pi()'s rt_mutex_timed_futex_lock() failed but we still see that task on the futex_q list (it hasn't yet done unqueue_me). I wondered if we could sort this case by making fixup_owner() more interesting, which got me looking at that. And it turns out fixup_owner() relies on futex_pi_unlock() holding hb->lock as well.. It does rt_mutex_owner() while holding wait_lock, but then drops wait_lock to call fixup_pi_state_owner(), assuming the owner it read remains valid. ARGGH, what a mess. Lemme stare at this more..
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[RFC][PATCH 0/4] FUTEX_UNLOCK_PI wobbles Peter Zijlstra <peterz@infradead.org> - 2016-10-03 11:30 +0200
[RFC][PATCH 4/4] futex: Rewrite FUTEX_UNLOCK_PI Peter Zijlstra <peterz@infradead.org> - 2016-10-03 11:30 +0200
Re: [RFC][PATCH 4/4] futex: Rewrite FUTEX_UNLOCK_PI Steven Rostedt <rostedt@goodmis.org> - 2016-10-03 17:40 +0200
Re: [RFC][PATCH 4/4] futex: Rewrite FUTEX_UNLOCK_PI Peter Zijlstra <peterz@infradead.org> - 2016-10-03 17:50 +0200
Re: [RFC][PATCH 4/4] futex: Rewrite FUTEX_UNLOCK_PI Steven Rostedt <rostedt@goodmis.org> - 2016-10-03 18:30 +0200
Re: [RFC][PATCH 4/4] futex: Rewrite FUTEX_UNLOCK_PI Peter Zijlstra <peterz@infradead.org> - 2016-10-03 17:50 +0200
Re: [RFC][PATCH 4/4] futex: Rewrite FUTEX_UNLOCK_PI Sebastian Andrzej Siewior <bigeasy@linutronix.de> - 2016-10-05 09:50 +0200
Re: [RFC][PATCH 4/4] futex: Rewrite FUTEX_UNLOCK_PI Peter Zijlstra <peterz@infradead.org> - 2016-10-05 10:10 +0200
Re: [RFC][PATCH 4/4] futex: Rewrite FUTEX_UNLOCK_PI Sebastian Andrzej Siewior <bigeasy@linutronix.de> - 2016-10-05 10:30 +0200
Re: [RFC][PATCH 4/4] futex: Rewrite FUTEX_UNLOCK_PI Peter Zijlstra <peterz@infradead.org> - 2016-10-05 10:40 +0200
Re: [RFC][PATCH 4/4] futex: Rewrite FUTEX_UNLOCK_PI Peter Zijlstra <peterz@infradead.org> - 2016-10-06 12:30 +0200
Re: [RFC][PATCH 4/4] futex: Rewrite FUTEX_UNLOCK_PI Peter Zijlstra <peterz@infradead.org> - 2016-10-07 13:30 +0200
Re: [RFC][PATCH 4/4] futex: Rewrite FUTEX_UNLOCK_PI Thomas Gleixner <tglx@linutronix.de> - 2016-10-08 18:00 +0200
Re: [RFC][PATCH 4/4] futex: Rewrite FUTEX_UNLOCK_PI Peter Zijlstra <peterz@infradead.org> - 2016-10-08 19:00 +0200
Re: [RFC][PATCH 4/4] futex: Rewrite FUTEX_UNLOCK_PI Thomas Gleixner <tglx@linutronix.de> - 2016-10-08 19:10 +0200
Re: [RFC][PATCH 4/4] futex: Rewrite FUTEX_UNLOCK_PI Thomas Gleixner <tglx@linutronix.de> - 2016-10-10 12:30 +0200
Re: [RFC][PATCH 4/4] futex: Rewrite FUTEX_UNLOCK_PI Peter Zijlstra <peterz@infradead.org> - 2016-10-10 13:50 +0200
Re: [RFC][PATCH 4/4] futex: Rewrite FUTEX_UNLOCK_PI Thomas Gleixner <tglx@linutronix.de> - 2016-10-08 20:30 +0200
Re: [RFC][PATCH 4/4] futex: Rewrite FUTEX_UNLOCK_PI Thomas Gleixner <tglx@linutronix.de> - 2016-10-09 13:30 +0200
Re: [RFC][PATCH 4/4] futex: Rewrite FUTEX_UNLOCK_PI Peter Zijlstra <peterz@infradead.org> - 2016-10-10 16:10 +0200
[RFC][PATCH 1/4] futex: Cleanup variable names for futex_top_waiter() Peter Zijlstra <peterz@infradead.org> - 2016-10-03 11:30 +0200
Re: [RFC][PATCH 1/4] futex: Cleanup variable names for futex_top_waiter() Steven Rostedt <rostedt@goodmis.org> - 2016-10-03 16:20 +0200
Re: [RFC][PATCH 1/4] futex: Cleanup variable names for futex_top_waiter() Davidlohr Bueso <dave@stgolabs.net> - 2016-10-05 06:00 +0200
[RFC][PATCH 3/4] futex: Remove rt_mutex_deadlock_account_*() Peter Zijlstra <peterz@infradead.org> - 2016-10-03 11:30 +0200
Re: [RFC][PATCH 3/4] futex: Remove rt_mutex_deadlock_account_*() Peter Zijlstra <peterz@infradead.org> - 2016-10-03 11:40 +0200
Re: [RFC][PATCH 3/4] futex: Remove rt_mutex_deadlock_account_*() Steven Rostedt <rostedt@goodmis.org> - 2016-10-03 16:30 +0200
Re: [RFC][PATCH 3/4] futex: Remove rt_mutex_deadlock_account_*() Davidlohr Bueso <dave@stgolabs.net> - 2016-10-05 03:10 +0200
Re: [RFC][PATCH 3/4] futex: Remove rt_mutex_deadlock_account_*() Sebastian Andrzej Siewior <bigeasy@linutronix.de> - 2016-10-05 09:40 +0200
Re: [RFC][PATCH 0/4] FUTEX_UNLOCK_PI wobbles Davidlohr Bueso <dave@stgolabs.net> - 2016-10-05 03:10 +0200
Re: [RFC][PATCH 0/4] FUTEX_UNLOCK_PI wobbles Peter Zijlstra <peterz@infradead.org> - 2016-10-05 08:30 +0200
Re: [RFC][PATCH 0/4] FUTEX_UNLOCK_PI wobbles Sebastian Andrzej Siewior <bigeasy@linutronix.de> - 2016-10-05 09:30 +0200
Re: [RFC][PATCH 0/4] FUTEX_UNLOCK_PI wobbles Davidlohr Bueso <dave@stgolabs.net> - 2016-10-05 18:10 +0200
csiph-web