| 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
| ||
|
Date: Mon, 18 Aug 2014 11:15:13 +0200
From: Ulf Hansson <ulf.hansson@...aro.org>
To: Doug Anderson <dianders@...omium.org>
Cc: Chris Ball <cjb@...top.org>, Seungwon Jeon <tgih.jun@...sung.com>,
Jaehoon Chung <jh80.chung@...sung.com>,
Sonny Rao <sonnyrao@...omium.org>,
Tomasz Figa <tomasz.figa@...il.com>,
Yuvaraj Kumar C D <yuvaraj.cd@...il.com>,
linux-samsung-soc <linux-samsung-soc@...r.kernel.org>,
Chris Ball <chris@...ntf.net>,
linux-mmc <linux-mmc@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [REPOST PATCH v2] mmc: dw_mmc: Make sure we don't get stuck when
we get an error
On 13 August 2014 17:13, Doug Anderson <dianders@...omium.org> wrote:
> If we happened to get a data error at just the wrong time the dw_mmc
> driver could get into a state where it would never complete its
> request. That would leave the caller just hanging there.
>
> We fix this two ways and both of the two fixes on their own appear to
> fix the problems we've seen:
>
> 1. Fix a race in the tasklet where the interrupt setting the data
> error happens _just after_ we check for it, then we get a
> EVENT_XFER_COMPLETE. We fix this by repeating a bit of code.
> 2. Fix it so that if we detect that we've got an error in the "data
> busy" state and we're not going to do anything else we end the
> request and unblock anyone waiting.
>
> Signed-off-by: Doug Anderson <dianders@...omium.org>
> Signed-off-by: Yuvaraj Kumar C D <yuvaraj.cd@...il.com>
> Acked-by: Seungwon Jeon <tgih.jun@...sung.com>
Thanks! Applied for next.
Kind regards
Uffe
> ---
> Changes in v2:
> - Removed TODO
> - Set cmd to NULL before calling dw_mci_request_end()
>
> drivers/mmc/host/dw_mmc.c | 46 ++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 46 insertions(+)
>
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> index 8f216ed..7f227e9 100644
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -1299,6 +1299,14 @@ static void dw_mci_tasklet_func(unsigned long priv)
> /* fall through */
>
> case STATE_SENDING_DATA:
> + /*
> + * We could get a data error and never a transfer
> + * complete so we'd better check for it here.
> + *
> + * Note that we don't really care if we also got a
> + * transfer complete; stopping the DMA and sending an
> + * abort won't hurt.
> + */
> if (test_and_clear_bit(EVENT_DATA_ERROR,
> &host->pending_events)) {
> dw_mci_stop_dma(host);
> @@ -1312,7 +1320,29 @@ static void dw_mci_tasklet_func(unsigned long priv)
> break;
>
> set_bit(EVENT_XFER_COMPLETE, &host->completed_events);
> +
> + /*
> + * Handle an EVENT_DATA_ERROR that might have shown up
> + * before the transfer completed. This might not have
> + * been caught by the check above because the interrupt
> + * could have gone off between the previous check and
> + * the check for transfer complete.
> + *
> + * Technically this ought not be needed assuming we
> + * get a DATA_COMPLETE eventually (we'll notice the
> + * error and end the request), but it shouldn't hurt.
> + *
> + * This has the advantage of sending the stop command.
> + */
> + if (test_and_clear_bit(EVENT_DATA_ERROR,
> + &host->pending_events)) {
> + dw_mci_stop_dma(host);
> + send_stop_abort(host, data);
> + state = STATE_DATA_ERROR;
> + break;
> + }
> prev_state = state = STATE_DATA_BUSY;
> +
> /* fall through */
>
> case STATE_DATA_BUSY:
> @@ -1335,6 +1365,22 @@ static void dw_mci_tasklet_func(unsigned long priv)
> /* stop command for open-ended transfer*/
> if (data->stop)
> send_stop_abort(host, data);
> + } else {
> + /*
> + * If we don't have a command complete now we'll
> + * never get one since we just reset everything;
> + * better end the request.
> + *
> + * If we do have a command complete we'll fall
> + * through to the SENDING_STOP command and
> + * everything will be peachy keen.
> + */
> + if (!test_bit(EVENT_CMD_COMPLETE,
> + &host->pending_events)) {
> + host->cmd = NULL;
> + dw_mci_request_end(host, mrq);
> + goto unlock;
> + }
> }
>
> /*
> --
> 2.1.0.rc2.206.gedb03e5
>
--
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