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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAEEQ3w=KrysBJrkYA6mUKCjC=fz23R7u81a2p8EipaN9oVHs_Q@mail.gmail.com>
Date: Thu, 21 Aug 2025 16:01:11 +0800
From: yunhui cui <cuiyunhui@...edance.com>
To: "Christoph Lameter (Ampere)" <cl@...two.org>
Cc: yury.norov@...il.com, linux@...musvillemoes.dk, paul.walmsley@...ive.com, 
	palmer@...belt.com, aou@...s.berkeley.edu, alex@...ti.fr, 
	linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org, 
	dennis@...nel.org, tj@...nel.org, linux-mm@...ck.org
Subject: Re: [External] Re: [PATCH 2/2] riscv: introduce percpu.h into include/asm

Hi Christoph,

On Thu, Aug 21, 2025 at 7:39 AM Christoph Lameter (Ampere)
<cl@...two.org> wrote:
>
> On Tue, 19 Aug 2025, Yunhui Cui wrote:
>
> > +#define __PERCPU_AMO_OP_CASE(sfx, name, sz, amo_insn)                        \
> > +static inline void                                                   \
> > +__percpu_##name##_amo_case_##sz(void *ptr, unsigned long val)                \
> > +{                                                                    \
> > +     asm volatile (                                                  \
> > +             "amo" #amo_insn #sfx " zero, %[val], %[ptr]"            \
> > +             : [ptr] "+A" (*(u##sz *)ptr)                            \
> > +             : [val] "r" ((u##sz)(val))                              \
> > +             : "memory");                                            \
> > +}
>
> AMO creates a single instruction that performs the operation?
>
> > +#define _pcp_protect(op, pcp, ...)                                   \
> > +({                                                                   \
> > +     preempt_disable_notrace();                                      \
> > +     op(raw_cpu_ptr(&(pcp)), __VA_ARGS__);                           \
> > +     preempt_enable_notrace();                                       \
> > +})
>
> Is "op" a single instruction? If so then preempt disable / endable would
> not be needed if there is no other instruction created.
>
> But raw_cpu_ptr performs a SHIFT_PERCPU_PTR which performs an addition.
> So you need the disabling of preemption to protect the add.
>
> Is there a way on RISC V to embedd the pointer arithmetic in the "AMO"
> instruction? Or can you use relative addressing to a register that
> contains the cpu offset. I believe RISC V has a thread pointer?
>
> If you can do this then a lot of preempt_enable/disable points can be
> removed from the core kernel and the instruction may be as scalable as x86
> which can do the per cpu operations with a single instruction.

Yes, thank you. While it’s certainly good to remove preemption
disabling, currently RISC-V’s amoadd.w/d instructions can take the
address of a variable rather than a register.

I previously submitted an attempt to use gp to store the percpu
offset, and we are also trying to push for an extension that uses a
register to store the percpu offset.
https://lore.kernel.org/all/CAEEQ3w=PsM5T+yMrEGdWZ2nm7m7SX3vzscLtWpOPVu1zpfm3YQ@mail.gmail.com/
https://lists.riscv.org/g/tech-privileged/topic/risc_v_tech_arch_review/113437553?page=2

>
> > +
> > +#define _pcp_protect_return(op, pcp, args...)                                \
> > +({                                                                   \
> > +     typeof(pcp) __retval;                                           \
> > +     preempt_disable_notrace();                                      \
> > +     __retval = (typeof(pcp))op(raw_cpu_ptr(&(pcp)), ##args);        \
> > +     preempt_enable_notrace();                                       \
> > +     __retval;                                                       \
> > +})
>
> Same here.
>
>

Thanks,
Yunhui

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ