• Thomas Gleixner's avatar
    alarmtimer: Rate limit periodic intervals · c5dd0dbf
    Thomas Gleixner authored
    commit ff86bf0c upstream.
    
    The alarmtimer code has another source of potentially rearming itself too
    fast. Interval timers with a very samll interval have a similar CPU hog
    effect as the previously fixed overflow issue.
    
    The reason is that alarmtimers do not implement the normal protection
    against this kind of problem which the other posix timer use:
    
      timer expires -> queue signal -> deliver signal -> rearm timer
    
    This scheme brings the rearming under scheduler control and prevents
    permanently firing timers which hog the CPU.
    
    Bringing this scheme to the alarm timer code is a major overhaul because it
    lacks all the necessary mechanisms completely.
    
    So for a quick fix limit the interval to one jiffie. This is not
    problematic in practice as alarmtimers are usually backed by an RTC for
    suspend which have 1 second resolution. It could be therefor argued that
    the resolution of this clock should be set to 1 second in general, but
    that's outside the scope of this fix.
    Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Kostya Serebryany <kcc@google.com>
    Cc: syzkaller <syzkaller@googlegroups.com>
    Cc: John Stultz <john.stultz@linaro.org>
    Cc: Dmitry Vyukov <dvyukov@google.com>
    Link: http://lkml.kernel.org/r/20170530211655.896767100@linutronix.de
    [bwh: Backported to 3.16:
     - Use ktime_to_ns()/ktime_set() as ktime_t is not scalar
     - Adjust context]
    Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
    c5dd0dbf
alarmtimer.c 21.5 KB