Re: [PATCH v4 3/3] riscv: store percpu offset into thread_info

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Secondary CPUs run with the boot CPU's `pcpu_offset` during early boot, leading to concurrent lockless access to per-CPU data.
--

commit 9630a483e2d689234bf576230edd1da2035ea88b
Author: Yunhui Cui <cuiyunhui@bytedance.com>

riscv: store percpu offset into thread_info

This commit moves the percpu offset calculation to be directly stored in
and retrieved from the thread_info structure. This speeds up percpu variable
reads and writes by reducing the number of access instructions.

Link: https://lists.riscv.org/g/tech-privileged/topic/risc_v_tech_arch_review/113437553?page=2

> diff --git a/arch/riscv/kernel/smpboot.c b/arch/riscv/kernel/smpboot.c
> index d85916a3660c3..9e95c068b966b 100644
> --- a/arch/riscv/kernel/smpboot.c
> +++ b/arch/riscv/kernel/smpboot.c

[ ... ]

> @@ -234,6 +239,8 @@ asmlinkage __visible void smp_callin(void)
>  	mmgrab(mm);
>  	current->active_mm = mm;
>  
> +	__my_cpu_offset = per_cpu_offset(smp_processor_id());
> +

Could this lead to concurrent lockless access to the boot CPU's per-CPU
data during early boot of secondary CPUs?

When the idle task for a secondary CPU is created via fork_idle(), it
copies the parent's task_struct and thread_info. As a result, the new
idle task inherits the parent's (the boot CPU's) pcpu_offset.

When the secondary CPU boots, it sets the tp register to this idle task
and begins executing C code without going through switch_to(). This
means any per-CPU access prior to the reassignment here in smp_callin()
will incorrectly access the boot CPU's per-CPU area.

Before this patch, __my_cpu_offset resolved dynamically using
thread_info->cpu, which was already correctly initialized on the boot
CPU via __set_task_cpu(), ensuring safe early access.

Now, for example, ftrace/kprobe hooks on function prologues, lockdep
checks, or mmgrab() itself could trigger a per-CPU access before this
assignment, leading to data races and potential memory corruption.

Would it be safer to initialize task_thread_info(tidle)->pcpu_offset =
per_cpu_offset(cpu) from the boot CPU in __cpu_up() prior to starting
the secondary CPU?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260505062026.91724-1-cuiyunhui@bytedance.com?part=3