From nobody Sat Feb 7 10:08:14 2026 Received: from out30-118.freemail.mail.aliyun.com (out30-118.freemail.mail.aliyun.com [115.124.30.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 747A82FF158 for ; Thu, 5 Feb 2026 12:16:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.118 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770293806; cv=none; b=HMYEI9WHcVdZ9sipe2yJhtQEpx89xMQ+QneXlpXr6rJ7z+6SjVIJahMlQP887XD1MUkBCfOxhCfobp7yfR92rrxKs0rX1N4dguXSTemotf2qEPFtLVW2LjxOVUhReTfw9tGTHhrJMRmPpaRe0MOdZ8pGn2CLRc5DJR5S/Cf8bsI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770293806; c=relaxed/simple; bh=QpAiufEX+cyDMRPxh6VXeLpZW4KWO24Y6I/x/JrZ7Xo=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=XFPJyAdpaAQygfFiV028dEgbER7PTWh961NfxIpJsb0lipkUDuOLaKGrMiNJ6zF63xPTkUdfaR0Nw80P5k0xZVwY3fOcbHNOOXGJZMCYxxE/w75vAhFMT9rKp/Fp3ZX3hzAa9CDm/47SdtInFvZkeUwZn08H5VKn5jhyoL29d0w= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=n9OlHHSD; arc=none smtp.client-ip=115.124.30.118 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="n9OlHHSD" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1770293802; h=From:To:Subject:Date:Message-ID:MIME-Version; bh=vqjw6KqXzJomH3TcE9LMBHSPYPYNGrUh0jEWCj+m51k=; b=n9OlHHSDt0nhG7d//w3gCtBxoijWO9HZnSXCiLPyrEaR5BzNkAK1ohKVqqmRW5KVmO7q45mxOMqA9pPXERWSEGtlAhG453pVMtNPKu98PI/VMHVTV29KmV+Kbzqo7v+JLozyVnZN23xLtGHQzZxQOAao/PnhbtkpR4ilitjFx2Y= Received: from DESKTOP-S9E58SO.localdomain(mailfrom:cp0613@linux.alibaba.com fp:SMTPD_---0WyawLmD_1770293795 cluster:ay36) by smtp.aliyun-inc.com; Thu, 05 Feb 2026 20:16:42 +0800 From: cp0613@linux.alibaba.com To: pjw@kernel.org, anup@brainfault.org, alex@ghiti.fr, guoren@kernel.org Cc: linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, Chen Pei Subject: [PATCH] riscv: smp: Align secondary_start_sbi to 4 bytes Date: Thu, 5 Feb 2026 20:16:25 +0800 Message-ID: <20260205121625.716-1-cp0613@linux.alibaba.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Chen Pei During SMP boot, the secondary_start_sbi address is passed to the slave core via sbi_hsm_hart_start. In OpenSBI, this address is written to STVEC in sbi_hart_switch_mode. According to the privileged specification, the BASE field of STVEC must always be aligned on a 4-byte boundary. However, System.map reveals that secondary_start_sbi is not a 4-byte aligned address. For example, the address of secondary_start_sbi is 0xffffffff80001066, and the disassembly is as follows: Dump of assembler code from 0xffffffff80001052 to 0xffffffff8000107a: 0xffffffff80001052 <_start+4178>: c.nop -11 0xffffffff80001054 <_start+4180>: auipc gp,0x1a1f 0xffffffff80001058 <_start+4184>: addi gp,gp,84 0xffffffff8000105c <_start+4188>: csrw satp,a2 0xffffffff80001060 <_start+4192>: sfence.vma 0xffffffff80001064 <_start+4196>: ret 0xffffffff80001066 <_start+4198>: csrw sie,zero 0xffffffff8000106a <_start+4202>: csrw sip,zero 0xffffffff8000106e <_start+4206>: li t0,2 0xffffffff80001070 <_start+4208>: csrw scounteren,t0 0xffffffff80001074 <_start+4212>: auipc gp,0x1a1f 0xffffffff80001078 <_start+4216>: addi gp,gp,52 When writing to STVEC at address 0xffffffff80001066, the actual write address is 0xffffffff80001064, corresponding to the address of the previous ret instruction. This is unexpected, and if an interrupt occurs at this point, it will cause unpredictable results. However, secondary_start_sbi immediately masks all interrupts and updates STVEC, so no problems occurred. In summary, it is more reasonable to make secondary_start_sbi satisfy 4-byte alignment. Signed-off-by: Chen Pei Reviewed-by: Andrew Jones Reviewed-by: Guo Ren (Alibaba DAMO Academy) --- arch/riscv/kernel/head.S | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/riscv/kernel/head.S b/arch/riscv/kernel/head.S index bdf3352acf4c..f35dbfa79505 100644 --- a/arch/riscv/kernel/head.S +++ b/arch/riscv/kernel/head.S @@ -124,6 +124,7 @@ relocate_enable_mmu: =20 ret #endif /* CONFIG_MMU */ +.align 2 #ifdef CONFIG_SMP .global secondary_start_sbi secondary_start_sbi: --=20 2.50.1