Badness in futex_wait

Badness in futex_wait

[Lenar Lõhmus]

Hi,

Don't now if this is useful or indicates any possible problems at all, 
but found this in kern.log:

Jan 20 18:33:30 horizon kernel: Badness in futex_wait at kernel/futex.c:509
Jan 20 18:33:31 horizon kernel: Call Trace:
Jan 20 18:33:31 horizon kernel:  [futex_wait+414/416] futex_wait+0x19e/0x1a0
Jan 20 18:33:31 horizon kernel:  [default_wake_function+0/32] 
default_wake_function+0x0/0x20
Jan 20 18:33:31 horizon kernel:  [default_wake_function+0/32] 
default_wake_function+0x0/0x20
Jan 20 18:33:31 horizon kernel:  [do_futex+112/128] do_futex+0x70/0x80
Jan 20 18:33:31 horizon kernel:  [sys_futex+268/304] sys_futex+0x10c/0x130
Jan 20 18:33:31 horizon kernel:  [sysenter_past_esp+67/101] 
sysenter_past_esp+0x43/0x65

2.5 days later machine hanged (but propably due to being nForce2 based).

Kernel version: 2.6.1-rc1-mm1

Lenar

Badness in futex_wait

[Jedi/Sector One]

  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?
  

Re: Badness in futex_wait

[William Lee Irwin III]

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