From: Greg Kroah-Hartman Date: Mon, 29 Jan 2018 12:34:33 +0000 (+0100) Subject: 4.14-stable patches X-Git-Tag: v4.4.114~7 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=277aac9235418bb843fab61534643a39c70030a1;p=thirdparty%2Fkernel%2Fstable-queue.git 4.14-stable patches added patches: cpufreq-governor-ensure-sufficiently-large-sampling-intervals.patch --- diff --git a/queue-4.14/cpufreq-governor-ensure-sufficiently-large-sampling-intervals.patch b/queue-4.14/cpufreq-governor-ensure-sufficiently-large-sampling-intervals.patch new file mode 100644 index 00000000000..4d0a7fa7487 --- /dev/null +++ b/queue-4.14/cpufreq-governor-ensure-sufficiently-large-sampling-intervals.patch @@ -0,0 +1,72 @@ +From 56026645e2b6f11ede34a5e6ab69d3eb56f9c8fc Mon Sep 17 00:00:00 2001 +From: "Rafael J. Wysocki" +Date: Mon, 18 Dec 2017 02:15:32 +0100 +Subject: cpufreq: governor: Ensure sufficiently large sampling intervals + +From: Rafael J. Wysocki + +commit 56026645e2b6f11ede34a5e6ab69d3eb56f9c8fc upstream. + +After commit aa7519af450d (cpufreq: Use transition_delay_us for legacy +governors as well) the sampling_rate field of struct dbs_data may be +less than the tick period which causes dbs_update() to produce +incorrect results, so make the code ensure that the value of that +field will always be sufficiently large. + +Fixes: aa7519af450d (cpufreq: Use transition_delay_us for legacy governors as well) +Reported-by: Andy Tang +Reported-by: Doug Smythies +Tested-by: Andy Tang +Signed-off-by: Rafael J. Wysocki +Acked-by: Viresh Kumar +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/cpufreq/cpufreq_governor.c | 19 ++++++++++++++++--- + 1 file changed, 16 insertions(+), 3 deletions(-) + +--- a/drivers/cpufreq/cpufreq_governor.c ++++ b/drivers/cpufreq/cpufreq_governor.c +@@ -22,6 +22,8 @@ + + #include "cpufreq_governor.h" + ++#define CPUFREQ_DBS_MIN_SAMPLING_INTERVAL (2 * TICK_NSEC / NSEC_PER_USEC) ++ + static DEFINE_PER_CPU(struct cpu_dbs_info, cpu_dbs); + + static DEFINE_MUTEX(gov_dbs_data_mutex); +@@ -47,11 +49,15 @@ ssize_t store_sampling_rate(struct gov_a + { + struct dbs_data *dbs_data = to_dbs_data(attr_set); + struct policy_dbs_info *policy_dbs; ++ unsigned int sampling_interval; + int ret; +- ret = sscanf(buf, "%u", &dbs_data->sampling_rate); +- if (ret != 1) ++ ++ ret = sscanf(buf, "%u", &sampling_interval); ++ if (ret != 1 || sampling_interval < CPUFREQ_DBS_MIN_SAMPLING_INTERVAL) + return -EINVAL; + ++ dbs_data->sampling_rate = sampling_interval; ++ + /* + * We are operating under dbs_data->mutex and so the list and its + * entries can't be freed concurrently. +@@ -430,7 +436,14 @@ int cpufreq_dbs_governor_init(struct cpu + if (ret) + goto free_policy_dbs_info; + +- dbs_data->sampling_rate = cpufreq_policy_transition_delay_us(policy); ++ /* ++ * The sampling interval should not be less than the transition latency ++ * of the CPU and it also cannot be too small for dbs_update() to work ++ * correctly. ++ */ ++ dbs_data->sampling_rate = max_t(unsigned int, ++ CPUFREQ_DBS_MIN_SAMPLING_INTERVAL, ++ cpufreq_policy_transition_delay_us(policy)); + + if (!have_governor_per_policy()) + gov->gdbs_data = dbs_data; diff --git a/queue-4.14/series b/queue-4.14/series index 7eda6773d41..5e471160125 100644 --- a/queue-4.14/series +++ b/queue-4.14/series @@ -68,3 +68,4 @@ bpf-fix-divides-by-zero.patch bpf-fix-32-bit-divide-by-zero.patch bpf-reject-stores-into-ctx-via-st-and-xadd.patch bpf-arm64-fix-stack_depth-tracking-in-combination-with-tail-calls.patch +cpufreq-governor-ensure-sufficiently-large-sampling-intervals.patch