Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1623674 > unrolled thread

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

Started byTony Lindgren <tony@atomide.com>
First post2017-04-14 16:10 +0200
Last post2017-04-14 16:30 +0200
Articles 4 — 2 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH] futex: Fix hrtimer oops in futex_lock_pi() Tony Lindgren <tony@atomide.com> - 2017-04-14 16:10 +0200
    Re: [PATCH] futex: Fix hrtimer oops in futex_lock_pi() Tony Lindgren <tony@atomide.com> - 2017-04-14 16:30 +0200
      Re: [PATCH] futex: Fix hrtimer oops in futex_lock_pi() Tony Lindgren <tony@atomide.com> - 2017-04-14 16:50 +0200
    Re: [PATCH] futex: Fix hrtimer oops in futex_lock_pi() Peter Zijlstra <peterz@infradead.org> - 2017-04-14 16:30 +0200

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

FromTony Lindgren <tony@atomide.com>
Date2017-04-14 16:10 +0200
Subject[PATCH] futex: Fix hrtimer oops in futex_lock_pi()
Message-ID<twa5c-22B-13@gated-at.bofh.it>
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

[toc] | [next] | [standalone]


#1623687

FromTony Lindgren <tony@atomide.com>
Date2017-04-14 16:30 +0200
Message-ID<twaoy-29o-19@gated-at.bofh.it>
In reply to#1623674
* 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

[toc] | [prev] | [next] | [standalone]


#1623708

FromTony Lindgren <tony@atomide.com>
Date2017-04-14 16:50 +0200
Message-ID<twaHT-2g9-11@gated-at.bofh.it>
In reply to#1623687
* 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

[toc] | [prev] | [next] | [standalone]


#1623695

FromPeter Zijlstra <peterz@infradead.org>
Date2017-04-14 16:30 +0200
Message-ID<twaoy-29o-21@gated-at.bofh.it>
In reply to#1623674
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.

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web