Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Medium] tqueue monitor causes false positive invalid state transitions for tasks scheduling during do_exit(). --
commit 22065a19b365cd05306cad5f1def6f25a73bdc87 Author: Gabriele Monaco <[email protected]> tools/rv: Add BPF monitors This commit adds the code for 2 initial BPF monitors, both DA (the only currently supported type): queue and nohz. It also integrates BPF monitor building into the main rv Makefile. > diff --git a/tools/verification/rv/bpf_monitors/tqueue.c > b/tools/verification/rv/bpf_monitors/tqueue.c > new file mode 100644 > index 0000000000000..c7516da01b65c > --- /dev/null > +++ b/tools/verification/rv/bpf_monitors/tqueue.c > @@ -0,0 +1,35 @@ [ ... ] > +SEC("tp_btf/sched_dequeue_tp") > +int BPF_PROG(handle_sched_dequeue, struct task_struct *tsk, int cpu) > +{ > + if (!(tsk->flags & PF_EXITING)) > + da_handle_start_event(tsk, sched_dequeue_tqueue); [Severity: Medium] Does skipping the dequeue event for exiting tasks here cause false positive state transitions when the task is later enqueued? If a task calls do_exit() (which sets PF_EXITING) and is preempted or sleeps before reaching trace_sched_process_exit(), this logic skips the sched_dequeue event. The state machine then incorrectly remains in the "enqueued" state. > + return 0; > +} > + > +SEC("tp_btf/sched_enqueue_tp") > +int BPF_PROG(handle_sched_enqueue, struct task_struct *tsk, int cpu) > +{ > + da_handle_event(tsk, sched_enqueue_tqueue); [Severity: Medium] When the exiting task is rescheduled, handle_sched_enqueue() unconditionally processes the sched_enqueue event. Since the corresponding dequeue event was skipped above, won't this un-paired enqueue cause the monitor to transition to an invalid state, breaking the intended functionality and flooding the trace logs with false positive violations? > + return 0; > +} -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=16
