[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-id: <000a01cecf8b$ab6c0530$02440f90$%jun@samsung.com>
Date: Wed, 23 Oct 2013 10:03:21 +0900
From: Seungwon Jeon <tgih.jun@...sung.com>
To: 'Ray Jui' <rjui@...adcom.com>, 'Chris Ball' <cjb@...top.org>
Cc: linux-kernel@...r.kernel.org
Subject: RE: MMC request with REQ_DISCARD option may not release host when it
should
Hi Ray,
Thank you for information. Your analysis is right.
I also noticed same problem.
If you'd like to submit patch, not to report, please send it with regular form.
Or I could send similar patch I have.
Thanks,
Seungwon Jeon
On Wed, Oct 23, 2013, Ray Jui wrote:
Hi Seungwon/Chris,
We recently came across an eMMC issue that causes mmc_suspend to stuck waiting to claim the host. This issue only happens when one
of the MMC partitions is mounted with the discard option. By tracing the issue down in the kernel MMC stack, in the function
mmc_blk_issue_rq under drivers/mmc/card/block.c, we noticed the host will be released when req is valid and when req->cmd_flags is
set to one of the masks: MMC_REQ_SPECIAL_MASK. Based on the code comment, I believe the intention is to always release the host in
the case of special request (which include both REQ_DISCARD and REQ_FLUSH).
Note in function call mmc_blk_issue_discard_rq, the memory where req points to can be freed. This means at the bottom of the
mmc_blk_issue_rq, req->cmd_flags may contain garbage value and I believe this is what’s causing the issue that we are seeing in
mmc_suspend after the discard operation: In mmc_suspend, it blocks waiting to claim the host but the host was never released after
the discard operation.
Please help to review the attached patch that fixes the issue.
Thanks,
Ray Jui
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists