From: Ingo Molnar <mingo@elte.hu>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>,
akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
Ulrich Drepper <drepper@redhat.com>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH] robust futex thread exit race
Date: Sun, 30 Sep 2007 17:57:16 +0200 [thread overview]
Message-ID: <20070930155716.GA29627@elte.hu> (raw)
In-Reply-To: <alpine.LFD.0.9999.0709301750430.3142@localhost.localdomain>
* Thomas Gleixner <tglx@linutronix.de> wrote:
>
> On Sun, 30 Sep 2007, Ingo Molnar wrote:
> > * Martin Schwidefsky <schwidefsky@de.ibm.com> wrote:
> >
> > > Hi Ingo,
> > > I finally found the bug that causes tst-robust8 from the glibc to fail
> > > on s390x. Turned out to be a common code problem with the processing of
> > > the robust futex list. The patch below fixes the bug for me.
> >
> > good catch! A quick preliminary review of your patch indicates it's fine
> > - and it might be v2.6.23 material.
> >
> > Acked-by: Ingo Molnar <mingo@elte.hu>
>
> Acked-by: Thomas Gleixner <tglx@linutronix.de>
>
> > > Calling handle_futex_death in exit_robust_list for the different
> > > robust mutexes of a thread basically frees the mutex. Another thread
> > > might grab the lock immediately which updates the next pointer of the
> > > mutex. fetch_robust_entry over the next pointer might therefore branch
> > > into the robust mutex list of a different thread. This can cause two
> > > problems: 1) some mutexes held by the dead thread are not getting
> > > freed and 2) some mutexs held by a different thread are freed. The
> > > next point need to be read before calling handle_futex_death.
> >
> > nasty race... Ulrich, Thomas, do you concur?
>
> Yes. Where do they sell those brown paperbags again ?
i've still got plenty of them stacked up, can pass over a few. (i'm
getting them cheap from the manufacturer - large quantity discount)
Ingo
next prev parent reply other threads:[~2007-09-30 15:57 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-30 15:02 [PATCH] robust futex thread exit race Martin Schwidefsky
2007-09-30 15:18 ` Ingo Molnar
2007-09-30 15:53 ` Thomas Gleixner
2007-09-30 15:57 ` Ingo Molnar [this message]
2007-09-30 16:06 ` Ingo Molnar
2007-09-30 16:10 ` Martin Schwidefsky
2007-09-30 17:11 ` Ingo Molnar
2007-09-30 17:32 ` Martin Schwidefsky
2007-09-30 19:55 ` Ingo Molnar
2007-09-30 23:41 ` David Miller
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=20070930155716.GA29627@elte.hu \
--to=mingo@elte.hu \
--cc=akpm@linux-foundation.org \
--cc=drepper@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=schwidefsky@de.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.