linux-kernel - [RFC] MMC multiwrite capability removal

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

Message-ID: <20080419095136.15a50cc9@mjolnir.drzeus.cx>
Date:	Sat, 19 Apr 2008 09:51:36 +0200
From:	Pierre Ossman <drzeus-list@...eus.cx>
To:	David Brownell <david-b@...bell.net>,
	Andrew Victor <linux@...im.org.za>,
	Pavel Pisa <ppisa@...ron.com>,
	Carlos Aguiar <carlos.aguiar@...t.org.br>,
	Anderson Briglia <briglia.anderson@...il.com>,
	"Syed Mohammed, Khasim" <x0khasim@...com>,
	Russell King <rmk@....linux.org.uk>,
	Alex Dubov <oakad@...oo.com>
Cc:	LKML <linux-kernel@...r.kernel.org>
Subject: [RFC] MMC multiwrite capability removal

Hi everyone,

I've been planning to remove the MMC multiwrite capability (making it
always on), but I need some help from all you driver maintainers first.

Ages ago, I had a chat with Axboe about the current situation and it
turns out that the MMC layer is a bit over-cautious. There are plenty
of other block devices that cannot report anything more than
success/failure for the whole request. So it's silly that we're
crippling the MMC layer when upper layers have to deal with that
scenario anyway.

What I need from you is and audit of your respective driver(s) and
check that they do not overestimate the number of successfully written
blocks. Please send a short reply even if your driver needs no changes.

Long version:

The data flow of a write is something like this:

1. Data starts moving from main memory to host memory (DMA or PIO)
2. Data finishes moving from main memory to host memory
3. A sector moves to the front of the device write queue
4. The sector starts being sent over the wire
5. The sector finishes being sent over the wire
6. The card acknowledges a successful transfer
7. The card finishes busy signalling
8. The sector moves to the front of the card write queue
9. The sector gets picked up by the FTL
10. The sector is written to media

In a perfect world we would report the number of sectors that made it
to 10. Unfortunately we have limited insight into what the card is up
to.

What your host drivers should report is sectors that have passed stage
6. If your controller doesn't give you enough information to determine
that, then you must report 0 for all failed transfers.

I'll be having a closer look at stages 7 through 10, but that's a core
issue that shouldn't involve your drivers.

Rgds

-- 
     -- Pierre Ossman

  Linux kernel, MMC maintainer        http://www.kernel.org
  PulseAudio, core developer          http://pulseaudio.org
  rdesktop, core developer          http://www.rdesktop.org
--
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/