Messages in this thread | | | Date | Fri, 13 Jun 2014 10:34:33 +0200 (CEST) | From | Thomas Gleixner <> | Subject | Re: [patch 5/5] futex: Simplify futex_lock_pi_atomic() and make it more robust |
| |
On Thu, 12 Jun 2014, Darren Hart wrote:
> On Wed, 2014-06-11 at 20:45 +0000, Thomas Gleixner wrote: > > futex_lock_pi_atomic() is a maze of retry hoops and loops. > > > > Reduce it to simple and understandable states: > > Heh... well... > > With this patch applied (1-4 will not reproduce without 5), if userspace > wrongly sets the uval to 0, the pi_state can end up being NULL for a > subsequent requeue_pi operation: > > [ 10.426159] requeue: 00000000006022e0 to 00000000006022e4 > [ 10.427737] this:ffff88013a637da8 > [ 10.428749] waking:ffff88013a637da8 > fut2 = 0 > [ 10.429994] comparing requeue_pi_key > [ 10.431034] prepare waiter to take the rt_mutex > [ 10.432344] pi_state: (null) > [ 10.433414] BUG: unable to handle kernel NULL pointer dereference at > 0000000000000038 > > This occurs in the requeue loop, in the requeue_pi block at: > > atomic_inc(&pi_state->refcount);
Hmm. Took me some time to reproduce. Digging into it now.
Thanks,
tglx
| |