Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Medium] The patch introduces a performance regression on fast paths when CONFIG_PROVE_LOCKING is enabled by adding an out-of-line function call to a macro that is unconditionally evaluated before checking if the assertion actually fails. --
commit a2a5c1f9c5f68f19a3e991808b6e812dde3fa53a Author: Byungchul Park <[email protected]> locking/lockdep: prevent various lockdep assertions when lockdep_off()'ed This commit adds a check for lockdep_recursing(current) to the __lockdep_enabled macro. To avoid header dependency issues, it introduces an out-of-line function lockdep_recursing_current(). > diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h > index 60b17a2ff555f..5113b7053b621 100644 > --- a/include/linux/lockdep.h > +++ b/include/linux/lockdep.h [ ... ] > @@ -630,7 +631,7 @@ DECLARE_PER_CPU(int, hardirqs_enabled); > DECLARE_PER_CPU(int, hardirq_context); > DECLARE_PER_CPU(unsigned int, lockdep_recursion); > > -#define __lockdep_enabled (debug_locks && > !this_cpu_read(lockdep_recursion)) > +#define __lockdep_enabled (debug_locks && > !this_cpu_read(lockdep_recursion) && !lockdep_recursing_current()) > > #define lockdep_assert_irqs_enabled() > \ > do { \ [Severity: Medium] Will this out-of-line call introduce measurable overhead on fast paths? Since debug_locks and !this_cpu_read(lockdep_recursion) are almost always true in healthy systems, lockdep_recursing_current() will be evaluated every time __lockdep_enabled is checked. For example, in lockdep_assert_irqs_enabled(): WARN_ON_ONCE(__lockdep_enabled && !this_cpu_read(hardirqs_enabled)); Because __lockdep_enabled is the first operand, the out-of-line call executes before checking if the assertion actually fails. Could we move __lockdep_enabled to the end of the && chain in these assertions? WARN_ON_ONCE(!this_cpu_read(hardirqs_enabled) && __lockdep_enabled); Placing the failure condition first would ensure the out-of-line function is only evaluated on the slow path when the assertion is already failing, avoiding the function call overhead on hot paths entirely. -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=24
