summaryrefslogtreecommitdiff
path: root/mm
diff options
context:
space:
mode:
authorImre Deak <imre.deak@intel.com>2013-05-24 15:55:09 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2013-05-24 16:22:50 -0700
commit4c663cfc523a88d97a8309b04a089c27dc57fd7e (patch)
treed3b9de53922dbc326017075bd5e1558b5f8c741d /mm
parent7b92d03c3239f43e5b86c9cc9630f026d36ee995 (diff)
downloadlwn-4c663cfc523a88d97a8309b04a089c27dc57fd7e.tar.gz
lwn-4c663cfc523a88d97a8309b04a089c27dc57fd7e.zip
wait: fix false timeouts when using wait_event_timeout()
Many callers of the wait_event_timeout() and wait_event_interruptible_timeout() expect that the return value will be positive if the specified condition becomes true before the timeout elapses. However, at the moment this isn't guaranteed. If the wake-up handler is delayed enough, the time remaining until timeout will be calculated as 0 - and passed back as a return value - even if the condition became true before the timeout has passed. Fix this by returning at least 1 if the condition becomes true. This semantic is in line with what wait_for_condition_timeout() does; see commit bb10ed09 ("sched: fix wait_for_completion_timeout() spurious failure under heavy load"). Daniel said "We have 3 instances of this bug in drm/i915. One case even where we switch between the interruptible and not interruptible wait_event_timeout variants, foolishly presuming they have the same semantics. I very much like this." One such bug is reported at https://bugs.freedesktop.org/show_bug.cgi?id=64133 Signed-off-by: Imre Deak <imre.deak@intel.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: David Howells <dhowells@redhat.com> Acked-by: Jens Axboe <axboe@kernel.dk> Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> Cc: Dave Jones <davej@redhat.com> Cc: Lukas Czerner <lczerner@redhat.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'mm')
0 files changed, 0 insertions, 0 deletions