lkml.org 
[lkml]   [2019]   [Jan]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: WARN_ON_ONCE(!new_owner) within wake_futex_pi() triggered
On Wed, 30 Jan 2019, Heiko Carstens wrote:
> On Tue, Jan 29, 2019 at 06:16:53PM +0100, Sebastian Sewior wrote:
> > if (unlikely(p->flags & PF_KTHREAD)) {
> > put_task_struct(p);
>
> Last lines of the trace with your additional patch (full log attached):
>
> <...>-50539 [003] .... 2376.398223: sys_futex -> 0x0
> <...>-50539 [003] .... 2376.398223: sys_futex(uaddr: 3ffb7700208, op: 6, val: 1, utime: 0, uaddr2: 3, val3: 0)
> <...>-50539 [003] .... 2376.398225: attach_to_pi_owner: Missing pid 50734
> <...>-50539 [003] .... 2376.398226: handle_exit_race: uval2 vs uval 8000c62e vs 8000c62e (-1)

So the user space value is: 8000c62e. FUTEX_WAITER bit is set and the owner
of the futex is PID 50734, which exited long time ago:

<...>-50734 [000] .... 2376.394936: sched_process_exit: comm=ld64.so.1 pid=50734 prio=120

But at least from the kernel view 50734 has released it last:

<...>-50734 [000] .... 2376.394930: sys_futex(uaddr: 3ffb7700208, op: 7, val: 3ff00000007, utime: 3ffb3ef8910, uaddr2: 3ffb3ef8910, val3: 3ffc0afe987)
<...>-50539 [003] .... 2376.398223: sys_futex(uaddr: 3ffb7700208, op: 6, val: 1, utime: 0, uaddr2: 3, val3: 0)

Now, if it would have acquired it in userspace again before exiting, then
the robust list exit code should have set the OWNER_DIED bit as well, but
that's not set....

debug patch for the robust list exit handling below.

Thanks,

tglx

8<-----------------
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -3440,10 +3440,13 @@ static int handle_futex_death(u32 __user
{
u32 uval, uninitialized_var(nval), mval;

+ trace_printk("uaddr: %lx pi: %d\n", (unsigned long) uaddr, pi);
retry:
if (get_user(uval, uaddr))
return -1;

+ trace_printk("uaddr: %lx uval: %08x\n", (unsigned long) uaddr, uval);
+
if ((uval & FUTEX_TID_MASK) == task_pid_vnr(curr)) {
/*
* Ok, this dying thread is truly holding a futex
@@ -3480,6 +3483,7 @@ static int handle_futex_death(u32 __user
if (!pi && (uval & FUTEX_WAITERS))
futex_wake(uaddr, 1, 1, FUTEX_BITSET_MATCH_ANY);
}
+ trace_printk("uaddr: %lx success\n", (unsigned long) uaddr);
return 0;
}



\
 
 \ /
  Last update: 2019-01-30 13:16    [W:0.068 / U:5.772 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site