Re: [PATCH v2 14/15] tools/rv: Add selftest for rv bpf monitors

[bot+bpf-ci]

> tools/rv: Add selftest for rv bpf monitors

TL;DR: Selftest issue: the two back-to-back tqueue runs in rv_mon.t may fail
with "already enabled" because the previous run's BPF maps aren't freed yet; a
sleep like the nohz tests use may be needed.

> diff --git a/tools/verification/rv/tests/rv_mon.t b/tools/verification/rv/tests/rv_mon.t
> --- a/tools/verification/rv/tests/rv_mon.t
> +++ b/tools/verification/rv/tests/rv_mon.t

[ ... ]

> @@ -92,4 +134,21 @@ check_if_exists "run per-cpu monitor tracing also self" \
>  	"$RV mon sco -t -s" "$RVDIR/monitors/sched/sco" \
>  	"$trace_cpu_self" "" "\($header\|$trace_cpu\)"
>
> +check_if_exists "run per-task BPF monitor with tracing" \
> +	"$RV mon tqueue -t" "$RVTOOL/bpf_monitors/tqueue.o" \
> +	"$header" "$trace_task_self" "\($header\|$trace_task\)"
> +
> +check_if_exists "run per-task BPF monitor tracing also self" \
> +	"$RV mon tqueue -t -s" "$RVTOOL/bpf_monitors/tqueue.o" \
> +	"$trace_task_self" "" "\($header\|$trace_task\)"
> +

Can this second tqueue run fail with "monitor tqueue (BPF) is already
enabled"?

Earlier in this patch the two consecutive nohz runs are separated by a
delay, because the previous run's maps are not necessarily cleaned up yet:

> +# Give some time for maps from previous run to be cleaned up
> +[ -n "$TEST_COUNT" ] && sleep 1

The two tqueue runs here are also back to back, with no delay between
"$RV mon tqueue -t" and "$RV mon tqueue -t -s".

bpf_read_enable() decides a monitor is already enabled by walking the map
IDs looking for an rv_mon_tqueue map.  After the first rv exits, that map
stays visible until the deferred frees finish:

  bpf_link_free()
    bpf_link_is_tracepoint()
      call_tracepoint_unregister_atomic()    <- SRCU grace period
    bpf_prog_put()
      bpf_prog_put_deferred()
        __bpf_prog_put_noref(prog, true)
          call_rcu()
            bpf_prog_free()
              schedule_work(bpf_prog_free_deferred)
                bpf_free_used_maps()
                  bpf_map_put()
                    bpf_map_free_id()

Until bpf_map_free_id() runs, bpf_map_get_fd_by_id() still succeeds.  If
the second rv reaches bpf_read_enable() in that window, it prints "bpf:
monitor tqueue (BPF) is already enabled" and exits with 1, while
check_if_exists expects 0.

tqueue is a tp_btf monitor, so this chain includes a tracepoint SRCU grace
period on top of what the fentry based nohz case has to wait for.  Would a
similar sleep between these two tqueue runs be needed?


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/36944413541