Re: [PATCH bpf-next v3 1/4] bpf: Introduce global percpu data

[Leon Hwang <leon.hwang@linux.dev>]

On 28/5/25 06:31, Andrii Nakryiko wrote:
> On Mon, May 26, 2025 at 9:22 AM Leon Hwang <leon.hwang@linux.dev> wrote:
>>
>> This patch introduces global percpu data, inspired by commit
>> 6316f78306c1 ("Merge branch 'support-global-data'"). It enables the
>> definition of global percpu variables in BPF, similar to the
>> DEFINE_PER_CPU() macro in the kernel[0].
>>

[...]

>> +
>>         err = check_map_access(env, regno, reg->off,
>>                                map->value_size - reg->off, false,
>>                                ACCESS_HELPER);
>> @@ -11101,6 +11109,11 @@ static int check_bpf_snprintf_call(struct bpf_verifier_env *env,
>>                 return -EINVAL;
>>         num_args = data_len_reg->var_off.value / 8;
>>
>> +       if (fmt_map->map_type != BPF_MAP_TYPE_ARRAY) {
>> +               verbose(env, "only array map supports snprintf\n");
>> +               return -EINVAL;
>> +       }
>> +
>>         /* fmt being ARG_PTR_TO_CONST_STR guarantees that var_off is const
>>          * and map_direct_value_addr is set.
>>          */
>> @@ -21906,6 +21919,38 @@ static int do_misc_fixups(struct bpf_verifier_env *env)
>>                         goto next_insn;
>>                 }
>>
>> +#ifdef CONFIG_SMP
> 
> Instead of CONFIG_SMP, I think it's more appropriate to check for
> bpf_jit_supports_percpu_insn(). We check CONFIG_SMP for
> BPF_FUNC_get_smp_processor_id inlining because of `cpu_number` per-CPU
> variable, not because BPF_MOV64_PERCPU_REG() doesn't work on single
> CPU systems (IIUC).
> 
Agreed.

Then, 'EMIT_mov(dst_reg, src_reg);' can be avoided if dst_reg is same as
src_reg while handling BPF_MOV64_PERCPU_REG() on x86_64.

Thanks,
Leon