[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <56B1CB7F.5070207@virtuozzo.com>
Date: Wed, 3 Feb 2016 12:42:23 +0300
From: Andrey Ryabinin <aryabinin@...tuozzo.com>
To: Ingo Molnar <mingo@...nel.org>, <akpm@...ux-foundation.org>
CC: <krinkin.m.u@...il.com>, <mingo@...e.hu>, <peterz@...radead.org>,
<mm-commits@...r.kernel.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
On 02/03/2016 10:44 AM, Ingo Molnar wrote:
> Yuck, I don't really like this.
>
> Lockdep initialization must happen early on, 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.
>
> Also, in addition to properly ordering UBSAN initialization, how about fixing the
> silent crash by adding a lockdep warning to that place instead of an auto-init?
>
> The warning will turn lockdep off safely and will generate an actionable kernel
> message and stackdump upon which the init ordering fix can be done.
>
Something like this already done for DEBUG_LOCKDEP=y (except it initializes lockdep instead of turning it off).
look_up_lock_class():
...
#ifdef CONFIG_DEBUG_LOCKDEP
/*
* If the architecture calls into lockdep before initializing
* the hashes then we'll warn about it later. (we cannot printk
* right now)
*/
if (unlikely(!lockdep_initialized)) {
lockdep_init();
lockdep_init_error = 1;
lock_init_error = lock->name;
save_stack_trace(&lockdep_init_trace);
}
#endif
Silent crash happens only in DEBUG_LOCKDEP=n && LOCKDEP=y combination.
So, what about simply removing this #ifdef (and the other one in lockdep_info() )?
I
Powered by blists - more mailing lists