lkml.org 
[lkml]   [2017]   [Oct]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH v2 2/3] lockdep: Remove BROKEN flag of LOCKDEP_CROSSRELEASE
Date
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.
\
 
 \ /
  Last update: 2017-10-22 17:26    [W:0.087 / U:0.544 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site