mtd_stresstest module bricked my dockstar

[Roland Kletzing]

Hello folks,
i was (really) happily fiddling with my dockstar NAS for the last 2 days and managed to get 3.0.4 vanilla kernel running on that device, and since i wanted do do some more testing with heartbeat/led, i fired up my proven "load all sort of modules until the kernel oopses, crashes, freezes" routine (i happily ran on x86 for years as a proven source for oopsing or hanging the kernel and/or for reporting unknown bugs) and this was the last thing i saw in dmesg:
mtd_stresstest: MTD device size 1048576, eraseblock size 131072, page size 2048, count of eraseblocks 8, pages per eraseblock 64, OOB
Âsize 64
mtd_stresstest: scanning for bad eraseblocks
mtd_stresstest: scanned 8 eraseblocks, 0 are bad
mtd_stresstest: doing operations
mtd_stresstest: 0 operations done
mtd_stresstest: 1024 operations done
mtd_stresstest: 2048 operations done
.....

could not stop that, could not kill modprobe, could not unload module - device dead, no signs of life after power-cycle anymore.

DOH!

Let`s have a look:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=7163cea15f7b362795b858e7c130cd617aecc0aa

ok - in there for a while.

Kconfig:

config MTD_TESTS
tristate "MTD tests support"
depends on m
help
 This option includes various MTD tests into compilation. The tests
 should normally be compiled as kernel modules. The modules perform
 various checks and verifications when loaded.


???ÂÂ
"depends on m" ?Â
Perform checks and verification when loaded ?
So, there is a linux kernel module whichÂ(apparently)Âstress-tests (i.e. overwrites)Âthe MTD and somehow from a derived config in a third party kernel that module gotÂitÂs way into my 3.0.4 build - and on module load, it started to hammer on the first mtd itÂcame across without any sign of warning and without any safeguardÂ? (i.e. the module kills your dataÂjust by loading it?)

It may be that it`s not recommendedÂor considered "best practise"Âto load all sorts of unkown modules (i.e. find /lib/modules....Â-name "*.ko"....) Â- but people do (see https://bugzilla.novell.com/show_bug.cgi?id=224522[https://bugzilla.novell.com/show_bug.cgi?id=224522]Â;). And it`s not obvious that it`s THAT dangerous. AndÂfor me this is the first time Linux REALLYÂmanaged toÂbadlyÂbrick my hardware in such a rigorousÂway. Maybe someone can understand that i`mÂnot really amused, as there is no easy way to recover, as seen on http://www.yourwarrantyisvoid.com/2010/09/08/dead-dockstar-resurrected-with-jtag/[http://www.yourwarrantyisvoid.com/2010/09/08/dead-dockstar-resurrected-with-jtag/]Â;

Luckily, i got that dockstar for cheap and have some more, so let`s call that "shit really happens".

I don`t want to accuse anybody, that module has it`sÂpurpose,Âbut please considerÂadding more safeguard against suchÂissues.

One last question:
Is there any other really dangerous stuff like this inside the kernel ? (found mtd_torturetest, which seems another beast like this)

regards
Roland

ps:
Someone want the Dockstar for spending the hours and the money for debrick ? Or for extracting gold and other precious metals from electronic waste ? ;)

___________________________________________________________
SMS schreiben mit WEB.DE FreeMail - einfach, schnell und
kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/