| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-Id: <20241014094705.71775-1-cuiyunhui@bytedance.com> Date: Mon, 14 Oct 2024 17:47:05 +0800 From: Yunhui Cui <cuiyunhui@...edance.com> To: punit.agrawal@...edance.com, paul.walmsley@...ive.com, palmer@...belt.com, aou@...s.berkeley.edu, sunilvl@...tanamicro.com, cuiyunhui@...edance.com, ajones@...tanamicro.com, alexghiti@...osinc.com, jeeheng.sia@...rfivetech.com, haibo1.xu@...el.com, linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org Subject: [PATCH] RISC-V: ACPI: fix early_ioremap to early_memremap When SVPBMT is enabled, __acpi_map_table() will directly access the data in DDR through the IO attribute, rather than through hardware cache consistency, resulting in incorrect data in the obtained ACPI table. The log: ACPI: [ACPI:0x18] Invalid zero length. We do not assume whether the bootloader flushes or not. We should access in a cacheable way instead of maintaining cache consistency by software. Signed-off-by: Yunhui Cui <cuiyunhui@...edance.com> --- arch/riscv/kernel/acpi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/riscv/kernel/acpi.c b/arch/riscv/kernel/acpi.c index 6e0d333f57e5..3177c9af8764 100644 --- a/arch/riscv/kernel/acpi.c +++ b/arch/riscv/kernel/acpi.c @@ -210,7 +210,7 @@ void __init __iomem *__acpi_map_table(unsigned long phys, unsigned long size) if (!size) return NULL; - return early_ioremap(phys, size); + return early_memremap(phys, size); } void __init __acpi_unmap_table(void __iomem *map, unsigned long size) -- 2.39.2
Powered by blists - more mailing lists