linux-kernel - Re: [PATCH] mmc_spi: use EILSEQ for possible transmission errors

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090609200750.2fa38dfe@mjolnir.ossman.eu>
Date:	Tue, 9 Jun 2009 20:07:50 +0200
From:	Pierre Ossman <pierre@...man.eu>
To:	Wolfgang Mües <wolfgang.mues@...rswald.de>
Cc:	"David Brownell" <david-b@...bell.net>,
	"Matt Fleming" <matt@...sole-pimps.org>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	"Mike Frysinger" <vapier.adi@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mmc_spi: use EILSEQ for possible transmission errors

On Mon, 25 May 2009 16:59:17 +0200
Wolfgang Mües <wolfgang.mues@...rswald.de> wrote:

> Pierre,
> 
> Am Montag, 25. Mai 2009 schrieb Pierre Ossman:
> > I don't remember why
> > mmc_spi is looking at responses to begin with.
> 
> Because responses are very different.
> 
> First of all, responses in SD mode and SPI mode are different.
> 

MMC and SD aren't identical either, but we don't delegate that to the
host drivers.

> Second, responses in SD mode are CRC-7 protected, so that it is easy to check 
> for transmission errors.
> 
> SPI mode responses (R1...) are without any CRC.
> 

This however is more relevant. But OTOH, I don't think mmc_spi has a
better idea if the status can be trusted or not than a higher layer.

> Third, if you have SD mode, you use a hardware host controller which manages 
> all command/data/response actions, and what you typically get is the content 
> of the status register of the host controller (which is different from the
> error code of the SD card).
> 
> So it is very natural that every host controller driver mapps the responses 
> from the host controller to a common representation (== error code). The 
> error codes with special meanings for MMC/SD are summed up in mmc/core.h .
> 

But the other drivers don't attempt to interpret the response from the
card. They just give the response back up and let the next layer deal
with it.

> The SPI host driver is a recent addition to the linux kernel, and the fact 
> that SPI responses are not CRC-protected was not accounted for in the code.
> 
> As it makes no sense to code the retry logic in every driver, the prefered way 
> is to code the retry logic in block.c. The non-SPI-mode-drivers will profit 
> from this logic, because they are getting retries for EILSEQ (CRC error) and
> ETIMEDOUT (card has not understand the command).

Indeed. But I don't like the fact that we're hiding interpretation of
responses down in the driver. It should be up to the layer issuing the
MMC request how the response should be interpreted.

But that's an issue that can be left for another day...

> 
> The biggest problem in the error codes is that EINVAL is used by the SPI 
> driver both for recoverable and for non-recoverable errors, which has to be 
> splitted IMHO.
> 

Indeed. I'll queue up the patch.

Rgds
-- 
     -- Pierre Ossman

  WARNING: This correspondence is being monitored by the
  Swedish government. Make sure your server uses encryption
  for SMTP traffic and consider using PGP for end-to-end
  encryption.

Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)