[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160229091102.GA8361@gmail.com>
Date: Mon, 29 Feb 2016 10:11:02 +0100
From: Ingo Molnar <mingo@...nel.org>
To: Andrew Morton <akpm@...ux-foundation.org>,
Sasha Levin <sasha.levin@...cle.com>
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:
> On Tue, 9 Feb 2016 12:12:29 +0100 Ingo Molnar <mingo@...nel.org> wrote:
>
> > > 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.
>
> OK, so the below has been in -next for nearly a week, no issues. We
> should get this into 4.5 to fix the CONFIG_UBSAN_ALIGNMENT issue.
So I think this patch broke liblockdep:
triton:~/tip/tools/lib/lockdep>
In file included from lockdep.c:2:0:
../../../kernel/locking/lockdep.c: In function ‘look_up_lock_class’:
../../../kernel/locking/lockdep.c:722:2: warning: implicit declaration of function ‘hlist_for_each_entry_rcu’ [-Wimplicit-function-declaration]
hlist_for_each_entry_rcu(class, hash_head, hash_entry) {
...
Thanks,
Ingo
Powered by blists - more mailing lists