From: William Lee Irwin III <wli@holomorphy.com>
To: Jedi/Sector One <lkml@pureftpd.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Badness in futex_wait
Date: Tue, 22 Jun 2004 07:13:51 -0700 [thread overview]
Message-ID: <20040622141351.GA2135@holomorphy.com> (raw)
In-Reply-To: <20040622135416.GA23543@c9x.org>
On Tue, Jun 22, 2004 at 03:53:54PM +0159, Jedi/Sector One wrote:
> Badness in futex_wait at kernel/futex.c:542
> [<c0128634>] futex_wait+0x180/0x18a
> [<c0114156>] default_wake_function+0x0/0xc
> [<c0114156>] default_wake_function+0x0/0xc
> [<c0128862>] do_futex+0x35/0x7f
> [<c012898c>] sys_futex+0xe0/0xec
> [<c0112cd1>] schedule_tail+0x15/0x4c
> [<c0103bdd>] sysenter_past_esp+0x52/0x71
> Is it harmless?
Probably yes; however, the WARN_ON() is there because it's not intended
to happen. I'd recommend removing the warning to shut it up as a local
patch until someone participating in maintaining that code investigates
it (basically they need to decide whether they want to find and fix the
spurious wakeup or otherwise to just ignore it).
This condition will not cause application errors or negatively affect
your system, apart from syslog spam. A spurious wakeup will only mean
that a thread wakes and rechecks the condition it was waiting for, but
it can't rely on that condition remaining true between the time the
kernel checks it and when userspace is returned to. For instance, the
scheduler may choose another task to return to, and take a very long
time to run the task that was waiting. So it can't introduce new errors
into userspace (except for the possibility, which I happen to know is
not how it's implemented, that it must have undergone a state transition
through that condition being true, for the userspace code to be correct).
-- wli
next prev parent reply other threads:[~2004-06-22 14:22 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-22 13:54 Badness in futex_wait Jedi/Sector One
2004-06-22 14:13 ` William Lee Irwin III [this message]
-- strict thread matches above, loose matches on Subject: below --
2004-01-23 17:14 Lenar Lõhmus
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=20040622141351.GA2135@holomorphy.com \
--to=wli@holomorphy.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lkml@pureftpd.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox