Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Medium] rcu: scoped_guard(rcu) drops lock prematurely, leaking RCU-protected pointer --
commit 578060191fd58b6c308a14708ec520459063ef75 Author: Wen Yang <[email protected]> rv: Add a KUnit test for the HA timer underflow This commit adds a minimal per-object HA monitor called rvtest. It also introduces a test to verify that the HA clock math does not underflow when checking invariants and starting timers. > diff --git a/kernel/trace/rv/rv_monitors_test.c > b/kernel/trace/rv/rv_monitors_test.c > index 3ad11195e664a..889a209f64358 100644 > --- a/kernel/trace/rv/rv_monitors_test.c > +++ b/kernel/trace/rv/rv_monitors_test.c [ ... ] > +static void rv_test_rvtest_underflow(struct kunit *test) > +{ > + struct ha_monitor *ha_mon; > + struct da_monitor *da_mon; > + const int id = 4242; > + > + prepare_test(test, &rvtest_mon); > + da_handle_start_run_event(id, NULL, start_rvtest); > + > + scoped_guard(rcu) > + da_mon = da_get_monitor(id, NULL); > + KUNIT_ASSERT_NOT_NULL(test, da_mon); > + ha_mon = to_ha_monitor(da_mon); > + > + /* Uptime below the budget: time_ns - expire_ns would underflow. */ > + ha_reset_clk_ns(ha_mon, clk_rvtest, 0); [Severity: Medium] Does this scoped_guard drop the lock prematurely? Because there are no curly braces around the scoped_guard, the RCU read-side critical section only covers the single assignment to da_mon. Immediately after da_get_monitor() returns, the guard scope ends and the lock is released. However, da_mon and its container ha_mon are dynamically allocated RCU-protected objects. They are extensively used outside the critical section in the subsequent test steps. For example, ha_reset_clk_ns(), ha_start_timer_ns(), and ha_cancel_timer_sync() all dereference this pointer after the RCU read lock has been dropped. Could this violate RCU lifetime rules and create a use-after-free risk? [ ... ] -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=3
