From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932976AbcBILMe (ORCPT ); Tue, 9 Feb 2016 06:12:34 -0500 Received: from mail-wm0-f67.google.com ([74.125.82.67]:32880 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932403AbcBILMd (ORCPT ); Tue, 9 Feb 2016 06:12:33 -0500 Date: Tue, 9 Feb 2016 12:12:29 +0100 From: Ingo Molnar To: Andrew Morton Cc: aryabinin@virtuozzo.com, krinkin.m.u@gmail.com, mingo@elte.hu, peterz@infradead.org, linux-kernel@vger.kernel.org, Peter Zijlstra , Thomas Gleixner Subject: Re: + kernel-locking-lockdepc-make-lockdep-initialize-itself-on-demand.patch added to -mm tree Message-ID: <20160209111228.GA32615@gmail.com> References: <56b11d2d.vVw1kB2la7Y+70xF%akpm@linux-foundation.org> <20160203074430.GA32652@gmail.com> <20160203085111.fc3f2631.akpm@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160203085111.fc3f2631.akpm@linux-foundation.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Andrew Morton 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