On 24/6/26 06:46, Andrii Nakryiko wrote:
> On Mon, Jun 22, 2026 at 7:38 AM Leon Hwang <[email protected]> wrote:
>>
>> Since percpu_array supports direct-read, it should not break accessing
> 
> what does "it" refer to here?
> 
>> rdonly percpu_array.
>>
>> Add a test to verify that adding '.map_direct_value_addr' to percpu_array
>> won't break the case.
> 
> what case?
> 
> I think you are testing (read-only) direct access to read-only per-CPU
> array, is that right? Just write that out? Though, really, negative

Right, will update the commit msg.

It was to test the change of patch #4:

@@ -6113,6 +6115,7 @@ static int check_mem_access(struct
bpf_verifier_env *env, int insn_idx, struct b
                        if (tnum_is_const(reg->var_off) &&
                            bpf_map_is_rdonly(map) &&
                            map->ops->map_direct_value_addr &&
+                           map->map_type != BPF_MAP_TYPE_PERCPU_ARRAY &&
                            map->map_type != BPF_MAP_TYPE_INSN_ARRAY) {
                                int map_off = off + reg->var_off.value;
                                u64 val = 0;

> test (we *cannot* access read-only per-cpu map for write operation)
> would be more trustworthy for this...
>

Makes sense.

I think it is worth testing both positive and negative cases:

1. (read-only) direct access the data of read-only percpu data's
   percpu_array map to test the above change.
2. direct writing the data of read-only percpu data's percpu_array map
   is disallowed.

Thanks,
Leon

> 
>> [...]

Reply via email to