Re: [PATCH] mmc: card: Fixup request missing in mmc_blk_issue_rw_rq

From: Ulf Hansson
Date: Thu May 28 2015 - 04:29:28 EST


On 19 May 2015 at 08:32, Justin Wang (çä) <Justin.Wang@xxxxxxxxxxxxxx> wrote:
> From 05849da563c80c20597ab6275d5881a8ed426f96 Mon Sep 17 00:00:00 2001
> From: justin.wang <justin.wang@xxxxxxxxxxxxxx>
> Date: Mon, 18 May 2015 20:14:15 +0800
> Subject: [PATCH] mmc: card: Fixup request missing in mmc_blk_issue_rw_rq
>
> The current handler of MMC_BLK_CMD_ERR in mmc_blk_issue_rw_rq function
> may cause new coming request permanent missing when the ongoing
> request (previoulsy started) complete end.

I think you need to elaborate a bit more here. In exactly what
scenario does this problem occur?

>
> This would cause the process related to the missing request stay at 'D'
> state forever.

'D' state?

I suppose it waits for a response for its IO request. Doesn't also the
block layer complain or timeout somehow? Would be interesting to know
a bit more about what really happens when things goes wrong.

>

Seems like we should have a fixes tag here as well, could you possibly
try to find what commit that introduced this bug?

> Signed-off-by: Ding Wang <justin.wang@xxxxxxxxxxxxxx>
> ---
> drivers/mmc/card/block.c | 8 +++++---
> 1 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
> index 60f7141..f05cd1f 100644
> --- a/drivers/mmc/card/block.c
> +++ b/drivers/mmc/card/block.c
> @@ -1910,9 +1910,11 @@ static int mmc_blk_issue_rw_rq(struct mmc_queue *mq, struct request *rqc)
> break;
> case MMC_BLK_CMD_ERR:
> ret = mmc_blk_cmd_err(md, card, brq, req, ret);
> - if (!mmc_blk_reset(md, card->host, type))
> - break;
> - goto cmd_abort;
> + if (mmc_blk_reset(md, card->host, type))
> + goto cmd_abort;
> + if (!ret)
> + goto start_new_req;
> + break;
> case MMC_BLK_RETRY:
> if (retry++ < 5)
> break;
> --
> 1.7.4.1
>

Kind regards
Uffe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/