On 12/04/18 03:43, Shawn Lin wrote:
> On 2018/4/11 18:26, Adrian Hunter wrote:
>> On 11/04/18 12:13, Shawn Lin wrote:
>>> On 2018/4/11 16:46, Adrian Hunter wrote:
>>>> On 11/04/18 10:24, Shawn Lin wrote:
>>>>> A simply continueous background I/O could 100% make the system stuck for
>>>>> a long time in my system when a unbind for the controller driver happens
>>>>> simultaneously. See:
>>>>>
>>>>> dd if=/dev/mmcblk0 of=/dev/null bs=512k count=100000 &&
>>>>> echo fe320000.dwmmc > /sys/bus/platform/drivers/dwmmc_rockchip/unbind
>>>>>
>>>>> The reason is all pending requests wait for timeout one by one, but never
>>>>> propagates BLK_STS_IOERR in the first place when kicked from the queue.
>>>>> Set the card as removed immediately in mmc_remove_card() to solve it.
>>>>>
>>>>> Signed-off-by: Shawn Lin <shawn.lin@xxxxxxxxxxxxxx>
>>>>> ---
>>>>>
>>>>> drivers/mmc/core/bus.c | 1 +
>>>>> 1 file changed, 1 insertion(+)
>>>>>
>>>>> diff --git a/drivers/mmc/core/bus.c b/drivers/mmc/core/bus.c
>>>>> index fc92c6c..c6c5dfe 100644
>>>>> --- a/drivers/mmc/core/bus.c
>>>>> +++ b/drivers/mmc/core/bus.c
>>>>> @@ -389,6 +389,7 @@ void mmc_remove_card(struct mmc_card *card)
>>>>> pr_info("%s: card %04x removed\n",
>>>>> mmc_hostname(card->host), card->rca);
>>>>> }
>>>>> + mmc_card_set_removed(card);
>>>>
>>>> Pedantically we should not call mmc_card_set_removed() if we have not
>>>> claimed the host. Of course we can't claim the host because the block
>>>
>>> yep.
>>>
>>>> driver already has it, but I am not sure this is the right place to do
>>>> this.
>>>> My first question is how come the I/O times out if the card is still
>>>> present i.e. you are only unbinding the host controller, so you should
>>>> remove the card while the host controller and card are still functional?
>>>
>>> The card is still functional for my host(but maybe not if ->remove()
>>> touchs the vmmc or vqmmc parts), but the host controller isn't, as the
>>> ->remove() calls.
>>
>> I don't understand why the host controller isn't functional. I tried it
>
> I guess we have misunderstanding about what the "functional" means. What
> I want to say is when unbinding the host driver, mmc_remove_host() is
> called, so the target host isn't present from the view of core layer,
> right?
>
>> with sdhci and it just waits for dd to finish but there are no I/O errors.
>>
>> Is there a use-case for unbinding quickly?
>
> Oh, I think I made a mistake in commit msg, the repro steps should be
> (1) run dd in background:
> dd if=/dev/mmcblk0 of=/dev/null bs=512k count=100000 &
> (2) unbind you driver, for instance:
> echo fe320000.dwmmc > /sys/bus/platform/drivers/dwmmc_rockchip/unbind
>
> Then yes, there is no I/O errors and it waits for dd to finish. But
> when waiting for dd to finish, console got stuck, and can't respond to
> any ctrl+{c,d,z}, even sysrq. The time depends how much I/O it submits,
> the above setp(1) make it stuck for 2 miniutes for my system.
Job control on a console might not always work, especially with busybox.
I guess if you run the unbind in the background, then there is not a problem.
Given that unbinding the host controller while it is still in use is a bad
thing, why do we care?
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
