[PATCH] futex: Fix hrtimer oops in futex_lock_pi()

[PATCH] futex: Fix hrtimer oops in futex_lock_pi()

[Tony Lindgren]

Commit cfafcd117da0 ("futex: Rework futex_lock_pi() to use
rt_mutex_*_proxy_lock()") caused a regression where things would
occasionally randomly oops when restarting X:

Unable to handle kernel NULL pointer dereference at virtual address 00000000
...
Internal error: Oops: 80000005 [#1] SMP ARM
...
PC is at 0x0
LR is at __hrtimer_run_queues+0x138/0x58c
pc : [<00000000>]    lr : [<c01c7884>]    psr: 20000193
...
[<c01c7884>] (__hrtimer_run_queues) from [<c01c7f4c>]
(hrtimer_interrupt+0xbc/0x210)
[<c01c7f4c>] (hrtimer_interrupt) from [<c010fcfc>]
...

When this happens, the hrtimer is not properly initialized and it's
function is NULL. This happens because we now call hrtimer_start_expires()
in futex_lock_pi() for the timer initialized with hrtimer_init_on_stack().

To fix it, let's pair the hrtimer_start_expires() with hrtimer_cancel()
in the same function.

Fixes: cfafcd117da0 ("futex: Rework futex_lock_pi() to use
rt_mutex_*_proxy_lock()")
Cc: juri.lelli@arm.com
Cc: bigeasy@linutronix.de
Cc: xlpang@redhat.com
Cc: rostedt@goodmis.org
Cc: mathieu.desnoyers@efficios.com
Cc: jdesfossez@efficios.com
Cc: dvhart@infradead.org
Cc: bristot@redhat.com
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 kernel/futex.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/kernel/futex.c b/kernel/futex.c
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -2736,8 +2736,10 @@ static int futex_lock_pi(u32 __user *uaddr, unsigned int flags,
 out_put_key:
 	put_futex_key(&q.key);
 out:
-	if (to)
+	if (to) {
+		hrtimer_cancel(&to->timer);
 		destroy_hrtimer_on_stack(&to->timer);
+	}
 	return ret != -EINTR ? ret : -ERESTARTNOINTR;
 
 uaddr_faulted:
-- 
2.12.2

Re: [PATCH] futex: Fix hrtimer oops in futex_lock_pi()

[Peter Zijlstra]

On Fri, Apr 14, 2017 at 07:08:19AM -0700, Tony Lindgren wrote:
> Commit cfafcd117da0 ("futex: Rework futex_lock_pi() to use
> rt_mutex_*_proxy_lock()") caused a regression where things would
> occasionally randomly oops when restarting X:
> 
> Unable to handle kernel NULL pointer dereference at virtual address 00000000
> ...
> Internal error: Oops: 80000005 [#1] SMP ARM
> ...
> PC is at 0x0
> LR is at __hrtimer_run_queues+0x138/0x58c
> pc : [<00000000>]    lr : [<c01c7884>]    psr: 20000193
> ...
> [<c01c7884>] (__hrtimer_run_queues) from [<c01c7f4c>]
> (hrtimer_interrupt+0xbc/0x210)
> [<c01c7f4c>] (hrtimer_interrupt) from [<c010fcfc>]
> ...
> 
> When this happens, the hrtimer is not properly initialized and it's
> function is NULL. This happens because we now call hrtimer_start_expires()
> in futex_lock_pi() for the timer initialized with hrtimer_init_on_stack().
> 
> To fix it, let's pair the hrtimer_start_expires() with hrtimer_cancel()
> in the same function.

Already fixed:

  https://lkml.kernel.org/r/tip-97181f9bd57405b879403763284537e27d46963d@git.kernel.org

Thanks for the patch though.

Re: [PATCH] futex: Fix hrtimer oops in futex_lock_pi()

[Tony Lindgren]

* Peter Zijlstra <peterz@infradead.org> [170414 07:25]:
> On Fri, Apr 14, 2017 at 07:08:19AM -0700, Tony Lindgren wrote:
> > Commit cfafcd117da0 ("futex: Rework futex_lock_pi() to use
> > rt_mutex_*_proxy_lock()") caused a regression where things would
> > occasionally randomly oops when restarting X:
> > 
> > Unable to handle kernel NULL pointer dereference at virtual address 00000000
> > ...
> > Internal error: Oops: 80000005 [#1] SMP ARM
> > ...
> > PC is at 0x0
> > LR is at __hrtimer_run_queues+0x138/0x58c
> > pc : [<00000000>]    lr : [<c01c7884>]    psr: 20000193
> > ...
> > [<c01c7884>] (__hrtimer_run_queues) from [<c01c7f4c>]
> > (hrtimer_interrupt+0xbc/0x210)
> > [<c01c7f4c>] (hrtimer_interrupt) from [<c010fcfc>]
> > ...
> > 
> > When this happens, the hrtimer is not properly initialized and it's
> > function is NULL. This happens because we now call hrtimer_start_expires()
> > in futex_lock_pi() for the timer initialized with hrtimer_init_on_stack().
> > 
> > To fix it, let's pair the hrtimer_start_expires() with hrtimer_cancel()
> > in the same function.
> 
> Already fixed:
> 
>   https://lkml.kernel.org/r/tip-97181f9bd57405b879403763284537e27d46963d@git.kernel.org
> 
> Thanks for the patch though.

Oh OK thanks. It seems to be missing in Linux next though.

Regards,

Tony

Re: [PATCH] futex: Fix hrtimer oops in futex_lock_pi()

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [170414 07:28]:
> * Peter Zijlstra <peterz@infradead.org> [170414 07:25]:
> > On Fri, Apr 14, 2017 at 07:08:19AM -0700, Tony Lindgren wrote:
> > > Commit cfafcd117da0 ("futex: Rework futex_lock_pi() to use
> > > rt_mutex_*_proxy_lock()") caused a regression where things would
> > > occasionally randomly oops when restarting X:
> > > 
> > > Unable to handle kernel NULL pointer dereference at virtual address 00000000
> > > ...
> > > Internal error: Oops: 80000005 [#1] SMP ARM
> > > ...
> > > PC is at 0x0
> > > LR is at __hrtimer_run_queues+0x138/0x58c
> > > pc : [<00000000>]    lr : [<c01c7884>]    psr: 20000193
> > > ...
> > > [<c01c7884>] (__hrtimer_run_queues) from [<c01c7f4c>]
> > > (hrtimer_interrupt+0xbc/0x210)
> > > [<c01c7f4c>] (hrtimer_interrupt) from [<c010fcfc>]
> > > ...
> > > 
> > > When this happens, the hrtimer is not properly initialized and it's
> > > function is NULL. This happens because we now call hrtimer_start_expires()
> > > in futex_lock_pi() for the timer initialized with hrtimer_init_on_stack().
> > > 
> > > To fix it, let's pair the hrtimer_start_expires() with hrtimer_cancel()
> > > in the same function.
> > 
> > Already fixed:
> > 
> >   https://lkml.kernel.org/r/tip-97181f9bd57405b879403763284537e27d46963d@git.kernel.org
> > 
> > Thanks for the patch though.
> 
> Oh OK thanks. It seems to be missing in Linux next though.

Oh it was just committed, I see it now in tip after git fetch.
So should be heading into nex soon.

Tony