Re: [PATCH v19 24/40] locking/lockdep: prevent various lockdep assertions when lockdep_off()'ed

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