Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1325105

Re: + kernel-locking-lockdepc-make-lockdep-initialize-itself-on-demand.patch added to -mm tree

From Ingo Molnar <mingo@kernel.org>
Newsgroups linux.kernel
Subject Re: + kernel-locking-lockdepc-make-lockdep-initialize-itself-on-demand.patch added to -mm tree
Date 2016-02-03 10:50 +0100
Message-ID <qY2ew-ew-43@gated-at.bofh.it> (permalink)
References <qY0mm-7ok-27@gated-at.bofh.it> <qY0mm-7ok-25@gated-at.bofh.it> <qY2eu-ew-15@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


* Andrey Ryabinin <aryabinin@virtuozzo.com> 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

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: +  kernel-locking-lockdepc-make-lockdep-initialize-itself-on-demand.patch added  to -mm tree Ingo Molnar <mingo@kernel.org> - 2016-02-03 08:50 +0100
  Re: +  kernel-locking-lockdepc-make-lockdep-initialize-itself-on-demand.patch added  to -mm tree Andrey Ryabinin <aryabinin@virtuozzo.com> - 2016-02-03 10:50 +0100
    Re: +  kernel-locking-lockdepc-make-lockdep-initialize-itself-on-demand.patch added  to -mm tree Ingo Molnar <mingo@kernel.org> - 2016-02-03 10:50 +0100
  Re: +  kernel-locking-lockdepc-make-lockdep-initialize-itself-on-demand.patch  added to -mm tree Andrew Morton <akpm@linux-foundation.org> - 2016-02-03 17:50 +0100
    Re: +  kernel-locking-lockdepc-make-lockdep-initialize-itself-on-demand.patch  added to -mm tree Andrew Morton <akpm@linux-foundation.org> - 2016-02-03 21:50 +0100
      Re: +  kernel-locking-lockdepc-make-lockdep-initialize-itself-on-demand.patch  added to -mm tree Andrew Morton <akpm@linux-foundation.org> - 2016-02-03 22:50 +0100
        Re: +  kernel-locking-lockdepc-make-lockdep-initialize-itself-on-demand.patch added  to -mm tree Andrey Ryabinin <aryabinin@virtuozzo.com> - 2016-02-04 14:20 +0100
          Re: +  kernel-locking-lockdepc-make-lockdep-initialize-itself-on-demand.patch  added to -mm tree Michael Ellerman <mpe@ellerman.id.au> - 2016-02-08 10:40 +0100

csiph-web