linux_dsm_epyc7002/drivers/mmc/card
Rabin Vincent a8c27c0bea mmc: queue: prevent soft lockups on PREEMPT=n
On systems with CONFIG_PREEMPT=n, under certain circumstances, mmcqd
can continuously process requests for several seconds without blocking,
triggering the soft lockup watchdog.  For example, this can happen if
mmcqd runs on the CPU which services the controller's interrupt, and
a process on a different CPU continuously writes to the MMC block
device.

 NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [mmcqd/0:664]
 CPU: 0 PID: 664 Comm: mmcqd/0 Not tainted 4.1.0-rc7+ #4
 PC is at _raw_spin_unlock_irqrestore+0x24/0x28
 LR is at mmc_start_request+0x104/0x134
 ...
 [<805112a8>] (_raw_spin_unlock_irqrestore) from [<803db664>] (mmc_start_request+0x104/0x134)
 [<803db664>] (mmc_start_request) from [<803dc008>] (mmc_start_req+0x274/0x394)
 [<803dc008>] (mmc_start_req) from [<803eb2c4>] (mmc_blk_issue_rw_rq+0xd0/0xb98)
 [<803eb2c4>] (mmc_blk_issue_rw_rq) from [<803ebe8c>] (mmc_blk_issue_rq+0x100/0x470)
 [<803ebe8c>] (mmc_blk_issue_rq) from [<803ecab8>] (mmc_queue_thread+0xd0/0x170)
 [<803ecab8>] (mmc_queue_thread) from [<8003fd14>] (kthread+0xe0/0xfc)
 [<8003fd14>] (kthread) from [<8000f768>] (ret_from_fork+0x14/0x2c)

Fix it by adding a cond_resched() in the request handling loop so that
other processes get a chance to run.

Signed-off-by: Rabin Vincent <rabin.vincent@axis.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2015-06-18 09:21:04 +02:00
..
block.c mmc: card: Fixup request missing in mmc_blk_issue_rw_rq 2015-06-16 08:58:36 +02:00
Kconfig tty: Added a CONFIG_TTY option to allow removal of TTY 2013-01-18 16:15:27 -08:00
Makefile mmc: Makefile: Fix EXTRA_CFLAGS assignment 2010-10-23 21:11:15 +08:00
mmc_test.c mmc: mmc-test: use swap() in mmc_test_nonblock_transfer() 2015-06-01 09:07:08 +02:00
queue.c mmc: queue: prevent soft lockups on PREEMPT=n 2015-06-18 09:21:04 +02:00
queue.h mmc: block: Retry errored data requests when re-tuning is needed 2015-06-01 09:06:59 +02:00
sdio_uart.c mmc: Convert pr_warning to pr_warn 2014-09-24 10:13:09 +02:00