linux-kernel - Re: [External] [PATCH] RISC-V: store percpu offset in CSR

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: <DB6MLPA3BJ75.2U5FP5JSJD2LO@ventanamicro.com>
Date: Tue, 08 Jul 2025 13:10:17 +0200
From: Radim Krčmář <rkrcmar@...tanamicro.com>
To: "yunhui cui" <cuiyunhui@...edance.com>
Cc: <masahiroy@...nel.org>, <nathan@...nel.org>, <nicolas.schier@...ux.dev>,
 <dennis@...nel.org>, <tj@...nel.org>, <cl@...two.org>,
 <paul.walmsley@...ive.com>, <palmer@...belt.com>, <aou@...s.berkeley.edu>,
 <alex@...ti.fr>, <andybnac@...il.com>, <bjorn@...osinc.com>,
 <cyrilbur@...storrent.com>, <rostedt@...dmis.org>, <puranjay@...nel.org>,
 <ben.dooks@...ethink.co.uk>, <zhangchunyan@...as.ac.cn>,
 <ruanjinjie@...wei.com>, <jszhang@...nel.org>, <charlie@...osinc.com>,
 <cleger@...osinc.com>, <antonb@...storrent.com>, <ajones@...tanamicro.com>,
 <debug@...osinc.com>, <haibo1.xu@...el.com>, <samuel.holland@...ive.com>,
 <linux-kbuild@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
 <linux-mm@...ck.org>, <linux-riscv@...ts.infradead.org>, "linux-riscv"
 <linux-riscv-bounces@...ts.infradead.org>, <wangziang.ok@...edance.com>
Subject: Re: [External] [PATCH] RISC-V: store percpu offset in CSR_SCRATCH

2025-07-08T18:07:27+08:00, yunhui cui <cuiyunhui@...edance.com>:
> This patch cleverly differentiates whether an exception originates
> from user mode or kernel mode. However, there's still an issue with
> using CSR_SCRATCH: each time handle_exception() is called, the
> following instructions must be executed:
>
> REG_L s0, TASK_TI_CPU(tp)
> slli s0, s0, 3
> la s1, __per_cpu_offset
> add s1, s1, s0
> REG_L s1, 0(s1)
> csrw CSR_SCRATCH, s1

We can minimize the cost at exception entry by storing the precomputed
offset in thread_info, which bloats the struct, and also incurs update
cost on cpu migration, but should still be a net performance gain.

The minimal code at exception entry would be:

  REG_L s0, TASK_TI_PERCPU_OFFSET(tp)
  csrw CSR_SCRATCH, s0

> Should we consider adding a dedicated CSR (e.g., CSR_SCRATCH2) to
> store the percpu offset instead?
> See: https://lists.riscv.org/g/tech-privileged/topic/113437553#msg2506

It would be nice to gather more data on the CSR_SCRATCH approach.
Basically, the overhead of "REG_L s0, TASK_TI_PERCPU_OFFSET(tp)".
(Or the longer sequence if we think it is worth it.)

Can you benchmark the patch after reverting percpu.h, so we include the
overhead of switching CSR_SCRATCH, but without any benefits provided by
the per-cpu offset?
The baseline would be the patch with reverted percpu.h, and reverted the
sequence that sets the CSR_SCRATCH in handle_exception, so we roughly
estimate the benefit of adding CSR_SCRATCH2.

The CSR_SCRATCH2 does add overhead to hardware, and to domain context
switches, and we also have to do something else for a few years anyway,
because it's not even ratified...  It's possible we might not benefit
enough from CSR_SCRATCH2 to make a good case for it.

Thanks.