linux-kernel - Re: [PATCH v2 2/3] lockdep: Remove BROKEN flag of LOCKDEP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 19 Oct 2017 15:05:28 +0000
From:   Bart Van Assche <Bart.VanAssche@....com>
To:     "mingo@...nel.org" <mingo@...nel.org>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "byungchul.park@....com" <byungchul.park@....com>
CC:     "tglx@...utronix.de" <tglx@...utronix.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "kernel-team@....com" <kernel-team@....com>
Subject: Re: [PATCH v2 2/3] lockdep: Remove BROKEN flag of
 LOCKDEP_CROSSRELEASE

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@....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.