[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFULd4aVc_GXy2BmnJLb3p7OdAtsLrqOE9vhZrOx7oaWU4Tg-w@mail.gmail.com>
Date: Thu, 19 Oct 2023 11:23:43 +0200
From: Uros Bizjak <ubizjak@...il.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Nadav Amit <namit@...are.com>,
"the arch/x86 maintainers" <x86@...nel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Andy Lutomirski <luto@...nel.org>,
Brian Gerst <brgerst@...il.com>,
Denys Vlasenko <dvlasenk@...hat.com>,
"H . Peter Anvin" <hpa@...or.com>,
Thomas Gleixner <tglx@...utronix.de>,
Josh Poimboeuf <jpoimboe@...hat.com>,
Nick Desaulniers <ndesaulniers@...gle.com>
Subject: Re: [PATCH v2 -tip] x86/percpu: Use C for arch_raw_cpu_ptr()
On Thu, Oct 19, 2023 at 11:09 AM Peter Zijlstra <peterz@...radead.org> wrote:
>
> On Wed, Oct 18, 2023 at 03:40:05PM -0700, Linus Torvalds wrote:
> > On Wed, 18 Oct 2023 at 14:40, Uros Bizjak <ubizjak@...il.com> wrote:
> > >
> > > The ones in "raw" form are not IRQ safe and these are implemented
> > > without volatile qualifier.
> >
> > You are misreading it.
> >
> > Both *are* irq safe - on x86.
>
> Stronger, x86 arch code very much relies on them being NMI-safe. Which
> makes the generic implementation insufficient.
>
> They *must* be single RmW instructions on x86.
Maybe I should rephrase my quoted claim above:
"raw" versions are not needed to be IRQ safe [*].
[*] Memory arguments need to be stable, so IRQ and NMI handlers can
not change them outside of the critical section where the "raw"
version operates. When memory arguments are stable, the compiler can
omit reads (cache) the arguments, or re-reads them (rematerialize)
from memory. The atomicity of the operation is irrelevant in the "raw"
context, so the implementation of raw_percpu_xchg_op using
raw_cpu_read/write is OK in this context.
Uros.
Powered by blists - more mailing lists