[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABCJKufYj6E8WagP5GyB3M_=WfA4H0d=MMxX6+DQg0F8qjNTcQ@mail.gmail.com>
Date: Mon, 24 Jul 2023 10:03:14 -0700
From: Sami Tolvanen <samitolvanen@...gle.com>
To: Guo Ren <guoren@...nel.org>
Cc: Deepak Gupta <debug@...osinc.com>, palmer@...belt.com,
linux-kernel@...r.kernel.org, linux-riscv@...ts.infradead.org,
Jisheng Zhang <jszhang@...nel.org>
Subject: Re: [PATCH v2] riscv: VMAP_STACK overflow detection thread-safe
On Thu, Jul 20, 2023 at 8:10 AM Guo Ren <guoren@...nel.org> wrote:
>
> On Thu, Nov 24, 2022 at 5:48 PM Deepak Gupta <debug@...osinc.com> wrote:
> > +.macro asm_per_cpu dst sym tmp
> > + REG_L \tmp, TASK_TI_CPU_NUM(tp)
> > + slli \tmp, \tmp, PER_CPU_OFFSET_SHIFT
> > + la \dst, __per_cpu_offset
> > + add \dst, \dst, \tmp
> > + REG_L \tmp, 0(\dst)
> > + la \dst, \sym
> > + add \dst, \dst, \tmp
> > +.endm
> It's a tricky implementation, and we can't maintain it here because it
> depends on percpu design.
I can certainly understand this concern, but AFAICT this part of the
percpu code hasn't changed in ~14 years, so adding an assembly macro
for the computation shouldn't be a huge maintenance burden. arm64 also
performs a similar computation in assembly (starting with commit
3d8c1a013d78) and I don't see their implementation needing constant
maintenance since then.
Sami
Powered by blists - more mailing lists