[PATCH] mtd: nand: omap: fix race condition in omap_wait()
Mark Olleson
mark.olleson at yamaha.co.uk
Fri Apr 27 07:26:28 EDT 2012
On 27 Apr 2012, at 06:50, Artem Bityutskiy wrote:
> On Tue, 2012-04-17 at 13:11 +0200, Ivan Djelic wrote:
>> If a context switch occurs in function omap_wait() just before the
>> while loop is entered, then upon return from context switch the
>> timeout may already have elapsed: in that case, status is never
>> read from NAND device, and omap_wait() returns an error.
>> This failure has been experimentally observed during stress tests.
>>
>> This patch ensures a NAND status read is always performed before
>> returning, as in the generic nand_wait() function.
>>
>> Signed-off-by: Ivan Djelic <ivan.djelic at parrot.com>
>
> Pushed this one to l2-mtd.git, thanks!
>
I'm investigating a problem where omap_wait() returns (apparently after the timeout) without the device being ready. In my case, the loop has run at least once (my system is lightly loaded so cond_resched() is unlikely to block us for long). This patch will help in the case where cond_resched() blocks the tread beyond the timeout as well as the case where a context switch occurs before ever reading a value.
When the timeout is reached without the device becoming ready, omap_wait() returns with a status value with the NAND_STATUS_FAIL clear, but in many places where omap_wait() is called from only check for NAND_STATUS_FAIL, and then go on to issue further commands to the device - which fail.
This includes the code enabled by CONFIG_MTD_NAND_VERIFY_WRITE when then reads back garbage and fails.
Mark
---
Mark Olleson - Senior R&D Engineer
Technology Research & Development Group
Yamaha R&D Centre London
More information about the linux-mtd
mailing list