On Wed, 3 Feb 2016 08:44:30 +0100 Ingo Molnar <[email protected]> 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.
