Re: [PATCH v2 2/3] lockdep: Remove BROKEN flag of LOCKDEP_CROSSRELEASE

From: Bart Van Assche
Date: Thu Oct 19 2017 - 11:06:03 EST


On Thu, 2017-10-19 at 14:55 +0900, Byungchul Park wrote:
> Now the performance regression was fixed, re-enable
> CONFIG_LOCKDEP_CROSSRELEASE and CONFIG_LOCKDEP_COMPLETIONS.
>
> Signed-off-by: Byungchul Park <byungchul.park@xxxxxxx>
> ---
> lib/Kconfig.debug | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 90ea784..fe8fceb 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -1138,8 +1138,8 @@ config PROVE_LOCKING
> select DEBUG_MUTEXES
> select DEBUG_RT_MUTEXES if RT_MUTEXES
> select DEBUG_LOCK_ALLOC
> - select LOCKDEP_CROSSRELEASE if BROKEN
> - select LOCKDEP_COMPLETIONS if BROKEN
> + select LOCKDEP_CROSSRELEASE
> + select LOCKDEP_COMPLETIONS
> select TRACE_IRQFLAGS
> default n
> help

I do not agree with this patch. Although the traditional lock validation
code can be proven not to produce false positives, that is not the case for
the cross-release checks. These checks are prone to produce false positives.
Many kernel developers, including myself, are not interested in spending
time on analyzing false positive deadlock reports. So I think that it is
wrong to enable cross-release checking unconditionally if PROVE_LOCKING has
been enabled. What I think that should happen is that either the cross-
release checking code is removed from the kernel or that
LOCKDEP_CROSSRELEASE becomes a new kernel configuration option. That will
give kernel developers who choose to enable PROVE_LOCKING the freedom to
decide whether or not to enable LOCKDEP_CROSSRELEASE.

Bart.