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
>
>> [...]