On Wed, Jan 18, 2017 at 10:17:32PM +0900, Byungchul Park wrote: > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug > index a6c8db1..7890661 100644 > --- a/lib/Kconfig.debug > +++ b/lib/Kconfig.debug > @@ -1042,6 +1042,19 @@ config DEBUG_LOCK_ALLOC > spin_lock_init()/mutex_init()/etc., or whether there is any lock > held during task exit. > > +config LOCKDEP_CROSSRELEASE > + bool "Lock debugging: make lockdep work for crosslocks" > + select LOCKDEP > + select TRACE_IRQFLAGS > + default n > + help > + This makes lockdep work for crosslock which is a lock allowed to > + be released in a different context from the acquisition context. > + Normally a lock must be released in the context acquiring the lock. > + However, relexing this constraint helps synchronization primitives > + such as page locks or completions can use the lock correctness > + detector, lockdep. > + > config PROVE_LOCKING > bool "Lock debugging: prove locking correctness" > depends on DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT Does CROSSRELEASE && !PROVE_LOCKING make any sense? -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
