On Mon, 24 Jul 2017, Greg KH wrote:
> On Mon, Jul 24, 2017 at 02:41:10PM -0700, Greg Hackmann wrote:
> > 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")
>
> Ick, yeah, that's not a stable patch :)
>
> > > 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.)
>
> Ok, thanks for the information.
>
> John and Thomas, any objection for me to take the original patch here in
> the stable trees to fix this issue?
No. I borked that when I was 'fixing' that DoS issue :(
Reviewed-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx>