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

[Bart Van Assche <Bart.VanAssche@wdc.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1716 bytes --]

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@lge.com>
> ---
>  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.N‹§²æìr¸›zǧu©ž²Æ {\b­†éì¹»\x1c®&Þ–)îÆi¢žØ^n‡r¶‰šŽŠÝ¢j$½§$¢¸\x05¢¹¨­è§~Š'.)îÄÃ,yèm¶ŸÿÃ\f%Š{±šj+ƒðèž×¦j)Z†·Ÿ