diff options
author | Yonghong Song <yonghong.song@linux.dev> | 2024-03-22 09:13:53 +0300 |
---|---|---|
committer | Daniel Borkmann <daniel@iogearbox.net> | 2024-03-25 19:25:54 +0300 |
commit | 14bb1e8c8d4ad5d9d2febb7d19c70a3cf536e1e5 (patch) | |
tree | 5beab7217bc5c3bfadba05c5aff751e20450502f /drivers/gpu/drm/amd/amdgpu | |
parent | 770546ae9f4c1ae1ebcaf0874f0dd9631d77ec97 (diff) | |
download | linux-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 'drivers/gpu/drm/amd/amdgpu')
0 files changed, 0 insertions, 0 deletions