[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <65899e6a-c881-3d68-4f72-78df597a38c5@google.com>
Date: Mon, 24 Jul 2017 14:41:10 -0700
From: Greg Hackmann <ghackmann@...gle.com>
To: Greg KH <greg@...ah.com>
Cc: John Stultz <john.stultz@...aro.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ben Fennema <fennema@...gle.com>, linux-kernel@...r.kernel.org,
stable@...r.kernel.org
Subject: Re: [PATCH] alarmtimer: don't rate limit one-shot timers
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.)
Powered by blists - more mailing lists