[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20180621073629.GP2494@hirez.programming.kicks-ass.net>
Date: Thu, 21 Jun 2018 09:36:29 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Jia-Ju Bai <baijiaju1990@...il.com>
Cc: mingo@...hat.com,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [BUG] kernel: locking: a possible sleep-in-atomic-context bug in
rt_mutex_slowlock()
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);
Powered by blists - more mailing lists