linux-kernel - Re: + kernel-locking-lockdepc-make-lockdep-initialize-itself-on-demand.patch added to -mm tree

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: <20160209111228.GA32615@gmail.com>
Date:	Tue, 9 Feb 2016 12:12:29 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	aryabinin@...tuozzo.com, krinkin.m.u@...il.com, mingo@...e.hu,
	peterz@...radead.org, linux-kernel@...r.kernel.org,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: +
 kernel-locking-lockdepc-make-lockdep-initialize-itself-on-demand.patch added
 to -mm tree


* Andrew Morton <akpm@...ux-foundation.org> wrote:

> > and it should happen in a well defined place, not be opportunistic (and 
> > relatively random) like this, making it dependent on config options and 
> > calling contexts.
> 
> That's an unusable assertion, sorry.
> 
> Initializing lockdep in the above manner guarantees that it is initialized 
> before it is used.  It is *much* more reliable than "try to initialize it before 
> some piece of code which hasn't even been written yet tries to take a lock".

So I didn't like that patch because it called into lockdep in a messy way, without 
having any real knowledge about whether it's safe to do. Should lockdep ever grow 
more complex initialization, such a solution could break in subtle ways. I prefer 
clearly broken code with static dependencies over context-dependent broken code 
with dynamic call ordering/dependencies.

Fortunately we don't have to apply the patch:

> The conceptual problem is that if some piece of code does spin_lock_init() or 
> DEFINE_SPINLOCK(), that lock isn't necessarily initialized yet.

The conceptual problem is that the data structures are not build time initialized 
- but the hlist conversion patch solves that problem nicely!

So I'm a happy camper.

Thanks,

	Ingo