* Andrey Ryabinin <[email protected]> wrote:
>
>
> 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
well, this is different, as we still generate an error - so it's not a
'permanent
solution' as the changelog says.
> 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() )?
That's fine with me, as long as we also fix the init bug that triggers this
code.
Thanks,
Ingo
