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: <CAHk-=whzhXdRz1UNaQWTSY2ue8biGqfS18VXcEQasQNCyg_AwQ@mail.gmail.com>
Date:   Thu, 12 Oct 2023 10:47:10 -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 10:10, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> The fix seems to be a simple one-liner, ie just
>
> -       asm(__pcpu_op2_##size(op, __percpu_arg(P[var]), "%[val]")       \
> +       asm(__pcpu_op2_##size(op, __percpu_arg(a[var]), "%[val]")       \

Nope. That doesn't work at all.

It turns out that we're not the only ones that didn't know about the
'a' modifier.

clang has also never heard of it in this context, and the above
one-liner results in an endless sea of errors, with

     error: invalid operand in inline asm: 'movq %gs:${1:a}, $0'

Looking around, I think it's X86AsmPrinter::PrintAsmOperand() that is
supposed to handle these things, and while it does have some handling
for 'a', the comment around it says

    case 'a': // This is an address.  Currently only 'i' and 'r' are expected.

and I think our use ends up just confusing the heck out of clang. Of
course, clang also does this:

    case 'P': // This is the operand of a call, treat specially.
        PrintPCRelImm(MI, OpNo, O);
        return false;

so clang *already* generates those 'current' accesses as PCrelative, and I see

        movq    %gs:pcpu_hot(%rip), %r13

in the generated code.

End result: clang actually generates what we want just using 'P', and
the whole "P vs a" is only a gcc thing.

Why *does* gcc do that silly thing of dropping '(%rip)' from the address, btw?

                 Linus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ