mtd locking

[Matthias Auchmann]

By intended you mean it's wrong and we know, but it's still wrong, right?

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?

I'm willing to contribute and fix the ECC part, but I first need to understand what other mechanisms or thread safety issues there might still be...

Thanks!

BR,

Matthias


-----Original Message-----
From: Richard Weinberger [mailto:richard.weinberger at gmail.com] 
Sent: Sunday, May 29, 2016 4:24 PM
To: Matthias Auchmann
Cc: linux-mtd at lists.infradead.org
Subject: Re: mtd locking

On Sun, May 29, 2016 at 3:38 PM, Matthias Auchmann <m.auchmann at artech.at> wrote:
> Hi all!
>
> I have a question - sorry if it turns out to be a beginner's question. I'm using kernel version 3.17, but as far as I can tell my question still applies.
>
> My question is how locking is ensured with MTD. I understand that usually there would only be one file system attached to one mtd partition, but what if I concurrently ran multiple instances of nanddump from userspace? Is MTD thread-safe?
>
> I'm asking since I had an issue where when I called nanddump on two partitions of the same NAND flash simultaneously, the ECC errors would count up for both nanddumps although only one partition had ECC errors. Experimentally adding a mutex to mtdpart.c's part_read() function solved the issue.

IIRC ECC error counting is not thread safe at all.
So, yes the behavior is indented.
...at least nobody cared enough to make it better.

-- 
Thanks,
//richard