[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