linux-kernel - [PATCH v6 6/7] sched: fix start hrtick for short schedule slices on UP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1416962647-76792-7-git-send-email-wanpeng.li@linux.intel.com>
Date:	Wed, 26 Nov 2014 08:44:06 +0800
From:	Wanpeng Li <wanpeng.li@...ux.intel.com>
To:	Ingo Molnar <mingo@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>
Cc:	Juri Lelli <juri.lelli@....com>,
	Kirill Tkhai <ktkhai@...allels.com>,
	linux-kernel@...r.kernel.org,
	Wanpeng Li <wanpeng.li@...ux.intel.com>
Subject: [PATCH v6 6/7] sched: fix start hrtick for short schedule slices on UP

Start hrtick for schedule slices shorter than 10000ns doesn't make any
sense and can cause timer DoS.

The commit 177ef2a6315e ("sched/deadline: Fix a precision problem in
the microseconds range") fixes the shorter slices issue for dl class.
Both the UP and SMP sides of hrtick_start() will handle the shorter
slices issue before the commit, however, the UP side of hrtick_start()
doesn't handle shorter slides issue any more after the commit applied.

This patch fix it by making sure the scheduling slice won't be smaller
than 10us in the UP side of hrtick_start() for fair and dl schedule
class.

Cc: Juri Lelli <juri.lelli@....com>
Signed-off-by: Wanpeng Li <wanpeng.li@...ux.intel.com>
---
 kernel/sched/core.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 837d2ea..b71a10e 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -490,6 +490,11 @@ static __init void init_hrtick(void)
  */
 void hrtick_start(struct rq *rq, u64 delay)
 {
+	/*
+	 * Don't schedule slices shorter than 10000ns, that just
+	 * doesn't make sense. Rely on vruntime for fairness.
+	 */
+	delay = max_t(u64, delay, 10000LL);
 	__hrtimer_start_range_ns(&rq->hrtick_timer, ns_to_ktime(delay), 0,
 			HRTIMER_MODE_REL_PINNED, 0);
 }
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/