From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933680AbcBCQsH (ORCPT ); Wed, 3 Feb 2016 11:48:07 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:45514 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932953AbcBCQsD (ORCPT ); Wed, 3 Feb 2016 11:48:03 -0500 Date: Wed, 3 Feb 2016 08:51:11 -0800 From: Andrew Morton To: Ingo Molnar 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: <20160203085111.fc3f2631.akpm@linux-foundation.org> In-Reply-To: <20160203074430.GA32652@gmail.com> References: <56b11d2d.vVw1kB2la7Y+70xF%akpm@linux-foundation.org> <20160203074430.GA32652@gmail.com> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 3 Feb 2016 08:44:30 +0100 Ingo Molnar wrote: > > Mike said: > > > > : CONFIG_UBSAN_ALIGNMENT breaks x86-64 kernel with lockdep enabled, i. e > > : kernel with CONFIG_UBSAN_ALIGNMENT fails to load without even any error > > : message. > > : > > : The problem is that ubsan callbacks use spinlocks and might be called > > : before lockdep is initialized. Particularly this line in the > > : reserve_ebda_region function causes problem: > > : > > : lowmem = *(unsigned short *)__va(BIOS_LOWMEM_KILOBYTES); > > : > > : If i put lockdep_init() before reserve_ebda_region call in > > : x86_64_start_reservations kernel loads well. > > > > Fix this ordering issue permanently: change lockdep so that it ensures > > that the hash tables are initialized when they are about to be used. > > > > The overhead will be pretty small: a test-n-branch in places where lockdep > > is about to do a lot of work anyway. > > > > Possibly lockdep_initialized should be made __read_mostly. > > > > A better fix would be to simply initialize these (32768 entry) arrays of > > empty list_heads at compile time, but I don't think there's a way of > > teaching gcc to do this. > > > > We could write a little script which, at compile time, emits a file > > containing > > > > [0] = LIST_HEAD_INIT(__chainhash_table[0]), > > [1] = LIST_HEAD_INIT(__chainhash_table[1]), > > ... > > [32767] = LIST_HEAD_INIT(__chainhash_table[32767]), > > > > and then #include this file into lockdep.c. Sounds like a lot of fuss. > > > > ... > > Yuck, I don't really like this. > > Lockdep initialization must happen early on, It should happen at compile time. > 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". The conceptual problem is that if some piece of code does spin_lock_init() or DEFINE_SPINLOCK(), that lock isn't necessarily initialized yet.