All of lore.kernel.org
 help / color / mirror / Atom feed
From: Darren Hart <dvhart@linux.intel.com>
To: Siddhesh Poyarekar <siddhesh.poyarekar@gmail.com>
Cc: linux-kernel@vger.kernel.org, Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH] [RESEND 2] Take over futex of dead task only if FUTEX_WAITERS is not set
Date: Tue, 23 Oct 2012 07:04:01 -0700	[thread overview]
Message-ID: <5086A3D1.7080709@linux.intel.com> (raw)
In-Reply-To: <1350876034-22023-1-git-send-email-siddhesh.poyarekar@gmail.com>

Hi Siddesh,

Thanks for the patch and your work to isolate it in the glibc bug 14076.

On 10/21/2012 08:20 PM, Siddhesh Poyarekar wrote:
> In futex_lock_pi_atomic, we consider that if the value in the futex
> variable is 0 with additional flags, then it is safe for takeover
> since the owner of the futex is dead.  However, when FUTEX_WAITERS is
> set in the futex value, handle_futex_death calls futex_wake to wake up
> one task. 

It shouldn't for PI mutexes. It should just set the FUTEX_OWNER_DIED flag,
maintaining the FUTEX_WAITERS flag, and exit.

int handle_futex_death(...
...
		/*
		 * Wake robust non-PI futexes here. The wakeup of
		 * PI futexes happens in exit_pi_state():
		 */
		if (!pi && (uval & FUTEX_WAITERS))
			futex_wake(uaddr, 1, 1, FUTEX_BITSET_MATCH_ANY);

There may still be an issue, as the commentary around exit_pi_state_list()
doesn't inspire confidence.

--
Darren

> Hence the assumption in futex_lock_pi_atomic is not correct.
> The correct assumption is that a futex may be considered safe for a
> takeover if The FUTEX_OWNER_DIED bit is set, the TID bits are 0 and
> the FUTEX_WAITERS bit is not set.
> 
> The race described above can be seen in the reproducer in the
> following glibc bug report:
> 
> http://sourceware.org/bugzilla/show_bug.cgi?id=14076
> 
> Signed-off-by: Siddhesh Poyarekar <siddhesh.poyarekar@gmail.com>
> ---
>  kernel/futex.c |    7 ++++++-
>  1 files changed, 6 insertions(+), 1 deletions(-)
> 
> diff --git a/kernel/futex.c b/kernel/futex.c
> index 3717e7b..9aa2d5a 100644
> --- a/kernel/futex.c
> +++ b/kernel/futex.c
> @@ -760,9 +760,14 @@ retry:
>  	 * case. We also do an unconditional take over, when the owner
>  	 * of the futex died.
>  	 *
> +	 * We do not take over the futex if FUTEX_WAITERS is set because we
> +	 * could end up waking two tasks, the current one and the one that the
> +	 * futex death event wakes in handle_futex_death.
> +	 *
>  	 * This is safe as we are protected by the hash bucket lock !
>  	 */
> -	if (unlikely(ownerdied || !(curval & FUTEX_TID_MASK))) {
> +	if (unlikely(ownerdied ||
> +			!(curval & (FUTEX_TID_MASK | FUTEX_WAITERS)))) {
>  		/* Keep the OWNER_DIED bit */
>  		newval = (curval & ~FUTEX_TID_MASK) | vpid;
>  		ownerdied = 0;
> 

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel

  reply	other threads:[~2012-10-23 14:35 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-11 14:52 [PATCH] Take over futex of dead task only if FUTEX_WAITERS is not set Siddhesh Poyarekar
2012-10-17  7:15 ` [PATCH RESEND] " Siddhesh Poyarekar
2012-10-22  3:20   ` [PATCH] [RESEND 2] " Siddhesh Poyarekar
2012-10-23 14:04     ` Darren Hart [this message]
2012-10-23 20:29       ` Thomas Gleixner
2012-10-24 12:48         ` Siddhesh Poyarekar
2012-10-24 18:08           ` Thomas Gleixner
2012-10-25  4:36             ` Darren Hart
2012-10-25  4:44               ` Siddhesh Poyarekar
2012-10-25  4:33         ` Darren Hart
2012-10-25  8:14           ` Thomas Gleixner
2012-10-25  8:18             ` Darren Hart
2012-11-01 21:35         ` [tip:core/urgent] futex: Handle futex_pi OWNER_DIED take over correctly tip-bot for 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=5086A3D1.7080709@linux.intel.com \
    --to=dvhart@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=siddhesh.poyarekar@gmail.com \
    --cc=tglx@linutronix.de \
    /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.