Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756325Ab3EBKbN (ORCPT ); Thu, 2 May 2013 06:31:13 -0400 Received: from mx1.redhat.com ([209.132.183.28]:22359 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753370Ab3EBKbM (ORCPT ); Thu, 2 May 2013 06:31:12 -0400 Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 From: David Howells In-Reply-To: <1367485129-4423-1-git-send-email-imre.deak@intel.com> References: <1367485129-4423-1-git-send-email-imre.deak@intel.com> To: Imre Deak Cc: dhowells@redhat.com, Daniel Vetter , "Paul E. McKenney" , Dave Jones , Jens Axboe , Lukas Czerner , linux-kernel@vger.kernel.org Subject: Re: [PATCH] wait: fix false timeouts when using wait_event_timeout() Date: Thu, 02 May 2013 11:29:29 +0100 Message-ID: <15077.1367490569@warthog.procyon.org.uk> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1299 Lines: 30 Imre Deak wrote: > 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. Fun. > 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. I'm not sure there's a good answer - except maybe making the timer expiry handler check the condition (which would likely get really yucky really quickly). David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/