linux-kernel - Re: [PATCH v2 -tip] x86/percpu: Use C for arch_raw_cpu

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]

Date:   Thu, 19 Oct 2023 14:04:47 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Uros Bizjak <ubizjak@...il.com>
Cc:     peterz@...radead.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, 19 Oct 2023 at 11:16, Uros Bizjak <ubizjak@...il.com> wrote:
>
> I wonder what are "certain circumstances" that the
> documentation is referring to.

Looking more at that "under certain circumstances" statement, I
actually think it refers even to the situation *with* "asm volatile".

In particular, when doing loop unrolling, gcc will obviously duplicate
the asm (both with and without volatile). That would obviously lead to
exactly the kinds of problems that snippet of documentation then talks
about:

  "This can lead to unexpected duplicate symbol errors during
compilation if your asm code defines symbols or labels"

so that makes complete sense. It also matches up with the fact that
this is all actually documented very much under the "volatile" label -
ie this is a generic thing that happens even *with* volatile in place,
and we should not expect that "one asm statement" will generate
exactly one copy of the resulting assembler.

It also matches up with the whole earlier preceding about "Note that
the compiler can move even volatile asm instructions relative to other
code, including across jump instructions". So I think what happened is
exactly that somebody was declaring a variable or local label inside
the asm, and then the docs were clarified to state that the asm can be
duplicated in the output.

Of course, this is all just by me reading the docs and looking at gcc
output for way too many years. It's not based on any knowledge of the
original issue.

             Linus