linux-kernel - Re: [PATCH] Move the judgement of timeout into mmc_switch_status

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-id: <56809EB8.3030706@samsung.com>
Date:	Mon, 28 Dec 2015 11:30:16 +0900
From:	Jaehoon Chung <jh80.chung@...sung.com>
To:	yj84.jang@...sung.com, ulf.hansson@...aro.org,
	linux-mmc@...r.kernel.org, linux-kernel@...r.kernel.org
Cc:	demon.lee@...sung.com, js07.lee@...sung.com
Subject: Re: [PATCH] Move the judgement of timeout into
 mmc_switch_status_error()

Hi,

Did you read my comment? Which kernel version did you use?

I think your patch doesn't need on mainline kernel.
If you want to apply the patch, work on the latest kernel.

https://patchwork.kernel.org/patch/7719811/

Author:     Chaotian Jing <chaotian.jing@...iatek.com>
AuthorDate: Mon Nov 30 09:27:30 2015 +0800
Commit:     Ulf Hansson <ulf.hansson@...aro.org>
CommitDate: Tue Dec 22 11:32:18 2015 +0100

    mmc: core: fix __mmc_switch timeout caused by preempt

    there is a time window between __mmc_send_status() and time_afer(),
    on some eMMC chip, the timeout_ms is only 10ms, if this thread was
    scheduled out during this period, then, even card has already changes
    to transfer state by the result of CMD13, this part of code also treat
    it to timeout error.
    So, need calculate timeout first, then call __mmc_send_status(), if
    already timeout and card still in programing state, then treat it to
    the real timeout error.

    Signed-off-by: Chaotian Jing <chaotian.jing@...iatek.com>
    Signed-off-by: Ulf Hansson <ulf.hansson@...aro.org>


Best Regards,
Jaehoon Chung

On 12/28/2015 11:07 AM, Youngjin Jang wrote:
> __mmc_switch() is possible to misjudge error.
> 
> Although jiffies was overed timeout,
> the chance about "R1_CURRENT_STATE(status) != R1_STATE_PRG" is exists.
> In other words, Successful completion of CMD6 with timeout error.
> 
> Kernel expects failure of __mmc_switch,
> but card is completed CMD6 in this case.
> It makes mismatch status between mmc subsystem and mmc card.
> 
> Especially, in case of partition switch,
> If timeout occurs with normal status of CMD13 response unfortunatley,
> "main_md->curr" will not be set, even card switched successfully.

main_md->curr is right? main_md->part_curr?

> 
> Checking state of mmc card is needed when judging an timeout error,
> if it is just timeout or timeout with error.
> 
> Reviewed-by: Jungseung Lee <js07.lee@...sung.com>
> Signed-off-by: Youngjin Jang <yj84.jang@...sung.com>
> ---
>  drivers/mmc/core/mmc_ops.c |    5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/mmc/core/mmc_ops.c b/drivers/mmc/core/mmc_ops.c
> index 1f44426..033f475 100644
> --- a/drivers/mmc/core/mmc_ops.c
> +++ b/drivers/mmc/core/mmc_ops.c
> @@ -456,6 +456,8 @@ int mmc_switch_status_error(struct mmc_host *host, u32 status)
>  		if (status & R1_SPI_ILLEGAL_COMMAND)
>  			return -EBADMSG;
>  	} else {
> +		if (R1_CURRENT_STATE(status) == R1_STATE_PRG)
> +			return -ETIMEDOUT;
>  		if (status & 0xFDFFA000)
>  			pr_warn("%s: unexpected status %#x after switch\n",
>  				mmc_hostname(host), status);
> @@ -568,8 +570,7 @@ int __mmc_switch(struct mmc_card *card, u8 set, u8 index, u8 value,
>  		if (time_after(jiffies, timeout)) {
>  			pr_err("%s: Card stuck in programming state! %s\n",
>  				mmc_hostname(host), __func__);
> -			err = -ETIMEDOUT;
> -			goto out;
> +			break;
>  		}
>  	} while (R1_CURRENT_STATE(status) == R1_STATE_PRG);
>  
> 

--
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/