* [GIT pull] timers/urgent for v6.2
2023-02-18 23:42 [GIT pull] irq/urgent for v6.2 Thomas Gleixner
@ 2023-02-18 23:42 ` Thomas Gleixner
2023-02-19 2:07 ` pr-tracker-bot
2023-02-18 23:42 ` [GIT pull] x86/urgent " Thomas Gleixner
2023-02-19 2:07 ` [GIT pull] irq/urgent " pr-tracker-bot
2 siblings, 1 reply; 6+ messages in thread
From: Thomas Gleixner @ 2023-02-18 23:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, x86
Linus,
please pull the latest timers/urgent branch from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers-urgent-2023-02-19
up to: d125d1349abe: alarmtimer: Prevent starvation by small intervals and SIG_IGN
A fix for a long standing issue in the alarmtimer code:
Posix-timers armed with a short interval with an ignored signal result
in an unpriviledged DoS. Due to the ignored signal the timer switches
into self rearm mode. This issue had been "fixed" before but a rework of
the alarmtimer code 5 years ago lost that workaround.
There is no real good solution for this issue, which is also worked around
in the core posix-timer code in the same way, but it certainly moved way
up on the ever growing todo list.
Thanks,
tglx
------------------>
Thomas Gleixner (1):
alarmtimer: Prevent starvation by small intervals and SIG_IGN
kernel/time/alarmtimer.c | 33 +++++++++++++++++++++++++++++----
1 file changed, 29 insertions(+), 4 deletions(-)
diff --git a/kernel/time/alarmtimer.c b/kernel/time/alarmtimer.c
index 5897828b9d7e..7e5dff602585 100644
--- a/kernel/time/alarmtimer.c
+++ b/kernel/time/alarmtimer.c
@@ -470,11 +470,35 @@ u64 alarm_forward(struct alarm *alarm, ktime_t now, ktime_t interval)
}
EXPORT_SYMBOL_GPL(alarm_forward);
-u64 alarm_forward_now(struct alarm *alarm, ktime_t interval)
+static u64 __alarm_forward_now(struct alarm *alarm, ktime_t interval, bool throttle)
{
struct alarm_base *base = &alarm_bases[alarm->type];
+ ktime_t now = base->get_ktime();
+
+ if (IS_ENABLED(CONFIG_HIGH_RES_TIMERS) && throttle) {
+ /*
+ * Same issue as with posix_timer_fn(). Timers which are
+ * periodic but the signal is ignored can starve the system
+ * with a very small interval. The real fix which was
+ * promised in the context of posix_timer_fn() never
+ * materialized, but someone should really work on it.
+ *
+ * To prevent DOS fake @now to be 1 jiffie out which keeps
+ * the overrun accounting correct but creates an
+ * inconsistency vs. timer_gettime(2).
+ */
+ ktime_t kj = NSEC_PER_SEC / HZ;
+
+ if (interval < kj)
+ now = ktime_add(now, kj);
+ }
+
+ return alarm_forward(alarm, now, interval);
+}
- return alarm_forward(alarm, base->get_ktime(), interval);
+u64 alarm_forward_now(struct alarm *alarm, ktime_t interval)
+{
+ return __alarm_forward_now(alarm, interval, false);
}
EXPORT_SYMBOL_GPL(alarm_forward_now);
@@ -551,9 +575,10 @@ static enum alarmtimer_restart alarm_handle_timer(struct alarm *alarm,
if (posix_timer_event(ptr, si_private) && ptr->it_interval) {
/*
* Handle ignored signals and rearm the timer. This will go
- * away once we handle ignored signals proper.
+ * away once we handle ignored signals proper. Ensure that
+ * small intervals cannot starve the system.
*/
- ptr->it_overrun += alarm_forward_now(alarm, ptr->it_interval);
+ ptr->it_overrun += __alarm_forward_now(alarm, ptr->it_interval, true);
++ptr->it_requeue_pending;
ptr->it_active = 1;
result = ALARMTIMER_RESTART;
^ permalink raw reply [flat|nested] 6+ messages in thread* [GIT pull] x86/urgent for v6.2
2023-02-18 23:42 [GIT pull] irq/urgent for v6.2 Thomas Gleixner
2023-02-18 23:42 ` [GIT pull] timers/urgent " Thomas Gleixner
@ 2023-02-18 23:42 ` Thomas Gleixner
2023-02-19 2:07 ` pr-tracker-bot
2023-02-19 2:07 ` [GIT pull] irq/urgent " pr-tracker-bot
2 siblings, 1 reply; 6+ messages in thread
From: Thomas Gleixner @ 2023-02-18 23:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, x86
Linus,
please pull the latest x86/urgent branch from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-urgent-2023-02-19
up to: f9f57da2c2d1: x86/mtrr: Revert 90b926e68f50 ("x86/pat: Fix pat_x_mtrr_type() for MTRR disabled case")
A single fix for x86:
Revert the recent change to the MTRR code which aimed to support
SEV-SNP guests on Hyper-V. It cuased a regression on XEN Dom0
kernels.
The underlying issue of MTTR (mis)handling in the x86 code needs some
deeper investigation and is definitely not 6.2 material.
Thanks,
tglx
------------------>
Juergen Gross (1):
x86/mtrr: Revert 90b926e68f50 ("x86/pat: Fix pat_x_mtrr_type() for MTRR disabled case")
arch/x86/mm/pat/memtype.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/x86/mm/pat/memtype.c b/arch/x86/mm/pat/memtype.c
index fb4b1b5e0dea..46de9cf5c91d 100644
--- a/arch/x86/mm/pat/memtype.c
+++ b/arch/x86/mm/pat/memtype.c
@@ -387,8 +387,7 @@ static unsigned long pat_x_mtrr_type(u64 start, u64 end,
u8 mtrr_type, uniform;
mtrr_type = mtrr_type_lookup(start, end, &uniform);
- if (mtrr_type != MTRR_TYPE_WRBACK &&
- mtrr_type != MTRR_TYPE_INVALID)
+ if (mtrr_type != MTRR_TYPE_WRBACK)
return _PAGE_CACHE_MODE_UC_MINUS;
return _PAGE_CACHE_MODE_WB;
^ permalink raw reply [flat|nested] 6+ messages in thread