+++ /dev/null
-From ff86bf0c65f14346bf2440534f9ba5ac232c39a0 Mon Sep 17 00:00:00 2001
-From: Thomas Gleixner <tglx@linutronix.de>
-Date: Tue, 30 May 2017 23:15:35 +0200
-Subject: alarmtimer: Rate limit periodic intervals
-
-From: Thomas Gleixner <tglx@linutronix.de>
-
-commit ff86bf0c65f14346bf2440534f9ba5ac232c39a0 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: Thomas 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
-Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
----
- kernel/time/alarmtimer.c | 8 ++++++++
- 1 file changed, 8 insertions(+)
-
---- a/kernel/time/alarmtimer.c
-+++ b/kernel/time/alarmtimer.c
-@@ -614,6 +614,14 @@ static int alarm_timer_set(struct k_itim
-
- /* start the timer */
- timr->it.alarm.interval = timespec_to_ktime(new_setting->it_interval);
-+
-+ /*
-+ * Rate limit to the tick as a hot fix to prevent DOS. Will be
-+ * mopped up later.
-+ */
-+ if (timr->it.alarm.interval < TICK_NSEC)
-+ timr->it.alarm.interval = TICK_NSEC;
-+
- exp = timespec_to_ktime(new_setting->it_value);
- /* Convert (if necessary) to absolute time */
- if (flags != TIMER_ABSTIME) {
mm-memory-failure.c-use-compound_head-flags-for-huge-pages.patch
swap-cond_resched-in-swap_cgroup_prepare.patch
genirq-release-resources-in-__setup_irq-error-path.patch
-alarmtimer-rate-limit-periodic-intervals.patch
+++ /dev/null
-From ff86bf0c65f14346bf2440534f9ba5ac232c39a0 Mon Sep 17 00:00:00 2001
-From: Thomas Gleixner <tglx@linutronix.de>
-Date: Tue, 30 May 2017 23:15:35 +0200
-Subject: alarmtimer: Rate limit periodic intervals
-
-From: Thomas Gleixner <tglx@linutronix.de>
-
-commit ff86bf0c65f14346bf2440534f9ba5ac232c39a0 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: Thomas 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
-Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
----
- kernel/time/alarmtimer.c | 8 ++++++++
- 1 file changed, 8 insertions(+)
-
---- a/kernel/time/alarmtimer.c
-+++ b/kernel/time/alarmtimer.c
-@@ -611,6 +611,14 @@ static int alarm_timer_set(struct k_itim
-
- /* start the timer */
- timr->it.alarm.interval = timespec_to_ktime(new_setting->it_interval);
-+
-+ /*
-+ * Rate limit to the tick as a hot fix to prevent DOS. Will be
-+ * mopped up later.
-+ */
-+ if (timr->it.alarm.interval < TICK_NSEC)
-+ timr->it.alarm.interval = TICK_NSEC;
-+
- exp = timespec_to_ktime(new_setting->it_value);
- /* Convert (if necessary) to absolute time */
- if (flags != TIMER_ABSTIME) {
genirq-release-resources-in-__setup_irq-error-path.patch
alarmtimer-prevent-overflow-of-relative-timers.patch
usb-dwc3-exynos-fix-axius-clock-error-path-to-do-cleanup.patch
-alarmtimer-rate-limit-periodic-intervals.patch
mips-fix-bnezc-jialc-return-address-calculation.patch
+++ /dev/null
-From ff86bf0c65f14346bf2440534f9ba5ac232c39a0 Mon Sep 17 00:00:00 2001
-From: Thomas Gleixner <tglx@linutronix.de>
-Date: Tue, 30 May 2017 23:15:35 +0200
-Subject: alarmtimer: Rate limit periodic intervals
-
-From: Thomas Gleixner <tglx@linutronix.de>
-
-commit ff86bf0c65f14346bf2440534f9ba5ac232c39a0 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: Thomas 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
-Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
----
- kernel/time/alarmtimer.c | 8 ++++++++
- 1 file changed, 8 insertions(+)
-
---- a/kernel/time/alarmtimer.c
-+++ b/kernel/time/alarmtimer.c
-@@ -624,6 +624,14 @@ static int alarm_timer_set(struct k_itim
-
- /* start the timer */
- timr->it.alarm.interval = timespec_to_ktime(new_setting->it_interval);
-+
-+ /*
-+ * Rate limit to the tick as a hot fix to prevent DOS. Will be
-+ * mopped up later.
-+ */
-+ if (timr->it.alarm.interval < TICK_NSEC)
-+ timr->it.alarm.interval = TICK_NSEC;
-+
- exp = timespec_to_ktime(new_setting->it_value);
- /* Convert (if necessary) to absolute time */
- if (flags != TIMER_ABSTIME) {
alarmtimer-prevent-overflow-of-relative-timers.patch
usb-gadget-composite-fix-function-used-to-free-memory.patch
usb-dwc3-exynos-fix-axius-clock-error-path-to-do-cleanup.patch
-alarmtimer-rate-limit-periodic-intervals.patch
virtio_balloon-disable-viommu-support.patch
mips-fix-bnezc-jialc-return-address-calculation.patch
mips-.its-targets-depend-on-vmlinux.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
