[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wiqpJfBicroWizUsc4k2Zyg+yHMgfbCSvU_gkT45KK0Cg@mail.gmail.com>
Date: Thu, 12 Oct 2023 09:56:27 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Uros Bizjak <ubizjak@...il.com>
Cc: 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>,
Peter Zijlstra <peterz@...radead.org>,
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, 12 Oct 2023 at 09:33, Uros Bizjak <ubizjak@...il.com> wrote:
>
> For some reason existing percpu_stable_op asm uses %P operand
> modifier. This will drop all syntax-specific prefixes and issue the
> bare constant. It will also remove the (%rip) suffix. What we want
> here is a generic %a modifier (See 6.47.2.8 Generic Operand Modifiers
> [1]) that will substitute a memory reference, with the actual operand
> treated as the address. In combination with "p" constraint will DTRT
> and will emit symbol with the (%rip) suffix when available, also when
> -fpie is in effect.
Well, I have to admit that I think the main reason we used "p" as a
constraint was simply that we knew about it, and I don't think I've
ever even realized "a" existed.
In fact, we historically didn't use a lot of operand modifiers, and
the only common ones (at least for x86) tend to be the "register size"
modifiers (b/w/q)
I just did
git grep 'asm.*[^%]%[a-z][0-9]' arch/x86
and while that will only catch one-liner inline asm cases, all it
finds is indeed just the size ones.
A slightly smarter grep finds a couple of uses of '%c' for bare constants.
So I think the "we used P for percpu_stable_op" is really mostly a "we
are not actually very familiar with the operand modifiers". We use
the constraints fairly wildly, but the operand modifiers are a
relative rarity.
I suspect - but it's much too long ago - that some gcc person just
told us that "solve this using 'P'" and we never went any further.
So changing it to use 'a' sounds like the right thing to do, and we
can only plead ignorance, not wilful stupidity.
Linus
Powered by blists - more mailing lists