| Message ID | 20230417154737.12740-4-laoar.shao@gmail.com (mailing list archive) |
|---|---|
| State | Handled Elsewhere |
| Headers | show |
| Series | bpf: Tracing recursion prevention mechanism improvement | expand |
diff --git a/include/linux/trace_recursion.h b/include/linux/trace_recursion.h index 80de2ee..445a055 100644 --- a/include/linux/trace_recursion.h +++ b/include/linux/trace_recursion.h @@ -168,6 +168,8 @@ static __always_inline int trace_test_and_set_recursion(unsigned long ip, unsign * will think a recursion occurred, and the event will be dropped. * Let a single instance happen via the TRANSITION_BIT to * not drop those events. + * After this rule is applied, one single recursion is allowed in + * the process context. */ bit = TRACE_CTX_TRANSITION + start; if (val & (1 << bit)) {
After TRACE_CTX_TRANSITION is applied, it will allow one single recursion in the process context. Below is an example, SEC("fentry/htab_map_delete_elem") int BPF_PROG(on_delete, struct bpf_map *map) { pass2++; bpf_map_delete_elem(&hash2, &key); return 0; } In the above test case, the recursion will be detected at the second bpf_map_delete_elem() call in this prog. Illustrated as follows, SEC("fentry/htab_map_delete_elem") pass2++; <<<< Turn out to be 1 after this operation. bpf_map_delete_elem(&hash2, &key); SEC("fentry/htab_map_delete_elem") <<<< no recursion pass2++; <<<< Turn out to be 2 after this operation. bpf_map_delete_elem(&hash2, &key); SEC("fentry/htab_map_delete_elem") <<<< RECURSION We'd better explain this behavior explicitly. Signed-off-by: Yafang Shao <laoar.shao@gmail.com> Cc: Steven Rostedt <rostedt@goodmis.org> --- include/linux/trace_recursion.h | 2 ++ 1 file changed, 2 insertions(+)