linux-kernel - Re: Recent and not-so problems with tifm

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]

Date:	Sun, 18 Feb 2007 00:14:05 +0100
From:	Pierre Ossman <drzeus-mmc@...eus.cx>
To:	Alex Dubov <oakad@...oo.com>
CC:	linux-kernel@...r.kernel.org
Subject: Re: Recent and not-so problems with tifm_sd driver

Alex Dubov wrote:
> If we are already on the topic, I would like to report two additional issues with mmc_block:
> 
> 1. If, for some reason, device driver cannot return the requested data amount, but does not sets
> any error, mmc_block would retry indefinitely. Of course, its always a device driver's fault, but
> may be we can set some limit on retry count (this can help a lot with debugging).

Well, we could add a check that data requests get fully satisfied.

> 
> And the more serious:
> 2. There was a write corruption problem with tifm_sd caused by missing wait cycle (card busy/card
> not busy) after stop command. It should not had been a problem (the mmc layer was spinning around
> with CMD13 untill the card become not-busy), but for some reason it was. We are currently testing
> this. The intersting part, however, is behavior of mmc_block given this situation:
> 
> It appears that mmc_block's instance manages to get stuck because of this. The symptoms: module
> usage count is not decremented when low level driver is unloaded and partition block devices do
> not get created afterwards. The fun part: the main block device gets created and deleted on card
> insertion/removal and its dump is correct (dd if=/dev/mmcblk0 ...); yet partition detection does
> not happens. To fix this, one have to reboot the machine or to wait about 30 minutes for mmc_block
> to regain its senses (then it becomes rmmod'able again).
> 
> On the other hand, it may be some sort of generic block layer problem.
> 

The block layer can get a bit fuzzy when you start yanking device out from under
it. That said, the mmc block driver should be forgiving. So if you can figure
out what it is up to (and more exactly how it is provoked), I'll try to fix it.

-- 
     -- 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/