On Thu, May 2, 2013 at 12:29 PM, David Howells <dhowe...@redhat.com> wrote: >> 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". > > But now you can't distinguish the timer expiring first, if the thread doing > the waiting gets delayed sufficiently long for the event to happen.
That can already happen, e.g. 1. wakeup happens and condition is true. 2. we compute remaining jiffies > 0 -> preempt 3. now wait_for_event_timeout returns. Only difference is that the delay/preempt happens in between 1. and 2., and then suddenly the wake up didn't happen in time (with the current return code semantics). So imo the current behaviour is simply a bug and will miss timely wakeups in some cases. The other way round, namely wait_for_event_timeout taking longer than the timeout is expected (and part of the interface for every timeout function). So all current callers already need to be able to cope with random preemption/delays pushing the total time before the call to wait_for_event and checking the return value over the timeout, even when condition was signalled in time. If there's any case which relies on accurate timeout detection that simply won't work with wait_for_event (they need an nmi or a hw timestamp counter or something similar). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/