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: <A2E458DE-8B84-4FB2-BF6D-3EAB2B355078@vmware.com>
Date:   Wed, 18 Oct 2023 10:54:13 +0000
From:   Nadav Amit <namit@...are.com>
To:     Uros Bizjak <ubizjak@...il.com>
CC:     Linus Torvalds <torvalds@...ux-foundation.org>,
        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 Oct 18, 2023, at 12:04 PM, Uros Bizjak <ubizjak@...il.com> wrote:
> 
> Solved.
> 
> All that is needed is to patch cpu_init() from
> arch/x86/kernel/cpu/common.c with:
> 
> --cut here--
> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> index b14fc8c1c953..61b6fcdf6937 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -2228,7 +2232,7 @@ void cpu_init_exception_handling(void)
> */
> void cpu_init(void)
> {
> -       struct task_struct *cur = current;
> +       struct task_struct *cur = this_cpu_read_stable(pcpu_hot.current_task);
>       int cpu = raw_smp_processor_id();

Thanks for solving that, and sorry that I missed it.

The reason I didn’t encounter it before is that in my original patch I created
a new compilation unit which only defined the alias.

Since there might be additional problems (any “current” use in common.c is
dangerous, even in included files), I think that while there may be additional
solutions, defining the alias in a separate compilation unit - as I did before -
is the safest.