On 7/15/25 7:49 AM, Alexei Starovoitov wrote:
Also you misread the kcsan report. It says that 'read' comes from: read to 0xffff888118f3d568 of 4 bytes by task 4719 on cpu 1: lookup_nulls_elem_raw kernel/bpf/hashtab.c:643 [inline] which is reading hash and key of htab_elem while write side actually writes hash too: *(u32 *)((void *)node + lru->hash_offset) = hash; Martin, is it really possible for these read/write to race ?
I think it is possible. The elem in the lru's freelist currently does not wait for a rcu gp before reuse. There is a chance that the rcu reader is still reading the hash value that was put in the freelist, while the writer is reusing and updating it.
I think the percpu_freelist used in the regular hashmap should have similar behavior, so may be worth finding a common solution, such as waiting for a rcu gp before reusing it.
