Skip to contentSkip to conversation

Badness in futex_wait

DISCUSSION Jedi/Sector One 2 participants 2 messages Jun 22, 2004

lore
Share & tools
lore
#0 lore raw

Hello.

I just had this with a 2.6.7-rc3-mm1 kernel:

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?

#1 lore raw
Quoted 9 lines · Jedi/Sector One

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