On Tue, Jun 23, 2026 at 9:16 PM Leon Hwang <[email protected]> wrote: > > 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. >
both is even better, but negative test is testing a condition that is hard to miss because you won't try to do that in practice ) > Thanks, > Leon > > > > >> [...]
