linux-kernel - Re: [PATCH V2 2/2] riscv: errata: Add ERRATA_THEAD_WRITE

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJF2gTQBzX9A=AEAaH5SyxWfuNwkG6eichC1w1ryEqRMeuOokA@mail.gmail.com>
Date: Tue, 15 Jul 2025 14:14:44 +0800
From: Guo Ren <guoren@...nel.org>
To: Drew Fustini <fustini@...nel.org>
Cc: palmer@...belt.com, conor@...nel.org, alexghiti@...osinc.com, 
	paul.walmsley@...ive.com, bjorn@...osinc.com, eobras@...hat.com, 
	corbet@....net, peterlin@...estech.com, rabenda.cn@...il.com, 
	linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org, 
	Leonardo Bras <leobras@...hat.com>
Subject: Re: [PATCH V2 2/2] riscv: errata: Add ERRATA_THEAD_WRITE_ONCE fixup

On Tue, Jul 15, 2025 at 11:02 AM Drew Fustini <fustini@...nel.org> wrote:
>
> On Sun, Jul 13, 2025 at 11:53:21AM -0400, guoren@...nel.org wrote:
> > From: "Guo Ren (Alibaba DAMO Academy)" <guoren@...nel.org>
> >
> > The early version of XuanTie C910 core has a store merge buffer
> > delay problem. The store merge buffer could improve the store queue
> > performance by merging multi-store requests, but when there are not
> > continued store requests, the prior single store request would be
> > waiting in the store queue for a long time. That would cause
> > significant problems for communication between multi-cores. This
> > problem was found on sg2042 & th1520 platforms with the qspinlock
> > lock torture test.
> >
> > So appending a fence w.o could immediately flush the store merge
> > buffer and let other cores see the write result.
> >
> > This will apply the WRITE_ONCE errata to handle the non-standard
> > behavior via appending a fence w.o instruction for WRITE_ONCE().
> >
> > This problem is only observed on the sg2042 hardware platform by
> > running the lock_torture test program for half an hour. The problem
> > was not found in the user space application, because interrupt can
> > break the livelock.
>
> The first paragraph states the problem was found on both the SG2042 and
> TH1520, but this paragraph states it is only observed on the SG2042. Is
> worth me trying to run lock_torture on the TH1520 for many hours?
We didn't observe that problem on the 1520 due to its small number of cores.
But, we still recommend the th1520 involve this patch for potential write delay.

>
> Thanks,
> Drew



-- 
Best Regards
 Guo Ren