summaryrefslogtreecommitdiff
path: root/lib/sg_split.c
diff options
context:
space:
mode:
authorYonghong Song <yonghong.song@linux.dev>2024-03-22 09:13:53 +0300
committerDaniel Borkmann <daniel@iogearbox.net>2024-03-25 19:25:54 +0300
commit14bb1e8c8d4ad5d9d2febb7d19c70a3cf536e1e5 (patch)
tree5beab7217bc5c3bfadba05c5aff751e20450502f /lib/sg_split.c
parent770546ae9f4c1ae1ebcaf0874f0dd9631d77ec97 (diff)
downloadlinux-14bb1e8c8d4ad5d9d2febb7d19c70a3cf536e1e5.tar.xz
selftests/bpf: Fix flaky test btf_map_in_map/lookup_update
Recently, I frequently hit the following test failure: [root@arch-fb-vm1 bpf]# ./test_progs -n 33/1 test_lookup_update:PASS:skel_open 0 nsec [...] test_lookup_update:PASS:sync_rcu 0 nsec test_lookup_update:FAIL:map1_leak inner_map1 leaked! #33/1 btf_map_in_map/lookup_update:FAIL #33 btf_map_in_map:FAIL In the test, after map is closed and then after two rcu grace periods, it is assumed that map_id is not available to user space. But the above assumption cannot be guaranteed. After zero or one or two rcu grace periods in different siturations, the actual freeing-map-work is put into a workqueue. Later on, when the work is dequeued, the map will be actually freed. See bpf_map_put() in kernel/bpf/syscall.c. By using workqueue, there is no ganrantee that map will be actually freed after a couple of rcu grace periods. This patch removed such map leak detection and then the test can pass consistently. Signed-off-by: Yonghong Song <yonghong.song@linux.dev> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20240322061353.632136-1-yonghong.song@linux.dev
Diffstat (limited to 'lib/sg_split.c')
0 files changed, 0 insertions, 0 deletions