of_find_node_by_path() returns a referenced device node.  In
arm_dt_init_cpu_maps(), the /cpus node is kept across CPU node parsing
but is never released on the success path or on post-acquire error
paths.

Route all exits after the /cpus lookup through a common cleanup label so
the node reference is dropped.

Fixes: a0ae02405076a ("ARM: kernel: add device tree init map function")
Signed-off-by: Yuho Choi <dbgh9129@gmail.com>
---
 arch/arm/kernel/devtree.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index 3b78966e750a..88a072d3b8e1 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -93,7 +93,7 @@ void __init arm_dt_init_cpu_maps(void)
 		 */
 		if (hwid & ~MPIDR_HWID_BITMASK) {
 			of_node_put(cpu);
-			return;
+			goto out_put_cpus;
 		}
 
 		/*
@@ -107,7 +107,7 @@ void __init arm_dt_init_cpu_maps(void)
 			if (WARN(tmp_map[j] == hwid,
 				 "Duplicate /cpu reg properties in the DT\n")) {
 				of_node_put(cpu);
-				return;
+				goto out_put_cpus;
 			}
 
 		/*
@@ -149,7 +149,7 @@ void __init arm_dt_init_cpu_maps(void)
 
 	if (!bootcpu_valid) {
 		pr_warn("DT missing boot CPU MPIDR[23:0], fall back to default cpu_logical_map\n");
-		return;
+		goto out_put_cpus;
 	}
 
 	/*
@@ -162,6 +162,9 @@ void __init arm_dt_init_cpu_maps(void)
 		cpu_logical_map(i) = tmp_map[i];
 		pr_debug("cpu logical map 0x%x\n", cpu_logical_map(i));
 	}
+
+out_put_cpus:
+	of_node_put(cpus);
 }
 
 bool arch_match_cpu_phys_id(int cpu, u64 phys_id)
-- 
2.43.0

Hi,

Just a gentle reminder regarding this patch.

I would appreciate any feedback when you have a chance to review it.

Thanks for your time.

Best regards,
Yuho Choi

On Tue, Jun 02, 2026 at 10:54:26PM -0400, 최유호 wrote:
> Hi,
> 
> Just a gentle reminder regarding this patch.
> 
> I would appreciate any feedback when you have a chance to review it.

You are more likely to get comments if you repost the patch.

But please think about what you are fixing. Is it theoretical? Is it
old code which has been running perfectly well for 10 years? Is it
something really early in the boot that if it fails, the machine is
dead anyway, so who cares about a minor resource leak?

Are these patches actual worth while?

      Andrew

Dear Andrew

On Tue, 2 Jun 2026 at 23:09, Andrew Lunn <andrew@lunn.ch> wrote:
>
> But please think about what you are fixing. Is it theoretical? Is it
> old code which has been running perfectly well for 10 years? Is it
> something really early in the boot that if it fails, the machine is
> dead anyway, so who cares about a minor resource leak?
>
> Are these patches actual worth while?

That's a fair point.

I am still relatively new to Linux kernel development, and I think I
focused too much on correctness itself without giving enough thought
to the practical impact of the issue.

I appreciate your feedback. I'll try to consider the mentioned points
when evaluating future patches.

Best regards,
Yuho