public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jamie Lokier <jamie@shareable.org>
To: Andrew Morton <akpm@osdl.org>
Cc: Lee Revell <rlrevell@joe-job.com>,
	linux-kernel@vger.kernel.org, mingo@elte.hu,
	cmorgan@alum.wpi.edu, paul@linuxaudiosystems.com,
	Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Subject: Re: kernel bug: futex_wait hang
Date: Tue, 22 Mar 2005 04:48:38 +0000	[thread overview]
Message-ID: <20050322044838.GB32432@mail.shareable.org> (raw)
In-Reply-To: <20050321202051.2796660e.akpm@osdl.org>

Andrew Morton wrote:
> iirc we ended up deciding that the futex problems around that time were due
> to userspace problems (a version of libc).  But then, there's no discussion
> around Seto's patch and it didn't get applied.  So I don't know what
> happened to that work - it's all a bit mysterious.

It can be fixed _either_ in Glibc, or by changing the kernel.

That problem is caused by differing assumptions between Glibc and the
kernel about subtle futex semantics.  Which goes to show they are
really clever, or something.

I provided pseudo-code for the Glibc fix, but not an actual patch
because NPTL is quite complicated and I wanted to know the Glibc
people were interested, but apparently they were too busy at the time
- benchmarks would have made sense for such a patch.

Scott Snyder started fixing part of Glibc, and that did fix his
instance of this problem so we know the approach works.  But a full
patch for Glibc was not prepared.

The most recent messages under "Futex queue_me/get_user ordering",
with a patch from Jakub Jelinek will fix this problem by changing the
kernel.  Yes, you should apply Jakub's most recent patch, message-ID
"<20050318165326.GB32746@devserv.devel.redhat.com>".

I have not tested the patch, but it looks convincing.

I argued for fixing Glibc on the grounds that the changed kernel
behaviour, or more exactly having Glibc depend on it, loses a certain
semantic property useful for unusual operations on multiple futexes at
the same time.  But I appear to have lost the argument, and Jakub's
latest patch does clean up some cruft quite nicely, with no expected
performance hit.

-- Jamie

  parent reply	other threads:[~2005-03-22  4:54 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-22  3:59 kernel bug: futex_wait hang Lee Revell
2005-03-22  4:20 ` Andrew Morton
2005-03-22  4:25   ` Lee Revell
2005-03-22  4:46     ` Jamie Lokier
2005-03-22  4:48   ` Jamie Lokier [this message]
2005-03-22  5:08     ` Andrew Morton
2005-03-22  5:30       ` Lee Revell
2005-03-22  6:34         ` Jakub Jelinek
2005-03-22 23:58           ` Lee Revell
2005-03-23 13:12             ` paul
2005-03-23 13:43               ` Jakub Jelinek
2005-03-22  5:15     ` Lee Revell
2005-03-22 15:30       ` Jamie Lokier
2005-03-22 23:18         ` Lee Revell

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=20050322044838.GB32432@mail.shareable.org \
    --to=jamie@shareable.org \
    --cc=akpm@osdl.org \
    --cc=cmorgan@alum.wpi.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=paul@linuxaudiosystems.com \
    --cc=rlrevell@joe-job.com \
    --cc=seto.hidetoshi@jp.fujitsu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox