aboutsummaryrefslogtreecommitdiffstats
path: root/tools/lib/bpf/libbpf.c
diff options
context:
space:
mode:
authorAlexei Starovoitov <[email protected]>2025-04-10 03:12:54 +0000
committerAlexei Starovoitov <[email protected]>2025-04-10 03:12:54 +0000
commita27a97f713947b20ba91b23a3ef77fa92d74171b (patch)
treee9e00761dd4013c0d79131ba93ab6993c30d6260 /tools/lib/bpf/libbpf.c
parentbpf: Clarify the meaning of BPF_F_PSEUDO_HDR (diff)
parentselftests/bpf: Add test case for atomic update of fd htab (diff)
downloadkernel-a27a97f713947b20ba91b23a3ef77fa92d74171b.tar.gz
kernel-a27a97f713947b20ba91b23a3ef77fa92d74171b.zip
Merge branch 'bpf-support-atomic-update-for-htab-of-maps'
Hou Tao says: ==================== bpf: Support atomic update for htab of maps From: Hou Tao <[email protected]> Hi, The motivation for the patch set comes from the question raised by Cody Haas [1]. When trying to concurrently lookup and update an existing element in a htab of maps, the lookup procedure may return -ENOENT unexpectedly. The first revision of the patch set tried to resolve the problem by making the insertion of the new element and the deletion of the old element being atomic from the perspective of the lookup process. While the solution would benefit all hash maps, it does not fully resolved the problem due to the immediate reuse issue. Therefore, in v2 of the patch set, it only fixes the problem for fd htab. Please see individual patches for details. Comments are always welcome. v3: * rebase on bpf_next/for-next * add Acked-by tags v2: https://lore.kernel.org/bpf/[email protected]/ * only support atomic update for fd htab v1: https://lore.kernel.org/bpf/[email protected] [1]: https://lore.kernel.org/xdp-newbies/CAH7f-ULFTwKdoH_t2SFc5rWCVYLEg-14d1fBYWH2eekudsnTRg@mail.gmail.com/ ==================== Link: https://patch.msgid.link/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]>
Diffstat (limited to 'tools/lib/bpf/libbpf.c')
0 files changed, 0 insertions, 0 deletions