* [PATCH v2 0/3] crossrelease: make it not unwind by default @ 2017-10-19 5:55 ` Byungchul Park 0 siblings, 0 replies; 50+ messages in thread From: Byungchul Park @ 2017-10-19 5:55 UTC (permalink / raw) To: peterz, mingo; +Cc: tglx, linux-kernel, linux-mm, kernel-team Change from v1 - Fix kconfig description as Ingo suggested - Fix commit message writing out CONFIG_ variable - Introduce a new kernel parameter, crossrelease_fullstack - Replace the number with the output of *perf* Byungchul Park (3): lockdep: Introduce CROSSRELEASE_STACK_TRACE and make it not unwind as default lockdep: Remove BROKEN flag of LOCKDEP_CROSSRELEASE lockdep: Add a kernel parameter, crossrelease_fullstack Documentation/admin-guide/kernel-parameters.txt | 3 +++ include/linux/lockdep.h | 4 ++++ kernel/locking/lockdep.c | 23 +++++++++++++++++++++-- lib/Kconfig.debug | 20 ++++++++++++++++++-- 4 files changed, 46 insertions(+), 4 deletions(-) -- 1.9.1 ^ permalink raw reply [flat|nested] 50+ messages in thread
* [PATCH v2 0/3] crossrelease: make it not unwind by default @ 2017-10-19 5:55 ` Byungchul Park 0 siblings, 0 replies; 50+ messages in thread From: Byungchul Park @ 2017-10-19 5:55 UTC (permalink / raw) To: peterz, mingo; +Cc: tglx, linux-kernel, linux-mm, kernel-team Change from v1 - Fix kconfig description as Ingo suggested - Fix commit message writing out CONFIG_ variable - Introduce a new kernel parameter, crossrelease_fullstack - Replace the number with the output of *perf* Byungchul Park (3): lockdep: Introduce CROSSRELEASE_STACK_TRACE and make it not unwind as default lockdep: Remove BROKEN flag of LOCKDEP_CROSSRELEASE lockdep: Add a kernel parameter, crossrelease_fullstack Documentation/admin-guide/kernel-parameters.txt | 3 +++ include/linux/lockdep.h | 4 ++++ kernel/locking/lockdep.c | 23 +++++++++++++++++++++-- lib/Kconfig.debug | 20 ++++++++++++++++++-- 4 files changed, 46 insertions(+), 4 deletions(-) -- 1.9.1 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 50+ messages in thread
* [PATCH v2 1/3] lockdep: Introduce CROSSRELEASE_STACK_TRACE and make it not unwind as default 2017-10-19 5:55 ` Byungchul Park @ 2017-10-19 5:55 ` Byungchul Park -1 siblings, 0 replies; 50+ messages in thread From: Byungchul Park @ 2017-10-19 5:55 UTC (permalink / raw) To: peterz, mingo; +Cc: tglx, linux-kernel, linux-mm, kernel-team Johan Hovold reported a performance regression by crossrelease like: > Boot time (from "Linux version" to login prompt) had in fact doubled > since 4.13 where it took 17 seconds (with my current config) compared to > the 35 seconds I now see with 4.14-rc4. > > I quick bisect pointed to lockdep and specifically the following commit: > > 28a903f63ec0 ("locking/lockdep: Handle non(or multi)-acquisition > of a crosslock") > > which I've verified is the commit which doubled the boot time (compared > to 28a903f63ec0^) (added by lockdep crossrelease series [1]). Currently crossrelease performs unwind on every acquisition. But, that overloads systems too much. So this patch makes unwind optional and set it to N as default. Instead, it records only acquire_ip normally. Of course, unwind is sometimes required for full analysis. In that case, we can set CROSSRELEASE_STACK_TRACE to Y and use it. In my qemu ubuntu machin (x86_64, 4 cores, 512M), the regression was fixed like, measuring booting times with 'perf stat --null --repeat 10 $QEMU', where $QEMU launchs a kernel with init=/bin/true: 1. No lockdep enabled Performance counter stats for 'qemu_booting_time.sh bzImage' (10 runs): 2.756558155 seconds time elapsed ( +- 0.09% ) 2. Lockdep enabled Performance counter stats for 'qemu_booting_time.sh bzImage' (10 runs): 2.968710420 seconds time elapsed ( +- 0.12% ) 3. Lockdep enabled + crossrelease enabled Performance counter stats for 'qemu_booting_time.sh bzImage' (10 runs): 3.153839636 seconds time elapsed ( +- 0.31% ) 4. Lockdep enabled + crossrelease enabled + this patch applied Performance counter stats for 'qemu_booting_time.sh bzImage' (10 runs): 2.963669551 seconds time elapsed ( +- 0.11% ) Signed-off-by: Byungchul Park <byungchul.park@lge.com> --- include/linux/lockdep.h | 4 ++++ kernel/locking/lockdep.c | 5 +++++ lib/Kconfig.debug | 15 +++++++++++++++ 3 files changed, 24 insertions(+) diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h index bfa8e0b..70358b5 100644 --- a/include/linux/lockdep.h +++ b/include/linux/lockdep.h @@ -278,7 +278,11 @@ struct held_lock { }; #ifdef CONFIG_LOCKDEP_CROSSRELEASE +#ifdef CONFIG_CROSSRELEASE_STACK_TRACE #define MAX_XHLOCK_TRACE_ENTRIES 5 +#else +#define MAX_XHLOCK_TRACE_ENTRIES 1 +#endif /* * This is for keeping locks waiting for commit so that true dependencies diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c index e36e652..5c2ddf2 100644 --- a/kernel/locking/lockdep.c +++ b/kernel/locking/lockdep.c @@ -4863,8 +4863,13 @@ static void add_xhlock(struct held_lock *hlock) xhlock->trace.nr_entries = 0; xhlock->trace.max_entries = MAX_XHLOCK_TRACE_ENTRIES; xhlock->trace.entries = xhlock->trace_entries; +#ifdef CONFIG_CROSSRELEASE_STACK_TRACE xhlock->trace.skip = 3; save_stack_trace(&xhlock->trace); +#else + xhlock->trace.nr_entries = 1; + xhlock->trace.entries[0] = hlock->acquire_ip; +#endif } static inline int same_context_xhlock(struct hist_lock *xhlock) diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index 3db9167..90ea784 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -1225,6 +1225,21 @@ config LOCKDEP_COMPLETIONS A deadlock caused by wait_for_completion() and complete() can be detected by lockdep using crossrelease feature. +config CROSSRELEASE_STACK_TRACE + bool "Record more than one entity of stack trace in crossrelease" + depends on LOCKDEP_CROSSRELEASE + default n + help + The lockdep "cross-release" feature needs to record stack traces + (of calling functions) for all acquisitions, for eventual later + use during analysis. By default only a single caller is recorded, + because the unwind operation can be very expensive with deeper + stack chains. However, sometimes deeper traces are required for + full analysis. This option turns on the saving of the full stack + trace entries. + + If unsure, say N. + config DEBUG_LOCKDEP bool "Lock dependency engine debugging" depends on DEBUG_KERNEL && LOCKDEP -- 1.9.1 ^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH v2 1/3] lockdep: Introduce CROSSRELEASE_STACK_TRACE and make it not unwind as default @ 2017-10-19 5:55 ` Byungchul Park 0 siblings, 0 replies; 50+ messages in thread From: Byungchul Park @ 2017-10-19 5:55 UTC (permalink / raw) To: peterz, mingo; +Cc: tglx, linux-kernel, linux-mm, kernel-team Johan Hovold reported a performance regression by crossrelease like: > Boot time (from "Linux version" to login prompt) had in fact doubled > since 4.13 where it took 17 seconds (with my current config) compared to > the 35 seconds I now see with 4.14-rc4. > > I quick bisect pointed to lockdep and specifically the following commit: > > 28a903f63ec0 ("locking/lockdep: Handle non(or multi)-acquisition > of a crosslock") > > which I've verified is the commit which doubled the boot time (compared > to 28a903f63ec0^) (added by lockdep crossrelease series [1]). Currently crossrelease performs unwind on every acquisition. But, that overloads systems too much. So this patch makes unwind optional and set it to N as default. Instead, it records only acquire_ip normally. Of course, unwind is sometimes required for full analysis. In that case, we can set CROSSRELEASE_STACK_TRACE to Y and use it. In my qemu ubuntu machin (x86_64, 4 cores, 512M), the regression was fixed like, measuring booting times with 'perf stat --null --repeat 10 $QEMU', where $QEMU launchs a kernel with init=/bin/true: 1. No lockdep enabled Performance counter stats for 'qemu_booting_time.sh bzImage' (10 runs): 2.756558155 seconds time elapsed ( +- 0.09% ) 2. Lockdep enabled Performance counter stats for 'qemu_booting_time.sh bzImage' (10 runs): 2.968710420 seconds time elapsed ( +- 0.12% ) 3. Lockdep enabled + crossrelease enabled Performance counter stats for 'qemu_booting_time.sh bzImage' (10 runs): 3.153839636 seconds time elapsed ( +- 0.31% ) 4. Lockdep enabled + crossrelease enabled + this patch applied Performance counter stats for 'qemu_booting_time.sh bzImage' (10 runs): 2.963669551 seconds time elapsed ( +- 0.11% ) Signed-off-by: Byungchul Park <byungchul.park@lge.com> --- include/linux/lockdep.h | 4 ++++ kernel/locking/lockdep.c | 5 +++++ lib/Kconfig.debug | 15 +++++++++++++++ 3 files changed, 24 insertions(+) diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h index bfa8e0b..70358b5 100644 --- a/include/linux/lockdep.h +++ b/include/linux/lockdep.h @@ -278,7 +278,11 @@ struct held_lock { }; #ifdef CONFIG_LOCKDEP_CROSSRELEASE +#ifdef CONFIG_CROSSRELEASE_STACK_TRACE #define MAX_XHLOCK_TRACE_ENTRIES 5 +#else +#define MAX_XHLOCK_TRACE_ENTRIES 1 +#endif /* * This is for keeping locks waiting for commit so that true dependencies diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c index e36e652..5c2ddf2 100644 --- a/kernel/locking/lockdep.c +++ b/kernel/locking/lockdep.c @@ -4863,8 +4863,13 @@ static void add_xhlock(struct held_lock *hlock) xhlock->trace.nr_entries = 0; xhlock->trace.max_entries = MAX_XHLOCK_TRACE_ENTRIES; xhlock->trace.entries = xhlock->trace_entries; +#ifdef CONFIG_CROSSRELEASE_STACK_TRACE xhlock->trace.skip = 3; save_stack_trace(&xhlock->trace); +#else + xhlock->trace.nr_entries = 1; + xhlock->trace.entries[0] = hlock->acquire_ip; +#endif } static inline int same_context_xhlock(struct hist_lock *xhlock) diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index 3db9167..90ea784 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -1225,6 +1225,21 @@ config LOCKDEP_COMPLETIONS A deadlock caused by wait_for_completion() and complete() can be detected by lockdep using crossrelease feature. +config CROSSRELEASE_STACK_TRACE + bool "Record more than one entity of stack trace in crossrelease" + depends on LOCKDEP_CROSSRELEASE + default n + help + The lockdep "cross-release" feature needs to record stack traces + (of calling functions) for all acquisitions, for eventual later + use during analysis. By default only a single caller is recorded, + because the unwind operation can be very expensive with deeper + stack chains. However, sometimes deeper traces are required for + full analysis. This option turns on the saving of the full stack + trace entries. + + If unsure, say N. + config DEBUG_LOCKDEP bool "Lock dependency engine debugging" depends on DEBUG_KERNEL && LOCKDEP -- 1.9.1 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH v2 2/3] lockdep: Remove BROKEN flag of LOCKDEP_CROSSRELEASE 2017-10-19 5:55 ` Byungchul Park @ 2017-10-19 5:55 ` Byungchul Park -1 siblings, 0 replies; 50+ messages in thread From: Byungchul Park @ 2017-10-19 5:55 UTC (permalink / raw) To: peterz, mingo; +Cc: tglx, linux-kernel, linux-mm, kernel-team Now the performance regression was fixed, re-enable CONFIG_LOCKDEP_CROSSRELEASE and CONFIG_LOCKDEP_COMPLETIONS. Signed-off-by: Byungchul Park <byungchul.park@lge.com> --- lib/Kconfig.debug | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index 90ea784..fe8fceb 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -1138,8 +1138,8 @@ config PROVE_LOCKING select DEBUG_MUTEXES select DEBUG_RT_MUTEXES if RT_MUTEXES select DEBUG_LOCK_ALLOC - select LOCKDEP_CROSSRELEASE if BROKEN - select LOCKDEP_COMPLETIONS if BROKEN + select LOCKDEP_CROSSRELEASE + select LOCKDEP_COMPLETIONS select TRACE_IRQFLAGS default n help -- 1.9.1 ^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH v2 2/3] lockdep: Remove BROKEN flag of LOCKDEP_CROSSRELEASE @ 2017-10-19 5:55 ` Byungchul Park 0 siblings, 0 replies; 50+ messages in thread From: Byungchul Park @ 2017-10-19 5:55 UTC (permalink / raw) To: peterz, mingo; +Cc: tglx, linux-kernel, linux-mm, kernel-team Now the performance regression was fixed, re-enable CONFIG_LOCKDEP_CROSSRELEASE and CONFIG_LOCKDEP_COMPLETIONS. Signed-off-by: Byungchul Park <byungchul.park@lge.com> --- lib/Kconfig.debug | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index 90ea784..fe8fceb 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -1138,8 +1138,8 @@ config PROVE_LOCKING select DEBUG_MUTEXES select DEBUG_RT_MUTEXES if RT_MUTEXES select DEBUG_LOCK_ALLOC - select LOCKDEP_CROSSRELEASE if BROKEN - select LOCKDEP_COMPLETIONS if BROKEN + select LOCKDEP_CROSSRELEASE + select LOCKDEP_COMPLETIONS select TRACE_IRQFLAGS default n help -- 1.9.1 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply related [flat|nested] 50+ messages in thread
* Re: [PATCH v2 2/3] lockdep: Remove BROKEN flag of LOCKDEP_CROSSRELEASE 2017-10-19 5:55 ` Byungchul Park @ 2017-10-19 15:05 ` Bart Van Assche -1 siblings, 0 replies; 50+ messages in thread From: Bart Van Assche @ 2017-10-19 15:05 UTC (permalink / raw) To: mingo, peterz, byungchul.park; +Cc: tglx, linux-kernel, linux-mm, kernel-team On Thu, 2017-10-19 at 14:55 +0900, Byungchul Park wrote: > Now the performance regression was fixed, re-enable > CONFIG_LOCKDEP_CROSSRELEASE and CONFIG_LOCKDEP_COMPLETIONS. > > Signed-off-by: Byungchul Park <byungchul.park@lge.com> > --- > lib/Kconfig.debug | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug > index 90ea784..fe8fceb 100644 > --- a/lib/Kconfig.debug > +++ b/lib/Kconfig.debug > @@ -1138,8 +1138,8 @@ config PROVE_LOCKING > select DEBUG_MUTEXES > select DEBUG_RT_MUTEXES if RT_MUTEXES > select DEBUG_LOCK_ALLOC > - select LOCKDEP_CROSSRELEASE if BROKEN > - select LOCKDEP_COMPLETIONS if BROKEN > + select LOCKDEP_CROSSRELEASE > + select LOCKDEP_COMPLETIONS > select TRACE_IRQFLAGS > default n > help I do not agree with this patch. Although the traditional lock validation code can be proven not to produce false positives, that is not the case for the cross-release checks. These checks are prone to produce false positives. Many kernel developers, including myself, are not interested in spending time on analyzing false positive deadlock reports. So I think that it is wrong to enable cross-release checking unconditionally if PROVE_LOCKING has been enabled. What I think that should happen is that either the cross- release checking code is removed from the kernel or that LOCKDEP_CROSSRELEASE becomes a new kernel configuration option. That will give kernel developers who choose to enable PROVE_LOCKING the freedom to decide whether or not to enable LOCKDEP_CROSSRELEASE. Bart. ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v2 2/3] lockdep: Remove BROKEN flag of LOCKDEP_CROSSRELEASE @ 2017-10-19 15:05 ` Bart Van Assche 0 siblings, 0 replies; 50+ messages in thread From: Bart Van Assche @ 2017-10-19 15:05 UTC (permalink / raw) To: mingo, peterz, byungchul.park; +Cc: tglx, linux-kernel, linux-mm, kernel-team [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1716 bytes --] On Thu, 2017-10-19 at 14:55 +0900, Byungchul Park wrote: > Now the performance regression was fixed, re-enable > CONFIG_LOCKDEP_CROSSRELEASE and CONFIG_LOCKDEP_COMPLETIONS. > > Signed-off-by: Byungchul Park <byungchul.park@lge.com> > --- > lib/Kconfig.debug | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug > index 90ea784..fe8fceb 100644 > --- a/lib/Kconfig.debug > +++ b/lib/Kconfig.debug > @@ -1138,8 +1138,8 @@ config PROVE_LOCKING > select DEBUG_MUTEXES > select DEBUG_RT_MUTEXES if RT_MUTEXES > select DEBUG_LOCK_ALLOC > - select LOCKDEP_CROSSRELEASE if BROKEN > - select LOCKDEP_COMPLETIONS if BROKEN > + select LOCKDEP_CROSSRELEASE > + select LOCKDEP_COMPLETIONS > select TRACE_IRQFLAGS > default n > help I do not agree with this patch. Although the traditional lock validation code can be proven not to produce false positives, that is not the case for the cross-release checks. These checks are prone to produce false positives. Many kernel developers, including myself, are not interested in spending time on analyzing false positive deadlock reports. So I think that it is wrong to enable cross-release checking unconditionally if PROVE_LOCKING has been enabled. What I think that should happen is that either the cross- release checking code is removed from the kernel or that LOCKDEP_CROSSRELEASE becomes a new kernel configuration option. That will give kernel developers who choose to enable PROVE_LOCKING the freedom to decide whether or not to enable LOCKDEP_CROSSRELEASE. Bart.N§²æìr¸zǧu©²Æ {\béì¹»\x1c®&Þ)îÆi¢Ø^nr¶Ý¢j$½§$¢¸\x05¢¹¨è§~'.)îÄÃ,yèm¶ÿÃ\f%{±j+ðèצj)Z· ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v2 2/3] lockdep: Remove BROKEN flag of LOCKDEP_CROSSRELEASE 2017-10-19 15:05 ` Bart Van Assche @ 2017-10-19 15:34 ` Thomas Gleixner -1 siblings, 0 replies; 50+ messages in thread From: Thomas Gleixner @ 2017-10-19 15:34 UTC (permalink / raw) To: Bart Van Assche Cc: mingo, peterz, byungchul.park, linux-kernel, linux-mm, kernel-team On Thu, 19 Oct 2017, Bart Van Assche wrote: > On Thu, 2017-10-19 at 14:55 +0900, Byungchul Park wrote: > > Now the performance regression was fixed, re-enable > > CONFIG_LOCKDEP_CROSSRELEASE and CONFIG_LOCKDEP_COMPLETIONS. > > > > Signed-off-by: Byungchul Park <byungchul.park@lge.com> > > --- > > lib/Kconfig.debug | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug > > index 90ea784..fe8fceb 100644 > > --- a/lib/Kconfig.debug > > +++ b/lib/Kconfig.debug > > @@ -1138,8 +1138,8 @@ config PROVE_LOCKING > > select DEBUG_MUTEXES > > select DEBUG_RT_MUTEXES if RT_MUTEXES > > select DEBUG_LOCK_ALLOC > > - select LOCKDEP_CROSSRELEASE if BROKEN > > - select LOCKDEP_COMPLETIONS if BROKEN > > + select LOCKDEP_CROSSRELEASE > > + select LOCKDEP_COMPLETIONS > > select TRACE_IRQFLAGS > > default n > > help > > I do not agree with this patch. Although the traditional lock validation > code can be proven not to produce false positives, that is not the case for > the cross-release checks. These checks are prone to produce false positives. > Many kernel developers, including myself, are not interested in spending > time on analyzing false positive deadlock reports. So I think that it is > wrong to enable cross-release checking unconditionally if PROVE_LOCKING has > been enabled. What I think that should happen is that either the cross- > release checking code is removed from the kernel or that > LOCKDEP_CROSSRELEASE becomes a new kernel configuration option. That will > give kernel developers who choose to enable PROVE_LOCKING the freedom to > decide whether or not to enable LOCKDEP_CROSSRELEASE. I really disagree with your reasoning completely 1) When lockdep was introduced more than ten years ago it was far from perfect and we spent a reasonable amount of time to improve it, analyze false positives and add the missing annotations all over the tree. That was a process which took years. 2) Surely nobody is interested in wasting time on analyzing false positives, but your (and other peoples) attidute of 'none of my business' is what makes kernel development extremly frustrating. It should be in the interest of everybody involved in kernel development to help with improving such features and not to lean back and wait for others to bring it into a shape which allows you to use it as you see fit. That's not how community works and lockdep would not be in the shape it is today, if only a handful of people would have used and improved it. Such things only work when used widely and when we get enough information so we can address the weak spots. Thanks, tglx ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v2 2/3] lockdep: Remove BROKEN flag of LOCKDEP_CROSSRELEASE @ 2017-10-19 15:34 ` Thomas Gleixner 0 siblings, 0 replies; 50+ messages in thread From: Thomas Gleixner @ 2017-10-19 15:34 UTC (permalink / raw) To: Bart Van Assche Cc: mingo, peterz, byungchul.park, linux-kernel, linux-mm, kernel-team On Thu, 19 Oct 2017, Bart Van Assche wrote: > On Thu, 2017-10-19 at 14:55 +0900, Byungchul Park wrote: > > Now the performance regression was fixed, re-enable > > CONFIG_LOCKDEP_CROSSRELEASE and CONFIG_LOCKDEP_COMPLETIONS. > > > > Signed-off-by: Byungchul Park <byungchul.park@lge.com> > > --- > > lib/Kconfig.debug | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug > > index 90ea784..fe8fceb 100644 > > --- a/lib/Kconfig.debug > > +++ b/lib/Kconfig.debug > > @@ -1138,8 +1138,8 @@ config PROVE_LOCKING > > select DEBUG_MUTEXES > > select DEBUG_RT_MUTEXES if RT_MUTEXES > > select DEBUG_LOCK_ALLOC > > - select LOCKDEP_CROSSRELEASE if BROKEN > > - select LOCKDEP_COMPLETIONS if BROKEN > > + select LOCKDEP_CROSSRELEASE > > + select LOCKDEP_COMPLETIONS > > select TRACE_IRQFLAGS > > default n > > help > > I do not agree with this patch. Although the traditional lock validation > code can be proven not to produce false positives, that is not the case for > the cross-release checks. These checks are prone to produce false positives. > Many kernel developers, including myself, are not interested in spending > time on analyzing false positive deadlock reports. So I think that it is > wrong to enable cross-release checking unconditionally if PROVE_LOCKING has > been enabled. What I think that should happen is that either the cross- > release checking code is removed from the kernel or that > LOCKDEP_CROSSRELEASE becomes a new kernel configuration option. That will > give kernel developers who choose to enable PROVE_LOCKING the freedom to > decide whether or not to enable LOCKDEP_CROSSRELEASE. I really disagree with your reasoning completely 1) When lockdep was introduced more than ten years ago it was far from perfect and we spent a reasonable amount of time to improve it, analyze false positives and add the missing annotations all over the tree. That was a process which took years. 2) Surely nobody is interested in wasting time on analyzing false positives, but your (and other peoples) attidute of 'none of my business' is what makes kernel development extremly frustrating. It should be in the interest of everybody involved in kernel development to help with improving such features and not to lean back and wait for others to bring it into a shape which allows you to use it as you see fit. That's not how community works and lockdep would not be in the shape it is today, if only a handful of people would have used and improved it. Such things only work when used widely and when we get enough information so we can address the weak spots. Thanks, tglx -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v2 2/3] lockdep: Remove BROKEN flag of LOCKDEP_CROSSRELEASE 2017-10-19 15:34 ` Thomas Gleixner (?) @ 2017-10-19 15:47 ` Bart Van Assche 2017-10-19 19:04 ` Thomas Gleixner -1 siblings, 1 reply; 50+ messages in thread From: Bart Van Assche @ 2017-10-19 15:47 UTC (permalink / raw) To: tglx; +Cc: mingo, linux-kernel, peterz, linux-mm, byungchul.park, kernel-team On Thu, 2017-10-19 at 17:34 +0200, Thomas Gleixner wrote: > I really disagree with your reasoning completely > > 1) When lockdep was introduced more than ten years ago it was far from > perfect and we spent a reasonable amount of time to improve it, analyze > false positives and add the missing annotations all over the tree. That > was a process which took years. > > 2) Surely nobody is interested in wasting time on analyzing false > positives, but your (and other peoples) attidute of 'none of my > business' is what makes kernel development extremly frustrating. > > It should be in the interest of everybody involved in kernel development > to help with improving such features and not to lean back and wait for > others to bring it into a shape which allows you to use it as you see > fit. > > That's not how community works and lockdep would not be in the shape it is > today, if only a handful of people would have used and improved it. Such > things only work when used widely and when we get enough information so we > can address the weak spots. Hello Thomas, It seems like you are missing my point. Cross-release checking is really *broken* as a concept. It is impossible to improve it to the same reliability level as the kernel v4.13 lockdep code. Hence my request to make it possible to disable cross-release checking if PROVE_LOCKING is enabled. Consider the following example from the cross-release documentation: TASK X TASK Y ------ ------ acquire AX acquire B /* A dependency 'AX -> B' exists */ release B release AX held by Y My understanding is that the cross-release code will add (AX, B) to the lock order graph after having encountered the above code. I think that's wrong because if the following sequence (Y: acquire AX, X: acquire B, X: release B) is encountered again that there is no guarantee that AX can only be released by X. Any task other than X could release that synchronization object too. Bart. ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v2 2/3] lockdep: Remove BROKEN flag of LOCKDEP_CROSSRELEASE 2017-10-19 15:47 ` Bart Van Assche @ 2017-10-19 19:04 ` Thomas Gleixner 0 siblings, 0 replies; 50+ messages in thread From: Thomas Gleixner @ 2017-10-19 19:04 UTC (permalink / raw) To: Bart Van Assche Cc: mingo, linux-kernel, peterz, linux-mm, byungchul.park, kernel-team Bart, On Thu, 19 Oct 2017, Bart Van Assche wrote: > It seems like you are missing my point. That might be a perception problem. > Cross-release checking is really *broken* as a concept. It is impossible > to improve it to the same reliability level as the kernel v4.13 lockdep > code. Hence my request to make it possible to disable cross-release > checking if PROVE_LOCKING is enabled. I did not read it as a request. If you'd had said: I have doubts about the concept and I think that it's impossible to handle the false positives up to the point where the existing lockdep infrastructure can do. Therefore I request that the feature gets an extra Kconfig entry (default y) or a command line parameter which allows to disable it in case of hard to fix false positive warnings, so the issue can be reported and normal lockdep testing can be resumed until the issue is fixed. Then I would have said: That makes sense, as long as its default on and people actually report the problems so the responsible developers can tackle them. What tripped me over was your statement: Many kernel developers, including myself, are not interested in spending time on analyzing false positive deadlock reports. Which sends a completely different message. > Consider the following example from the cross-release documentation: > > TASK X TASK Y > ------ ------ > acquire AX > acquire B /* A dependency 'AX -> B' exists */ > release B > release AX held by Y > > My understanding is that the cross-release code will add (AX, B) to the lock > order graph after having encountered the above code. I think that's wrong > because if the following sequence (Y: acquire AX, X: acquire B, X: release B) > is encountered again that there is no guarantee that AX can only be released > by X. Any task other than X could release that synchronization object too. Emphasis on could. That's not a lockdep problem and neither can the pure locking dependency tracking know that a particular deadlock is not possible by design. It can merily record the dependency chains and detect circular dependencies. There is enough code which is obviously correct in terms of locking which has lockdep annotations in one form or the other (nesting, different lock_class_keys etc.). These annotations are there to teach lockdep about false positives. It's pretty much the same with the cross release feature and we won't get these annotations into the code when people disable it Thanks, tglx ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v2 2/3] lockdep: Remove BROKEN flag of LOCKDEP_CROSSRELEASE @ 2017-10-19 19:04 ` Thomas Gleixner 0 siblings, 0 replies; 50+ messages in thread From: Thomas Gleixner @ 2017-10-19 19:04 UTC (permalink / raw) To: Bart Van Assche Cc: mingo, linux-kernel, peterz, linux-mm, byungchul.park, kernel-team Bart, On Thu, 19 Oct 2017, Bart Van Assche wrote: > It seems like you are missing my point. That might be a perception problem. > Cross-release checking is really *broken* as a concept. It is impossible > to improve it to the same reliability level as the kernel v4.13 lockdep > code. Hence my request to make it possible to disable cross-release > checking if PROVE_LOCKING is enabled. I did not read it as a request. If you'd had said: I have doubts about the concept and I think that it's impossible to handle the false positives up to the point where the existing lockdep infrastructure can do. Therefore I request that the feature gets an extra Kconfig entry (default y) or a command line parameter which allows to disable it in case of hard to fix false positive warnings, so the issue can be reported and normal lockdep testing can be resumed until the issue is fixed. Then I would have said: That makes sense, as long as its default on and people actually report the problems so the responsible developers can tackle them. What tripped me over was your statement: Many kernel developers, including myself, are not interested in spending time on analyzing false positive deadlock reports. Which sends a completely different message. > Consider the following example from the cross-release documentation: > > TASK X TASK Y > ------ ------ > acquire AX > acquire B /* A dependency 'AX -> B' exists */ > release B > release AX held by Y > > My understanding is that the cross-release code will add (AX, B) to the lock > order graph after having encountered the above code. I think that's wrong > because if the following sequence (Y: acquire AX, X: acquire B, X: release B) > is encountered again that there is no guarantee that AX can only be released > by X. Any task other than X could release that synchronization object too. Emphasis on could. That's not a lockdep problem and neither can the pure locking dependency tracking know that a particular deadlock is not possible by design. It can merily record the dependency chains and detect circular dependencies. There is enough code which is obviously correct in terms of locking which has lockdep annotations in one form or the other (nesting, different lock_class_keys etc.). These annotations are there to teach lockdep about false positives. It's pretty much the same with the cross release feature and we won't get these annotations into the code when people disable it Thanks, tglx -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v2 2/3] lockdep: Remove BROKEN flag of LOCKDEP_CROSSRELEASE 2017-10-19 19:04 ` Thomas Gleixner @ 2017-10-19 19:12 ` Thomas Gleixner -1 siblings, 0 replies; 50+ messages in thread From: Thomas Gleixner @ 2017-10-19 19:12 UTC (permalink / raw) To: Bart Van Assche Cc: mingo, linux-kernel, peterz, linux-mm, byungchul.park, kernel-team On Thu, 19 Oct 2017, Thomas Gleixner wrote: > That's not a lockdep problem and neither can the pure locking dependency > tracking know that a particular deadlock is not possible by design. It can > merily record the dependency chains and detect circular dependencies. > > There is enough code which is obviously correct in terms of locking which > has lockdep annotations in one form or the other (nesting, different > lock_class_keys etc.). These annotations are there to teach lockdep about > false positives. It's pretty much the same with the cross release feature > and we won't get these annotations into the code when people disable it And just for the record, I wasted enough of my time already to decode 'can not happen' dead locks where completions or other wait primitives have been involved. I rather spend time annotating stuff after analyzing it proper than chasing happens once in a blue moon lockups which are completely unexplainable. That's why lockdep exists in the first place. Ingo, Steven, myself and others spent an insane amount of time to fix locking bugs all over the tree when we started the preempt RT work. Lockdep was a rescue because it forced people to look at their own crap and if it was 100% clear that lockdep tripped a false positive either lockdep was fixed or the code in question annotated, which is a good thing because that's documentation at the same time. Thanks, tglx ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v2 2/3] lockdep: Remove BROKEN flag of LOCKDEP_CROSSRELEASE @ 2017-10-19 19:12 ` Thomas Gleixner 0 siblings, 0 replies; 50+ messages in thread From: Thomas Gleixner @ 2017-10-19 19:12 UTC (permalink / raw) To: Bart Van Assche Cc: mingo, linux-kernel, peterz, linux-mm, byungchul.park, kernel-team On Thu, 19 Oct 2017, Thomas Gleixner wrote: > That's not a lockdep problem and neither can the pure locking dependency > tracking know that a particular deadlock is not possible by design. It can > merily record the dependency chains and detect circular dependencies. > > There is enough code which is obviously correct in terms of locking which > has lockdep annotations in one form or the other (nesting, different > lock_class_keys etc.). These annotations are there to teach lockdep about > false positives. It's pretty much the same with the cross release feature > and we won't get these annotations into the code when people disable it And just for the record, I wasted enough of my time already to decode 'can not happen' dead locks where completions or other wait primitives have been involved. I rather spend time annotating stuff after analyzing it proper than chasing happens once in a blue moon lockups which are completely unexplainable. That's why lockdep exists in the first place. Ingo, Steven, myself and others spent an insane amount of time to fix locking bugs all over the tree when we started the preempt RT work. Lockdep was a rescue because it forced people to look at their own crap and if it was 100% clear that lockdep tripped a false positive either lockdep was fixed or the code in question annotated, which is a good thing because that's documentation at the same time. Thanks, tglx -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v2 2/3] lockdep: Remove BROKEN flag of LOCKDEP_CROSSRELEASE 2017-10-19 19:12 ` Thomas Gleixner @ 2017-10-19 20:21 ` Bart Van Assche -1 siblings, 0 replies; 50+ messages in thread From: Bart Van Assche @ 2017-10-19 20:21 UTC (permalink / raw) To: tglx; +Cc: mingo, linux-kernel, peterz, linux-mm, byungchul.park, kernel-team On Thu, 2017-10-19 at 21:12 +0200, Thomas Gleixner wrote: > And just for the record, I wasted enough of my time already to decode 'can > not happen' dead locks where completions or other wait primitives have been > involved. I rather spend time annotating stuff after analyzing it proper > than chasing happens once in a blue moon lockups which are completely > unexplainable. > > That's why lockdep exists in the first place. Ingo, Steven, myself and > others spent an insane amount of time to fix locking bugs all over the tree > when we started the preempt RT work. Lockdep was a rescue because it forced > people to look at their own crap and if it was 100% clear that lockdep > tripped a false positive either lockdep was fixed or the code in question > annotated, which is a good thing because that's documentation at the same > time. Hello Thomas, In case it wouldn't be clear, your work and the work of others on lockdep and preempt-rt is highly appreciated. Sorry that I missed the discussion about the cross-release functionality when it went upstream. I have several questions about that functionality: * How many lock inversion problems have been found so far thanks to the cross-release checking? How many false positives have the cross-release checks triggered so far? Does the number of real issues that has been found outweigh the effort spent on suppressing false positives? * What alternatives have been considered other than enabling cross-release checking for all locking objects that support releasing from the context of another task than the context from which the lock was obtained? Has it e.g. been considered to introduce two versions of the lock objects that support cross-releases - one version for which lock inversion checking is always enabled and another version for which lock inversion checking is always disabled? * How much review has the Documentation/locking/crossrelease.txt received before it went upstream? At least to me that document seems much harder to read than other kernel documentation due to weird use of the English grammar. Thanks, Bart. ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v2 2/3] lockdep: Remove BROKEN flag of LOCKDEP_CROSSRELEASE @ 2017-10-19 20:21 ` Bart Van Assche 0 siblings, 0 replies; 50+ messages in thread From: Bart Van Assche @ 2017-10-19 20:21 UTC (permalink / raw) To: tglx; +Cc: mingo, linux-kernel, peterz, linux-mm, byungchul.park, kernel-team [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2256 bytes --] On Thu, 2017-10-19 at 21:12 +0200, Thomas Gleixner wrote: > And just for the record, I wasted enough of my time already to decode 'can > not happen' dead locks where completions or other wait primitives have been > involved. I rather spend time annotating stuff after analyzing it proper > than chasing happens once in a blue moon lockups which are completely > unexplainable. > > That's why lockdep exists in the first place. Ingo, Steven, myself and > others spent an insane amount of time to fix locking bugs all over the tree > when we started the preempt RT work. Lockdep was a rescue because it forced > people to look at their own crap and if it was 100% clear that lockdep > tripped a false positive either lockdep was fixed or the code in question > annotated, which is a good thing because that's documentation at the same > time. Hello Thomas, In case it wouldn't be clear, your work and the work of others on lockdep and preempt-rt is highly appreciated. Sorry that I missed the discussion about the cross-release functionality when it went upstream. I have several questions about that functionality: * How many lock inversion problems have been found so far thanks to the cross-release checking? How many false positives have the cross-release checks triggered so far? Does the number of real issues that has been found outweigh the effort spent on suppressing false positives? * What alternatives have been considered other than enabling cross-release checking for all locking objects that support releasing from the context of another task than the context from which the lock was obtained? Has it e.g. been considered to introduce two versions of the lock objects that support cross-releases - one version for which lock inversion checking is always enabled and another version for which lock inversion checking is always disabled? * How much review has the Documentation/locking/crossrelease.txt received before it went upstream? At least to me that document seems much harder to read than other kernel documentation due to weird use of the English grammar. Thanks, Bart.N§²æìr¸zǧu©²Æ {\béì¹»\x1c®&Þ)îÆi¢Ø^nr¶Ý¢j$½§$¢¸\x05¢¹¨è§~'.)îÄÃ,yèm¶ÿÃ\f%{±j+ðèצj)Z· ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v2 2/3] lockdep: Remove BROKEN flag of LOCKDEP_CROSSRELEASE 2017-10-19 20:21 ` Bart Van Assche @ 2017-10-19 20:33 ` Matthew Wilcox -1 siblings, 0 replies; 50+ messages in thread From: Matthew Wilcox @ 2017-10-19 20:33 UTC (permalink / raw) To: Bart Van Assche Cc: tglx, mingo, linux-kernel, peterz, linux-mm, byungchul.park, kernel-team On Thu, Oct 19, 2017 at 08:21:56PM +0000, Bart Van Assche wrote: > In case it wouldn't be clear, your work and the work of others on lockdep > and preempt-rt is highly appreciated. Sorry that I missed the discussion > about the cross-release functionality when it went upstream. I have several > questions about that functionality: > * How many lock inversion problems have been found so far thanks to the > cross-release checking? How many false positives have the cross-release > checks triggered so far? Does the number of real issues that has been > found outweigh the effort spent on suppressing false positives? > * What alternatives have been considered other than enabling cross-release > checking for all locking objects that support releasing from the context > of another task than the context from which the lock was obtained? Has it > e.g. been considered to introduce two versions of the lock objects that > support cross-releases - one version for which lock inversion checking is > always enabled and another version for which lock inversion checking is > always disabled? > * How much review has the Documentation/locking/crossrelease.txt received > before it went upstream? At least to me that document seems much harder > to read than other kernel documentation due to weird use of the English > grammar. While interesting, I think this list of questions misses an important one: * How many bugs is this going to catch in the future? For example, the page lock is not annotatable with lockdep -- we return to userspace with it held, for heaven's sake! So it is quite easy for someone not familiar with the MM locking hierarchy to inadvertently introduce an ABBA deadlock against the page lock. (ie me. I did that.) Right now, that has to be caught by a human reviewer; if cross-release checking can catch that, then it's worth having. ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v2 2/3] lockdep: Remove BROKEN flag of LOCKDEP_CROSSRELEASE @ 2017-10-19 20:33 ` Matthew Wilcox 0 siblings, 0 replies; 50+ messages in thread From: Matthew Wilcox @ 2017-10-19 20:33 UTC (permalink / raw) To: Bart Van Assche Cc: tglx, mingo, linux-kernel, peterz, linux-mm, byungchul.park, kernel-team On Thu, Oct 19, 2017 at 08:21:56PM +0000, Bart Van Assche wrote: > In case it wouldn't be clear, your work and the work of others on lockdep > and preempt-rt is highly appreciated. Sorry that I missed the discussion > about the cross-release functionality when it went upstream. I have several > questions about that functionality: > * How many lock inversion problems have been found so far thanks to the > cross-release checking? How many false positives have the cross-release > checks triggered so far? Does the number of real issues that has been > found outweigh the effort spent on suppressing false positives? > * What alternatives have been considered other than enabling cross-release > checking for all locking objects that support releasing from the context > of another task than the context from which the lock was obtained? Has it > e.g. been considered to introduce two versions of the lock objects that > support cross-releases - one version for which lock inversion checking is > always enabled and another version for which lock inversion checking is > always disabled? > * How much review has the Documentation/locking/crossrelease.txt received > before it went upstream? At least to me that document seems much harder > to read than other kernel documentation due to weird use of the English > grammar. While interesting, I think this list of questions misses an important one: * How many bugs is this going to catch in the future? For example, the page lock is not annotatable with lockdep -- we return to userspace with it held, for heaven's sake! So it is quite easy for someone not familiar with the MM locking hierarchy to inadvertently introduce an ABBA deadlock against the page lock. (ie me. I did that.) Right now, that has to be caught by a human reviewer; if cross-release checking can catch that, then it's worth having. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v2 2/3] lockdep: Remove BROKEN flag of LOCKDEP_CROSSRELEASE 2017-10-19 20:33 ` Matthew Wilcox (?) @ 2017-10-19 20:41 ` Bart Van Assche 2017-10-19 20:53 ` Thomas Gleixner -1 siblings, 1 reply; 50+ messages in thread From: Bart Van Assche @ 2017-10-19 20:41 UTC (permalink / raw) To: willy Cc: tglx, mingo, linux-kernel, peterz, byungchul.park, linux-mm, kernel-team On Thu, 2017-10-19 at 13:33 -0700, Matthew Wilcox wrote: > For example, the page lock is not annotatable with lockdep -- we return > to userspace with it held, for heaven's sake! So it is quite easy for > someone not familiar with the MM locking hierarchy to inadvertently > introduce an ABBA deadlock against the page lock. (ie me. I did that.) > Right now, that has to be caught by a human reviewer; if cross-release > checking can catch that, then it's worth having. Hello Matthew, Although I agree that enabling lock inversion checking for page locks is useful, I think my questions still apply to other locking objects than page locks. Thanks, Bart. ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v2 2/3] lockdep: Remove BROKEN flag of LOCKDEP_CROSSRELEASE 2017-10-19 20:41 ` Bart Van Assche @ 2017-10-19 20:53 ` Thomas Gleixner 0 siblings, 0 replies; 50+ messages in thread From: Thomas Gleixner @ 2017-10-19 20:53 UTC (permalink / raw) To: Bart Van Assche Cc: willy, mingo, linux-kernel, peterz, byungchul.park, linux-mm, kernel-team On Thu, 19 Oct 2017, Bart Van Assche wrote: > On Thu, 2017-10-19 at 13:33 -0700, Matthew Wilcox wrote: > > For example, the page lock is not annotatable with lockdep -- we return > > to userspace with it held, for heaven's sake! So it is quite easy for > > someone not familiar with the MM locking hierarchy to inadvertently > > introduce an ABBA deadlock against the page lock. (ie me. I did that.) > > Right now, that has to be caught by a human reviewer; if cross-release > > checking can catch that, then it's worth having. > > Hello Matthew, > > Although I agree that enabling lock inversion checking for page locks is > useful, I think my questions still apply to other locking objects than page > locks. Why are other objects any different? lock(L) -> wait_for_completion(A) lock(L) -> complete(A) is a simple ABBA and they exist and have not been caught for a long time until they choked a production machine. Thanks, tglx ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v2 2/3] lockdep: Remove BROKEN flag of LOCKDEP_CROSSRELEASE @ 2017-10-19 20:53 ` Thomas Gleixner 0 siblings, 0 replies; 50+ messages in thread From: Thomas Gleixner @ 2017-10-19 20:53 UTC (permalink / raw) To: Bart Van Assche Cc: willy, mingo, linux-kernel, peterz, byungchul.park, linux-mm, kernel-team On Thu, 19 Oct 2017, Bart Van Assche wrote: > On Thu, 2017-10-19 at 13:33 -0700, Matthew Wilcox wrote: > > For example, the page lock is not annotatable with lockdep -- we return > > to userspace with it held, for heaven's sake! So it is quite easy for > > someone not familiar with the MM locking hierarchy to inadvertently > > introduce an ABBA deadlock against the page lock. (ie me. I did that.) > > Right now, that has to be caught by a human reviewer; if cross-release > > checking can catch that, then it's worth having. > > Hello Matthew, > > Although I agree that enabling lock inversion checking for page locks is > useful, I think my questions still apply to other locking objects than page > locks. Why are other objects any different? lock(L) -> wait_for_completion(A) lock(L) -> complete(A) is a simple ABBA and they exist and have not been caught for a long time until they choked a production machine. Thanks, tglx -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v2 2/3] lockdep: Remove BROKEN flag of LOCKDEP_CROSSRELEASE 2017-10-19 20:21 ` Bart Van Assche @ 2017-10-19 20:49 ` Thomas Gleixner -1 siblings, 0 replies; 50+ messages in thread From: Thomas Gleixner @ 2017-10-19 20:49 UTC (permalink / raw) To: Bart Van Assche Cc: mingo, linux-kernel, peterz, linux-mm, byungchul.park, kernel-team On Thu, 19 Oct 2017, Bart Van Assche wrote: > * How many lock inversion problems have been found so far thanks to the > cross-release checking? How many false positives have the cross-release > checks triggered so far? Does the number of real issues that has been > found outweigh the effort spent on suppressing false positives? That's bean counting which is completely irrelevant. Real issues and false positives are both problems which need to be looked at carefully. - The deadlock needs to be fixed, which is obvious. - The false positive needs to be annotated, which is a good thing in several aspects: It proofs that this was done intentional and is correct and the annotation documents it at the same time in the code. I'm pretty sure that except for a few obvious ones the effort to prove that a false positive is a false positive is substantial, but not proving it would either be arrogant or outright stupid. So it's not a N > M question. Even if the number of false positives is higher than the number of real deadlocks, then everyone out in the field who had to stare at his server once a year not making progress and not telling why will appreciate that these obscure issues are gone. > * What alternatives have been considered other than enabling cross-release > checking for all locking objects that support releasing from the context > of another task than the context from which the lock was obtained? Has it > e.g. been considered to introduce two versions of the lock objects that > support cross-releases - one version for which lock inversion checking is > always enabled and another version for which lock inversion checking is > always disabled? That would just make the door open for evading lockdep. This has been discussed when lockdep was introduced and with a lot of other 'annoying' debug features we've seen the same discussion happening. When they get introduced the number of real issues and false positives is high, but once the dust settles it's just business as usual and the overall code quality improves and the number of hard to decode problems shrinks. > * How much review has the Documentation/locking/crossrelease.txt received > before it went upstream? At least to me that document seems much harder > to read than other kernel documentation due to weird use of the English > grammar. It was reviewed, and yes it could do with some polishing, but it's a good start. Thanks, tglx ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v2 2/3] lockdep: Remove BROKEN flag of LOCKDEP_CROSSRELEASE @ 2017-10-19 20:49 ` Thomas Gleixner 0 siblings, 0 replies; 50+ messages in thread From: Thomas Gleixner @ 2017-10-19 20:49 UTC (permalink / raw) To: Bart Van Assche Cc: mingo, linux-kernel, peterz, linux-mm, byungchul.park, kernel-team On Thu, 19 Oct 2017, Bart Van Assche wrote: > * How many lock inversion problems have been found so far thanks to the > cross-release checking? How many false positives have the cross-release > checks triggered so far? Does the number of real issues that has been > found outweigh the effort spent on suppressing false positives? That's bean counting which is completely irrelevant. Real issues and false positives are both problems which need to be looked at carefully. - The deadlock needs to be fixed, which is obvious. - The false positive needs to be annotated, which is a good thing in several aspects: It proofs that this was done intentional and is correct and the annotation documents it at the same time in the code. I'm pretty sure that except for a few obvious ones the effort to prove that a false positive is a false positive is substantial, but not proving it would either be arrogant or outright stupid. So it's not a N > M question. Even if the number of false positives is higher than the number of real deadlocks, then everyone out in the field who had to stare at his server once a year not making progress and not telling why will appreciate that these obscure issues are gone. > * What alternatives have been considered other than enabling cross-release > checking for all locking objects that support releasing from the context > of another task than the context from which the lock was obtained? Has it > e.g. been considered to introduce two versions of the lock objects that > support cross-releases - one version for which lock inversion checking is > always enabled and another version for which lock inversion checking is > always disabled? That would just make the door open for evading lockdep. This has been discussed when lockdep was introduced and with a lot of other 'annoying' debug features we've seen the same discussion happening. When they get introduced the number of real issues and false positives is high, but once the dust settles it's just business as usual and the overall code quality improves and the number of hard to decode problems shrinks. > * How much review has the Documentation/locking/crossrelease.txt received > before it went upstream? At least to me that document seems much harder > to read than other kernel documentation due to weird use of the English > grammar. It was reviewed, and yes it could do with some polishing, but it's a good start. Thanks, tglx -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v2 2/3] lockdep: Remove BROKEN flag of LOCKDEP_CROSSRELEASE 2017-10-19 20:49 ` Thomas Gleixner @ 2017-10-20 7:30 ` Ingo Molnar -1 siblings, 0 replies; 50+ messages in thread From: Ingo Molnar @ 2017-10-20 7:30 UTC (permalink / raw) To: Thomas Gleixner Cc: Bart Van Assche, linux-kernel, peterz, linux-mm, byungchul.park, kernel-team * Thomas Gleixner <tglx@linutronix.de> wrote: > That would just make the door open for evading lockdep. This has been > discussed when lockdep was introduced and with a lot of other 'annoying' > debug features we've seen the same discussion happening. > > When they get introduced the number of real issues and false positives is > high, but once the dust settles it's just business as usual and the overall > code quality improves and the number of hard to decode problems shrinks. Yes, also note that it's typical that the proportion of false positives *increases* once a lock debugging feature enters a more mature period of its existence, because real deadlocks tend to be fixed at the development stage without us ever seeing them. I.e. for every lockdep-debugged bug fixed upstream I'm pretty sure there are at least 10 times as many bugs that were fixed in earlier stages of development, without ever hitting the upstream kernel. At least that's the rough proportion for locking bugs I introduce ;-) So even false positives are not a problem as long as their annotation improves the code or documents it better. Thanks, Ingo ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v2 2/3] lockdep: Remove BROKEN flag of LOCKDEP_CROSSRELEASE @ 2017-10-20 7:30 ` Ingo Molnar 0 siblings, 0 replies; 50+ messages in thread From: Ingo Molnar @ 2017-10-20 7:30 UTC (permalink / raw) To: Thomas Gleixner Cc: Bart Van Assche, linux-kernel, peterz, linux-mm, byungchul.park, kernel-team * Thomas Gleixner <tglx@linutronix.de> wrote: > That would just make the door open for evading lockdep. This has been > discussed when lockdep was introduced and with a lot of other 'annoying' > debug features we've seen the same discussion happening. > > When they get introduced the number of real issues and false positives is > high, but once the dust settles it's just business as usual and the overall > code quality improves and the number of hard to decode problems shrinks. Yes, also note that it's typical that the proportion of false positives *increases* once a lock debugging feature enters a more mature period of its existence, because real deadlocks tend to be fixed at the development stage without us ever seeing them. I.e. for every lockdep-debugged bug fixed upstream I'm pretty sure there are at least 10 times as many bugs that were fixed in earlier stages of development, without ever hitting the upstream kernel. At least that's the rough proportion for locking bugs I introduce ;-) So even false positives are not a problem as long as their annotation improves the code or documents it better. Thanks, Ingo -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v2 2/3] lockdep: Remove BROKEN flag of LOCKDEP_CROSSRELEASE 2017-10-19 20:21 ` Bart Van Assche @ 2017-10-20 6:03 ` Byungchul Park -1 siblings, 0 replies; 50+ messages in thread From: Byungchul Park @ 2017-10-20 6:03 UTC (permalink / raw) To: Bart Van Assche; +Cc: tglx, mingo, linux-kernel, peterz, linux-mm, kernel-team On Thu, Oct 19, 2017 at 08:21:56PM +0000, Bart Van Assche wrote: > * How much review has the Documentation/locking/crossrelease.txt received > before it went upstream? At least to me that document seems much harder > to read than other kernel documentation due to weird use of the English > grammar. Sorry for the bad English. Please help it enhanced. For others, Thomas and Matthew already did exactly what to say, well. ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v2 2/3] lockdep: Remove BROKEN flag of LOCKDEP_CROSSRELEASE @ 2017-10-20 6:03 ` Byungchul Park 0 siblings, 0 replies; 50+ messages in thread From: Byungchul Park @ 2017-10-20 6:03 UTC (permalink / raw) To: Bart Van Assche; +Cc: tglx, mingo, linux-kernel, peterz, linux-mm, kernel-team On Thu, Oct 19, 2017 at 08:21:56PM +0000, Bart Van Assche wrote: > * How much review has the Documentation/locking/crossrelease.txt received > before it went upstream? At least to me that document seems much harder > to read than other kernel documentation due to weird use of the English > grammar. Sorry for the bad English. Please help it enhanced. For others, Thomas and Matthew already did exactly what to say, well. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 50+ messages in thread
* [PATCH v2 3/3] lockdep: Add a kernel parameter, crossrelease_fullstack 2017-10-19 5:55 ` Byungchul Park @ 2017-10-19 5:55 ` Byungchul Park -1 siblings, 0 replies; 50+ messages in thread From: Byungchul Park @ 2017-10-19 5:55 UTC (permalink / raw) To: peterz, mingo; +Cc: tglx, linux-kernel, linux-mm, kernel-team Make whether to allow recording full stack, in cross-release feature, switchable at boot time via a kernel parameter, 'crossrelease_fullstack'. In case of a splat with no stack trace, one could just reboot and set the kernel parameter to get the full data without having to recompile the kernel. Change CONFIG_CROSSRELEASE_STACK_TRACE default from N to Y, and introduce the new kernel parameter. Suggested-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Byungchul Park <byungchul.park@lge.com> --- Documentation/admin-guide/kernel-parameters.txt | 3 +++ kernel/locking/lockdep.c | 18 ++++++++++++++++-- lib/Kconfig.debug | 5 +++-- 3 files changed, 22 insertions(+), 4 deletions(-) diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index ead7f40..4107b01 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -709,6 +709,9 @@ It will be ignored when crashkernel=X,high is not used or memory reserved is below 4G. + crossrelease_fullstack + [KNL] Allow to record full stack trace in cross-release + cryptomgr.notests [KNL] Disable crypto self-tests diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c index 5c2ddf2..feba887 100644 --- a/kernel/locking/lockdep.c +++ b/kernel/locking/lockdep.c @@ -76,6 +76,15 @@ #define lock_stat 0 #endif +static int crossrelease_fullstack; +static int __init allow_crossrelease_fullstack(char *str) +{ + crossrelease_fullstack = 1; + return 0; +} + +early_param("crossrelease_fullstack", allow_crossrelease_fullstack); + /* * lockdep_lock: protects the lockdep graph, the hashes and the * class/list/hash allocators. @@ -4864,8 +4873,13 @@ static void add_xhlock(struct held_lock *hlock) xhlock->trace.max_entries = MAX_XHLOCK_TRACE_ENTRIES; xhlock->trace.entries = xhlock->trace_entries; #ifdef CONFIG_CROSSRELEASE_STACK_TRACE - xhlock->trace.skip = 3; - save_stack_trace(&xhlock->trace); + if (crossrelease_fullstack) { + xhlock->trace.skip = 3; + save_stack_trace(&xhlock->trace); + } else { + xhlock->trace.nr_entries = 1; + xhlock->trace.entries[0] = hlock->acquire_ip; + } #else xhlock->trace.nr_entries = 1; xhlock->trace.entries[0] = hlock->acquire_ip; diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index fe8fceb..132536d 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -1228,7 +1228,7 @@ config LOCKDEP_COMPLETIONS config CROSSRELEASE_STACK_TRACE bool "Record more than one entity of stack trace in crossrelease" depends on LOCKDEP_CROSSRELEASE - default n + default y help The lockdep "cross-release" feature needs to record stack traces (of calling functions) for all acquisitions, for eventual later @@ -1238,7 +1238,8 @@ config CROSSRELEASE_STACK_TRACE full analysis. This option turns on the saving of the full stack trace entries. - If unsure, say N. + To make the feature actually on, set "crossrelease_fullstack" + kernel parameter, too. config DEBUG_LOCKDEP bool "Lock dependency engine debugging" -- 1.9.1 ^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH v2 3/3] lockdep: Add a kernel parameter, crossrelease_fullstack @ 2017-10-19 5:55 ` Byungchul Park 0 siblings, 0 replies; 50+ messages in thread From: Byungchul Park @ 2017-10-19 5:55 UTC (permalink / raw) To: peterz, mingo; +Cc: tglx, linux-kernel, linux-mm, kernel-team Make whether to allow recording full stack, in cross-release feature, switchable at boot time via a kernel parameter, 'crossrelease_fullstack'. In case of a splat with no stack trace, one could just reboot and set the kernel parameter to get the full data without having to recompile the kernel. Change CONFIG_CROSSRELEASE_STACK_TRACE default from N to Y, and introduce the new kernel parameter. Suggested-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Byungchul Park <byungchul.park@lge.com> --- Documentation/admin-guide/kernel-parameters.txt | 3 +++ kernel/locking/lockdep.c | 18 ++++++++++++++++-- lib/Kconfig.debug | 5 +++-- 3 files changed, 22 insertions(+), 4 deletions(-) diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index ead7f40..4107b01 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -709,6 +709,9 @@ It will be ignored when crashkernel=X,high is not used or memory reserved is below 4G. + crossrelease_fullstack + [KNL] Allow to record full stack trace in cross-release + cryptomgr.notests [KNL] Disable crypto self-tests diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c index 5c2ddf2..feba887 100644 --- a/kernel/locking/lockdep.c +++ b/kernel/locking/lockdep.c @@ -76,6 +76,15 @@ #define lock_stat 0 #endif +static int crossrelease_fullstack; +static int __init allow_crossrelease_fullstack(char *str) +{ + crossrelease_fullstack = 1; + return 0; +} + +early_param("crossrelease_fullstack", allow_crossrelease_fullstack); + /* * lockdep_lock: protects the lockdep graph, the hashes and the * class/list/hash allocators. @@ -4864,8 +4873,13 @@ static void add_xhlock(struct held_lock *hlock) xhlock->trace.max_entries = MAX_XHLOCK_TRACE_ENTRIES; xhlock->trace.entries = xhlock->trace_entries; #ifdef CONFIG_CROSSRELEASE_STACK_TRACE - xhlock->trace.skip = 3; - save_stack_trace(&xhlock->trace); + if (crossrelease_fullstack) { + xhlock->trace.skip = 3; + save_stack_trace(&xhlock->trace); + } else { + xhlock->trace.nr_entries = 1; + xhlock->trace.entries[0] = hlock->acquire_ip; + } #else xhlock->trace.nr_entries = 1; xhlock->trace.entries[0] = hlock->acquire_ip; diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index fe8fceb..132536d 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -1228,7 +1228,7 @@ config LOCKDEP_COMPLETIONS config CROSSRELEASE_STACK_TRACE bool "Record more than one entity of stack trace in crossrelease" depends on LOCKDEP_CROSSRELEASE - default n + default y help The lockdep "cross-release" feature needs to record stack traces (of calling functions) for all acquisitions, for eventual later @@ -1238,7 +1238,8 @@ config CROSSRELEASE_STACK_TRACE full analysis. This option turns on the saving of the full stack trace entries. - If unsure, say N. + To make the feature actually on, set "crossrelease_fullstack" + kernel parameter, too. config DEBUG_LOCKDEP bool "Lock dependency engine debugging" -- 1.9.1 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH v2 0/4] Fix false positives by cross-release feature 2017-10-19 5:55 ` Byungchul Park @ 2017-10-19 7:03 ` Byungchul Park -1 siblings, 0 replies; 50+ messages in thread From: Byungchul Park @ 2017-10-19 7:03 UTC (permalink / raw) To: peterz, mingo Cc: tglx, linux-kernel, linux-mm, tj, johannes.berg, oleg, amir73il, david, darrick.wong, linux-xfs, linux-fsdevel, linux-block, hch, idryomov, kernel-team I attached this patchset into another thread for patches fixing a performance regression by cross-release, so that the cross-release can be re-enabled easily as the last, after fixing false positives as well. Changes from v1 - Separate a patch removing white space Byungchul Park (4): completion: Add support for initializing completion with lockdep_map lockdep: Remove unnecessary acquisitions wrt workqueue flush genhd.h: Remove trailing white space lockdep: Assign a lock_class per gendisk used for wait_for_completion() block/bio.c | 2 +- block/genhd.c | 13 +++++-------- include/linux/completion.h | 8 ++++++++ include/linux/genhd.h | 26 ++++++++++++++++++++++---- include/linux/workqueue.h | 4 ++-- kernel/workqueue.c | 20 ++++---------------- 6 files changed, 42 insertions(+), 31 deletions(-) -- 1.9.1 ^ permalink raw reply [flat|nested] 50+ messages in thread
* [PATCH v2 0/4] Fix false positives by cross-release feature @ 2017-10-19 7:03 ` Byungchul Park 0 siblings, 0 replies; 50+ messages in thread From: Byungchul Park @ 2017-10-19 7:03 UTC (permalink / raw) To: peterz, mingo Cc: tglx, linux-kernel, linux-mm, tj, johannes.berg, oleg, amir73il, david, darrick.wong, linux-xfs, linux-fsdevel, linux-block, hch, idryomov, kernel-team I attached this patchset into another thread for patches fixing a performance regression by cross-release, so that the cross-release can be re-enabled easily as the last, after fixing false positives as well. Changes from v1 - Separate a patch removing white space Byungchul Park (4): completion: Add support for initializing completion with lockdep_map lockdep: Remove unnecessary acquisitions wrt workqueue flush genhd.h: Remove trailing white space lockdep: Assign a lock_class per gendisk used for wait_for_completion() block/bio.c | 2 +- block/genhd.c | 13 +++++-------- include/linux/completion.h | 8 ++++++++ include/linux/genhd.h | 26 ++++++++++++++++++++++---- include/linux/workqueue.h | 4 ++-- kernel/workqueue.c | 20 ++++---------------- 6 files changed, 42 insertions(+), 31 deletions(-) -- 1.9.1 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 50+ messages in thread
* [PATCH v2 1/4] completion: Add support for initializing completion with lockdep_map 2017-10-19 7:03 ` Byungchul Park @ 2017-10-19 7:03 ` Byungchul Park -1 siblings, 0 replies; 50+ messages in thread From: Byungchul Park @ 2017-10-19 7:03 UTC (permalink / raw) To: peterz, mingo Cc: tglx, linux-kernel, linux-mm, tj, johannes.berg, oleg, amir73il, david, darrick.wong, linux-xfs, linux-fsdevel, linux-block, hch, idryomov, kernel-team Sometimes, we want to initialize completions with sparate lockdep maps to assign lock classes under control. For example, the workqueue code manages lockdep maps, as it can classify lockdep maps properly. Provided a function for that purpose. Signed-off-by: Byungchul Park <byungchul.park@lge.com> --- include/linux/completion.h | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/include/linux/completion.h b/include/linux/completion.h index cae5400..182d56e 100644 --- a/include/linux/completion.h +++ b/include/linux/completion.h @@ -49,6 +49,13 @@ static inline void complete_release_commit(struct completion *x) lock_commit_crosslock((struct lockdep_map *)&x->map); } +#define init_completion_with_map(x, m) \ +do { \ + lockdep_init_map_crosslock((struct lockdep_map *)&(x)->map, \ + (m)->name, (m)->key, 0); \ + __init_completion(x); \ +} while (0) + #define init_completion(x) \ do { \ static struct lock_class_key __key; \ @@ -58,6 +65,7 @@ static inline void complete_release_commit(struct completion *x) __init_completion(x); \ } while (0) #else +#define init_completion_with_map(x, m) __init_completion(x) #define init_completion(x) __init_completion(x) static inline void complete_acquire(struct completion *x) {} static inline void complete_release(struct completion *x) {} -- 1.9.1 ^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH v2 1/4] completion: Add support for initializing completion with lockdep_map @ 2017-10-19 7:03 ` Byungchul Park 0 siblings, 0 replies; 50+ messages in thread From: Byungchul Park @ 2017-10-19 7:03 UTC (permalink / raw) To: peterz, mingo Cc: tglx, linux-kernel, linux-mm, tj, johannes.berg, oleg, amir73il, david, darrick.wong, linux-xfs, linux-fsdevel, linux-block, hch, idryomov, kernel-team Sometimes, we want to initialize completions with sparate lockdep maps to assign lock classes under control. For example, the workqueue code manages lockdep maps, as it can classify lockdep maps properly. Provided a function for that purpose. Signed-off-by: Byungchul Park <byungchul.park@lge.com> --- include/linux/completion.h | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/include/linux/completion.h b/include/linux/completion.h index cae5400..182d56e 100644 --- a/include/linux/completion.h +++ b/include/linux/completion.h @@ -49,6 +49,13 @@ static inline void complete_release_commit(struct completion *x) lock_commit_crosslock((struct lockdep_map *)&x->map); } +#define init_completion_with_map(x, m) \ +do { \ + lockdep_init_map_crosslock((struct lockdep_map *)&(x)->map, \ + (m)->name, (m)->key, 0); \ + __init_completion(x); \ +} while (0) + #define init_completion(x) \ do { \ static struct lock_class_key __key; \ @@ -58,6 +65,7 @@ static inline void complete_release_commit(struct completion *x) __init_completion(x); \ } while (0) #else +#define init_completion_with_map(x, m) __init_completion(x) #define init_completion(x) __init_completion(x) static inline void complete_acquire(struct completion *x) {} static inline void complete_release(struct completion *x) {} -- 1.9.1 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH v2 2/4] lockdep: Remove unnecessary acquisitions wrt workqueue flush 2017-10-19 7:03 ` Byungchul Park @ 2017-10-19 7:03 ` Byungchul Park -1 siblings, 0 replies; 50+ messages in thread From: Byungchul Park @ 2017-10-19 7:03 UTC (permalink / raw) To: peterz, mingo Cc: tglx, linux-kernel, linux-mm, tj, johannes.berg, oleg, amir73il, david, darrick.wong, linux-xfs, linux-fsdevel, linux-block, hch, idryomov, kernel-team The workqueue added manual acquisitions to catch deadlock cases. Now crossrelease was introduced, some of those are redundant, since wait_for_completion() already includes the acquisition for itself. Removed it. Signed-off-by: Byungchul Park <byungchul.park@lge.com> --- include/linux/workqueue.h | 4 ++-- kernel/workqueue.c | 20 ++++---------------- 2 files changed, 6 insertions(+), 18 deletions(-) diff --git a/include/linux/workqueue.h b/include/linux/workqueue.h index f3c47a0..1455b5e 100644 --- a/include/linux/workqueue.h +++ b/include/linux/workqueue.h @@ -218,7 +218,7 @@ static inline void destroy_delayed_work_on_stack(struct delayed_work *work) { } \ __init_work((_work), _onstack); \ (_work)->data = (atomic_long_t) WORK_DATA_INIT(); \ - lockdep_init_map(&(_work)->lockdep_map, #_work, &__key, 0); \ + lockdep_init_map(&(_work)->lockdep_map, "(complete)"#_work, &__key, 0); \ INIT_LIST_HEAD(&(_work)->entry); \ (_work)->func = (_func); \ } while (0) @@ -399,7 +399,7 @@ enum { static struct lock_class_key __key; \ const char *__lock_name; \ \ - __lock_name = #fmt#args; \ + __lock_name = "(complete)"#fmt#args; \ \ __alloc_workqueue_key((fmt), (flags), (max_active), \ &__key, __lock_name, ##args); \ diff --git a/kernel/workqueue.c b/kernel/workqueue.c index c77fdf6..8cef533 100644 --- a/kernel/workqueue.c +++ b/kernel/workqueue.c @@ -2496,15 +2496,8 @@ static void insert_wq_barrier(struct pool_workqueue *pwq, INIT_WORK_ONSTACK(&barr->work, wq_barrier_func); __set_bit(WORK_STRUCT_PENDING_BIT, work_data_bits(&barr->work)); - /* - * Explicitly init the crosslock for wq_barrier::done, make its lock - * key a subkey of the corresponding work. As a result we won't - * build a dependency between wq_barrier::done and unrelated work. - */ - lockdep_init_map_crosslock((struct lockdep_map *)&barr->done.map, - "(complete)wq_barr::done", - target->lockdep_map.key, 1); - __init_completion(&barr->done); + init_completion_with_map(&barr->done, &target->lockdep_map); + barr->task = current; /* @@ -2610,16 +2603,14 @@ void flush_workqueue(struct workqueue_struct *wq) struct wq_flusher this_flusher = { .list = LIST_HEAD_INIT(this_flusher.list), .flush_color = -1, - .done = COMPLETION_INITIALIZER_ONSTACK(this_flusher.done), }; int next_color; + init_completion_with_map(&this_flusher.done, &wq->lockdep_map); + if (WARN_ON(!wq_online)) return; - lock_map_acquire(&wq->lockdep_map); - lock_map_release(&wq->lockdep_map); - mutex_lock(&wq->mutex); /* @@ -2882,9 +2873,6 @@ bool flush_work(struct work_struct *work) if (WARN_ON(!wq_online)) return false; - lock_map_acquire(&work->lockdep_map); - lock_map_release(&work->lockdep_map); - if (start_flush_work(work, &barr)) { wait_for_completion(&barr.done); destroy_work_on_stack(&barr.work); -- 1.9.1 ^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH v2 2/4] lockdep: Remove unnecessary acquisitions wrt workqueue flush @ 2017-10-19 7:03 ` Byungchul Park 0 siblings, 0 replies; 50+ messages in thread From: Byungchul Park @ 2017-10-19 7:03 UTC (permalink / raw) To: peterz, mingo Cc: tglx, linux-kernel, linux-mm, tj, johannes.berg, oleg, amir73il, david, darrick.wong, linux-xfs, linux-fsdevel, linux-block, hch, idryomov, kernel-team The workqueue added manual acquisitions to catch deadlock cases. Now crossrelease was introduced, some of those are redundant, since wait_for_completion() already includes the acquisition for itself. Removed it. Signed-off-by: Byungchul Park <byungchul.park@lge.com> --- include/linux/workqueue.h | 4 ++-- kernel/workqueue.c | 20 ++++---------------- 2 files changed, 6 insertions(+), 18 deletions(-) diff --git a/include/linux/workqueue.h b/include/linux/workqueue.h index f3c47a0..1455b5e 100644 --- a/include/linux/workqueue.h +++ b/include/linux/workqueue.h @@ -218,7 +218,7 @@ static inline void destroy_delayed_work_on_stack(struct delayed_work *work) { } \ __init_work((_work), _onstack); \ (_work)->data = (atomic_long_t) WORK_DATA_INIT(); \ - lockdep_init_map(&(_work)->lockdep_map, #_work, &__key, 0); \ + lockdep_init_map(&(_work)->lockdep_map, "(complete)"#_work, &__key, 0); \ INIT_LIST_HEAD(&(_work)->entry); \ (_work)->func = (_func); \ } while (0) @@ -399,7 +399,7 @@ enum { static struct lock_class_key __key; \ const char *__lock_name; \ \ - __lock_name = #fmt#args; \ + __lock_name = "(complete)"#fmt#args; \ \ __alloc_workqueue_key((fmt), (flags), (max_active), \ &__key, __lock_name, ##args); \ diff --git a/kernel/workqueue.c b/kernel/workqueue.c index c77fdf6..8cef533 100644 --- a/kernel/workqueue.c +++ b/kernel/workqueue.c @@ -2496,15 +2496,8 @@ static void insert_wq_barrier(struct pool_workqueue *pwq, INIT_WORK_ONSTACK(&barr->work, wq_barrier_func); __set_bit(WORK_STRUCT_PENDING_BIT, work_data_bits(&barr->work)); - /* - * Explicitly init the crosslock for wq_barrier::done, make its lock - * key a subkey of the corresponding work. As a result we won't - * build a dependency between wq_barrier::done and unrelated work. - */ - lockdep_init_map_crosslock((struct lockdep_map *)&barr->done.map, - "(complete)wq_barr::done", - target->lockdep_map.key, 1); - __init_completion(&barr->done); + init_completion_with_map(&barr->done, &target->lockdep_map); + barr->task = current; /* @@ -2610,16 +2603,14 @@ void flush_workqueue(struct workqueue_struct *wq) struct wq_flusher this_flusher = { .list = LIST_HEAD_INIT(this_flusher.list), .flush_color = -1, - .done = COMPLETION_INITIALIZER_ONSTACK(this_flusher.done), }; int next_color; + init_completion_with_map(&this_flusher.done, &wq->lockdep_map); + if (WARN_ON(!wq_online)) return; - lock_map_acquire(&wq->lockdep_map); - lock_map_release(&wq->lockdep_map); - mutex_lock(&wq->mutex); /* @@ -2882,9 +2873,6 @@ bool flush_work(struct work_struct *work) if (WARN_ON(!wq_online)) return false; - lock_map_acquire(&work->lockdep_map); - lock_map_release(&work->lockdep_map); - if (start_flush_work(work, &barr)) { wait_for_completion(&barr.done); destroy_work_on_stack(&barr.work); -- 1.9.1 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH v2 3/4] genhd.h: Remove trailing white space 2017-10-19 7:03 ` Byungchul Park @ 2017-10-19 7:03 ` Byungchul Park -1 siblings, 0 replies; 50+ messages in thread From: Byungchul Park @ 2017-10-19 7:03 UTC (permalink / raw) To: peterz, mingo Cc: tglx, linux-kernel, linux-mm, tj, johannes.berg, oleg, amir73il, david, darrick.wong, linux-xfs, linux-fsdevel, linux-block, hch, idryomov, kernel-team Trailing white space is not accepted in kernel coding style. Remove them. Signed-off-by: Byungchul Park <byungchul.park@lge.com> --- include/linux/genhd.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/linux/genhd.h b/include/linux/genhd.h index ea652bf..6d85a75 100644 --- a/include/linux/genhd.h +++ b/include/linux/genhd.h @@ -3,7 +3,7 @@ /* * genhd.h Copyright (C) 1992 Drew Eckhardt - * Generic hard disk header file by + * Generic hard disk header file by * Drew Eckhardt * * <drew@colorado.edu> @@ -471,7 +471,7 @@ struct bsd_disklabel { __s16 d_type; /* drive type */ __s16 d_subtype; /* controller/d_type specific */ char d_typename[16]; /* type name, e.g. "eagle" */ - char d_packname[16]; /* pack identifier */ + char d_packname[16]; /* pack identifier */ __u32 d_secsize; /* # of bytes per sector */ __u32 d_nsectors; /* # of data sectors per track */ __u32 d_ntracks; /* # of tracks per cylinder */ -- 1.9.1 ^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH v2 3/4] genhd.h: Remove trailing white space @ 2017-10-19 7:03 ` Byungchul Park 0 siblings, 0 replies; 50+ messages in thread From: Byungchul Park @ 2017-10-19 7:03 UTC (permalink / raw) To: peterz, mingo Cc: tglx, linux-kernel, linux-mm, tj, johannes.berg, oleg, amir73il, david, darrick.wong, linux-xfs, linux-fsdevel, linux-block, hch, idryomov, kernel-team Trailing white space is not accepted in kernel coding style. Remove them. Signed-off-by: Byungchul Park <byungchul.park@lge.com> --- include/linux/genhd.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/linux/genhd.h b/include/linux/genhd.h index ea652bf..6d85a75 100644 --- a/include/linux/genhd.h +++ b/include/linux/genhd.h @@ -3,7 +3,7 @@ /* * genhd.h Copyright (C) 1992 Drew Eckhardt - * Generic hard disk header file by + * Generic hard disk header file by * Drew Eckhardt * * <drew@colorado.edu> @@ -471,7 +471,7 @@ struct bsd_disklabel { __s16 d_type; /* drive type */ __s16 d_subtype; /* controller/d_type specific */ char d_typename[16]; /* type name, e.g. "eagle" */ - char d_packname[16]; /* pack identifier */ + char d_packname[16]; /* pack identifier */ __u32 d_secsize; /* # of bytes per sector */ __u32 d_nsectors; /* # of data sectors per track */ __u32 d_ntracks; /* # of tracks per cylinder */ -- 1.9.1 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH v2 4/4] lockdep: Assign a lock_class per gendisk used for wait_for_completion() 2017-10-19 7:03 ` Byungchul Park @ 2017-10-19 7:03 ` Byungchul Park -1 siblings, 0 replies; 50+ messages in thread From: Byungchul Park @ 2017-10-19 7:03 UTC (permalink / raw) To: peterz, mingo Cc: tglx, linux-kernel, linux-mm, tj, johannes.berg, oleg, amir73il, david, darrick.wong, linux-xfs, linux-fsdevel, linux-block, hch, idryomov, kernel-team Darrick and Dave Chinner posted the following warning: > ====================================================== > WARNING: possible circular locking dependency detected > 4.14.0-rc1-fixes #1 Tainted: G W > ------------------------------------------------------ > loop0/31693 is trying to acquire lock: > (&(&ip->i_mmaplock)->mr_lock){++++}, at: [<ffffffffa00f1b0c>] xfs_ilock+0x23c/0x330 [xfs] > > but now in release context of a crosslock acquired at the following: > ((complete)&ret.event){+.+.}, at: [<ffffffff81326c1f>] submit_bio_wait+0x7f/0xb0 > > which lock already depends on the new lock. > > the existing dependency chain (in reverse order) is: > > -> #2 ((complete)&ret.event){+.+.}: > lock_acquire+0xab/0x200 > wait_for_completion_io+0x4e/0x1a0 > submit_bio_wait+0x7f/0xb0 > blkdev_issue_zeroout+0x71/0xa0 > xfs_bmapi_convert_unwritten+0x11f/0x1d0 [xfs] > xfs_bmapi_write+0x374/0x11f0 [xfs] > xfs_iomap_write_direct+0x2ac/0x430 [xfs] > xfs_file_iomap_begin+0x20d/0xd50 [xfs] > iomap_apply+0x43/0xe0 > dax_iomap_rw+0x89/0xf0 > xfs_file_dax_write+0xcc/0x220 [xfs] > xfs_file_write_iter+0xf0/0x130 [xfs] > __vfs_write+0xd9/0x150 > vfs_write+0xc8/0x1c0 > SyS_write+0x45/0xa0 > entry_SYSCALL_64_fastpath+0x1f/0xbe > > -> #1 (&xfs_nondir_ilock_class){++++}: > lock_acquire+0xab/0x200 > down_write_nested+0x4a/0xb0 > xfs_ilock+0x263/0x330 [xfs] > xfs_setattr_size+0x152/0x370 [xfs] > xfs_vn_setattr+0x6b/0x90 [xfs] > notify_change+0x27d/0x3f0 > do_truncate+0x5b/0x90 > path_openat+0x237/0xa90 > do_filp_open+0x8a/0xf0 > do_sys_open+0x11c/0x1f0 > entry_SYSCALL_64_fastpath+0x1f/0xbe > > -> #0 (&(&ip->i_mmaplock)->mr_lock){++++}: > up_write+0x1c/0x40 > xfs_iunlock+0x1d0/0x310 [xfs] > xfs_file_fallocate+0x8a/0x310 [xfs] > loop_queue_work+0xb7/0x8d0 > kthread_worker_fn+0xb9/0x1f0 > > Chain exists of: > &(&ip->i_mmaplock)->mr_lock --> &xfs_nondir_ilock_class --> (complete)&ret.event > > Possible unsafe locking scenario by crosslock: > > CPU0 CPU1 > ---- ---- > lock(&xfs_nondir_ilock_class); > lock((complete)&ret.event); > lock(&(&ip->i_mmaplock)->mr_lock); > unlock((complete)&ret.event); > > *** DEADLOCK *** The warning is a false positive, caused by the fact that all wait_for_completion()s in submit_bio_wait() are waiting with the same lock class. However, some bios have nothing to do with others, for example, the case might happen while using loop devices, between bios of an upper device and a lower device(=loop device). The safest way to assign different lock classes to different devices is to do it for each gendisk. In other words, this patch assigns a lockdep_map per gendisk and uses it when initializing completion in submit_bio_wait(). Of course, it might be too conservative. But, making it safest for now and extended by block layer experts later is good, atm. Signed-off-by: Byungchul Park <byungchul.park@lge.com> --- block/bio.c | 2 +- block/genhd.c | 13 +++++-------- include/linux/genhd.h | 22 ++++++++++++++++++++-- 3 files changed, 26 insertions(+), 11 deletions(-) diff --git a/block/bio.c b/block/bio.c index 101c2a9..6dd640d 100644 --- a/block/bio.c +++ b/block/bio.c @@ -945,7 +945,7 @@ int submit_bio_wait(struct bio *bio) { struct submit_bio_ret ret; - init_completion(&ret.event); + init_completion_with_map(&ret.event, &bio->bi_disk->lockdep_map); bio->bi_private = &ret; bio->bi_end_io = submit_bio_wait_endio; bio->bi_opf |= REQ_SYNC; diff --git a/block/genhd.c b/block/genhd.c index dd305c6..f195d22 100644 --- a/block/genhd.c +++ b/block/genhd.c @@ -1354,13 +1354,7 @@ dev_t blk_lookup_devt(const char *name, int partno) } EXPORT_SYMBOL(blk_lookup_devt); -struct gendisk *alloc_disk(int minors) -{ - return alloc_disk_node(minors, NUMA_NO_NODE); -} -EXPORT_SYMBOL(alloc_disk); - -struct gendisk *alloc_disk_node(int minors, int node_id) +struct gendisk *__alloc_disk_node(int minors, int node_id, struct lock_class_key *key, const char *lock_name) { struct gendisk *disk; struct disk_part_tbl *ptbl; @@ -1409,9 +1403,12 @@ struct gendisk *alloc_disk_node(int minors, int node_id) disk_to_dev(disk)->type = &disk_type; device_initialize(disk_to_dev(disk)); } + + lockdep_init_map(&disk->lockdep_map, lock_name, key, 0); + return disk; } -EXPORT_SYMBOL(alloc_disk_node); +EXPORT_SYMBOL(__alloc_disk_node); struct kobject *get_disk(struct gendisk *disk) { diff --git a/include/linux/genhd.h b/include/linux/genhd.h index 6d85a75..9832e3c 100644 --- a/include/linux/genhd.h +++ b/include/linux/genhd.h @@ -206,6 +206,9 @@ struct gendisk { #endif /* CONFIG_BLK_DEV_INTEGRITY */ int node_id; struct badblocks *bb; +#ifdef CONFIG_LOCKDEP_COMPLETIONS + struct lockdep_map lockdep_map; +#endif }; static inline struct gendisk *part_to_disk(struct hd_struct *part) @@ -590,8 +593,7 @@ extern struct hd_struct * __must_check add_partition(struct gendisk *disk, extern void delete_partition(struct gendisk *, int); extern void printk_all_partitions(void); -extern struct gendisk *alloc_disk_node(int minors, int node_id); -extern struct gendisk *alloc_disk(int minors); +extern struct gendisk *__alloc_disk_node(int minors, int node_id, struct lock_class_key *key, const char *lock_name); extern struct kobject *get_disk(struct gendisk *disk); extern void put_disk(struct gendisk *disk); extern void blk_register_region(dev_t devt, unsigned long range, @@ -615,6 +617,22 @@ extern ssize_t part_fail_store(struct device *dev, const char *buf, size_t count); #endif /* CONFIG_FAIL_MAKE_REQUEST */ +#ifdef CONFIG_LOCKDEP_COMPLETIONS +#define alloc_disk_node(m, id) \ +({ \ + static struct lock_class_key __key; \ + const char *__lock_name; \ + \ + __lock_name = "(complete)"#m"("#id")"; \ + \ + __alloc_disk_node(m, id, &__key, __lock_name); \ +}) +#else +#define alloc_disk_node(m, id) __alloc_disk_node(m, id, NULL, NULL) +#endif + +#define alloc_disk(m) alloc_disk_node(m, NUMA_NO_NODE) + static inline int hd_ref_init(struct hd_struct *part) { if (percpu_ref_init(&part->ref, __delete_partition, 0, -- 1.9.1 ^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH v2 4/4] lockdep: Assign a lock_class per gendisk used for wait_for_completion() @ 2017-10-19 7:03 ` Byungchul Park 0 siblings, 0 replies; 50+ messages in thread From: Byungchul Park @ 2017-10-19 7:03 UTC (permalink / raw) To: peterz, mingo Cc: tglx, linux-kernel, linux-mm, tj, johannes.berg, oleg, amir73il, david, darrick.wong, linux-xfs, linux-fsdevel, linux-block, hch, idryomov, kernel-team Darrick and Dave Chinner posted the following warning: > ====================================================== > WARNING: possible circular locking dependency detected > 4.14.0-rc1-fixes #1 Tainted: G W > ------------------------------------------------------ > loop0/31693 is trying to acquire lock: > (&(&ip->i_mmaplock)->mr_lock){++++}, at: [<ffffffffa00f1b0c>] xfs_ilock+0x23c/0x330 [xfs] > > but now in release context of a crosslock acquired at the following: > ((complete)&ret.event){+.+.}, at: [<ffffffff81326c1f>] submit_bio_wait+0x7f/0xb0 > > which lock already depends on the new lock. > > the existing dependency chain (in reverse order) is: > > -> #2 ((complete)&ret.event){+.+.}: > lock_acquire+0xab/0x200 > wait_for_completion_io+0x4e/0x1a0 > submit_bio_wait+0x7f/0xb0 > blkdev_issue_zeroout+0x71/0xa0 > xfs_bmapi_convert_unwritten+0x11f/0x1d0 [xfs] > xfs_bmapi_write+0x374/0x11f0 [xfs] > xfs_iomap_write_direct+0x2ac/0x430 [xfs] > xfs_file_iomap_begin+0x20d/0xd50 [xfs] > iomap_apply+0x43/0xe0 > dax_iomap_rw+0x89/0xf0 > xfs_file_dax_write+0xcc/0x220 [xfs] > xfs_file_write_iter+0xf0/0x130 [xfs] > __vfs_write+0xd9/0x150 > vfs_write+0xc8/0x1c0 > SyS_write+0x45/0xa0 > entry_SYSCALL_64_fastpath+0x1f/0xbe > > -> #1 (&xfs_nondir_ilock_class){++++}: > lock_acquire+0xab/0x200 > down_write_nested+0x4a/0xb0 > xfs_ilock+0x263/0x330 [xfs] > xfs_setattr_size+0x152/0x370 [xfs] > xfs_vn_setattr+0x6b/0x90 [xfs] > notify_change+0x27d/0x3f0 > do_truncate+0x5b/0x90 > path_openat+0x237/0xa90 > do_filp_open+0x8a/0xf0 > do_sys_open+0x11c/0x1f0 > entry_SYSCALL_64_fastpath+0x1f/0xbe > > -> #0 (&(&ip->i_mmaplock)->mr_lock){++++}: > up_write+0x1c/0x40 > xfs_iunlock+0x1d0/0x310 [xfs] > xfs_file_fallocate+0x8a/0x310 [xfs] > loop_queue_work+0xb7/0x8d0 > kthread_worker_fn+0xb9/0x1f0 > > Chain exists of: > &(&ip->i_mmaplock)->mr_lock --> &xfs_nondir_ilock_class --> (complete)&ret.event > > Possible unsafe locking scenario by crosslock: > > CPU0 CPU1 > ---- ---- > lock(&xfs_nondir_ilock_class); > lock((complete)&ret.event); > lock(&(&ip->i_mmaplock)->mr_lock); > unlock((complete)&ret.event); > > *** DEADLOCK *** The warning is a false positive, caused by the fact that all wait_for_completion()s in submit_bio_wait() are waiting with the same lock class. However, some bios have nothing to do with others, for example, the case might happen while using loop devices, between bios of an upper device and a lower device(=loop device). The safest way to assign different lock classes to different devices is to do it for each gendisk. In other words, this patch assigns a lockdep_map per gendisk and uses it when initializing completion in submit_bio_wait(). Of course, it might be too conservative. But, making it safest for now and extended by block layer experts later is good, atm. Signed-off-by: Byungchul Park <byungchul.park@lge.com> --- block/bio.c | 2 +- block/genhd.c | 13 +++++-------- include/linux/genhd.h | 22 ++++++++++++++++++++-- 3 files changed, 26 insertions(+), 11 deletions(-) diff --git a/block/bio.c b/block/bio.c index 101c2a9..6dd640d 100644 --- a/block/bio.c +++ b/block/bio.c @@ -945,7 +945,7 @@ int submit_bio_wait(struct bio *bio) { struct submit_bio_ret ret; - init_completion(&ret.event); + init_completion_with_map(&ret.event, &bio->bi_disk->lockdep_map); bio->bi_private = &ret; bio->bi_end_io = submit_bio_wait_endio; bio->bi_opf |= REQ_SYNC; diff --git a/block/genhd.c b/block/genhd.c index dd305c6..f195d22 100644 --- a/block/genhd.c +++ b/block/genhd.c @@ -1354,13 +1354,7 @@ dev_t blk_lookup_devt(const char *name, int partno) } EXPORT_SYMBOL(blk_lookup_devt); -struct gendisk *alloc_disk(int minors) -{ - return alloc_disk_node(minors, NUMA_NO_NODE); -} -EXPORT_SYMBOL(alloc_disk); - -struct gendisk *alloc_disk_node(int minors, int node_id) +struct gendisk *__alloc_disk_node(int minors, int node_id, struct lock_class_key *key, const char *lock_name) { struct gendisk *disk; struct disk_part_tbl *ptbl; @@ -1409,9 +1403,12 @@ struct gendisk *alloc_disk_node(int minors, int node_id) disk_to_dev(disk)->type = &disk_type; device_initialize(disk_to_dev(disk)); } + + lockdep_init_map(&disk->lockdep_map, lock_name, key, 0); + return disk; } -EXPORT_SYMBOL(alloc_disk_node); +EXPORT_SYMBOL(__alloc_disk_node); struct kobject *get_disk(struct gendisk *disk) { diff --git a/include/linux/genhd.h b/include/linux/genhd.h index 6d85a75..9832e3c 100644 --- a/include/linux/genhd.h +++ b/include/linux/genhd.h @@ -206,6 +206,9 @@ struct gendisk { #endif /* CONFIG_BLK_DEV_INTEGRITY */ int node_id; struct badblocks *bb; +#ifdef CONFIG_LOCKDEP_COMPLETIONS + struct lockdep_map lockdep_map; +#endif }; static inline struct gendisk *part_to_disk(struct hd_struct *part) @@ -590,8 +593,7 @@ extern struct hd_struct * __must_check add_partition(struct gendisk *disk, extern void delete_partition(struct gendisk *, int); extern void printk_all_partitions(void); -extern struct gendisk *alloc_disk_node(int minors, int node_id); -extern struct gendisk *alloc_disk(int minors); +extern struct gendisk *__alloc_disk_node(int minors, int node_id, struct lock_class_key *key, const char *lock_name); extern struct kobject *get_disk(struct gendisk *disk); extern void put_disk(struct gendisk *disk); extern void blk_register_region(dev_t devt, unsigned long range, @@ -615,6 +617,22 @@ extern ssize_t part_fail_store(struct device *dev, const char *buf, size_t count); #endif /* CONFIG_FAIL_MAKE_REQUEST */ +#ifdef CONFIG_LOCKDEP_COMPLETIONS +#define alloc_disk_node(m, id) \ +({ \ + static struct lock_class_key __key; \ + const char *__lock_name; \ + \ + __lock_name = "(complete)"#m"("#id")"; \ + \ + __alloc_disk_node(m, id, &__key, __lock_name); \ +}) +#else +#define alloc_disk_node(m, id) __alloc_disk_node(m, id, NULL, NULL) +#endif + +#define alloc_disk(m) alloc_disk_node(m, NUMA_NO_NODE) + static inline int hd_ref_init(struct hd_struct *part) { if (percpu_ref_init(&part->ref, __delete_partition, 0, -- 1.9.1 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply related [flat|nested] 50+ messages in thread
* Re: [PATCH v2 4/4] lockdep: Assign a lock_class per gendisk used for wait_for_completion() 2017-10-19 7:03 ` Byungchul Park (?) @ 2017-10-20 14:44 ` Christoph Hellwig -1 siblings, 0 replies; 50+ messages in thread From: Christoph Hellwig @ 2017-10-20 14:44 UTC (permalink / raw) To: Byungchul Park Cc: peterz, mingo, tglx, linux-kernel, linux-mm, tj, johannes.berg, oleg, amir73il, david, darrick.wong, linux-xfs, linux-fsdevel, linux-block, hch, idryomov, kernel-team The Subject prefix for this should be "block:". > @@ -945,7 +945,7 @@ int submit_bio_wait(struct bio *bio) > { > struct submit_bio_ret ret; > > - init_completion(&ret.event); > + init_completion_with_map(&ret.event, &bio->bi_disk->lockdep_map); FYI, I have an outstanding patch to simplify this a lot, which switches this to DECLARE_COMPLETION_ONSTACK. I can delay this or let you pick it up with your series, but we'll need a variant of DECLARE_COMPLETION_ONSTACK with the lockdep annotations. Patch below for reference: --- >From d65b89843c9f82c0744643515ba51dd10e66e67b Mon Sep 17 00:00:00 2001 From: Christoph Hellwig <hch@lst.de> Date: Thu, 5 Oct 2017 18:31:02 +0200 Subject: block: use DECLARE_COMPLETION_ONSTACK in submit_bio_wait Simplify the code by getting rid of the submit_bio_ret structure. Signed-off-by: Christoph Hellwig <hch@lst.de> --- block/bio.c | 19 +++++-------------- 1 file changed, 5 insertions(+), 14 deletions(-) diff --git a/block/bio.c b/block/bio.c index 8338304ea256..4e18e959fc0a 100644 --- a/block/bio.c +++ b/block/bio.c @@ -917,17 +917,9 @@ int bio_iov_iter_get_pages(struct bio *bio, struct iov_iter *iter) } EXPORT_SYMBOL_GPL(bio_iov_iter_get_pages); -struct submit_bio_ret { - struct completion event; - int error; -}; - static void submit_bio_wait_endio(struct bio *bio) { - struct submit_bio_ret *ret = bio->bi_private; - - ret->error = blk_status_to_errno(bio->bi_status); - complete(&ret->event); + complete(bio->bi_private); } /** @@ -943,16 +935,15 @@ static void submit_bio_wait_endio(struct bio *bio) */ int submit_bio_wait(struct bio *bio) { - struct submit_bio_ret ret; + DECLARE_COMPLETION_ONSTACK(done); - init_completion(&ret.event); - bio->bi_private = &ret; + bio->bi_private = &done; bio->bi_end_io = submit_bio_wait_endio; bio->bi_opf |= REQ_SYNC; submit_bio(bio); - wait_for_completion_io(&ret.event); + wait_for_completion_io(&done); - return ret.error; + return blk_status_to_errno(bio->bi_status); } EXPORT_SYMBOL(submit_bio_wait); -- 2.14.2 ^ permalink raw reply related [flat|nested] 50+ messages in thread
* Re: [PATCH v2 4/4] lockdep: Assign a lock_class per gendisk used for wait_for_completion() @ 2017-10-20 14:44 ` Christoph Hellwig 0 siblings, 0 replies; 50+ messages in thread From: Christoph Hellwig @ 2017-10-20 14:44 UTC (permalink / raw) To: Byungchul Park Cc: peterz, mingo, tglx, linux-kernel, linux-mm, tj, johannes.berg, oleg, amir73il, david, darrick.wong, linux-xfs, linux-fsdevel, linux-block, hch, idryomov, kernel-team The Subject prefix for this should be "block:". > @@ -945,7 +945,7 @@ int submit_bio_wait(struct bio *bio) > { > struct submit_bio_ret ret; > > - init_completion(&ret.event); > + init_completion_with_map(&ret.event, &bio->bi_disk->lockdep_map); FYI, I have an outstanding patch to simplify this a lot, which switches this to DECLARE_COMPLETION_ONSTACK. I can delay this or let you pick it up with your series, but we'll need a variant of DECLARE_COMPLETION_ONSTACK with the lockdep annotations. Patch below for reference: --- ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v2 4/4] lockdep: Assign a lock_class per gendisk used for wait_for_completion() @ 2017-10-20 14:44 ` Christoph Hellwig 0 siblings, 0 replies; 50+ messages in thread From: Christoph Hellwig @ 2017-10-20 14:44 UTC (permalink / raw) To: Byungchul Park Cc: peterz, mingo, tglx, linux-kernel, linux-mm, tj, johannes.berg, oleg, amir73il, david, darrick.wong, linux-xfs, linux-fsdevel, linux-block, hch, idryomov, kernel-team The Subject prefix for this should be "block:". > @@ -945,7 +945,7 @@ int submit_bio_wait(struct bio *bio) > { > struct submit_bio_ret ret; > > - init_completion(&ret.event); > + init_completion_with_map(&ret.event, &bio->bi_disk->lockdep_map); FYI, I have an outstanding patch to simplify this a lot, which switches this to DECLARE_COMPLETION_ONSTACK. I can delay this or let you pick it up with your series, but we'll need a variant of DECLARE_COMPLETION_ONSTACK with the lockdep annotations. Patch below for reference: --- >From d65b89843c9f82c0744643515ba51dd10e66e67b Mon Sep 17 00:00:00 2001 From: Christoph Hellwig <hch@lst.de> Date: Thu, 5 Oct 2017 18:31:02 +0200 Subject: block: use DECLARE_COMPLETION_ONSTACK in submit_bio_wait Simplify the code by getting rid of the submit_bio_ret structure. Signed-off-by: Christoph Hellwig <hch@lst.de> --- block/bio.c | 19 +++++-------------- 1 file changed, 5 insertions(+), 14 deletions(-) diff --git a/block/bio.c b/block/bio.c index 8338304ea256..4e18e959fc0a 100644 --- a/block/bio.c +++ b/block/bio.c @@ -917,17 +917,9 @@ int bio_iov_iter_get_pages(struct bio *bio, struct iov_iter *iter) } EXPORT_SYMBOL_GPL(bio_iov_iter_get_pages); -struct submit_bio_ret { - struct completion event; - int error; -}; - static void submit_bio_wait_endio(struct bio *bio) { - struct submit_bio_ret *ret = bio->bi_private; - - ret->error = blk_status_to_errno(bio->bi_status); - complete(&ret->event); + complete(bio->bi_private); } /** @@ -943,16 +935,15 @@ static void submit_bio_wait_endio(struct bio *bio) */ int submit_bio_wait(struct bio *bio) { - struct submit_bio_ret ret; + DECLARE_COMPLETION_ONSTACK(done); - init_completion(&ret.event); - bio->bi_private = &ret; + bio->bi_private = &done; bio->bi_end_io = submit_bio_wait_endio; bio->bi_opf |= REQ_SYNC; submit_bio(bio); - wait_for_completion_io(&ret.event); + wait_for_completion_io(&done); - return ret.error; + return blk_status_to_errno(bio->bi_status); } EXPORT_SYMBOL(submit_bio_wait); -- 2.14.2 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply related [flat|nested] 50+ messages in thread
* Re: [PATCH v2 4/4] lockdep: Assign a lock_class per gendisk used for wait_for_completion() 2017-10-20 14:44 ` Christoph Hellwig @ 2017-10-22 23:53 ` Byungchul Park -1 siblings, 0 replies; 50+ messages in thread From: Byungchul Park @ 2017-10-22 23:53 UTC (permalink / raw) To: Christoph Hellwig Cc: peterz, mingo, tglx, linux-kernel, linux-mm, tj, johannes.berg, oleg, amir73il, david, darrick.wong, linux-xfs, linux-fsdevel, linux-block, idryomov, kernel-team On Fri, Oct 20, 2017 at 07:44:51AM -0700, Christoph Hellwig wrote: > The Subject prefix for this should be "block:". > > > @@ -945,7 +945,7 @@ int submit_bio_wait(struct bio *bio) > > { > > struct submit_bio_ret ret; > > > > - init_completion(&ret.event); > > + init_completion_with_map(&ret.event, &bio->bi_disk->lockdep_map); > > FYI, I have an outstanding patch to simplify this a lot, which > switches this to DECLARE_COMPLETION_ONSTACK. I can delay this or let > you pick it up with your series, but we'll need a variant of > DECLARE_COMPLETION_ONSTACK with the lockdep annotations. Hello, I'm sorry for late. I think your patch makes block code simpler and better. I like it. But, I just wonder if it's related to my series. Is it proper to add your patch into my series? Thanks, Byungchul > Patch below for reference: > > --- > >From d65b89843c9f82c0744643515ba51dd10e66e67b Mon Sep 17 00:00:00 2001 > From: Christoph Hellwig <hch@lst.de> > Date: Thu, 5 Oct 2017 18:31:02 +0200 > Subject: block: use DECLARE_COMPLETION_ONSTACK in submit_bio_wait > > Simplify the code by getting rid of the submit_bio_ret structure. > > Signed-off-by: Christoph Hellwig <hch@lst.de> > --- > block/bio.c | 19 +++++-------------- > 1 file changed, 5 insertions(+), 14 deletions(-) > > diff --git a/block/bio.c b/block/bio.c > index 8338304ea256..4e18e959fc0a 100644 > --- a/block/bio.c > +++ b/block/bio.c > @@ -917,17 +917,9 @@ int bio_iov_iter_get_pages(struct bio *bio, struct iov_iter *iter) > } > EXPORT_SYMBOL_GPL(bio_iov_iter_get_pages); > > -struct submit_bio_ret { > - struct completion event; > - int error; > -}; > - > static void submit_bio_wait_endio(struct bio *bio) > { > - struct submit_bio_ret *ret = bio->bi_private; > - > - ret->error = blk_status_to_errno(bio->bi_status); > - complete(&ret->event); > + complete(bio->bi_private); > } > > /** > @@ -943,16 +935,15 @@ static void submit_bio_wait_endio(struct bio *bio) > */ > int submit_bio_wait(struct bio *bio) > { > - struct submit_bio_ret ret; > + DECLARE_COMPLETION_ONSTACK(done); > > - init_completion(&ret.event); > - bio->bi_private = &ret; > + bio->bi_private = &done; > bio->bi_end_io = submit_bio_wait_endio; > bio->bi_opf |= REQ_SYNC; > submit_bio(bio); > - wait_for_completion_io(&ret.event); > + wait_for_completion_io(&done); > > - return ret.error; > + return blk_status_to_errno(bio->bi_status); > } > EXPORT_SYMBOL(submit_bio_wait); > > -- > 2.14.2 ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v2 4/4] lockdep: Assign a lock_class per gendisk used for wait_for_completion() @ 2017-10-22 23:53 ` Byungchul Park 0 siblings, 0 replies; 50+ messages in thread From: Byungchul Park @ 2017-10-22 23:53 UTC (permalink / raw) To: Christoph Hellwig Cc: peterz, mingo, tglx, linux-kernel, linux-mm, tj, johannes.berg, oleg, amir73il, david, darrick.wong, linux-xfs, linux-fsdevel, linux-block, idryomov, kernel-team On Fri, Oct 20, 2017 at 07:44:51AM -0700, Christoph Hellwig wrote: > The Subject prefix for this should be "block:". > > > @@ -945,7 +945,7 @@ int submit_bio_wait(struct bio *bio) > > { > > struct submit_bio_ret ret; > > > > - init_completion(&ret.event); > > + init_completion_with_map(&ret.event, &bio->bi_disk->lockdep_map); > > FYI, I have an outstanding patch to simplify this a lot, which > switches this to DECLARE_COMPLETION_ONSTACK. I can delay this or let > you pick it up with your series, but we'll need a variant of > DECLARE_COMPLETION_ONSTACK with the lockdep annotations. Hello, I'm sorry for late. I think your patch makes block code simpler and better. I like it. But, I just wonder if it's related to my series. Is it proper to add your patch into my series? Thanks, Byungchul > Patch below for reference: > > --- > >From d65b89843c9f82c0744643515ba51dd10e66e67b Mon Sep 17 00:00:00 2001 > From: Christoph Hellwig <hch@lst.de> > Date: Thu, 5 Oct 2017 18:31:02 +0200 > Subject: block: use DECLARE_COMPLETION_ONSTACK in submit_bio_wait > > Simplify the code by getting rid of the submit_bio_ret structure. > > Signed-off-by: Christoph Hellwig <hch@lst.de> > --- > block/bio.c | 19 +++++-------------- > 1 file changed, 5 insertions(+), 14 deletions(-) > > diff --git a/block/bio.c b/block/bio.c > index 8338304ea256..4e18e959fc0a 100644 > --- a/block/bio.c > +++ b/block/bio.c > @@ -917,17 +917,9 @@ int bio_iov_iter_get_pages(struct bio *bio, struct iov_iter *iter) > } > EXPORT_SYMBOL_GPL(bio_iov_iter_get_pages); > > -struct submit_bio_ret { > - struct completion event; > - int error; > -}; > - > static void submit_bio_wait_endio(struct bio *bio) > { > - struct submit_bio_ret *ret = bio->bi_private; > - > - ret->error = blk_status_to_errno(bio->bi_status); > - complete(&ret->event); > + complete(bio->bi_private); > } > > /** > @@ -943,16 +935,15 @@ static void submit_bio_wait_endio(struct bio *bio) > */ > int submit_bio_wait(struct bio *bio) > { > - struct submit_bio_ret ret; > + DECLARE_COMPLETION_ONSTACK(done); > > - init_completion(&ret.event); > - bio->bi_private = &ret; > + bio->bi_private = &done; > bio->bi_end_io = submit_bio_wait_endio; > bio->bi_opf |= REQ_SYNC; > submit_bio(bio); > - wait_for_completion_io(&ret.event); > + wait_for_completion_io(&done); > > - return ret.error; > + return blk_status_to_errno(bio->bi_status); > } > EXPORT_SYMBOL(submit_bio_wait); > > -- > 2.14.2 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v2 4/4] lockdep: Assign a lock_class per gendisk used for wait_for_completion() 2017-10-22 23:53 ` Byungchul Park @ 2017-10-23 6:36 ` Christoph Hellwig -1 siblings, 0 replies; 50+ messages in thread From: Christoph Hellwig @ 2017-10-23 6:36 UTC (permalink / raw) To: Byungchul Park Cc: Christoph Hellwig, peterz, mingo, tglx, linux-kernel, linux-mm, tj, johannes.berg, oleg, amir73il, david, darrick.wong, linux-xfs, linux-fsdevel, linux-block, idryomov, kernel-team On Mon, Oct 23, 2017 at 08:53:35AM +0900, Byungchul Park wrote: > On Fri, Oct 20, 2017 at 07:44:51AM -0700, Christoph Hellwig wrote: > > The Subject prefix for this should be "block:". > > > > > @@ -945,7 +945,7 @@ int submit_bio_wait(struct bio *bio) > > > { > > > struct submit_bio_ret ret; > > > > > > - init_completion(&ret.event); > > > + init_completion_with_map(&ret.event, &bio->bi_disk->lockdep_map); > > > > FYI, I have an outstanding patch to simplify this a lot, which > > switches this to DECLARE_COMPLETION_ONSTACK. I can delay this or let > > you pick it up with your series, but we'll need a variant of > > DECLARE_COMPLETION_ONSTACK with the lockdep annotations. > > Hello, > > I'm sorry for late. > > I think your patch makes block code simpler and better. I like it. > > But, I just wonder if it's related to my series. Because it shows that we also need a version of DECLARE_COMPLETION_ONSTACK the gets passed an explicit lockdep map. And because if it was merged through a different tree it would create a conflict. > Is it proper to add > your patch into my series? Sure. ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v2 4/4] lockdep: Assign a lock_class per gendisk used for wait_for_completion() @ 2017-10-23 6:36 ` Christoph Hellwig 0 siblings, 0 replies; 50+ messages in thread From: Christoph Hellwig @ 2017-10-23 6:36 UTC (permalink / raw) To: Byungchul Park Cc: Christoph Hellwig, peterz, mingo, tglx, linux-kernel, linux-mm, tj, johannes.berg, oleg, amir73il, david, darrick.wong, linux-xfs, linux-fsdevel, linux-block, idryomov, kernel-team On Mon, Oct 23, 2017 at 08:53:35AM +0900, Byungchul Park wrote: > On Fri, Oct 20, 2017 at 07:44:51AM -0700, Christoph Hellwig wrote: > > The Subject prefix for this should be "block:". > > > > > @@ -945,7 +945,7 @@ int submit_bio_wait(struct bio *bio) > > > { > > > struct submit_bio_ret ret; > > > > > > - init_completion(&ret.event); > > > + init_completion_with_map(&ret.event, &bio->bi_disk->lockdep_map); > > > > FYI, I have an outstanding patch to simplify this a lot, which > > switches this to DECLARE_COMPLETION_ONSTACK. I can delay this or let > > you pick it up with your series, but we'll need a variant of > > DECLARE_COMPLETION_ONSTACK with the lockdep annotations. > > Hello, > > I'm sorry for late. > > I think your patch makes block code simpler and better. I like it. > > But, I just wonder if it's related to my series. Because it shows that we also need a version of DECLARE_COMPLETION_ONSTACK the gets passed an explicit lockdep map. And because if it was merged through a different tree it would create a conflict. > Is it proper to add > your patch into my series? Sure. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v2 4/4] lockdep: Assign a lock_class per gendisk used for wait_for_completion() 2017-10-23 6:36 ` Christoph Hellwig @ 2017-10-23 7:04 ` Byungchul Park -1 siblings, 0 replies; 50+ messages in thread From: Byungchul Park @ 2017-10-23 7:04 UTC (permalink / raw) To: Christoph Hellwig Cc: peterz, mingo, tglx, linux-kernel, linux-mm, tj, johannes.berg, oleg, amir73il, david, darrick.wong, linux-xfs, linux-fsdevel, linux-block, idryomov, kernel-team On Sun, Oct 22, 2017 at 11:36:30PM -0700, Christoph Hellwig wrote: > On Mon, Oct 23, 2017 at 08:53:35AM +0900, Byungchul Park wrote: > > On Fri, Oct 20, 2017 at 07:44:51AM -0700, Christoph Hellwig wrote: > > > The Subject prefix for this should be "block:". > > > > > > > @@ -945,7 +945,7 @@ int submit_bio_wait(struct bio *bio) > > > > { > > > > struct submit_bio_ret ret; > > > > > > > > - init_completion(&ret.event); > > > > + init_completion_with_map(&ret.event, &bio->bi_disk->lockdep_map); > > > > > > FYI, I have an outstanding patch to simplify this a lot, which > > > switches this to DECLARE_COMPLETION_ONSTACK. I can delay this or let > > > you pick it up with your series, but we'll need a variant of > > > DECLARE_COMPLETION_ONSTACK with the lockdep annotations. > > > > Hello, > > > > I'm sorry for late. > > > > I think your patch makes block code simpler and better. I like it. > > > > But, I just wonder if it's related to my series. > > Because it shows that we also need a version of DECLARE_COMPLETION_ONSTACK > the gets passed an explicit lockdep map. And because if it was merged > through a different tree it would create a conflict. > > > Is it proper to add > > your patch into my series? > > Sure. I will add yours at the next spin. Thank you. BTW, to all... Any additional opinions about these patches? ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v2 4/4] lockdep: Assign a lock_class per gendisk used for wait_for_completion() @ 2017-10-23 7:04 ` Byungchul Park 0 siblings, 0 replies; 50+ messages in thread From: Byungchul Park @ 2017-10-23 7:04 UTC (permalink / raw) To: Christoph Hellwig Cc: peterz, mingo, tglx, linux-kernel, linux-mm, tj, johannes.berg, oleg, amir73il, david, darrick.wong, linux-xfs, linux-fsdevel, linux-block, idryomov, kernel-team On Sun, Oct 22, 2017 at 11:36:30PM -0700, Christoph Hellwig wrote: > On Mon, Oct 23, 2017 at 08:53:35AM +0900, Byungchul Park wrote: > > On Fri, Oct 20, 2017 at 07:44:51AM -0700, Christoph Hellwig wrote: > > > The Subject prefix for this should be "block:". > > > > > > > @@ -945,7 +945,7 @@ int submit_bio_wait(struct bio *bio) > > > > { > > > > struct submit_bio_ret ret; > > > > > > > > - init_completion(&ret.event); > > > > + init_completion_with_map(&ret.event, &bio->bi_disk->lockdep_map); > > > > > > FYI, I have an outstanding patch to simplify this a lot, which > > > switches this to DECLARE_COMPLETION_ONSTACK. I can delay this or let > > > you pick it up with your series, but we'll need a variant of > > > DECLARE_COMPLETION_ONSTACK with the lockdep annotations. > > > > Hello, > > > > I'm sorry for late. > > > > I think your patch makes block code simpler and better. I like it. > > > > But, I just wonder if it's related to my series. > > Because it shows that we also need a version of DECLARE_COMPLETION_ONSTACK > the gets passed an explicit lockdep map. And because if it was merged > through a different tree it would create a conflict. > > > Is it proper to add > > your patch into my series? > > Sure. I will add yours at the next spin. Thank you. BTW, to all... Any additional opinions about these patches? -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v2 4/4] lockdep: Assign a lock_class per gendisk used for wait_for_completion() 2017-10-19 7:03 ` Byungchul Park (?) (?) @ 2017-10-21 19:17 ` kbuild test robot -1 siblings, 0 replies; 50+ messages in thread From: kbuild test robot @ 2017-10-21 19:17 UTC (permalink / raw) To: Byungchul Park Cc: kbuild-all, peterz, mingo, tglx, linux-kernel, linux-mm, tj, johannes.berg, oleg, amir73il, david, darrick.wong, linux-xfs, linux-fsdevel, linux-block, hch, idryomov, kernel-team [-- Attachment #1: Type: text/plain, Size: 2900 bytes --] Hi Byungchul, [auto build test ERROR on linus/master] [also build test ERROR on v4.14-rc5 next-20171018] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Byungchul-Park/Fix-false-positives-by-cross-release-feature/20171022-022121 config: i386-randconfig-x002-201743 (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: # save the attached .config to linux build tree make ARCH=i386 All errors (new ones prefixed by >>): block/genhd.c: In function '__alloc_disk_node': >> block/genhd.c:1407:24: error: 'struct gendisk' has no member named 'lockdep_map' lockdep_init_map(&disk->lockdep_map, lock_name, key, 0); ^~ vim +1407 block/genhd.c 1356 1357 struct gendisk *__alloc_disk_node(int minors, int node_id, struct lock_class_key *key, const char *lock_name) 1358 { 1359 struct gendisk *disk; 1360 struct disk_part_tbl *ptbl; 1361 1362 if (minors > DISK_MAX_PARTS) { 1363 printk(KERN_ERR 1364 "block: can't allocated more than %d partitions\n", 1365 DISK_MAX_PARTS); 1366 minors = DISK_MAX_PARTS; 1367 } 1368 1369 disk = kzalloc_node(sizeof(struct gendisk), GFP_KERNEL, node_id); 1370 if (disk) { 1371 if (!init_part_stats(&disk->part0)) { 1372 kfree(disk); 1373 return NULL; 1374 } 1375 disk->node_id = node_id; 1376 if (disk_expand_part_tbl(disk, 0)) { 1377 free_part_stats(&disk->part0); 1378 kfree(disk); 1379 return NULL; 1380 } 1381 ptbl = rcu_dereference_protected(disk->part_tbl, 1); 1382 rcu_assign_pointer(ptbl->part[0], &disk->part0); 1383 1384 /* 1385 * set_capacity() and get_capacity() currently don't use 1386 * seqcounter to read/update the part0->nr_sects. Still init 1387 * the counter as we can read the sectors in IO submission 1388 * patch using seqence counters. 1389 * 1390 * TODO: Ideally set_capacity() and get_capacity() should be 1391 * converted to make use of bd_mutex and sequence counters. 1392 */ 1393 seqcount_init(&disk->part0.nr_sects_seq); 1394 if (hd_ref_init(&disk->part0)) { 1395 hd_free_part(&disk->part0); 1396 kfree(disk); 1397 return NULL; 1398 } 1399 1400 disk->minors = minors; 1401 rand_initialize_disk(disk); 1402 disk_to_dev(disk)->class = &block_class; 1403 disk_to_dev(disk)->type = &disk_type; 1404 device_initialize(disk_to_dev(disk)); 1405 } 1406 > 1407 lockdep_init_map(&disk->lockdep_map, lock_name, key, 0); 1408 1409 return disk; 1410 } 1411 EXPORT_SYMBOL(__alloc_disk_node); 1412 --- 0-DAY kernel test infrastructure Open Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation [-- Attachment #2: .config.gz --] [-- Type: application/gzip, Size: 26642 bytes --] ^ permalink raw reply [flat|nested] 50+ messages in thread
end of thread, other threads:[~2017-10-23 7:04 UTC | newest] Thread overview: 50+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-10-19 5:55 [PATCH v2 0/3] crossrelease: make it not unwind by default Byungchul Park 2017-10-19 5:55 ` Byungchul Park 2017-10-19 5:55 ` [PATCH v2 1/3] lockdep: Introduce CROSSRELEASE_STACK_TRACE and make it not unwind as default Byungchul Park 2017-10-19 5:55 ` Byungchul Park 2017-10-19 5:55 ` [PATCH v2 2/3] lockdep: Remove BROKEN flag of LOCKDEP_CROSSRELEASE Byungchul Park 2017-10-19 5:55 ` Byungchul Park 2017-10-19 15:05 ` Bart Van Assche 2017-10-19 15:05 ` Bart Van Assche 2017-10-19 15:34 ` Thomas Gleixner 2017-10-19 15:34 ` Thomas Gleixner 2017-10-19 15:47 ` Bart Van Assche 2017-10-19 19:04 ` Thomas Gleixner 2017-10-19 19:04 ` Thomas Gleixner 2017-10-19 19:12 ` Thomas Gleixner 2017-10-19 19:12 ` Thomas Gleixner 2017-10-19 20:21 ` Bart Van Assche 2017-10-19 20:21 ` Bart Van Assche 2017-10-19 20:33 ` Matthew Wilcox 2017-10-19 20:33 ` Matthew Wilcox 2017-10-19 20:41 ` Bart Van Assche 2017-10-19 20:53 ` Thomas Gleixner 2017-10-19 20:53 ` Thomas Gleixner 2017-10-19 20:49 ` Thomas Gleixner 2017-10-19 20:49 ` Thomas Gleixner 2017-10-20 7:30 ` Ingo Molnar 2017-10-20 7:30 ` Ingo Molnar 2017-10-20 6:03 ` Byungchul Park 2017-10-20 6:03 ` Byungchul Park 2017-10-19 5:55 ` [PATCH v2 3/3] lockdep: Add a kernel parameter, crossrelease_fullstack Byungchul Park 2017-10-19 5:55 ` Byungchul Park 2017-10-19 7:03 ` [PATCH v2 0/4] Fix false positives by cross-release feature Byungchul Park 2017-10-19 7:03 ` Byungchul Park 2017-10-19 7:03 ` [PATCH v2 1/4] completion: Add support for initializing completion with lockdep_map Byungchul Park 2017-10-19 7:03 ` Byungchul Park 2017-10-19 7:03 ` [PATCH v2 2/4] lockdep: Remove unnecessary acquisitions wrt workqueue flush Byungchul Park 2017-10-19 7:03 ` Byungchul Park 2017-10-19 7:03 ` [PATCH v2 3/4] genhd.h: Remove trailing white space Byungchul Park 2017-10-19 7:03 ` Byungchul Park 2017-10-19 7:03 ` [PATCH v2 4/4] lockdep: Assign a lock_class per gendisk used for wait_for_completion() Byungchul Park 2017-10-19 7:03 ` Byungchul Park 2017-10-20 14:44 ` Christoph Hellwig 2017-10-20 14:44 ` Christoph Hellwig 2017-10-20 14:44 ` Christoph Hellwig 2017-10-22 23:53 ` Byungchul Park 2017-10-22 23:53 ` Byungchul Park 2017-10-23 6:36 ` Christoph Hellwig 2017-10-23 6:36 ` Christoph Hellwig 2017-10-23 7:04 ` Byungchul Park 2017-10-23 7:04 ` Byungchul Park 2017-10-21 19:17 ` kbuild test robot
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.