All of lore.kernel.org
 help / color / mirror / Atom feed
From: Adrian Hunter <adrian.hunter@intel.com>
To: Ben Hutchings <ben@decadent.org.uk>
Cc: "Torne (Richard Coles)" <torne@google.com>,
	cjb@laptop.org, linus.walleij@linaro.org, jh80.chung@samsung.com,
	linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH V2] MMC: core: cap MMC card timeouts at 2 seconds.
Date: Fri, 01 Jun 2012 11:35:54 +0300	[thread overview]
Message-ID: <4FC87EEA.5010707@intel.com> (raw)
In-Reply-To: <1338258732.20487.171.camel@deadeye>

On 29/05/12 05:32, Ben Hutchings wrote:
> On Mon, 2012-05-28 at 18:31 +0100, Torne (Richard Coles) wrote:
>> From: "Torne (Richard Coles)" <torne@google.com>
>>
>> MMC CSD info can specify very large, ridiculous timeouts, big enough to
>> overflow timeout_ns on 32-bit machines. This can result in the card
>> timing out on every operation because the wrapped timeout value is far
>> too small.
>>
>> Fix the overflow by capping the result at 2 seconds.  Cards specifying
>> longer timeouts are almost certainly insane, and host controllers
>> generally cannot support timeouts that long in any case.
>>
>> 2 seconds should be plenty of time for any card to actually function;
>> the timeout calculation code is already using 1 second as a "worst case"
>> timeout for cards running in SPI mode.
> 
> Needs a 'Signed-off-by'.
> 
>> ---
>>  drivers/mmc/core/core.c |   11 ++++++++++-
>>  1 files changed, 10 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
>> index 0b6141d..3b4a9fc 100644
>> --- a/drivers/mmc/core/core.c
>> +++ b/drivers/mmc/core/core.c
>> @@ -512,7 +512,16 @@ void mmc_set_data_timeout(struct mmc_data *data, const struct mmc_card *card)
>>  	if (data->flags & MMC_DATA_WRITE)
>>  		mult <<= card->csd.r2w_factor;
>>  
>> -	data->timeout_ns = card->csd.tacc_ns * mult;
>> +	/*
>> +	 * The timeout in nanoseconds may overflow with some cards. Cap it at
>> +	 * two seconds both to avoid the overflow and also because host
>> +	 * controllers cannot generally generate timeouts that long anyway.
>> +	 */
>> +	if (card->csd.tacc_ns <= (2 * NSEC_PER_SEC) / mult)
>> +		data->timeout_ns = card->csd.tacc_ns * mult;
>> +	else
>> +		data->timeout_ns = 2 * NSEC_PER_SEC;
> 
> We clearly need to guard against overflow here, and this is the correct
> way to clamp the multiplication.  I can't speak as to whether 2 seconds
> is the right limit.

The host controllers I have looked at have a limit of around 2.5 seconds.

But why not just use the size of the type as the limit? e.g.

	if (card->csd.tacc_ns <= UINT_MAX / mult)
		data->timeout_ns = card->csd.tacc_ns * mult;
	else
		data->timeout_ns = UINT_MAX;

> 
> Ben.
> 
>>  	data->timeout_clks = card->csd.tacc_clks * mult;
>>  
>>  	/*
> 

  parent reply	other threads:[~2012-06-01  8:35 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-28 17:31 [PATCH V2] MMC: core: cap MMC card timeouts at 2 seconds Torne (Richard Coles)
2012-05-29  2:32 ` Ben Hutchings
2012-05-29  9:02   ` Torne (Richard Coles)
2012-05-29  9:02     ` [PATCH] " Torne (Richard Coles)
2012-05-31 10:00       ` Ulf Hansson
2012-05-31 10:15         ` Torne (Richard Coles)
2012-05-31 15:00           ` Ulf Hansson
2012-06-01  8:35   ` Adrian Hunter [this message]
2012-06-01  9:31     ` [PATCH V2] " Torne (Richard Coles)
2012-06-01  9:32       ` Torne (Richard Coles)
2012-06-01 10:09         ` Adrian Hunter
2012-06-01 10:20           ` Torne (Richard Coles)
2012-06-01 12:59             ` Adrian Hunter
2012-06-01 13:12               ` Torne (Richard Coles)
2012-06-01 13:20                 ` [PATCH V3] MMC: core: cap MMC card timeouts at UINT_MAX Torne (Richard Coles)
2012-06-04  8:13                   ` Adrian Hunter
2012-06-01 14:48               ` [PATCH V2] MMC: core: cap MMC card timeouts at 2 seconds Chris Ball
2012-06-01 14:48                 ` Chris Ball

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FC87EEA.5010707@intel.com \
    --to=adrian.hunter@intel.com \
    --cc=ben@decadent.org.uk \
    --cc=cjb@laptop.org \
    --cc=jh80.chung@samsung.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=torne@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.