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: <200905201231.53873.wolfgang.mues@auerswald.de>
Date:	Wed, 20 May 2009 12:31:53 +0200
From:	Wolfgang Mües <wolfgang.mues@...rswald.de>
To:	"David Brownell" <david-b@...bell.net>
Cc:	"Matt Fleming" <matt@...sole-pimps.org>,
	"Pierre Ossman" <drzeus@...eus.cx>,
	"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

Matt,

Am Mittwoch, 20. Mai 2009 schrieb David Brownell:
> > R1_SPI_ERASE_SEQ and R1_SPI_ERASE_RESET are responses to a sector erase
> > command. block.c is not sending such commands, so block.c can safely
> > assume that each such response is a transmission error.
>
> Hmm, would hope that's not a long-term plan.  Remember that the
> firmware in the card can leverage "that's erased" knowledge for
> things like wear leveling.  SSDs and other storage devices would
> likewise benefit from such knowledge.  I'm quite certain there's
> been discussion about adding support for that in the block layer.

But if the block layer IS sending such erase commands in the future, it CAN 
treat these error codes different:

if (read or write block command)
   erase errors must be transmission errors
else
   accept erase errors;

As it is not neccessary to change the handling of these errors in mmc_spi.c, 
no information is lost.

> And the key issue is -- correct me if I'm wrong -- that returning
> EINVAL makes trouble

Yes, because EINVAL is used for TWO different purposes:
- reporting an error of the driver or host controller
  (which is by nature non-recoverable, a retry is harmless,
   but makes no sense).
- reporting an error from the SD card (in mmc_spi).
  (which might be a transmission error and retries make
   sense).

> so you need to change those three codes.  

Yepp.

> The others don't much matter, right?

Yes. I can simple treat them as transmission errors in block.c

regards
 
i. A. Wolfgang Mües
-- 
Auerswald GmbH & Co. KG
Hardware Development
Telefon: +49 (0)5306 9219 0
Telefax: +49 (0)5306 9219 94 
E-Mail: Wolfgang.Mues@...rswald.de
Web: http://www.auerswald.de
 
--------------------------------------------------------------
Auerswald GmbH & Co. KG, Vor den Grashöfen 1, 38162 Cremlingen
Registriert beim AG Braunschweig HRA 13289
p.h.G Auerswald Geschäftsführungsges. mbH
Registriert beim AG Braunschweig HRB 7463
Geschäftsführer: Dipl-Ing. Gerhard Auerswald
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ