From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id DE1FDC87FCA for ; Mon, 4 Aug 2025 01:08:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From: Reply-To:Content-Type:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=2h+msSwB37cIutRMpSTDoGXpSycPtsmQovPsuONXx+Q=; b=WEkDS4ML5chcH2GEAfv6Q1h0Uq 8wntw+PPdt1WsbwhkGVZ5IcB26mlbYynWKscTMKOUeqggYOPs3/5Uym86FYpfMDkfIu07tgGl1Ws8 HnQ9UpJU+1G9TnmZsJ/Bjt26Dc3ZJfUiRtMtp7ThiSA6C/4xr0CgXXS7JR0ywqwMOKKXQftgxq2xa ARMOTRYqfHZbicHMWqpw0YPHyIKriNKnbjemZnLEdKDvpB7946D+V0g+QWNcGnlIPwf0TXRvrQnHW iGUmOf1F7J15t+zdQGEgxUYsVVy/o6EYHz76n3PdZ/lEQHV5L8WiXJE7ldhxre968UGA18NnzQIQa weWzNKLA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1uijgD-00000009Oip-3w8H; Mon, 04 Aug 2025 01:07:57 +0000 Received: from tor.source.kernel.org ([2600:3c04:e001:324:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1uij7b-00000009LY9-12bz; Mon, 04 Aug 2025 00:32:11 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id AA773601E8; Mon, 4 Aug 2025 00:32:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2D46FC4CEF8; Mon, 4 Aug 2025 00:32:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1754267530; bh=xfIDBkosaUm8UJ4nUT5Fdx0QMC4jhRR/FYER00pacDk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=o7CWAicxHhSdBdZ5VEtkm1ptA6tkpLAXop70e/a/Y2SB2hgCNNTxRb219uNCJ++YO jEH0UgJDRIO4Ff0I62fs4NT7CfyQ3d9mEpW+FODI+ZrmWpTmc55qbAzRWOvGwDtbl2 v2x3NI3dA8fnyTzV+MgxOkJV2K7eFhpzKKeDWQsr2kH8hs83s34dQzLe+SXzNnWHDx w5sZd5aQ71ArnZrXFyHmnvcOmOn8/KUG3hTUP0qDGTF9A4IkQAxzaeXitYXOnBCfCh j7XsJyAn895FTPQGa9/mCno+YAmfO/NJtRaAQIFKYwUP81NT333iDSgLr2gpW0b506 Zb53q4Xp8jlrA== From: Sasha Levin To: patches@lists.linux.dev, stable@vger.kernel.org Cc: Alexander Kochetkov , Heiko Stuebner , Sasha Levin , linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org Subject: [PATCH AUTOSEL 6.12 19/69] ARM: rockchip: fix kernel hang during smp initialization Date: Sun, 3 Aug 2025 20:30:29 -0400 Message-Id: <20250804003119.3620476-19-sashal@kernel.org> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20250804003119.3620476-1-sashal@kernel.org> References: <20250804003119.3620476-1-sashal@kernel.org> MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore X-stable-base: Linux 6.12.41 Content-Transfer-Encoding: 8bit X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org From: Alexander Kochetkov [ Upstream commit 7cdb433bb44cdc87dc5260cdf15bf03cc1cd1814 ] In order to bring up secondary CPUs main CPU write trampoline code to SRAM. The trampoline code is written while secondary CPUs are powered on (at least that true for RK3188 CPU). Sometimes that leads to kernel hang. Probably because secondary CPU execute trampoline code while kernel doesn't expect. The patch moves SRAM initialization step to the point where all secondary CPUs are powered down. That fixes rarely hangs on RK3188: [ 0.091568] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 [ 0.091996] rockchip_smp_prepare_cpus: ncores 4 Signed-off-by: Alexander Kochetkov Link: https://lore.kernel.org/r/20250703140453.1273027-1-al.kochet@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin --- LLM Generated explanations, may be completely bogus: Based on my analysis of the commit and the code context, here's my determination: **Backport Status: YES** This commit should be backported to stable kernel trees for the following reasons: 1. **Fixes a real bug affecting users**: The commit explicitly mentions that it "fixes rarely hangs on RK3188" during SMP initialization. This is a critical boot-time issue that prevents the system from functioning properly. 2. **Small and contained fix**: The change is minimal - it only moves the SRAM initialization code (`rockchip_smp_prepare_sram()`) to execute after all secondary CPUs are powered down. The code movement is straightforward: - Lines 281-285 (old location) are moved to lines 321-325 (new location) - The fix is contained within a single function (`rockchip_smp_prepare_cpus()`) 3. **Clear root cause**: The commit message explains the race condition clearly - secondary CPUs may execute trampoline code while it's being written to SRAM, causing unpredictable behavior and hangs. 4. **No architectural changes**: This is purely a timing/ordering fix that doesn't introduce new features or change the architecture of the code. 5. **Critical subsystem**: SMP initialization is a critical kernel subsystem. A hang during boot makes the system unusable, which is a severe issue for affected users. 6. **Platform-specific fix**: The change only affects Rockchip ARM platforms (specifically those with Cortex-A9 CPUs like RK3188), limiting the scope of potential regressions. 7. **Follows stable tree rules**: The fix addresses an important bug (boot hang), is small and self-contained, has minimal risk of regression, and doesn't introduce new features. The key insight from the code analysis is that the original code had a clear race condition where: 1. Secondary CPUs were powered on (lines 287-288 in the original) 2. Trampoline code was written to SRAM (line 282 in the original) 3. Secondary CPUs could potentially execute incomplete/corrupted trampoline code The fix ensures all secondary CPUs are powered down (lines 321-323) before writing the trampoline code to SRAM (lines 321-325 in the new version), eliminating the race condition. arch/arm/mach-rockchip/platsmp.c | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/arch/arm/mach-rockchip/platsmp.c b/arch/arm/mach-rockchip/platsmp.c index 36915a073c23..f432d22bfed8 100644 --- a/arch/arm/mach-rockchip/platsmp.c +++ b/arch/arm/mach-rockchip/platsmp.c @@ -279,11 +279,6 @@ static void __init rockchip_smp_prepare_cpus(unsigned int max_cpus) } if (read_cpuid_part() == ARM_CPU_PART_CORTEX_A9) { - if (rockchip_smp_prepare_sram(node)) { - of_node_put(node); - return; - } - /* enable the SCU power domain */ pmu_set_power_domain(PMU_PWRDN_SCU, true); @@ -316,11 +311,19 @@ static void __init rockchip_smp_prepare_cpus(unsigned int max_cpus) asm ("mrc p15, 1, %0, c9, c0, 2\n" : "=r" (l2ctlr)); ncores = ((l2ctlr >> 24) & 0x3) + 1; } - of_node_put(node); /* Make sure that all cores except the first are really off */ for (i = 1; i < ncores; i++) pmu_set_power_domain(0 + i, false); + + if (read_cpuid_part() == ARM_CPU_PART_CORTEX_A9) { + if (rockchip_smp_prepare_sram(node)) { + of_node_put(node); + return; + } + } + + of_node_put(node); } static void __init rk3036_smp_prepare_cpus(unsigned int max_cpus) -- 2.39.5 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id A5F80C87FCB for ; Mon, 4 Aug 2025 01:08:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-Id:Date:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Cnxpf508KTuGxhKaQ0M7XXZYPY90ct+AnZDr1oByGxI=; b=4BbYiRC+K/GfLR uWvXXs+2c5b8KD1rc6q/ijzwfo8bB/WS663G94RLqMJlIIJ3Vg2CPoanpdw+o6f3Q0vA5qz3a4A/n 8c5z3d+ovA6zeZyZs32yrKNia54tLWH+lBpx45tV/wZ3ZbGwoi989eH+XC1BXxOq+jcn4/ZJyw+KU HvUOYc7pwi/Ul4ZiTXxhNhy29slWYywLxxkLSsobtZN58+GgrS3uA309qEDxoOkrsHrmvaodgAHAD jm4DddTEeBxGANIQB7aYtX1cqh+NXVNa5Ez1Z5+vwEmckGaIchiIbARbM/bFsR3DsPY38G6gWFZ7h HVch/jJefIPDcIQYxGGw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1uijgE-00000009Oj5-21qM; Mon, 04 Aug 2025 01:07:58 +0000 Received: from tor.source.kernel.org ([2600:3c04:e001:324:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1uij7b-00000009LY9-12bz; Mon, 04 Aug 2025 00:32:11 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id AA773601E8; Mon, 4 Aug 2025 00:32:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2D46FC4CEF8; Mon, 4 Aug 2025 00:32:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1754267530; bh=xfIDBkosaUm8UJ4nUT5Fdx0QMC4jhRR/FYER00pacDk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=o7CWAicxHhSdBdZ5VEtkm1ptA6tkpLAXop70e/a/Y2SB2hgCNNTxRb219uNCJ++YO jEH0UgJDRIO4Ff0I62fs4NT7CfyQ3d9mEpW+FODI+ZrmWpTmc55qbAzRWOvGwDtbl2 v2x3NI3dA8fnyTzV+MgxOkJV2K7eFhpzKKeDWQsr2kH8hs83s34dQzLe+SXzNnWHDx w5sZd5aQ71ArnZrXFyHmnvcOmOn8/KUG3hTUP0qDGTF9A4IkQAxzaeXitYXOnBCfCh j7XsJyAn895FTPQGa9/mCno+YAmfO/NJtRaAQIFKYwUP81NT333iDSgLr2gpW0b506 Zb53q4Xp8jlrA== From: Sasha Levin To: patches@lists.linux.dev, stable@vger.kernel.org Cc: Alexander Kochetkov , Heiko Stuebner , Sasha Levin , linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org Subject: [PATCH AUTOSEL 6.12 19/69] ARM: rockchip: fix kernel hang during smp initialization Date: Sun, 3 Aug 2025 20:30:29 -0400 Message-Id: <20250804003119.3620476-19-sashal@kernel.org> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20250804003119.3620476-1-sashal@kernel.org> References: <20250804003119.3620476-1-sashal@kernel.org> MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore X-stable-base: Linux 6.12.41 X-BeenThere: linux-rockchip@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Upstream kernel work for Rockchip platforms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "Linux-rockchip" Errors-To: linux-rockchip-bounces+linux-rockchip=archiver.kernel.org@lists.infradead.org From: Alexander Kochetkov [ Upstream commit 7cdb433bb44cdc87dc5260cdf15bf03cc1cd1814 ] In order to bring up secondary CPUs main CPU write trampoline code to SRAM. The trampoline code is written while secondary CPUs are powered on (at least that true for RK3188 CPU). Sometimes that leads to kernel hang. Probably because secondary CPU execute trampoline code while kernel doesn't expect. The patch moves SRAM initialization step to the point where all secondary CPUs are powered down. That fixes rarely hangs on RK3188: [ 0.091568] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 [ 0.091996] rockchip_smp_prepare_cpus: ncores 4 Signed-off-by: Alexander Kochetkov Link: https://lore.kernel.org/r/20250703140453.1273027-1-al.kochet@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin --- LLM Generated explanations, may be completely bogus: Based on my analysis of the commit and the code context, here's my determination: **Backport Status: YES** This commit should be backported to stable kernel trees for the following reasons: 1. **Fixes a real bug affecting users**: The commit explicitly mentions that it "fixes rarely hangs on RK3188" during SMP initialization. This is a critical boot-time issue that prevents the system from functioning properly. 2. **Small and contained fix**: The change is minimal - it only moves the SRAM initialization code (`rockchip_smp_prepare_sram()`) to execute after all secondary CPUs are powered down. The code movement is straightforward: - Lines 281-285 (old location) are moved to lines 321-325 (new location) - The fix is contained within a single function (`rockchip_smp_prepare_cpus()`) 3. **Clear root cause**: The commit message explains the race condition clearly - secondary CPUs may execute trampoline code while it's being written to SRAM, causing unpredictable behavior and hangs. 4. **No architectural changes**: This is purely a timing/ordering fix that doesn't introduce new features or change the architecture of the code. 5. **Critical subsystem**: SMP initialization is a critical kernel subsystem. A hang during boot makes the system unusable, which is a severe issue for affected users. 6. **Platform-specific fix**: The change only affects Rockchip ARM platforms (specifically those with Cortex-A9 CPUs like RK3188), limiting the scope of potential regressions. 7. **Follows stable tree rules**: The fix addresses an important bug (boot hang), is small and self-contained, has minimal risk of regression, and doesn't introduce new features. The key insight from the code analysis is that the original code had a clear race condition where: 1. Secondary CPUs were powered on (lines 287-288 in the original) 2. Trampoline code was written to SRAM (line 282 in the original) 3. Secondary CPUs could potentially execute incomplete/corrupted trampoline code The fix ensures all secondary CPUs are powered down (lines 321-323) before writing the trampoline code to SRAM (lines 321-325 in the new version), eliminating the race condition. arch/arm/mach-rockchip/platsmp.c | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/arch/arm/mach-rockchip/platsmp.c b/arch/arm/mach-rockchip/platsmp.c index 36915a073c23..f432d22bfed8 100644 --- a/arch/arm/mach-rockchip/platsmp.c +++ b/arch/arm/mach-rockchip/platsmp.c @@ -279,11 +279,6 @@ static void __init rockchip_smp_prepare_cpus(unsigned int max_cpus) } if (read_cpuid_part() == ARM_CPU_PART_CORTEX_A9) { - if (rockchip_smp_prepare_sram(node)) { - of_node_put(node); - return; - } - /* enable the SCU power domain */ pmu_set_power_domain(PMU_PWRDN_SCU, true); @@ -316,11 +311,19 @@ static void __init rockchip_smp_prepare_cpus(unsigned int max_cpus) asm ("mrc p15, 1, %0, c9, c0, 2\n" : "=r" (l2ctlr)); ncores = ((l2ctlr >> 24) & 0x3) + 1; } - of_node_put(node); /* Make sure that all cores except the first are really off */ for (i = 1; i < ncores; i++) pmu_set_power_domain(0 + i, false); + + if (read_cpuid_part() == ARM_CPU_PART_CORTEX_A9) { + if (rockchip_smp_prepare_sram(node)) { + of_node_put(node); + return; + } + } + + of_node_put(node); } static void __init rk3036_smp_prepare_cpus(unsigned int max_cpus) -- 2.39.5 _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip