The for_each_child_of_node() macro requires an explicit call to
of_node_put() on early exits to decrement the child refcount and avoid a
memory leak.
The child node is not required outsie the loop, and the resource must be
released before the function returns.
Add the missing of_node_put().
Cc: stable(a)vger.kernel.org
Fixes: 82e82130a78b ("usb: core: Set connect_type of ports based on DT node")
Signed-off-by: Javier Carrasco <javier.carrasco.cruz(a)gmail.com>
---
This bug was found while doing some code analysis, and I could not test
it with real hardware. Although the issue and it solution are
straightforward, any validation beyond compilation and static analysis
is always welcome.
---
drivers/usb/core/of.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/core/of.c b/drivers/usb/core/of.c
index f1a499ee482c..763e4122ed5b 100644
--- a/drivers/usb/core/of.c
+++ b/drivers/usb/core/of.c
@@ -84,9 +84,12 @@ static bool usb_of_has_devices_or_graph(const struct usb_device *hub)
if (of_graph_is_present(np))
return true;
- for_each_child_of_node(np, child)
- if (of_property_present(child, "reg"))
+ for_each_child_of_node(np, child) {
+ if (of_property_present(child, "reg")) {
+ of_node_put(child);
return true;
+ }
+ }
return false;
}
---
base-commit: 62c97045b8f720c2eac807a5f38e26c9ed512371
change-id: 20240624-usb_core_of_memleak-79161623b62e
Best regards,
--
Javier Carrasco <javier.carrasco.cruz(a)gmail.com>
The acpi_cst_latency_cmp comparison function currently used for sorting
C-state latencies does not satisfy transitivity, causing incorrect
sorting results. Specifically, if there are two valid acpi_processor_cx
elements A and B and one invalid element C, it may occur that A < B,
A = C, and B = C. Sorting algorithms assume that if A < B and A = C,
then C < B, leading to incorrect ordering.
Given the small size of the array (<=8), we replace the library sort
function with a simple insertion sort that properly ignores invalid
elements and sorts valid ones based on latency. This change ensures
correct ordering of the C-state latencies.
Fixes: 65ea8f2c6e23 ("ACPI: processor idle: Fix up C-state latency if not ordered")
Cc: stable(a)vger.kernel.org
Reported-by: Julian Sikorski <belegdol(a)gmail.com>
Closes: https://lore.kernel.org/lkml/70674dc7-5586-4183-8953-8095567e73df@gmail.com/
Signed-off-by: Kuan-Wei Chiu <visitorckw(a)gmail.com>
---
v2 -> v3:
- Remove #include <linux/sort.h>
- Cc @stable
Note: I only performed a build test and a simple unit test to ensure
the latency of valid elements is correctly sorted in the randomly
generated data.
drivers/acpi/processor_idle.c | 36 ++++++++++++++---------------------
1 file changed, 14 insertions(+), 22 deletions(-)
diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
index bd6a7857ce05..17cc81340b4b 100644
--- a/drivers/acpi/processor_idle.c
+++ b/drivers/acpi/processor_idle.c
@@ -16,7 +16,6 @@
#include <linux/acpi.h>
#include <linux/dmi.h>
#include <linux/sched.h> /* need_resched() */
-#include <linux/sort.h>
#include <linux/tick.h>
#include <linux/cpuidle.h>
#include <linux/cpu.h>
@@ -386,25 +385,21 @@ static void acpi_processor_power_verify_c3(struct acpi_processor *pr,
acpi_write_bit_register(ACPI_BITREG_BUS_MASTER_RLD, 1);
}
-static int acpi_cst_latency_cmp(const void *a, const void *b)
+static void acpi_cst_latency_sort(struct acpi_processor_cx *arr, size_t length)
{
- const struct acpi_processor_cx *x = a, *y = b;
+ int i, j, k;
- if (!(x->valid && y->valid))
- return 0;
- if (x->latency > y->latency)
- return 1;
- if (x->latency < y->latency)
- return -1;
- return 0;
-}
-static void acpi_cst_latency_swap(void *a, void *b, int n)
-{
- struct acpi_processor_cx *x = a, *y = b;
-
- if (!(x->valid && y->valid))
- return;
- swap(x->latency, y->latency);
+ for (i = 1; i < length; i++) {
+ if (!arr[i].valid)
+ continue;
+ for (j = i - 1, k = i; j >= 0; j--) {
+ if (!arr[j].valid)
+ continue;
+ if (arr[j].latency > arr[k].latency)
+ swap(arr[j].latency, arr[k].latency);
+ k = j;
+ }
+ }
}
static int acpi_processor_power_verify(struct acpi_processor *pr)
@@ -449,10 +444,7 @@ static int acpi_processor_power_verify(struct acpi_processor *pr)
if (buggy_latency) {
pr_notice("FW issue: working around C-state latencies out of order\n");
- sort(&pr->power.states[1], max_cstate,
- sizeof(struct acpi_processor_cx),
- acpi_cst_latency_cmp,
- acpi_cst_latency_swap);
+ acpi_cst_latency_sort(&pr->power.states[1], max_cstate);
}
lapic_timer_propagate_broadcast(pr);
--
2.34.1
Linux kernel uses thermal zone node name during registering thermal
zones and has a hard-coded limit of 20 characters, including terminating
NUL byte. The bindings expect node names to finish with '-thermal'
which is eight bytes long, thus we have only 11 characters for the reset
of the node name (thus 10 for the pattern after leading fixed character).
Reported-by: Rob Herring <robh(a)kernel.org>
Closes: https://lore.kernel.org/all/CAL_JsqKogbT_4DPd1n94xqeHaU_J8ve5K09WOyVsRX3jxx…
Fixes: 1202a442a31f ("dt-bindings: thermal: Add yaml bindings for thermal zones")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org>
---
Changes in v2:
1. Shorten the pattern and mention source of size requirement (Rob).
---
Documentation/devicetree/bindings/thermal/thermal-zones.yaml | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/thermal/thermal-zones.yaml b/Documentation/devicetree/bindings/thermal/thermal-zones.yaml
index 68398e7e8655..606b80965a44 100644
--- a/Documentation/devicetree/bindings/thermal/thermal-zones.yaml
+++ b/Documentation/devicetree/bindings/thermal/thermal-zones.yaml
@@ -49,7 +49,10 @@ properties:
to take when the temperature crosses those thresholds.
patternProperties:
- "^[a-zA-Z][a-zA-Z0-9\\-]{1,12}-thermal$":
+ # Node name is limited in size due to Linux kernel requirements - 19
+ # characters in total (see THERMAL_NAME_LENGTH, including terminating NUL
+ # byte):
+ "^[a-zA-Z][a-zA-Z0-9\\-]{1,10}-thermal$":
type: object
description:
Each thermal zone node contains information about how frequently it
--
2.43.0
Driver API devm_krealloc() calls alloc_dr() with wrong argument
@total_new_size, so causes more memory to be allocated than required
fix this memory waste by using @new_size as the argument for alloc_dr().
Fixes: f82485722e5d ("devres: provide devm_krealloc()")
Cc: stable(a)vger.kernel.org
Signed-off-by: Zijun Hu <quic_zijuhu(a)quicinc.com>
---
Previous discussion link:
https://lore.kernel.org/all/1718531655-29761-1-git-send-email-quic_zijuhu@q…
Changes since the original one:
- Correct tile and commit message
- Add inline comments and stable tag
drivers/base/devres.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/base/devres.c b/drivers/base/devres.c
index 3df0025d12aa..ff2247eec43c 100644
--- a/drivers/base/devres.c
+++ b/drivers/base/devres.c
@@ -896,9 +896,12 @@ void *devm_krealloc(struct device *dev, void *ptr, size_t new_size, gfp_t gfp)
/*
* Otherwise: allocate new, larger chunk. We need to allocate before
* taking the lock as most probably the caller uses GFP_KERNEL.
+ * alloc_dr() will call check_dr_size() to reserve extra memory
+ * for struct devres automatically, so size @new_size user request
+ * is delivered to it directly as devm_kmalloc() does.
*/
new_dr = alloc_dr(devm_kmalloc_release,
- total_new_size, gfp, dev_to_node(dev));
+ new_size, gfp, dev_to_node(dev));
if (!new_dr)
return NULL;
--
2.34.1
In the future, please send this to the regressions M/L and CC people
instead of just sending a private message.
For now, I've added the @regressions and @stable mailing lists as this
is an issue you find exposed specifically in the LTS series.
Hi Lars,
Can you please test 6.9.7? If this is still failing, can you please
check 6.10-rc6?
I'd like to understand if we just have a missing commit to backport or
it's a problem in the mainline kernel as well.
From the below description it's specifically with boost in passive
mode, right?
If 6.10-rc6 is still affected, can you please see if this commit helps?
https://git.kernel.org/pub/scm/linux/kernel/git/superm1/linux.git/commit/?h…
This is going into 6.11-rc1.
Perry, Jassmine,
Can you try to repro this using bleeding-edge or linux-next branches?
Thanks,
On 7/1/2024 4:33, Huang, Ray wrote:
> [AMD Official Use Only - AMD Internal Distribution Only]
>
> Hi all,
>
> Could you please help for a quick fix?
>
> -----Original Message-----
> From: Lars Wendler <wendler.lars(a)web.de>
> Sent: Monday, July 1, 2024 5:30 PM
> To: Huang, Ray <Ray.Huang(a)amd.com>
> Cc: gregkh(a)linuxfoundation.org
> Subject: linux-6.6.y: Regression in amd-pstate cpufreq driver since 6.6.34
>
> Hello dear kernel developers,
>
> I might have found a regression in the amd-pstate driver of linux-6.6 stable series. I haven't checked linux-master nor any other LTS branch.
>
>
> Now here's what I have found:
>
> Since linux-6.6.34 the following command fails:
>
> # echo 0 > /sys/devices/system/cpu/cpufreq/boost
> -bash: echo: write error: Invalid argument
>
> and indeed, disabling CPU boost seems to not work:
>
> # cat /sys/devices/system/cpu/cpufreq/boost
> 1
>
> I have bisected the issue to commit
> 8f893e52b9e030a25ea62e31271bf930b01f2f07:
>
> cpufreq: amd-pstate: Fix the inconsistency in max frequency units
>
> commit e4731baaf29438508197d3a8a6d4f5a8c51663f8 upstream.
>
> Reverting that commit (even on latest linux-6.6 release) gives me back the ability to disable CPU boost again.
>
> I can only reproduce this bug on my Zen4 machine:
>
> # lscpu | grep "^Model name:" | sed 's@[[:space:]][[:space:]]\+@ @'
> Model name: AMD Ryzen 7 7745HX with Radeon Graphics
>
> My older Zen3 machines seem not to be affected by this issue. All my Ryzen systems run on latest linux-6.6 kernels and have the following configuration regarding amd-pstate:
>
> # zgrep -F AMD_PSTATE /proc/config.gz
> CONFIG_X86_AMD_PSTATE=y
> CONFIG_X86_AMD_PSTATE_DEFAULT_MODE=2
> # CONFIG_X86_AMD_PSTATE_UT is not set
>
>
> If you need more information, please don't hesitate to ask.
>
> Kind regards
> Lars Wendler