All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Sebastian Sewior <bigeasy@linutronix.de>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@kernel.org>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-s390@vger.kernel.org, Stefan Liebler <stli@linux.ibm.com>
Subject: Re: WARN_ON_ONCE(!new_owner) within wake_futex_pi() triggered
Date: Wed, 30 Jan 2019 15:33:47 +0100 (CET)	[thread overview]
Message-ID: <alpine.DEB.2.21.1901301517220.1950@nanos.tec.linutronix.de> (raw)
In-Reply-To: <alpine.DEB.2.21.1901301428390.5537@nanos.tec.linutronix.de>

[-- Attachment #1: Type: text/plain, Size: 2732 bytes --]

On Wed, 30 Jan 2019, Thomas Gleixner wrote:
> On Wed, 30 Jan 2019, Sebastian Sewior wrote:
> 
> > On 2019-01-30 13:59:55 [+0100], Heiko Carstens wrote:
> > > Last lines of trace below (full log attached):
> > 
> >             <...>-56956 [005] ....   658.931364: handle_futex_death: uaddr: 3ff9e880c58 pi: 1
> > …
> >             <...>-56956 [005] ....   658.931369: handle_futex_death: uaddr: 3ff9e8808c0 success
> >             <...>-56956 [005] ....   658.931370: sched_process_exit: comm=ld64.so.1 pid=56956 prio=120
> > 
> > not including 3ff9e880140
> > 
> >             <...>-56956 [005] ....   658.931370: sched_process_exit: comm=ld64.so.1 pid=56956 prio=120
> > 
> >             <...>-56496 [001] ....   658.932404: sys_futex(uaddr: 3ff9e880140, op: 6, val: 1, utime: 0, uaddr2: 5, val3: 0)
> >             <...>-56496 [001] ....   658.932405: attach_to_pi_owner: Missing pid 56956
> >             <...>-56496 [001] ....   658.932406: handle_exit_race: uval2 vs uval 8000de7c vs 8000de7c (-1)
> >             <...>-56496 [001] ....   658.932501: sys_futex -> 0xfffffffffffffffd
> > …
> >             <...>-56496 [001] ....   659.020750: handle_futex_death: uaddr: 3ff9e880140 pi: 1
> >             <...>-56496 [001] ....   659.020750: handle_futex_death: uaddr: 3ff9e880140 uval: 8000de7c
> >             <...>-56496 [001] ....   659.020750: handle_futex_death: uaddr: 3ff9e880140 success
> > 
> > and here we have it.

Well no. That futex is in the robust list of the dying task because it
tried to lock it and then died probably before removing itself from the
robust list.

handle_futex_death() of that task does not touch it because the userspace
TID value is de7c which is 56956.

The last entries with that uaddr are:

          <...>-56956 [005] ....   658.923608: sys_futex(uaddr: 3ff9e880140, op: 7, val: 3ff00000007, utime: 3ff9b078910, uaddr2: 3ff9b078910, val3: 3ffea67e3f7)

UNLOCK

           <...>-56945 [006] ....   658.923612: sys_futex(uaddr: 3ff9e880140, op: 6, val: 1, utime: 1003ff0, uaddr2: 3ff9e87f910, val3: 3ff0000de71)

LOCK

           <...>-56956 [005] ....   658.923612: sys_futex(uaddr: 3ff9e880140, op: 7, val: 3ff00000007, utime: 3ff9b078910, uaddr2: 3ff9b078910, val3: 3ffea67e3f7)

UNLOCK

           <...>-56945 [006] ....   658.923830: sys_futex(uaddr: 3ff9e880140, op: 7, val: 3ff00000007, utime: 3ff9e87f910, uaddr2: 3ff9e87f910, val3: 3ffea67e3f7)

UNLOCK

           <...>-56496 [001] ....   658.932404: sys_futex(uaddr: 3ff9e880140, op: 6, val: 1, utime: 0, uaddr2: 5, val3: 0)

LOCK which fails.

This does not make any sense. The last kernel visible operation of 56956 on
that uaddr is the UNLOCK above.

I need to think some more about what might happen.

Thanks,

	tglx




  reply	other threads:[~2019-01-30 14:34 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-27  8:11 WARN_ON_ONCE(!new_owner) within wake_futex_pi() triggered Heiko Carstens
2018-11-28 14:32 ` Thomas Gleixner
2018-11-29 11:23   ` Heiko Carstens
2019-01-21 12:21     ` Heiko Carstens
2019-01-21 13:12       ` Thomas Gleixner
2019-01-22 21:14         ` Thomas Gleixner
2019-01-23  9:24           ` Heiko Carstens
2019-01-23 12:33             ` Thomas Gleixner
2019-01-23 12:40               ` Heiko Carstens
2019-01-28 13:44     ` Peter Zijlstra
2019-01-28 13:58       ` Peter Zijlstra
2019-01-28 15:53         ` Thomas Gleixner
2019-01-29  8:49           ` Peter Zijlstra
2019-01-29 22:15             ` [PATCH] futex: Handle early deadlock return correctly Thomas Gleixner
2019-01-30 12:01               ` Thomas Gleixner
2019-02-08 12:05               ` [tip:locking/urgent] " tip-bot for Thomas Gleixner
2019-01-29  9:01           ` WARN_ON_ONCE(!new_owner) within wake_futex_pi() triggered Heiko Carstens
2019-01-29  9:33             ` Peter Zijlstra
2019-01-29  9:45             ` Thomas Gleixner
2019-01-29 10:24               ` Heiko Carstens
2019-01-29 10:35                 ` Peter Zijlstra
2019-01-29 13:03                   ` Thomas Gleixner
2019-01-29 13:23                     ` Heiko Carstens
     [not found]                       ` <20190129151058.GG26906@osiris>
2019-01-29 17:16                         ` Sebastian Sewior
2019-01-29 21:45                           ` Thomas Gleixner
     [not found]                           ` <20190130094913.GC5299@osiris>
2019-01-30 12:15                             ` Thomas Gleixner
     [not found]                               ` <20190130125955.GD5299@osiris>
2019-01-30 13:24                                 ` Sebastian Sewior
2019-01-30 13:29                                   ` Thomas Gleixner
2019-01-30 14:33                                     ` Thomas Gleixner [this message]
2019-01-30 17:56                                       ` Thomas Gleixner
2019-01-30 21:07                                         ` Sebastian Sewior
2019-01-30 23:13                                           ` WARN_ON_ONCE(!new_owner) within wake_futex_pi() triggerede Thomas Gleixner
2019-01-30 23:35                                             ` Paul E. McKenney
2019-01-30 23:55                                               ` Thomas Gleixner
2019-01-31  0:27                                                 ` Thomas Gleixner
2019-01-31  1:45                                                   ` Paul E. McKenney
2019-01-31 16:52                                                   ` Heiko Carstens
2019-01-31 17:06                                                     ` Sebastian Sewior
2019-01-31 20:42                                                       ` Heiko Carstens
2019-02-01 16:12                                                       ` Heiko Carstens
2019-02-01 21:59                                                         ` Thomas Gleixner
     [not found]                                                           ` <20190202091043.GA3381@osiris>
2019-02-02 10:14                                                             ` Thomas Gleixner
2019-02-02 11:20                                                               ` Heiko Carstens
2019-02-03 16:30                                                                 ` Thomas Gleixner
2019-02-04 11:40                                                                   ` Heiko Carstens
2019-01-31  1:44                                                 ` Paul E. McKenney
2019-01-30 13:25                                 ` WARN_ON_ONCE(!new_owner) within wake_futex_pi() triggered Thomas Gleixner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.21.1901301517220.1950@nanos.tec.linutronix.de \
    --to=tglx@linutronix.de \
    --cc=bigeasy@linutronix.de \
    --cc=heiko.carstens@de.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=schwidefsky@de.ibm.com \
    --cc=stli@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.