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.��.n������g��� �a��� �&ޖ)���)��h���&������梷���� �Ǟ�m������)������^�����������v���O��zf������
