public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [BUG] kernel: locking: a possible sleep-in-atomic-context bug in rt_mutex_slowlock()
@ 2018-06-21  3:14 Jia-Ju Bai
  2018-06-21  7:36 ` Peter Zijlstra
  0 siblings, 1 reply; 2+ messages in thread
From: Jia-Ju Bai @ 2018-06-21  3:14 UTC (permalink / raw)
  To: peterz, mingo; +Cc: Linux Kernel Mailing List

The kernel may sleep with holding a spinlock.
The function call path (from bottom to top) in Linux-4.16.7 is:

[FUNC] schedule
kernel/locking/rtmutex.c, 1223: schedule in rt_mutex_handle_deadlock
kernel/locking/rtmutex.c, 1273: rt_mutex_handle_deadlock in 
rt_mutex_slowlock
kernel/locking/rtmutex.c, 1249: _raw_spin_lock_irqsave in rt_mutex_slowlock

This bug is found by my static analysis tool (DSAC-2) and checked by my
code review.

I do not know how to correctly fix this bug, so I just report them.


Best wishes,
Jia-Ju Bai

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

* Re: [BUG] kernel: locking: a possible sleep-in-atomic-context bug in rt_mutex_slowlock()
  2018-06-21  3:14 [BUG] kernel: locking: a possible sleep-in-atomic-context bug in rt_mutex_slowlock() Jia-Ju Bai
@ 2018-06-21  7:36 ` Peter Zijlstra
  0 siblings, 0 replies; 2+ messages in thread
From: Peter Zijlstra @ 2018-06-21  7:36 UTC (permalink / raw)
  To: Jia-Ju Bai; +Cc: mingo, Linux Kernel Mailing List, Thomas Gleixner

On Thu, Jun 21, 2018 at 11:14:49AM +0800, Jia-Ju Bai wrote:
> The kernel may sleep with holding a spinlock.
> The function call path (from bottom to top) in Linux-4.16.7 is:
> 
> [FUNC] schedule
> kernel/locking/rtmutex.c, 1223: schedule in rt_mutex_handle_deadlock
> kernel/locking/rtmutex.c, 1273: rt_mutex_handle_deadlock in
> rt_mutex_slowlock
> kernel/locking/rtmutex.c, 1249: _raw_spin_lock_irqsave in rt_mutex_slowlock
> 
> This bug is found by my static analysis tool (DSAC-2) and checked by my
> code review.
> 
> I do not know how to correctly fix this bug, so I just report them.

I think the below will do. The purpose seems to be to take out the task
when we cannot return -EDEADLOCK to userspace. And it can do so just
fine after we unlock the wait_lock.

Thomas?

---
 kernel/locking/rtmutex.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c
index 4f014be7a4b8..d33446a05681 100644
--- a/kernel/locking/rtmutex.c
+++ b/kernel/locking/rtmutex.c
@@ -1269,7 +1269,6 @@ rt_mutex_slowlock(struct rt_mutex *lock, int state,
 	if (unlikely(ret)) {
 		__set_current_state(TASK_RUNNING);
 		remove_waiter(lock, &waiter);
-		rt_mutex_handle_deadlock(ret, chwalk, &waiter);
 	}
 
 	/*
@@ -1280,6 +1279,8 @@ rt_mutex_slowlock(struct rt_mutex *lock, int state,
 
 	raw_spin_unlock_irqrestore(&lock->wait_lock, flags);
 
+	rt_mutex_handle_deadlock(ret, chwalk, &waiter);
+
 	/* Remove pending timer: */
 	if (unlikely(timeout))
 		hrtimer_cancel(&timeout->timer);


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

end of thread, other threads:[~2018-06-21  7:36 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-06-21  3:14 [BUG] kernel: locking: a possible sleep-in-atomic-context bug in rt_mutex_slowlock() Jia-Ju Bai
2018-06-21  7:36 ` Peter Zijlstra

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox