From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752632AbbKJLKE (ORCPT ); Tue, 10 Nov 2015 06:10:04 -0500 Received: from bombadil.infradead.org ([198.137.202.9]:45800 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752597AbbKJLKB (ORCPT ); Tue, 10 Nov 2015 06:10:01 -0500 Date: Tue, 10 Nov 2015 12:09:56 +0100 From: Peter Zijlstra To: Kalle Kankare Cc: linux-kernel@vger.kernel.org, Ingo Molnar Subject: Re: During high load wait_event_timeout might return a wrong value Message-ID: <20151110110956.GY17308@twins.programming.kicks-ass.net> References: <20151110091812.1e7f326e@kalleka-typewriter> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151110091812.1e7f326e@kalleka-typewriter> User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.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.