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]

Message-ID: <F48A9D34-3627-4372-B555-B58CBFC3F241@vmware.com>
Date:   Wed, 11 Oct 2023 07:41:57 +0000
From:   Nadav Amit <namit@...are.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
CC:     Uros Bizjak <ubizjak@...il.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>
Subject: Re: [PATCH v2 -tip] x86/percpu: Use C for arch_raw_cpu_ptr()



> On Oct 10, 2023, at 9:37 PM, Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> 
> !! External Email
> 
> On Tue, 10 Oct 2023 at 11:22, Uros Bizjak <ubizjak@...il.com> wrote:
>> 
>> Please note that besides propagation of the addition into address, the
>> patch also exposes memory load to the compiler, with the anticipation
>> that the compiler CSEs the load from this_cpu_off from eventual
>> multiple addresses. For this to work, we have to get rid of the asms.
> 
> I actually checked that the inline asm gets combined, the same way the
> this_cpu_read_stable cases do (which we use for 'current’)

You are correct. Having said that, for “current" we may be able to do something
better, as regardless to preemption “current" remains the same, and
this_cpu_read_stable() does miss some opportunities to avoid reloading the
value from memory. I proposed a solution before, but I am not sure it would
work properly with LTO. I guess Uros would know better.