All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Ingo Molnar <mingo@kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	"Paul E. McKenney" <paulmck@us.ibm.com>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [GIT PULL] locking fixes
Date: Mon, 22 Jan 2018 11:39:47 +0100	[thread overview]
Message-ID: <20180122103947.GD2228@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <CAMuHMdXXJkqguSOv2Sy5wCZcRBae3KHDCKX554bPfhP+=Mmqnw@mail.gmail.com>

On Mon, Jan 22, 2018 at 10:43:36AM +0100, Geert Uytterhoeven wrote:
> >  static int fixup_pi_state_owner(u32 __user *uaddr, struct futex_q *q,
> > +                               struct task_struct *argowner)
> >  {
> >         struct futex_pi_state *pi_state = q->pi_state;
> >         u32 uval, uninitialized_var(curval), newval;
> > +       struct task_struct *oldowner, *newowner;
> > +       u32 newtid;
> 
> new tid is no longer initialized...
> 
> >         int ret;
> >
> > +       lockdep_assert_held(q->lock_ptr);
> > +
> >         raw_spin_lock_irq(&pi_state->pi_mutex.wait_lock);
> >
> >         oldowner = pi_state->owner;
> > @@ -2317,11 +2316,17 @@ static int fixup_pi_state_owner(u32 __user *uaddr, struct futex_q *q,
> >                 newtid |= FUTEX_OWNER_DIED;
> 
> ... leading to a compiler warning with gcc 4.1.2:
> 
>     warning: ‘newtid’ is used uninitialized in this function
> 
> I guess newer compilers don't give the warning, as the result of the
> assignment above is not used at all, and thus may be optimized away...
> 
> >
> >         /*
> > +        * We are here because either:
> > +        *
> > +        *  - we stole the lock and pi_state->owner needs updating to reflect
> > +        *    that (@argowner == current),
> > +        *
> > +        * or:
> > +        *
> > +        *  - someone stole our lock and we need to fix things to point to the
> > +        *    new owner (@argowner == NULL).
> >          *
> > +        * Either way, we have to replace the TID in the user space variable.
> >          * This must be atomic as we have to preserve the owner died bit here.
> >          *
> >          * Note: We write the user space value _before_ changing the pi_state
> > @@ -2334,6 +2339,42 @@ static int fixup_pi_state_owner(u32 __user *uaddr, struct futex_q *q,
> >          * in the PID check in lookup_pi_state.
> >          */
> >  retry:
> > +       if (!argowner) {
> > +               if (oldowner != current) {
> > +                       /*
> > +                        * We raced against a concurrent self; things are
> > +                        * already fixed up. Nothing to do.
> > +                        */
> > +                       ret = 0;
> > +                       goto out_unlock;
> > +               }
> > +
> > +               if (__rt_mutex_futex_trylock(&pi_state->pi_mutex)) {
> > +                       /* We got the lock after all, nothing to fix. */
> > +                       ret = 0;
> > +                       goto out_unlock;
> > +               }
> > +
> > +               /*
> > +                * Since we just failed the trylock; there must be an owner.
> > +                */
> > +               newowner = rt_mutex_owner(&pi_state->pi_mutex);
> > +               BUG_ON(!newowner);
> > +       } else {
> > +               WARN_ON_ONCE(argowner != current);
> > +               if (oldowner == current) {
> > +                       /*
> > +                        * We raced against a concurrent self; things are
> > +                        * already fixed up. Nothing to do.
> > +                        */
> > +                       ret = 0;
> > +                       goto out_unlock;
> > +               }
> > +               newowner = argowner;
> > +       }
> > +
> > +       newtid = task_pid_vnr(newowner) | FUTEX_WAITERS;
> 
> ... since it is always overwritten here.
> 
> Is that intentional?

No, I think you actually spotted a bug there. We now can't set
OWNER_DIED anymore, which is bad.

I think the below fixes things, but let me go trawl through the various
futex test things, because I think I've seen a unit test for this
_somewhere_.

---
 kernel/futex.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/kernel/futex.c b/kernel/futex.c
index 8c5424dd5924..7f719d110908 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -2311,9 +2311,6 @@ static int fixup_pi_state_owner(u32 __user *uaddr, struct futex_q *q,
 	raw_spin_lock_irq(&pi_state->pi_mutex.wait_lock);
 
 	oldowner = pi_state->owner;
-	/* Owner died? */
-	if (!pi_state->owner)
-		newtid |= FUTEX_OWNER_DIED;
 
 	/*
 	 * We are here because either:
@@ -2374,6 +2371,9 @@ static int fixup_pi_state_owner(u32 __user *uaddr, struct futex_q *q,
 	}
 
 	newtid = task_pid_vnr(newowner) | FUTEX_WAITERS;
+	/* Owner died? */
+	if (!pi_state->owner)
+		newtid |= FUTEX_OWNER_DIED;
 
 	if (get_futex_value_locked(&uval, uaddr))
 		goto handle_fault;

  reply	other threads:[~2018-01-22 10:39 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-17 15:24 [GIT PULL] locking fixes Ingo Molnar
2018-01-22  9:43 ` Geert Uytterhoeven
2018-01-22 10:39   ` Peter Zijlstra [this message]
2018-01-23 16:19     ` [PATCH] futex: Fix OWNER_DEAD fixup Peter Zijlstra
2018-01-24 10:37     ` [tip:locking/urgent] " tip-bot for Peter Zijlstra
  -- strict thread matches above, loose matches on Subject: below --
2026-04-24 13:49 [GIT PULL] locking fixes Ingo Molnar
2026-04-24 18:32 ` pr-tracker-bot
2026-03-29  5:20 Ingo Molnar
2026-03-29 17:29 ` pr-tracker-bot
2025-12-06 11:32 Ingo Molnar
2025-12-06 20:42 ` pr-tracker-bot
2025-09-26 13:46 Ingo Molnar
2025-09-26 20:44 ` pr-tracker-bot
2025-03-28 21:05 Ingo Molnar
2025-03-30 23:04 ` pr-tracker-bot
2025-03-14  9:06 Ingo Molnar
2025-03-14 20:14 ` pr-tracker-bot
2023-09-22 10:12 Ingo Molnar
2023-09-22 20:19 ` pr-tracker-bot
2021-07-11 13:22 Ingo Molnar
2021-07-11 18:22 ` pr-tracker-bot
2021-04-11 12:14 Ingo Molnar
2021-04-11 18:56 ` pr-tracker-bot
2021-03-21 10:53 Ingo Molnar
2021-03-21 18:45 ` pr-tracker-bot
2020-12-27  9:50 Ingo Molnar
2020-12-27 17:27 ` pr-tracker-bot
2020-08-15 11:13 Ingo Molnar
2020-08-16  1:55 ` pr-tracker-bot
2020-01-18 17:53 Ingo Molnar
2020-01-18 21:05 ` pr-tracker-bot
2019-12-17 11:27 Ingo Molnar
2019-12-17 19:20 ` pr-tracker-bot
2019-04-20  7:30 Ingo Molnar
2019-04-20 16:51 ` Linus Torvalds
2019-04-21 18:23   ` Ingo Molnar
2019-04-20 19:25 ` pr-tracker-bot
2019-02-10  8:53 Ingo Molnar
2019-02-10 18:30 ` pr-tracker-bot
2018-10-05  9:36 Ingo Molnar
2018-10-05 23:06 ` Greg Kroah-Hartman
2018-09-15 12:56 Ingo Molnar
2018-07-30 17:49 Ingo Molnar
2018-03-25  8:49 Ingo Molnar
2018-02-15  0:50 Ingo Molnar
2018-01-12 13:45 Ingo Molnar
2017-12-15 15:55 Ingo Molnar
2017-10-14 16:01 Ingo Molnar
2017-03-07 20:27 Ingo Molnar
2017-02-28  7:57 Ingo Molnar
2017-02-28 18:37 ` Linus Torvalds
2017-05-03 23:21 ` Linus Torvalds
2017-05-04  5:40   ` Peter Zijlstra
     [not found]     ` <CA+55aFymvtCAYHdz__3Lj=YqmORB7_A-NXrw=+h+60znJVsDTw@mail.gmail.com>
2017-05-04 22:44       ` Greg Kroah-Hartman
2016-12-07 18:42 Ingo Molnar
2016-10-18 10:55 Ingo Molnar
2016-08-18 20:34 Ingo Molnar
2016-08-12 19:32 Ingo Molnar
2016-06-10 12:45 Ingo Molnar
2016-04-28 17:52 Ingo Molnar
2016-04-23 11:22 Ingo Molnar
2016-03-24  7:47 Ingo Molnar
2015-09-17  7:57 Ingo Molnar
2015-04-18 15:15 Ingo Molnar
2015-02-20 13:37 Ingo Molnar
2015-02-21  0:03 ` Linus Torvalds
2015-02-21  1:51   ` Linus Torvalds
2015-02-23  8:35     ` Christian Borntraeger
2015-02-21  5:07   ` Ingo Molnar
2015-02-21  5:16     ` Ingo Molnar
2015-02-21  5:28       ` Ingo Molnar
2015-01-11  8:39 Ingo Molnar
2014-10-31 11:06 Ingo Molnar
2014-04-16 11:39 Ingo Molnar
2014-01-15 18:15 Ingo Molnar
2009-12-10 19:45 Ingo Molnar

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=20180122103947.GD2228@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=geert@linux-m68k.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=paulmck@us.ibm.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    /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.