+++ /dev/null
-From 7491cdf46b5cbdf123fc84fbe0a07e9e3d7b7620 Mon Sep 17 00:00:00 2001
-From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
-Date: Wed, 16 Apr 2025 16:12:37 +0200
-Subject: cpufreq: Avoid using inconsistent policy->min and policy->max
-
-From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
-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+ <stable@vger.kernel.org> # 5.16+
-Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-Reviewed-by: Christian Loehle <christian.loehle@arm.com>
-Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
-Link: https://patch.msgid.link/5907080.DvuYhMxLoT@rjwysocki.net
-Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
----
- 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;
--- 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)
{
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
+++ /dev/null
-From 7491cdf46b5cbdf123fc84fbe0a07e9e3d7b7620 Mon Sep 17 00:00:00 2001
-From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
-Date: Wed, 16 Apr 2025 16:12:37 +0200
-Subject: cpufreq: Avoid using inconsistent policy->min and policy->max
-
-From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
-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+ <stable@vger.kernel.org> # 5.16+
-Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-Reviewed-by: Christian Loehle <christian.loehle@arm.com>
-Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
-Link: https://patch.msgid.link/5907080.DvuYhMxLoT@rjwysocki.net
-Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
----
- 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);
--- 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)
{
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
+++ /dev/null
-From 7491cdf46b5cbdf123fc84fbe0a07e9e3d7b7620 Mon Sep 17 00:00:00 2001
-From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
-Date: Wed, 16 Apr 2025 16:12:37 +0200
-Subject: cpufreq: Avoid using inconsistent policy->min and policy->max
-
-From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
-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+ <stable@vger.kernel.org> # 5.16+
-Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-Reviewed-by: Christian Loehle <christian.loehle@arm.com>
-Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
-Link: https://patch.msgid.link/5907080.DvuYhMxLoT@rjwysocki.net
-Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
----
- 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);
--- 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)
{
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
+++ /dev/null
-From 7491cdf46b5cbdf123fc84fbe0a07e9e3d7b7620 Mon Sep 17 00:00:00 2001
-From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
-Date: Wed, 16 Apr 2025 16:12:37 +0200
-Subject: cpufreq: Avoid using inconsistent policy->min and policy->max
-
-From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
-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+ <stable@vger.kernel.org> # 5.16+
-Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-Reviewed-by: Christian Loehle <christian.loehle@arm.com>
-Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
-Link: https://patch.msgid.link/5907080.DvuYhMxLoT@rjwysocki.net
-Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
----
- 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;
--- 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)
{
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
projects / thirdparty / kernel / stable-queue.git / commitdiff
