Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755464AbdGXVl3 (ORCPT ); Mon, 24 Jul 2017 17:41:29 -0400 Received: from mail-pg0-f48.google.com ([74.125.83.48]:33899 "EHLO mail-pg0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755458AbdGXVlN (ORCPT ); Mon, 24 Jul 2017 17:41:13 -0400 Subject: Re: [PATCH] alarmtimer: don't rate limit one-shot timers To: Greg KH Cc: John Stultz , Thomas Gleixner , Ben Fennema , linux-kernel@vger.kernel.org, stable@vger.kernel.org References: <20170724171924.27898-1-ghackmann@google.com> <20170724182122.GA6539@kroah.com> From: Greg Hackmann Message-ID: <65899e6a-c881-3d68-4f72-78df597a38c5@google.com> Date: Mon, 24 Jul 2017 14:41:10 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170724182122.GA6539@kroah.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1270 Lines: 29 On 07/24/2017 11:21 AM, Greg KH wrote: > On Mon, Jul 24, 2017 at 10:19:24AM -0700, Greg Hackmann wrote: >> Commit ff86bf0c65f1 ("alarmtimer: Rate limit periodic intervals") sets a >> minimum bound on the alarm timer interval. This minimum bound shouldn't >> be applied if the interval is 0. Otherwise, one-shot timers will be >> converted into periodic ones. >> >> This patch is against 4.9.39, and is only needed in -stable trees. >> 4.13-rc2 isn't impacted due to a later refactoring. > > What refactoring patch fixed this up? f2c45807d399 ("alarmtimer: Switch over to generic set/get/rearm routine") > As this was a 4.12 patch, 4.12-stable needs this fix as well, right? Looks like it, but I haven't actually tried 4.12 yet to confirm. > Also, was there some test-case that you caught this with that perhaps > could be added to LTP or kselftests? Unfortunately not a direct testcase. This first showed up as a regression in AOSP's userspace Bluetooth stack, which uses CLOCK_BOOTTIME_ALARM internally. I'm working on a patch to add one-shot timer testcases to set-timer-lat.c, which would have caught this. (I wrote a very rough test program to make sure this patch fixes the regression, but set-timer-lat.c already exists and is more comprehensive.)