All of lore.kernel.org
 help / color / mirror / Atom feed
From: Darren Hart <dvhart@linux.intel.com>
To: Louis Rilling <louis.rilling@kerlabs.com>
Cc: linux-kernel@vger.kernel.org,
	"Rusty Russell" <rusty@rustcorp.com.au>,
	"Ingo Molnar" <mingo@elte.hu>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Matthieu Fertré" <matthieu.fertre@kerlabs.com>
Subject: Re: [RESEND PATCH] futex: fix key reference counter in case of requeue.
Date: Fri, 15 Oct 2010 12:13:47 -0700	[thread overview]
Message-ID: <4CB8A7EB.6050303@linux.intel.com> (raw)
In-Reply-To: <1287055805-18233-1-git-send-email-louis.rilling@kerlabs.com>

On 10/14/2010 04:30 AM, Louis Rilling wrote:
> From: Matthieu Fertré<matthieu.fertre@kerlabs.com>

Hi Matthew,

>
> This patch ensures that we are referring to the right key when dropping
> reference for the futex_wait operation.
>
> The following scenario explains a typical case where the bug was
> happening:
>
> Process P calls futex_wait() on futex identified by 'key1'. 2 references
> are taken on this key: one for the struct futex_q itself, and one for the
> futex_wait operation.
> If now, process P is requeued on a futex identified by 'key2', its
> futex_q->key is updated from 'key1' to 'key2' and a reference is got
> to 'key2' and one is dropped to 'key1'.
> Later, another process calls futex_wake(): it gets a reference to
> 'key2', wakes process P, and drops reference to 'key2'.
> Once process P is woken up, it should unqueue, drop reference to 'key2'
> (the one referring to the futex_q, this is done in unqueue_me())
> and to 'key1' (the one referring to futex_wait operation). Without this
> patch it drops reference to 'key2' instead of 'key1'.

Nice catch. How did this manifest itself? Did you catch it just by code 
inspection?

I've been trying to develop a futex test suite to catch issues with the 
futex implementation, as well as to test any changes made to avoid 
regressions. Mind having a look?

http://git.kernel.org/?p=linux/kernel/git/dvhart/futextest.git;a=summary

> Signed-off-by: Matthieu Fertré<matthieu.fertre@kerlabs.com>
> Signed-off-by: Louis Rilling<louis.rilling@kerlabs.com>
> ---
>   kernel/futex.c |    8 ++++++--
>   1 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/futex.c b/kernel/futex.c
> index 6a3a5fa..bed6717 100644
> --- a/kernel/futex.c
> +++ b/kernel/futex.c
> @@ -1791,6 +1791,7 @@ static int futex_wait(u32 __user *uaddr, int fshared,
>   	struct restart_block *restart;
>   	struct futex_hash_bucket *hb;
>   	struct futex_q q;
> +	union futex_key key;

We should be able to do this properly without requiring an additional 
key variable. I think tglx has proposed a suitable fix - but it needs 
testing to avoid any subtle regressions.

-- 
Darren Hart
Embedded Linux Kernel

  parent reply	other threads:[~2010-10-15 19:13 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-14 11:30 [RESEND PATCH] futex: fix key reference counter in case of requeue Louis Rilling
2010-10-15 12:16 ` Thomas Gleixner
2010-10-15 19:19   ` Darren Hart
2010-10-18 12:14   ` Matthieu Fertré
2010-10-15 19:13 ` Darren Hart [this message]
2010-10-15 19:18   ` Thomas Gleixner
2010-10-18 12:51   ` Matthieu Fertré

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=4CB8A7EB.6050303@linux.intel.com \
    --to=dvhart@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=louis.rilling@kerlabs.com \
    --cc=matthieu.fertre@kerlabs.com \
    --cc=mingo@elte.hu \
    --cc=rusty@rustcorp.com.au \
    --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.