All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH -tip] locking/mutex: Complain upon api misuse wrt interrupt context
@ 2019-10-25  3:36 Davidlohr Bueso
  2019-10-25  8:10 ` Peter Zijlstra
  2019-10-30 10:03 ` [tip: locking/core] locking/mutex: Complain upon mutex API misuse in IRQ contexts tip-bot2 for Davidlohr Bueso
  0 siblings, 2 replies; 4+ messages in thread
From: Davidlohr Bueso @ 2019-10-25  3:36 UTC (permalink / raw)
  To: mingo; +Cc: peterz, dave, linux-kernel, Davidlohr Bueso

Sprinkle warning checks, under CONFIG_DEBUG_MUTEXES. While the mutex
rules and semantics are explicitly documented, this allows to expose
any abusers and robustifies the whole thing. While trylock and unlock
are non-blocking, calling from irq context is still forbidden (lock
must be within the same context as unlock).

Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
---
 kernel/locking/mutex.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
index 468a9b8422e3..7e9c316c646c 100644
--- a/kernel/locking/mutex.c
+++ b/kernel/locking/mutex.c
@@ -733,6 +733,9 @@ static noinline void __sched __mutex_unlock_slowpath(struct mutex *lock, unsigne
  */
 void __sched mutex_unlock(struct mutex *lock)
 {
+#ifdef CONFIG_DEBUG_MUTEXES
+	WARN_ON(in_interrupt());
+#endif
 #ifndef CONFIG_DEBUG_LOCK_ALLOC
 	if (__mutex_unlock_fast(lock))
 		return;
@@ -1413,6 +1416,7 @@ int __sched mutex_trylock(struct mutex *lock)
 
 #ifdef CONFIG_DEBUG_MUTEXES
 	DEBUG_LOCKS_WARN_ON(lock->magic != lock);
+	WARN_ON(in_interrupt());
 #endif
 
 	locked = __mutex_trylock(lock);
-- 
2.16.4


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH -tip] locking/mutex: Complain upon api misuse wrt interrupt context
  2019-10-25  3:36 [PATCH -tip] locking/mutex: Complain upon api misuse wrt interrupt context Davidlohr Bueso
@ 2019-10-25  8:10 ` Peter Zijlstra
  2019-10-25 17:27   ` Davidlohr Bueso
  2019-10-30 10:03 ` [tip: locking/core] locking/mutex: Complain upon mutex API misuse in IRQ contexts tip-bot2 for Davidlohr Bueso
  1 sibling, 1 reply; 4+ messages in thread
From: Peter Zijlstra @ 2019-10-25  8:10 UTC (permalink / raw)
  To: Davidlohr Bueso; +Cc: mingo, linux-kernel, Davidlohr Bueso

On Thu, Oct 24, 2019 at 08:36:34PM -0700, Davidlohr Bueso wrote:
> Sprinkle warning checks, under CONFIG_DEBUG_MUTEXES. While the mutex
> rules and semantics are explicitly documented, this allows to expose
> any abusers and robustifies the whole thing. While trylock and unlock
> are non-blocking, calling from irq context is still forbidden (lock
> must be within the same context as unlock).
> 
> Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
> ---
>  kernel/locking/mutex.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
> index 468a9b8422e3..7e9c316c646c 100644
> --- a/kernel/locking/mutex.c
> +++ b/kernel/locking/mutex.c
> @@ -733,6 +733,9 @@ static noinline void __sched __mutex_unlock_slowpath(struct mutex *lock, unsigne
>   */
>  void __sched mutex_unlock(struct mutex *lock)
>  {
> +#ifdef CONFIG_DEBUG_MUTEXES
> +	WARN_ON(in_interrupt());
> +#endif
>  #ifndef CONFIG_DEBUG_LOCK_ALLOC
>  	if (__mutex_unlock_fast(lock))
>  		return;
> @@ -1413,6 +1416,7 @@ int __sched mutex_trylock(struct mutex *lock)
>  
>  #ifdef CONFIG_DEBUG_MUTEXES
>  	DEBUG_LOCKS_WARN_ON(lock->magic != lock);
> +	WARN_ON(in_interrupt());
>  #endif
>  
>  	locked = __mutex_trylock(lock);


No real objection, but should not lockdep already complain about this?
__mutex_unlock_slowpath() takes ->wait_lock irq-unsafe, so then using it
from an IRQ should generate an insta IRQ inversion report.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH -tip] locking/mutex: Complain upon api misuse wrt interrupt context
  2019-10-25  8:10 ` Peter Zijlstra
@ 2019-10-25 17:27   ` Davidlohr Bueso
  0 siblings, 0 replies; 4+ messages in thread
From: Davidlohr Bueso @ 2019-10-25 17:27 UTC (permalink / raw)
  To: Peter Zijlstra; +Cc: mingo, linux-kernel, Davidlohr Bueso

On Fri, 25 Oct 2019, Peter Zijlstra wrote:
>No real objection, but should not lockdep already complain about this?
>__mutex_unlock_slowpath() takes ->wait_lock irq-unsafe, so then using it
>from an IRQ should generate an insta IRQ inversion report.

But we still have the unlock fastpath and the trylock scenarios which
don't take locks.

Thanks,
davidlohr

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [tip: locking/core] locking/mutex: Complain upon mutex API misuse in IRQ contexts
  2019-10-25  3:36 [PATCH -tip] locking/mutex: Complain upon api misuse wrt interrupt context Davidlohr Bueso
  2019-10-25  8:10 ` Peter Zijlstra
@ 2019-10-30 10:03 ` tip-bot2 for Davidlohr Bueso
  1 sibling, 0 replies; 4+ messages in thread
From: tip-bot2 for Davidlohr Bueso @ 2019-10-30 10:03 UTC (permalink / raw)
  To: linux-tip-commits
  Cc: Davidlohr Bueso, Peter Zijlstra (Intel),
	Linus Torvalds, Thomas Gleixner, dave, Ingo Molnar,
	Borislav Petkov, linux-kernel

The following commit has been merged into the locking/core branch of tip:

Commit-ID:     a0855d24fc22d49cdc25664fb224caee16998683
Gitweb:        https://git.kernel.org/tip/a0855d24fc22d49cdc25664fb224caee16998683
Author:        Davidlohr Bueso <dave@stgolabs.net>
AuthorDate:    Thu, 24 Oct 2019 20:36:34 -07:00
Committer:     Ingo Molnar <mingo@kernel.org>
CommitterDate: Tue, 29 Oct 2019 12:22:52 +01:00

locking/mutex: Complain upon mutex API misuse in IRQ contexts

Add warning checks if mutex_trylock() or mutex_unlock() are used in
IRQ contexts, under CONFIG_DEBUG_MUTEXES=y.

While the mutex rules and semantics are explicitly documented, this allows
to expose any abusers and robustifies the whole thing.

While trylock and unlock are non-blocking, calling from IRQ context
is still forbidden (lock must be within the same context as unlock).

Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: dave@stgolabs.net
Link: https://lkml.kernel.org/r/20191025033634.3330-1-dave@stgolabs.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 kernel/locking/mutex.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
index 5352ce5..54cc5f9 100644
--- a/kernel/locking/mutex.c
+++ b/kernel/locking/mutex.c
@@ -733,6 +733,9 @@ static noinline void __sched __mutex_unlock_slowpath(struct mutex *lock, unsigne
  */
 void __sched mutex_unlock(struct mutex *lock)
 {
+#ifdef CONFIG_DEBUG_MUTEXES
+	WARN_ON(in_interrupt());
+#endif
 #ifndef CONFIG_DEBUG_LOCK_ALLOC
 	if (__mutex_unlock_fast(lock))
 		return;
@@ -1413,6 +1416,7 @@ int __sched mutex_trylock(struct mutex *lock)
 
 #ifdef CONFIG_DEBUG_MUTEXES
 	DEBUG_LOCKS_WARN_ON(lock->magic != lock);
+	WARN_ON(in_interrupt());
 #endif
 
 	locked = __mutex_trylock(lock);

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2019-10-30 10:04 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-10-25  3:36 [PATCH -tip] locking/mutex: Complain upon api misuse wrt interrupt context Davidlohr Bueso
2019-10-25  8:10 ` Peter Zijlstra
2019-10-25 17:27   ` Davidlohr Bueso
2019-10-30 10:03 ` [tip: locking/core] locking/mutex: Complain upon mutex API misuse in IRQ contexts tip-bot2 for Davidlohr Bueso

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.