On 28/5/25 06:31, Andrii Nakryiko wrote:
> On Mon, May 26, 2025 at 9:22 AM Leon Hwang <leon.hwang@xxxxxxxxx> 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
