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


Groups > linux.kernel > #1620147 > unrolled thread

Re: [PATCH -v6 11/13] futex: Rework futex_lock_pi() to use rt_mutex_*_proxy_lock()

Started byalexander.levin@verizon.com
First post2017-04-10 18:00 +0200
Last post2017-04-14 11:40 +0200
Articles 3 — 3 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH -v6 11/13] futex: Rework futex_lock_pi() to use  rt_mutex_*_proxy_lock() alexander.levin@verizon.com - 2017-04-10 18:00 +0200
    Re: [PATCH -v6 11/13] futex: Rework futex_lock_pi() to use  rt_mutex_*_proxy_lock() Thomas Gleixner <tglx@linutronix.de> - 2017-04-10 18:10 +0200
      [tip:locking/core] futex: Avoid freeing an active timer tip-bot for Thomas Gleixner <tipbot@zytor.com> - 2017-04-14 11:40 +0200

#1620147 — Re: [PATCH -v6 11/13] futex: Rework futex_lock_pi() to use rt_mutex_*_proxy_lock()

Fromalexander.levin@verizon.com
Date2017-04-10 18:00 +0200
SubjectRe: [PATCH -v6 11/13] futex: Rework futex_lock_pi() to use rt_mutex_*_proxy_lock()
Message-ID<tuJTv-2D4-91@gated-at.bofh.it>
On Wed, Mar 22, 2017 at 11:35:58AM +0100, Peter Zijlstra wrote:
> By changing futex_lock_pi() to use rt_mutex_*_proxy_lock() we arrive
> at a point where all wait_list modifications are done under both
> hb->lock and wait_lock.
[...]

Hey Peter,

I'm seeing the following, which seems to be related to this patch:

[   21.762875] ODEBUG: free active (active state 0) object type: hrtimer hint: hrtimer_wakeup (kernel/time/hrtimer.c:1423)
[   21.771034] ------------[ cut here ]------------
[   21.771657] WARNING: CPU: 6 PID: 1974 at lib/debugobjects.c:289 debug_print_object (lib/debugobjects.c:286)
[   21.772872] Modules linked in:
[   21.773323] CPU: 6 PID: 1974 Comm: trinity-c92 Not tainted 4.11.0-rc5-next-20170407-dirty #21
[   21.774534] task: ffff880389063e40 task.stack: ffff880389158000
[   21.775383] RIP: 0010:debug_print_object (??:?)
[   21.776081] RSP: 0018:ffff88038915f108 EFLAGS: 00010086
[   21.776815] RAX: 0000000000000057 RBX: 0000000000000003 RCX: 0000000000000000
[   21.777791] RDX: 0000000000000057 RSI: 1ffff1007122bdc0 RDI: ffffed007122be17
[   21.778773] RBP: ffff88038915f130 R08: 203a47554245444f R09: 7463612065657266
[   21.779756] R10: 0000000000000000 R11: 000000000000147e R12: ffffffff834598e0
[   21.780741] R13: ffffffff8127c150 R14: 0000000000000000 R15: ffffffff8410e588
[   21.782945] FS:  00007fd5e261f700(0000) GS:ffff88039cb80000(0000) knlGS:0000000000000000
[   21.783942] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   21.784638] CR2: 00007fd5e21f2520 CR3: 000000038d4c9000 CR4: 00000000000406a0
[   21.785718] DR0: 00007fd5e00df000 DR1: 0000000000000000 DR2: 0000000000000000
[   21.786675] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600
[   21.787684] Call Trace:
[   21.788050] debug_object_free (lib/debugobjects.c:603)
[   21.791105] destroy_hrtimer_on_stack (kernel/time/hrtimer.c:427)
[   21.791746] futex_lock_pi (kernel/futex.c:2740)
[   21.800721] do_futex (kernel/futex.c:3399)
[   21.818395] SyS_futex (kernel/futex.c:3447 kernel/futex.c:3415)
[   21.822260] do_syscall_64 (arch/x86/entry/common.c:284)
[   21.827328] entry_SYSCALL64_slow_path (arch/x86/entry/entry_64.S:249)                                                                                      [   21.827960] RIP: 0033:0x7fd5e1f2e8e9^M                                                                                                                     [   21.828455] RSP: 002b:00007ffcfe586f48 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca^M                                                                       [   21.829931] RAX: ffffffffffffffda RBX: 00000000000000ca RCX: 00007fd5e1f2e8e9^M                                                                            [   21.830875] RDX: 0000000000004000 RSI: 0000000000000086 RDI: 00007fd5e00df000^M                                                                            [   21.831783] RBP: 00007fd5e0a12000 R08: 00007fd5e2426000 R09: 008008000100a000^M                                                                            [   21.832775] R10: 00007fd5e00e1000 R11: 0000000000000246 R12: 0000000000000002^M                                                                            [   21.833705] R13: 00007fd5e0a12048 R14: 00007fd5e261f698 R15: 00007fd5e0a12000^M                                                                            [   21.834644] Code: 0d 48 89 75 d8 e8 30 01 8b ff 48 8b 75 d8 48 8b 14 dd 40 8f 51 83 4d 89 e9 4d 89 e0 44 89 f1 48 c7 c7 e0 85 51 83 e8 e3 29 75 ff <0f> ff 83 05 4a 1e 16 02 01 48 83 c4 08 5b 41 5c 41 5d 41 5e 5d 
All code                                                                                                                                                      ========
   0:   0d 48 89 75 d8          or     $0xd8758948,%eax                                                                                                          5:   e8 30 01 8b ff          callq  0xffffffffff8b013a
   a:   48 8b 75 d8             mov    -0x28(%rbp),%rsi                                                                                                          e:   48 8b 14 dd 40 8f 51    mov    -0x7cae70c0(,%rbx,8),%rdx                                                                                                15:   83                                                                                                                                                      16:   4d 89 e9                mov    %r13,%r9                                                                                                                 19:   4d 89 e0                mov    %r12,%r8                                                                                                                 1c:   44 89 f1                mov    %r14d,%ecx
  1f:   48 c7 c7 e0 85 51 83    mov    $0xffffffff835185e0,%rdi
  26:   e8 e3 29 75 ff          callq  0xffffffffff752a0e
  2b:*  0f ff                   (bad)           <-- trapping instruction
  2d:   83 05 4a 1e 16 02 01    addl   $0x1,0x2161e4a(%rip)        # 0x2161e7e
  34:   48 83 c4 08             add    $0x8,%rsp
  38:   5b                      pop    %rbx
  39:   41 5c                   pop    %r12
  3b:   41 5d                   pop    %r13
  3d:   41 5e                   pop    %r14
  3f:   5d                      pop    %rbp
        ...

Code starting with the faulting instruction
===========================================
   0:   0f ff                   (bad)
   2:   83 05 4a 1e 16 02 01    addl   $0x1,0x2161e4a(%rip)        # 0x2161e53
   9:   48 83 c4 08             add    $0x8,%rsp
   d:   5b                      pop    %rbx
   e:   41 5c                   pop    %r12
  10:   41 5d                   pop    %r13
  12:   41 5e                   pop    %r14
  14:   5d                      pop    %rbp
        ...
[   21.837142] ---[ end trace 9e2690a9beaffa07 ]---
-- 

Thanks,
Sasha

[toc] | [next] | [standalone]


#1620156

FromThomas Gleixner <tglx@linutronix.de>
Date2017-04-10 18:10 +0200
Message-ID<tuK38-2W1-17@gated-at.bofh.it>
In reply to#1620147
On Mon, 10 Apr 2017, alexander.levin@verizon.com wrote:
> On Wed, Mar 22, 2017 at 11:35:58AM +0100, Peter Zijlstra wrote:
> > By changing futex_lock_pi() to use rt_mutex_*_proxy_lock() we arrive
> > at a point where all wait_list modifications are done under both
> > hb->lock and wait_lock.
> [...]
> 
> Hey Peter,
> 
> I'm seeing the following, which seems to be related to this patch:
> 
> [   21.762875] ODEBUG: free active (active state 0) object type: hrtimer hint: hrtimer_wakeup (kernel/time/hrtimer.c:1423)

> [   21.788050] debug_object_free (lib/debugobjects.c:603)
> [   21.791105] destroy_hrtimer_on_stack (kernel/time/hrtimer.c:427)
> [   21.791746] futex_lock_pi (kernel/futex.c:2740)
> [   21.800721] do_futex (kernel/futex.c:3399)
> [   21.818395] SyS_futex (kernel/futex.c:3447 kernel/futex.c:3415)
> [   21.822260] do_syscall_64 (arch/x86/entry/common.c:284)
> [   21.827328] entry_SYSCALL64_slow_path (arch/x86/entry/entry_64.S:249)

Yep, that rework dropped the hrtimer cancel. Fix below.

Thanks,

	tglx

8<------------------------

diff --git a/kernel/futex.c b/kernel/futex.c
index c3eebcdac206..7ac167683c9f 100644
--- 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:

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


#1623609 — [tip:locking/core] futex: Avoid freeing an active timer

Fromtip-bot for Thomas Gleixner <tipbot@zytor.com>
Date2017-04-14 11:40 +0200
Subject[tip:locking/core] futex: Avoid freeing an active timer
Message-ID<tw5RU-7Pb-33@gated-at.bofh.it>
In reply to#1620156
Commit-ID:  97181f9bd57405b879403763284537e27d46963d
Gitweb:     http://git.kernel.org/tip/97181f9bd57405b879403763284537e27d46963d
Author:     Thomas Gleixner <tglx@linutronix.de>
AuthorDate: Mon, 10 Apr 2017 18:03:36 +0200
Committer:  Ingo Molnar <mingo@kernel.org>
CommitDate: Fri, 14 Apr 2017 10:29:53 +0200

futex: Avoid freeing an active timer

Alexander reported a hrtimer debug_object splat:

  ODEBUG: free active (active state 0) object type: hrtimer hint: hrtimer_wakeup (kernel/time/hrtimer.c:1423)

  debug_object_free (lib/debugobjects.c:603)
  destroy_hrtimer_on_stack (kernel/time/hrtimer.c:427)
  futex_lock_pi (kernel/futex.c:2740)
  do_futex (kernel/futex.c:3399)
  SyS_futex (kernel/futex.c:3447 kernel/futex.c:3415)
  do_syscall_64 (arch/x86/entry/common.c:284)
  entry_SYSCALL64_slow_path (arch/x86/entry/entry_64.S:249)

Which was caused by commit:

  cfafcd117da0 ("futex: Rework futex_lock_pi() to use rt_mutex_*_proxy_lock()")

... losing the hrtimer_cancel() in the shuffle. Where previously the
hrtimer_cancel() was done by rt_mutex_slowlock() we now need to do it
manually.

Reported-by: Alexander Levin <alexander.levin@verizon.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Fixes: cfafcd117da0 ("futex: Rework futex_lock_pi() to use rt_mutex_*_proxy_lock()")
Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1704101802370.2906@nanos
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 kernel/futex.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/kernel/futex.c b/kernel/futex.c
index c3eebcd..7ac1676 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -2736,8 +2736,10 @@ out_unlock_put_key:
 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:

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web