aboutsummaryrefslogtreecommitdiffstats
path: root/scripts/bpf_doc.py
diff options
context:
space:
mode:
authorDelyan Kratunov <[email protected]>2022-10-21 19:36:38 +0000
committerAlexei Starovoitov <[email protected]>2022-10-21 20:58:09 +0000
commiteb814cf1adea0ce24413c26c22e9f1a556a45d34 (patch)
tree57f74ecffec4ad4400e21b78f6afe43007d9d3a9 /scripts/bpf_doc.py
parentMerge branch 'bpftool: Add autoattach for bpf prog load|loadall' (diff)
downloadkernel-eb814cf1adea0ce24413c26c22e9f1a556a45d34.tar.gz
kernel-eb814cf1adea0ce24413c26c22e9f1a556a45d34.zip
selftests/bpf: fix task_local_storage/exit_creds rcu usage
BPF CI has revealed flakiness in the task_local_storage/exit_creds test. The failure point in CI [1] is that null_ptr_count is equal to 0, which indicates that the program hasn't run yet. This points to the kern_sync_rcu (sys_membarrier -> synchronize_rcu underneath) not waiting sufficiently. Indeed, synchronize_rcu only waits for read-side sections that started before the call. If the program execution starts *during* the synchronize_rcu invocation (due to, say, preemption), the test won't wait long enough. As a speculative fix, make the synchornize_rcu calls in a loop until an explicit run counter has gone up. [1]: https://github.com/kernel-patches/bpf/actions/runs/3268263235/jobs/5374940791 Signed-off-by: Delyan Kratunov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]>
Diffstat (limited to 'scripts/bpf_doc.py')
0 files changed, 0 insertions, 0 deletions