From ae67d5077189adc8a6b2f2647b19a486a2a5670e Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Fri, 25 Apr 2025 09:29:51 +0200 Subject: [PATCH] drop cpufreq-avoid-using-inconsistent-policy-min-and-policy-max.patch from everywhere --- ...consistent-policy-min-and-policy-max.patch | 106 ------------------ ...ount-policy-in-cpufreq_update_limits.patch | 2 +- queue-6.1/series | 1 - ...consistent-policy-min-and-policy-max.patch | 106 ------------------ ...ount-policy-in-cpufreq_update_limits.patch | 2 +- queue-6.12/series | 1 - ...consistent-policy-min-and-policy-max.patch | 106 ------------------ ...ount-policy-in-cpufreq_update_limits.patch | 2 +- queue-6.14/series | 1 - ...consistent-policy-min-and-policy-max.patch | 106 ------------------ ...ount-policy-in-cpufreq_update_limits.patch | 2 +- queue-6.6/series | 1 - 12 files changed, 4 insertions(+), 432 deletions(-) delete mode 100644 queue-6.1/cpufreq-avoid-using-inconsistent-policy-min-and-policy-max.patch delete mode 100644 queue-6.12/cpufreq-avoid-using-inconsistent-policy-min-and-policy-max.patch delete mode 100644 queue-6.14/cpufreq-avoid-using-inconsistent-policy-min-and-policy-max.patch delete mode 100644 queue-6.6/cpufreq-avoid-using-inconsistent-policy-min-and-policy-max.patch diff --git a/queue-6.1/cpufreq-avoid-using-inconsistent-policy-min-and-policy-max.patch b/queue-6.1/cpufreq-avoid-using-inconsistent-policy-min-and-policy-max.patch deleted file mode 100644 index 98b5fd0939..0000000000 --- a/queue-6.1/cpufreq-avoid-using-inconsistent-policy-min-and-policy-max.patch +++ /dev/null @@ -1,106 +0,0 @@ -From 7491cdf46b5cbdf123fc84fbe0a07e9e3d7b7620 Mon Sep 17 00:00:00 2001 -From: "Rafael J. Wysocki" -Date: Wed, 16 Apr 2025 16:12:37 +0200 -Subject: cpufreq: Avoid using inconsistent policy->min and policy->max - -From: Rafael J. Wysocki - -commit 7491cdf46b5cbdf123fc84fbe0a07e9e3d7b7620 upstream. - -Since cpufreq_driver_resolve_freq() can run in parallel with -cpufreq_set_policy() and there is no synchronization between them, -the former may access policy->min and policy->max while the latter -is updating them and it may see intermediate values of them due -to the way the update is carried out. Also the compiler is free -to apply any optimizations it wants both to the stores in -cpufreq_set_policy() and to the loads in cpufreq_driver_resolve_freq() -which may result in additional inconsistencies. - -To address this, use WRITE_ONCE() when updating policy->min and -policy->max in cpufreq_set_policy() and use READ_ONCE() for reading -them in cpufreq_driver_resolve_freq(). Moreover, rearrange the update -in cpufreq_set_policy() to avoid storing intermediate values in -policy->min and policy->max with the help of the observation that -their new values are expected to be properly ordered upfront. - -Also modify cpufreq_driver_resolve_freq() to take the possible reverse -ordering of policy->min and policy->max, which may happen depending on -the ordering of operations when this function and cpufreq_set_policy() -run concurrently, into account by always honoring the max when it -turns out to be less than the min (in case it comes from thermal -throttling or similar). - -Fixes: 151717690694 ("cpufreq: Make policy min/max hard requirements") -Cc: 5.16+ # 5.16+ -Signed-off-by: Rafael J. Wysocki -Reviewed-by: Christian Loehle -Acked-by: Viresh Kumar -Link: https://patch.msgid.link/5907080.DvuYhMxLoT@rjwysocki.net -Signed-off-by: Greg Kroah-Hartman ---- - drivers/cpufreq/cpufreq.c | 32 +++++++++++++++++++++++++------- - 1 file changed, 25 insertions(+), 7 deletions(-) - ---- a/drivers/cpufreq/cpufreq.c -+++ b/drivers/cpufreq/cpufreq.c -@@ -532,8 +532,6 @@ static unsigned int __resolve_freq(struc - { - unsigned int idx; - -- target_freq = clamp_val(target_freq, policy->min, policy->max); -- - if (!policy->freq_table) - return target_freq; - -@@ -557,7 +555,22 @@ static unsigned int __resolve_freq(struc - unsigned int cpufreq_driver_resolve_freq(struct cpufreq_policy *policy, - unsigned int target_freq) - { -- return __resolve_freq(policy, target_freq, CPUFREQ_RELATION_LE); -+ unsigned int min = READ_ONCE(policy->min); -+ unsigned int max = READ_ONCE(policy->max); -+ -+ /* -+ * If this function runs in parallel with cpufreq_set_policy(), it may -+ * read policy->min before the update and policy->max after the update -+ * or the other way around, so there is no ordering guarantee. -+ * -+ * Resolve this by always honoring the max (in case it comes from -+ * thermal throttling or similar). -+ */ -+ if (unlikely(min > max)) -+ min = max; -+ -+ return __resolve_freq(policy, clamp_val(target_freq, min, max), -+ CPUFREQ_RELATION_LE); - } - EXPORT_SYMBOL_GPL(cpufreq_driver_resolve_freq); - -@@ -2283,6 +2296,7 @@ int __cpufreq_driver_target(struct cpufr - if (cpufreq_disabled()) - return -ENODEV; - -+ target_freq = clamp_val(target_freq, policy->min, policy->max); - target_freq = __resolve_freq(policy, target_freq, relation); - - pr_debug("target for CPU %u: %u kHz, relation %u, requested %u kHz\n", -@@ -2573,11 +2587,15 @@ static int cpufreq_set_policy(struct cpu - * Resolve policy min/max to available frequencies. It ensures - * no frequency resolution will neither overshoot the requested maximum - * nor undershoot the requested minimum. -+ * -+ * Avoid storing intermediate values in policy->max or policy->min and -+ * compiler optimizations around them because they may be accessed -+ * concurrently by cpufreq_driver_resolve_freq() during the update. - */ -- policy->min = new_data.min; -- policy->max = new_data.max; -- policy->min = __resolve_freq(policy, policy->min, CPUFREQ_RELATION_L); -- policy->max = __resolve_freq(policy, policy->max, CPUFREQ_RELATION_H); -+ WRITE_ONCE(policy->max, __resolve_freq(policy, new_data.max, CPUFREQ_RELATION_H)); -+ new_data.min = __resolve_freq(policy, new_data.min, CPUFREQ_RELATION_L); -+ WRITE_ONCE(policy->min, new_data.min > policy->max ? policy->max : new_data.min); -+ - trace_cpu_frequency_limits(policy); - - policy->cached_target_freq = UINT_MAX; diff --git a/queue-6.1/cpufreq-reference-count-policy-in-cpufreq_update_limits.patch b/queue-6.1/cpufreq-reference-count-policy-in-cpufreq_update_limits.patch index 60a88705f9..fd226de8d2 100644 --- a/queue-6.1/cpufreq-reference-count-policy-in-cpufreq_update_limits.patch +++ b/queue-6.1/cpufreq-reference-count-policy-in-cpufreq_update_limits.patch @@ -35,7 +35,7 @@ Signed-off-by: Greg Kroah-Hartman --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c -@@ -2691,10 +2691,18 @@ EXPORT_SYMBOL(cpufreq_update_policy); +@@ -2673,10 +2673,18 @@ EXPORT_SYMBOL(cpufreq_update_policy); */ void cpufreq_update_limits(unsigned int cpu) { diff --git a/queue-6.1/series b/queue-6.1/series index da0b969c5e..5c09721a3d 100644 --- a/queue-6.1/series +++ b/queue-6.1/series @@ -204,7 +204,6 @@ nfs-move-nfs_fhandle_hash-to-common-include-file.patch nfs-add-missing-selections-of-config_crc32.patch nfsd-decrease-sc_count-directly-if-fail-to-queue-dl_.patch btrfs-correctly-escape-subvol-in-btrfs_show_options.patch -cpufreq-avoid-using-inconsistent-policy-min-and-policy-max.patch crypto-caam-qi-fix-drv_ctx-refcount-bug.patch hfs-hfsplus-fix-slab-out-of-bounds-in-hfs_bnode_read_key.patch i2c-cros-ec-tunnel-defer-probe-if-parent-ec-is-not-present.patch diff --git a/queue-6.12/cpufreq-avoid-using-inconsistent-policy-min-and-policy-max.patch b/queue-6.12/cpufreq-avoid-using-inconsistent-policy-min-and-policy-max.patch deleted file mode 100644 index 055733a04e..0000000000 --- a/queue-6.12/cpufreq-avoid-using-inconsistent-policy-min-and-policy-max.patch +++ /dev/null @@ -1,106 +0,0 @@ -From 7491cdf46b5cbdf123fc84fbe0a07e9e3d7b7620 Mon Sep 17 00:00:00 2001 -From: "Rafael J. Wysocki" -Date: Wed, 16 Apr 2025 16:12:37 +0200 -Subject: cpufreq: Avoid using inconsistent policy->min and policy->max - -From: Rafael J. Wysocki - -commit 7491cdf46b5cbdf123fc84fbe0a07e9e3d7b7620 upstream. - -Since cpufreq_driver_resolve_freq() can run in parallel with -cpufreq_set_policy() and there is no synchronization between them, -the former may access policy->min and policy->max while the latter -is updating them and it may see intermediate values of them due -to the way the update is carried out. Also the compiler is free -to apply any optimizations it wants both to the stores in -cpufreq_set_policy() and to the loads in cpufreq_driver_resolve_freq() -which may result in additional inconsistencies. - -To address this, use WRITE_ONCE() when updating policy->min and -policy->max in cpufreq_set_policy() and use READ_ONCE() for reading -them in cpufreq_driver_resolve_freq(). Moreover, rearrange the update -in cpufreq_set_policy() to avoid storing intermediate values in -policy->min and policy->max with the help of the observation that -their new values are expected to be properly ordered upfront. - -Also modify cpufreq_driver_resolve_freq() to take the possible reverse -ordering of policy->min and policy->max, which may happen depending on -the ordering of operations when this function and cpufreq_set_policy() -run concurrently, into account by always honoring the max when it -turns out to be less than the min (in case it comes from thermal -throttling or similar). - -Fixes: 151717690694 ("cpufreq: Make policy min/max hard requirements") -Cc: 5.16+ # 5.16+ -Signed-off-by: Rafael J. Wysocki -Reviewed-by: Christian Loehle -Acked-by: Viresh Kumar -Link: https://patch.msgid.link/5907080.DvuYhMxLoT@rjwysocki.net -Signed-off-by: Greg Kroah-Hartman ---- - drivers/cpufreq/cpufreq.c | 32 +++++++++++++++++++++++++------- - 1 file changed, 25 insertions(+), 7 deletions(-) - ---- a/drivers/cpufreq/cpufreq.c -+++ b/drivers/cpufreq/cpufreq.c -@@ -538,8 +538,6 @@ static unsigned int __resolve_freq(struc - { - unsigned int idx; - -- target_freq = clamp_val(target_freq, policy->min, policy->max); -- - if (!policy->freq_table) - return target_freq; - -@@ -563,7 +561,22 @@ static unsigned int __resolve_freq(struc - unsigned int cpufreq_driver_resolve_freq(struct cpufreq_policy *policy, - unsigned int target_freq) - { -- return __resolve_freq(policy, target_freq, CPUFREQ_RELATION_LE); -+ unsigned int min = READ_ONCE(policy->min); -+ unsigned int max = READ_ONCE(policy->max); -+ -+ /* -+ * If this function runs in parallel with cpufreq_set_policy(), it may -+ * read policy->min before the update and policy->max after the update -+ * or the other way around, so there is no ordering guarantee. -+ * -+ * Resolve this by always honoring the max (in case it comes from -+ * thermal throttling or similar). -+ */ -+ if (unlikely(min > max)) -+ min = max; -+ -+ return __resolve_freq(policy, clamp_val(target_freq, min, max), -+ CPUFREQ_RELATION_LE); - } - EXPORT_SYMBOL_GPL(cpufreq_driver_resolve_freq); - -@@ -2323,6 +2336,7 @@ int __cpufreq_driver_target(struct cpufr - if (cpufreq_disabled()) - return -ENODEV; - -+ target_freq = clamp_val(target_freq, policy->min, policy->max); - target_freq = __resolve_freq(policy, target_freq, relation); - - pr_debug("target for CPU %u: %u kHz, relation %u, requested %u kHz\n", -@@ -2647,11 +2661,15 @@ static int cpufreq_set_policy(struct cpu - * Resolve policy min/max to available frequencies. It ensures - * no frequency resolution will neither overshoot the requested maximum - * nor undershoot the requested minimum. -+ * -+ * Avoid storing intermediate values in policy->max or policy->min and -+ * compiler optimizations around them because they may be accessed -+ * concurrently by cpufreq_driver_resolve_freq() during the update. - */ -- policy->min = new_data.min; -- policy->max = new_data.max; -- policy->min = __resolve_freq(policy, policy->min, CPUFREQ_RELATION_L); -- policy->max = __resolve_freq(policy, policy->max, CPUFREQ_RELATION_H); -+ WRITE_ONCE(policy->max, __resolve_freq(policy, new_data.max, CPUFREQ_RELATION_H)); -+ new_data.min = __resolve_freq(policy, new_data.min, CPUFREQ_RELATION_L); -+ WRITE_ONCE(policy->min, new_data.min > policy->max ? policy->max : new_data.min); -+ - trace_cpu_frequency_limits(policy); - - cpufreq_update_pressure(policy); diff --git a/queue-6.12/cpufreq-reference-count-policy-in-cpufreq_update_limits.patch b/queue-6.12/cpufreq-reference-count-policy-in-cpufreq_update_limits.patch index 9b4889341c..6d8967ef5d 100644 --- a/queue-6.12/cpufreq-reference-count-policy-in-cpufreq_update_limits.patch +++ b/queue-6.12/cpufreq-reference-count-policy-in-cpufreq_update_limits.patch @@ -35,7 +35,7 @@ Signed-off-by: Greg Kroah-Hartman --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c -@@ -2766,10 +2766,18 @@ EXPORT_SYMBOL(cpufreq_update_policy); +@@ -2748,10 +2748,18 @@ EXPORT_SYMBOL(cpufreq_update_policy); */ void cpufreq_update_limits(unsigned int cpu) { diff --git a/queue-6.12/series b/queue-6.12/series index 16aa6874cc..34108009c9 100644 --- a/queue-6.12/series +++ b/queue-6.12/series @@ -102,7 +102,6 @@ bluetooth-l2cap-process-valid-commands-in-too-long-frame.patch bluetooth-vhci-avoid-needless-snprintf-calls.patch btrfs-correctly-escape-subvol-in-btrfs_show_options.patch cpufreq-sched-explicitly-synchronize-limits_changed-flag-handling.patch -cpufreq-avoid-using-inconsistent-policy-min-and-policy-max.patch crypto-caam-qi-fix-drv_ctx-refcount-bug.patch hfs-hfsplus-fix-slab-out-of-bounds-in-hfs_bnode_read_key.patch i2c-cros-ec-tunnel-defer-probe-if-parent-ec-is-not-present.patch diff --git a/queue-6.14/cpufreq-avoid-using-inconsistent-policy-min-and-policy-max.patch b/queue-6.14/cpufreq-avoid-using-inconsistent-policy-min-and-policy-max.patch deleted file mode 100644 index f360ccbd70..0000000000 --- a/queue-6.14/cpufreq-avoid-using-inconsistent-policy-min-and-policy-max.patch +++ /dev/null @@ -1,106 +0,0 @@ -From 7491cdf46b5cbdf123fc84fbe0a07e9e3d7b7620 Mon Sep 17 00:00:00 2001 -From: "Rafael J. Wysocki" -Date: Wed, 16 Apr 2025 16:12:37 +0200 -Subject: cpufreq: Avoid using inconsistent policy->min and policy->max - -From: Rafael J. Wysocki - -commit 7491cdf46b5cbdf123fc84fbe0a07e9e3d7b7620 upstream. - -Since cpufreq_driver_resolve_freq() can run in parallel with -cpufreq_set_policy() and there is no synchronization between them, -the former may access policy->min and policy->max while the latter -is updating them and it may see intermediate values of them due -to the way the update is carried out. Also the compiler is free -to apply any optimizations it wants both to the stores in -cpufreq_set_policy() and to the loads in cpufreq_driver_resolve_freq() -which may result in additional inconsistencies. - -To address this, use WRITE_ONCE() when updating policy->min and -policy->max in cpufreq_set_policy() and use READ_ONCE() for reading -them in cpufreq_driver_resolve_freq(). Moreover, rearrange the update -in cpufreq_set_policy() to avoid storing intermediate values in -policy->min and policy->max with the help of the observation that -their new values are expected to be properly ordered upfront. - -Also modify cpufreq_driver_resolve_freq() to take the possible reverse -ordering of policy->min and policy->max, which may happen depending on -the ordering of operations when this function and cpufreq_set_policy() -run concurrently, into account by always honoring the max when it -turns out to be less than the min (in case it comes from thermal -throttling or similar). - -Fixes: 151717690694 ("cpufreq: Make policy min/max hard requirements") -Cc: 5.16+ # 5.16+ -Signed-off-by: Rafael J. Wysocki -Reviewed-by: Christian Loehle -Acked-by: Viresh Kumar -Link: https://patch.msgid.link/5907080.DvuYhMxLoT@rjwysocki.net -Signed-off-by: Greg Kroah-Hartman ---- - drivers/cpufreq/cpufreq.c | 32 +++++++++++++++++++++++++------- - 1 file changed, 25 insertions(+), 7 deletions(-) - ---- a/drivers/cpufreq/cpufreq.c -+++ b/drivers/cpufreq/cpufreq.c -@@ -539,8 +539,6 @@ static unsigned int __resolve_freq(struc - { - unsigned int idx; - -- target_freq = clamp_val(target_freq, policy->min, policy->max); -- - if (!policy->freq_table) - return target_freq; - -@@ -564,7 +562,22 @@ static unsigned int __resolve_freq(struc - unsigned int cpufreq_driver_resolve_freq(struct cpufreq_policy *policy, - unsigned int target_freq) - { -- return __resolve_freq(policy, target_freq, CPUFREQ_RELATION_LE); -+ unsigned int min = READ_ONCE(policy->min); -+ unsigned int max = READ_ONCE(policy->max); -+ -+ /* -+ * If this function runs in parallel with cpufreq_set_policy(), it may -+ * read policy->min before the update and policy->max after the update -+ * or the other way around, so there is no ordering guarantee. -+ * -+ * Resolve this by always honoring the max (in case it comes from -+ * thermal throttling or similar). -+ */ -+ if (unlikely(min > max)) -+ min = max; -+ -+ return __resolve_freq(policy, clamp_val(target_freq, min, max), -+ CPUFREQ_RELATION_LE); - } - EXPORT_SYMBOL_GPL(cpufreq_driver_resolve_freq); - -@@ -2337,6 +2350,7 @@ int __cpufreq_driver_target(struct cpufr - if (cpufreq_disabled()) - return -ENODEV; - -+ target_freq = clamp_val(target_freq, policy->min, policy->max); - target_freq = __resolve_freq(policy, target_freq, relation); - - pr_debug("target for CPU %u: %u kHz, relation %u, requested %u kHz\n", -@@ -2661,11 +2675,15 @@ static int cpufreq_set_policy(struct cpu - * Resolve policy min/max to available frequencies. It ensures - * no frequency resolution will neither overshoot the requested maximum - * nor undershoot the requested minimum. -+ * -+ * Avoid storing intermediate values in policy->max or policy->min and -+ * compiler optimizations around them because they may be accessed -+ * concurrently by cpufreq_driver_resolve_freq() during the update. - */ -- policy->min = new_data.min; -- policy->max = new_data.max; -- policy->min = __resolve_freq(policy, policy->min, CPUFREQ_RELATION_L); -- policy->max = __resolve_freq(policy, policy->max, CPUFREQ_RELATION_H); -+ WRITE_ONCE(policy->max, __resolve_freq(policy, new_data.max, CPUFREQ_RELATION_H)); -+ new_data.min = __resolve_freq(policy, new_data.min, CPUFREQ_RELATION_L); -+ WRITE_ONCE(policy->min, new_data.min > policy->max ? policy->max : new_data.min); -+ - trace_cpu_frequency_limits(policy); - - cpufreq_update_pressure(policy); diff --git a/queue-6.14/cpufreq-reference-count-policy-in-cpufreq_update_limits.patch b/queue-6.14/cpufreq-reference-count-policy-in-cpufreq_update_limits.patch index 01f693bf59..5d9fc8a882 100644 --- a/queue-6.14/cpufreq-reference-count-policy-in-cpufreq_update_limits.patch +++ b/queue-6.14/cpufreq-reference-count-policy-in-cpufreq_update_limits.patch @@ -35,7 +35,7 @@ Signed-off-by: Greg Kroah-Hartman --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c -@@ -2780,10 +2780,18 @@ EXPORT_SYMBOL(cpufreq_update_policy); +@@ -2762,10 +2762,18 @@ EXPORT_SYMBOL(cpufreq_update_policy); */ void cpufreq_update_limits(unsigned int cpu) { diff --git a/queue-6.14/series b/queue-6.14/series index bca91b274a..5d776fd051 100644 --- a/queue-6.14/series +++ b/queue-6.14/series @@ -124,7 +124,6 @@ bluetooth-vhci-avoid-needless-snprintf-calls.patch btrfs-ioctl-don-t-free-iov-when-btrfs_encoded_read-returns-eagain.patch btrfs-correctly-escape-subvol-in-btrfs_show_options.patch cpufreq-sched-explicitly-synchronize-limits_changed-flag-handling.patch -cpufreq-avoid-using-inconsistent-policy-min-and-policy-max.patch crypto-caam-qi-fix-drv_ctx-refcount-bug.patch hfs-hfsplus-fix-slab-out-of-bounds-in-hfs_bnode_read_key.patch i2c-cros-ec-tunnel-defer-probe-if-parent-ec-is-not-present.patch diff --git a/queue-6.6/cpufreq-avoid-using-inconsistent-policy-min-and-policy-max.patch b/queue-6.6/cpufreq-avoid-using-inconsistent-policy-min-and-policy-max.patch deleted file mode 100644 index b505105b9f..0000000000 --- a/queue-6.6/cpufreq-avoid-using-inconsistent-policy-min-and-policy-max.patch +++ /dev/null @@ -1,106 +0,0 @@ -From 7491cdf46b5cbdf123fc84fbe0a07e9e3d7b7620 Mon Sep 17 00:00:00 2001 -From: "Rafael J. Wysocki" -Date: Wed, 16 Apr 2025 16:12:37 +0200 -Subject: cpufreq: Avoid using inconsistent policy->min and policy->max - -From: Rafael J. Wysocki - -commit 7491cdf46b5cbdf123fc84fbe0a07e9e3d7b7620 upstream. - -Since cpufreq_driver_resolve_freq() can run in parallel with -cpufreq_set_policy() and there is no synchronization between them, -the former may access policy->min and policy->max while the latter -is updating them and it may see intermediate values of them due -to the way the update is carried out. Also the compiler is free -to apply any optimizations it wants both to the stores in -cpufreq_set_policy() and to the loads in cpufreq_driver_resolve_freq() -which may result in additional inconsistencies. - -To address this, use WRITE_ONCE() when updating policy->min and -policy->max in cpufreq_set_policy() and use READ_ONCE() for reading -them in cpufreq_driver_resolve_freq(). Moreover, rearrange the update -in cpufreq_set_policy() to avoid storing intermediate values in -policy->min and policy->max with the help of the observation that -their new values are expected to be properly ordered upfront. - -Also modify cpufreq_driver_resolve_freq() to take the possible reverse -ordering of policy->min and policy->max, which may happen depending on -the ordering of operations when this function and cpufreq_set_policy() -run concurrently, into account by always honoring the max when it -turns out to be less than the min (in case it comes from thermal -throttling or similar). - -Fixes: 151717690694 ("cpufreq: Make policy min/max hard requirements") -Cc: 5.16+ # 5.16+ -Signed-off-by: Rafael J. Wysocki -Reviewed-by: Christian Loehle -Acked-by: Viresh Kumar -Link: https://patch.msgid.link/5907080.DvuYhMxLoT@rjwysocki.net -Signed-off-by: Greg Kroah-Hartman ---- - drivers/cpufreq/cpufreq.c | 32 +++++++++++++++++++++++++------- - 1 file changed, 25 insertions(+), 7 deletions(-) - ---- a/drivers/cpufreq/cpufreq.c -+++ b/drivers/cpufreq/cpufreq.c -@@ -538,8 +538,6 @@ static unsigned int __resolve_freq(struc - { - unsigned int idx; - -- target_freq = clamp_val(target_freq, policy->min, policy->max); -- - if (!policy->freq_table) - return target_freq; - -@@ -563,7 +561,22 @@ static unsigned int __resolve_freq(struc - unsigned int cpufreq_driver_resolve_freq(struct cpufreq_policy *policy, - unsigned int target_freq) - { -- return __resolve_freq(policy, target_freq, CPUFREQ_RELATION_LE); -+ unsigned int min = READ_ONCE(policy->min); -+ unsigned int max = READ_ONCE(policy->max); -+ -+ /* -+ * If this function runs in parallel with cpufreq_set_policy(), it may -+ * read policy->min before the update and policy->max after the update -+ * or the other way around, so there is no ordering guarantee. -+ * -+ * Resolve this by always honoring the max (in case it comes from -+ * thermal throttling or similar). -+ */ -+ if (unlikely(min > max)) -+ min = max; -+ -+ return __resolve_freq(policy, clamp_val(target_freq, min, max), -+ CPUFREQ_RELATION_LE); - } - EXPORT_SYMBOL_GPL(cpufreq_driver_resolve_freq); - -@@ -2335,6 +2348,7 @@ int __cpufreq_driver_target(struct cpufr - if (cpufreq_disabled()) - return -ENODEV; - -+ target_freq = clamp_val(target_freq, policy->min, policy->max); - target_freq = __resolve_freq(policy, target_freq, relation); - - pr_debug("target for CPU %u: %u kHz, relation %u, requested %u kHz\n", -@@ -2625,11 +2639,15 @@ static int cpufreq_set_policy(struct cpu - * Resolve policy min/max to available frequencies. It ensures - * no frequency resolution will neither overshoot the requested maximum - * nor undershoot the requested minimum. -+ * -+ * Avoid storing intermediate values in policy->max or policy->min and -+ * compiler optimizations around them because they may be accessed -+ * concurrently by cpufreq_driver_resolve_freq() during the update. - */ -- policy->min = new_data.min; -- policy->max = new_data.max; -- policy->min = __resolve_freq(policy, policy->min, CPUFREQ_RELATION_L); -- policy->max = __resolve_freq(policy, policy->max, CPUFREQ_RELATION_H); -+ WRITE_ONCE(policy->max, __resolve_freq(policy, new_data.max, CPUFREQ_RELATION_H)); -+ new_data.min = __resolve_freq(policy, new_data.min, CPUFREQ_RELATION_L); -+ WRITE_ONCE(policy->min, new_data.min > policy->max ? policy->max : new_data.min); -+ - trace_cpu_frequency_limits(policy); - - policy->cached_target_freq = UINT_MAX; diff --git a/queue-6.6/cpufreq-reference-count-policy-in-cpufreq_update_limits.patch b/queue-6.6/cpufreq-reference-count-policy-in-cpufreq_update_limits.patch index 06da4f0870..2d0b553611 100644 --- a/queue-6.6/cpufreq-reference-count-policy-in-cpufreq_update_limits.patch +++ b/queue-6.6/cpufreq-reference-count-policy-in-cpufreq_update_limits.patch @@ -35,7 +35,7 @@ Signed-off-by: Greg Kroah-Hartman --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c -@@ -2743,10 +2743,18 @@ EXPORT_SYMBOL(cpufreq_update_policy); +@@ -2725,10 +2725,18 @@ EXPORT_SYMBOL(cpufreq_update_policy); */ void cpufreq_update_limits(unsigned int cpu) { diff --git a/queue-6.6/series b/queue-6.6/series index bfa5e6f7ea..6251796073 100644 --- a/queue-6.6/series +++ b/queue-6.6/series @@ -305,7 +305,6 @@ ftrace-fix-incorrect-hash-size-in-register_ftrace_di.patch bluetooth-l2cap-process-valid-commands-in-too-long-frame.patch bluetooth-vhci-avoid-needless-snprintf-calls.patch btrfs-correctly-escape-subvol-in-btrfs_show_options.patch -cpufreq-avoid-using-inconsistent-policy-min-and-policy-max.patch crypto-caam-qi-fix-drv_ctx-refcount-bug.patch hfs-hfsplus-fix-slab-out-of-bounds-in-hfs_bnode_read_key.patch i2c-cros-ec-tunnel-defer-probe-if-parent-ec-is-not-present.patch -- 2.47.3