+ Jens, Christoph, Adrian, Linus On Thu, 31 Jan 2019 at 21:16, Zachary Hays <zhays@xxxxxxxxxxx> wrote: > > The kblockd workqueue is created with the WQ_MEM_RECLAIM flag set. > This generates a rescuer thread for that queue that will trigger when > the CPU is under heavy load and collect the uncompleted work. > > In the case of mmc, this creates the possibility of a deadlock as > other blk-mq is also run on the same queue. For example: > > - worker 0 claims the mmc host > - worker 1 attempts to claim the host > - worker 0 schedules complete_work to release the host > - rescuer thread is triggered after time-out and collects the dangling > work > - rescuer thread attempts to complete the work in order starting with > claim host > - the task to release host is now blocked by a task to claim it and > will never be called > > The above results in multiple hung tasks that lead to failures to boot. > > Switching complete_work to the system_highpri queue avoids this > because system_highpri is not flagged with WQ_MEM_RECLAIM. This allows > the host to be released without getting blocked by other claims tasks. > Thanks for fix and the detailed description to the problem! > Signed-off-by: Zachary Hays <zhays@xxxxxxxxxxx> > --- > drivers/mmc/core/block.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c > index aef1185f383d..59b6b41b84c6 100644 > --- a/drivers/mmc/core/block.c > +++ b/drivers/mmc/core/block.c > @@ -2112,7 +2112,7 @@ static void mmc_blk_mq_req_done(struct mmc_request *mrq) > if (waiting) > wake_up(&mq->wait); > else > - kblockd_schedule_work(&mq->complete_work); > + queue_work(system_highpri_wq, &mq->complete_work); Even if this solves the problem, I think we need some input from some of the block experts/maintainers to understand if this is the correct way to fix the problem. So, I have lopped them in. I am guessing MMC is not the only block device driver that have this kind of locking issue. Or perhaps it is.. > > return; > } > -- > 2.7.4 > Kind regards Uffe