From: Steven Rostedt <rostedt@goodmis.org>
To: linux-kernel@vger.kernel.org,
linux-rt-users <linux-rt-users@vger.kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Carsten Emde <C.Emde@osadl.org>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
John Kacur <jkacur@redhat.com>,
Paul Gortmaker <paul.gortmaker@windriver.com>,
Julia Cartwright <julia@ni.com>,
Daniel Wagner <daniel.wagner@siemens.com>,
tom.zanussi@linux.intel.com, Alex Shi <alex.shi@linaro.org>,
stable-rt@vger.kernel.org, Mikulas Patocka <mpatocka@redhat.com>
Subject: [PATCH RT 06/13] locking/rt-mutex: fix deadlock in device mapper / block-IO
Date: Wed, 17 Jan 2018 10:14:10 -0500 [thread overview]
Message-ID: <20180117151431.425437643@goodmis.org> (raw)
In-Reply-To: 20180117151404.093229667@goodmis.org
[-- Attachment #1: 0006-locking-rt-mutex-fix-deadlock-in-device-mapper-block.patch --]
[-- Type: text/plain, Size: 3198 bytes --]
3.18.91-rt98-rc1 stable review patch.
If anyone has any objections, please let me know.
------------------
From: Mikulas Patocka <mpatocka@redhat.com>
When some block device driver creates a bio and submits it to another
block device driver, the bio is added to current->bio_list (in order to
avoid unbounded recursion).
However, this queuing of bios can cause deadlocks, in order to avoid them,
device mapper registers a function flush_current_bio_list. This function
is called when device mapper driver blocks. It redirects bios queued on
current->bio_list to helper workqueues, so that these bios can proceed
even if the driver is blocked.
The problem with CONFIG_PREEMPT_RT_FULL is that when the device mapper
driver blocks, it won't call flush_current_bio_list (because
tsk_is_pi_blocked returns true in sched_submit_work), so deadlocks in
block device stack can happen.
Note that we can't call blk_schedule_flush_plug if tsk_is_pi_blocked
returns true - that would cause
BUG_ON(rt_mutex_real_waiter(task->pi_blocked_on)) in
task_blocks_on_rt_mutex when flush_current_bio_list attempts to take a
spinlock.
So the proper fix is to call blk_schedule_flush_plug in rt_mutex_fastlock,
when fast acquire failed and when the task is about to block.
CC: stable-rt@vger.kernel.org
[bigeasy: The deadlock is not device-mapper specific, it can also occur
in plain EXT4]
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
---
kernel/locking/rtmutex.c | 25 ++++++++++++++++++++-----
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c
index da35f7ef5324..d58780b59583 100644
--- a/kernel/locking/rtmutex.c
+++ b/kernel/locking/rtmutex.c
@@ -22,6 +22,7 @@
#include <linux/sched/deadline.h>
#include <linux/timer.h>
#include <linux/ww_mutex.h>
+#include <linux/blkdev.h>
#include "rtmutex_common.h"
@@ -1843,9 +1844,19 @@ rt_mutex_fastlock(struct rt_mutex *lock, int state,
if (likely(rt_mutex_cmpxchg(lock, NULL, current))) {
rt_mutex_deadlock_account_lock(lock, current);
return 0;
- } else
- return slowfn(lock, state, NULL, RT_MUTEX_MIN_CHAINWALK,
- ww_ctx);
+ }
+
+ /*
+ * If rt_mutex blocks, the function sched_submit_work will not call
+ * blk_schedule_flush_plug (because tsk_is_pi_blocked would be true).
+ * We must call blk_schedule_flush_plug here, if we don't call it,
+ * a deadlock in device mapper may happen.
+ */
+ if (unlikely(blk_needs_flush_plug(current)))
+ blk_schedule_flush_plug(current);
+
+ return slowfn(lock, state, NULL, RT_MUTEX_MIN_CHAINWALK,
+ ww_ctx);
}
static inline int
@@ -1862,8 +1873,12 @@ rt_mutex_timed_fastlock(struct rt_mutex *lock, int state,
likely(rt_mutex_cmpxchg(lock, NULL, current))) {
rt_mutex_deadlock_account_lock(lock, current);
return 0;
- } else
- return slowfn(lock, state, timeout, chwalk, ww_ctx);
+ }
+
+ if (unlikely(blk_needs_flush_plug(current)))
+ blk_schedule_flush_plug(current);
+
+ return slowfn(lock, state, timeout, chwalk, ww_ctx);
}
static inline int
--
2.13.2
next prev parent reply other threads:[~2018-01-17 15:14 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-17 15:14 [PATCH RT 00/13] Linux 3.18.91-rt98-rc1 Steven Rostedt
2018-01-17 15:14 ` [PATCH RT 01/13] rtmutex: Make lock_killable work Steven Rostedt
2018-01-17 15:14 ` [PATCH RT 02/13] random: avoid preempt_disable()ed section Steven Rostedt
2018-01-17 15:14 ` [PATCH RT 03/13] sched: Prevent task state corruption by spurious lock wakeup Steven Rostedt
2018-01-17 15:14 ` [PATCH RT 04/13] fs: convert two more BH_Uptodate_Lock related bitspinlocks Steven Rostedt
2018-01-17 15:14 ` [PATCH RT 05/13] md/raid5: do not disable interrupts Steven Rostedt
2018-01-17 15:14 ` Steven Rostedt [this message]
2018-01-17 15:14 ` [PATCH RT 07/13] Revert "fs: jbd2: pull your plug when waiting for space" Steven Rostedt
2018-01-17 15:46 ` Sebastian Andrzej Siewior
2018-01-17 17:13 ` Steven Rostedt
2018-01-17 15:14 ` [PATCH RT 08/13] cpu_pm: replace raw_notifier to atomic_notifier Steven Rostedt
2018-01-17 15:14 ` [PATCH RT 09/13] kernel/hrtimer: migrate deferred timer on CPU down Steven Rostedt
2018-01-17 15:14 ` [PATCH RT 10/13] kernel/hrtimer/hotplug: dont wake ktimersoftd while holding the hrtimer base lock Steven Rostedt
2018-01-17 15:14 ` [PATCH RT 11/13] rt/locking: allow recursive local_trylock() Steven Rostedt
2018-01-17 15:14 ` [PATCH RT 12/13] net: use trylock in icmp_sk Steven Rostedt
2018-01-17 15:14 ` [PATCH RT 13/13] Linux 3.18.91-rt98-rc1 Steven Rostedt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180117151431.425437643@goodmis.org \
--to=rostedt@goodmis.org \
--cc=C.Emde@osadl.org \
--cc=alex.shi@linaro.org \
--cc=bigeasy@linutronix.de \
--cc=daniel.wagner@siemens.com \
--cc=jkacur@redhat.com \
--cc=julia@ni.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=mpatocka@redhat.com \
--cc=paul.gortmaker@windriver.com \
--cc=stable-rt@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=tom.zanussi@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.