mtd locking

[Boris Brezillon]

+Brian and Sasha

Hi Matthias,

On Sun, 29 May 2016 18:17:02 +0200
Richard Weinberger <richard at nod.at> wrote:

> Hi!
> 
> Am 29.05.2016 um 17:53 schrieb Matthias Auchmann:
> > By intended you mean it's wrong and we know, but it's still wrong, right?  
> 
> I'd say lazy. Sometimes counters don't need to be exact.
> Having exact counting is expensive. See network stack.
> 
> I'm not sure what the exact reasons in the ECC error counting
> case are.
> Maybe Brian or Boris can tell more.
> 
> > What about thread safety in general? Is the rest of the mtd system thread safe? Can it happen that e.g. a command is issued to NAND, and before the buffer is read, another command is issued (and similar scenarios)? Or is there some kind of protection in place for that?  
> 
> NAND chip access is strictly serialized. :-)
> See nand_get_device().

Yep, read/write accesses are correctly protected. The statistics update
are also protected, but it does not prevent tools like nanddump to
retrieve incorrect information. Actually, nanddump uses the following
sequence:

1/ get stats
2/ read stuff
3/ get new stats and compare with information retrieved in #1

Since we can't lock access to the MTD device for the whole sequence,
the statistics might change because of other read accesses on the same
MTD device.

I recently suggested the addition of a new ioctl to address that [1].

Regards,

Boris

[1]http://thread.gmane.org/gmane.linux.drivers.mtd/66834

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com