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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 12 Aug 2010 00:22:43 -0700 (PDT)
From:	Alex Dubov <oakad@...oo.com>
To:	Maxim Levitsky <maximlevitsky@...il.com>
Cc:	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] MEMSTICK: Add driver for Ricoh R5C592 Card reader.

> Maximum I might need to clear page status bits, but I can
> do that later
> after I write the block.
> This won't be any performance impact because amount of bad
> pages
> shouldn't be normally greater that zero.
> (Otherwise there will be data loss...)


These things do degrade. I think, memsticks do write-verify, so bad blocks
will appear during write and can be marked as such without any data loss.

> 
> One interesting thing that I just want your opinion on is
> what to do
> with correctable errors.
> Common sense suggests to relocate the sector + and mark it
> bad.
> But I don't know how common such sectors are, and thus I
> could do more
> harm that good by marking too many sectors as bad.

I agree that number of writes to the media should be kept minimal.
So bad (in either way) blocks encountered should be logged, but not
touched, unless the error appears during an actual write/modify operation.

> 
> I hope I create ms_block.c soon, and put that old problem
> to the rest.

If you have time and desire, try to put a low level format option in - 
some function to erase all blocks, except the system ones.

> 
> As time permits I will also port your driver for xD portion
> of jMicron
> device (which I have).

By the way, I've got some errata for the newer JMicron chipsets. If they
have not contacted you yet, I'll forward it to you.



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