Re: During high load wait_event_timeout might return a wrong value

[Peter Zijlstra <peterz@infradead.org>]

On Tue, Nov 10, 2015 at 09:18:12AM +0200, Kalle Kankare wrote:
> Hi,
> 
> The problem is that the call to might_sleep might sleep and the return
> value of wait_event_timeout does not account for the time slept in
> there.
> 
> The might_sleep includes a call to __schedule if
> CONFIG_PREEMPT_VOLUNTARY is defined.
> 
> A problematic scenario can be like the following:
> 
> - A driver calls wait_event_timeout with timeout = 10 jiffies, starts sleeping in might_sleep.
> - An interrupt handler sets the condition true at 5 jiffies and calls wake_up for the waitqueue.
> - Due to high load the might_sleep wakes up at 100 jiffies.
> - In the next if the __wait_cond_timeout returns 1 without manipulating __ret.
> - wait_event_timeout returns 10 where it should have returned 1 to denote that a timeout was reached.
> 
> Or am I misunderstanding what the return value should be ?

No, but you count a preemption as sleep, and this is incorrect.

Also, as with all the sleep APIs, the timeout is a minimum. We're
allowed to actually sleep longer. Conversely any reported sleep time is
therefore also subject to similar inequality. And this is for actual
sleep time.

Further note that the time returned does not include scheduling
latencies -- like the time it takes for the woken task to actually get
scheduled.

Similarly, preemptions, like possible with any PREEMPT setting (be it
voluntary or forced) will add scheduling latencies, which are not to be
confused with actual sleeping.