linux-kernel - Re: [PATCH v8 00/14] lockdep: Implement crossrelease feature

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]

Message-ID: <20170814105748.zbnkjbgwbaxftu43@gmail.com>
Date:   Mon, 14 Aug 2017 12:57:48 +0200
From:   Ingo Molnar <mingo@...nel.org>
To:     Byungchul Park <byungchul.park@....com>
Cc:     peterz@...radead.org, tglx@...utronix.de, walken@...gle.com,
        boqun.feng@...il.com, kirill@...temov.name,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        akpm@...ux-foundation.org, willy@...radead.org, npiggin@...il.com,
        kernel-team@....com
Subject: Re: [PATCH v8 00/14] lockdep: Implement crossrelease feature


* Byungchul Park <byungchul.park@....com> wrote:

> On Thu, Aug 10, 2017 at 01:10:19PM +0200, Ingo Molnar wrote:
> > 
> > * Byungchul Park <byungchul.park@....com> wrote:
> > 
> > > Change from v7
> > > 	- rebase on latest tip/sched/core (Jul 26 2017)
> > > 	- apply peterz's suggestions
> > > 	- simplify code of crossrelease_{hist/soft/hard}_{start/end}
> > > 	- exclude a patch avoiding redundant links
> > > 	- exclude a patch already applied onto the base
> > 
> > Ok, it's looking pretty good here now, there's one thing I'd like you to change, 
> > please remove all the new Kconfig dependencies:
> > 
> >  CONFIG_LOCKDEP_CROSSRELEASE=y
> >  CONFIG_LOCKDEP_COMPLETE=y
> > 
> > and make it all part of PROVE_LOCKING, like most of the other lock debugging bits.
> 
> OK. I will remove them. What about CONFIG_LOCKDEP_PAGELOCK? Should I also
> remove it?

So I'd only remove the forced _configurability_ - we can still keep those 
variables just fine. They modularize the code and they might be useful later on if 
for some reason there's some really bad performance aspect that would make one of 
these lockdep components to be configured out by default.

Just make the user interface sane - i.e. only one switch needed to enable full 
lockdep. Internal modularization is fine, as long as it's not ugly and the user is 
not burdened with it.

Thanks,

	Ingo