Badness in futex_wait
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?
Quoted 9 lines · Jedi/Sector One
Badness in
futex_waitatkernel/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