Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759984AbcJRNop (ORCPT ); Tue, 18 Oct 2016 09:44:45 -0400 Received: from mail-io0-f177.google.com ([209.85.223.177]:36005 "EHLO mail-io0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753609AbcJRNoh (ORCPT ); Tue, 18 Oct 2016 09:44:37 -0400 MIME-Version: 1.0 In-Reply-To: <1476133442-17757-1-git-send-email-dianders@chromium.org> References: <1476133442-17757-1-git-send-email-dianders@chromium.org> From: Daniel Kurtz Date: Tue, 18 Oct 2016 21:44:16 +0800 X-Google-Sender-Auth: T4M76NdOzpVcDoe7-L_U9UTkm8A Message-ID: Subject: Re: [PATCH v2] timers: Fix usleep_range() in the context of wake_up_process() To: Douglas Anderson Cc: Thomas Gleixner , John Stultz , Tao Huang , Brian Norris , Andreas Mohr , "linux-kernel@vger.kernel.org" , "open list:ARM/Rockchip SoC..." , tony.xie@rock-chips.com, Akihiro Tsukada Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2339 Lines: 58 Hi Doug, On Tue, Oct 11, 2016 at 5:04 AM, Douglas Anderson wrote: > Users of usleep_range() expect that it will _never_ return in less time > than the minimum passed parameter. However, nothing in any of the code > ensures this. Specifically: > > usleep_range() => do_usleep_range() => schedule_hrtimeout_range() => > schedule_hrtimeout_range_clock() just ends up calling schedule() with an > appropriate timeout set using the hrtimer. If someone else happens to > wake up our task then we'll happily return from usleep_range() early. I think this change works, and fixes a real issue, however, I don't think you are fixing this at the right layer. The comment for schedule_hrtimeout_range says: /** * schedule_hrtimeout_range - sleep until timeout * @expires: timeout value (ktime_t) * @delta: slack in expires timeout (ktime_t) * @mode: timer mode, HRTIMER_MODE_ABS or HRTIMER_MODE_REL * * Make the current task sleep until the given expiry time has * elapsed. The routine will return immediately unless * the current task state has been set (see set_current_state()). * * The @delta argument gives the kernel the freedom to schedule the * actual wakeup to a time that is both power and performance friendly. * The kernel give the normal best effort behavior for "@expires+@delta", * but may decide to fire the timer earlier, but no earlier than @expires. * * You can set the task state as follows - * * %TASK_UNINTERRUPTIBLE - at least @timeout time is guaranteed to * pass before the routine returns. * * %TASK_INTERRUPTIBLE - the routine may return early if a signal is * delivered to the current task. * * The current task state is guaranteed to be TASK_RUNNING when this * routine returns. * * Returns 0 when the timer has expired otherwise -EINTR */ The behavior as specified for this function "at least @timeout time is guaranteed to pass before the routine returns" already guarantees the behavior you are adding to do_usleep_range() whenever the current task state is (pre-)set to TASK_UNINTERRUPTIBLE. Thus, I think the loop around 'schedule()' should be moved to schedule_hrtimeout_range() itself. This would also fix direct callers of schedule_hrtimeout_range() that use TASK_UNINTERRUPTIBLE, although, I could only find one: pt3_fetch_thread() -Dan