* nand_do_write_ops issue with writing OOB data
@ 2011-05-24 10:13 THOMSON, Adam (Adam)
2011-05-24 10:15 ` Artem Bityutskiy
0 siblings, 1 reply; 2+ messages in thread
From: THOMSON, Adam (Adam) @ 2011-05-24 10:13 UTC (permalink / raw)
To: linux-mtd@lists.infradead.org
Hi,
I have recently come across an issue in the NAND generic driver code (Kernel & U-Boot),
in particular to do with 'nand_do_write_ops' method in nand_base.c, when writing OOB data
(the problem is noted from at least from 2.6.31 to current latest version of the linux kernel,
and from 1.3.4 of U-Boot to current).
The issue I observed happened in the following scenario using YAFFS2:
1) Scan is performed on NAND to identify bad blocks, and last block in NAND is marked bad.
This is the last block read in by the scan, so chip->oob_poi buffer contains contents of this blocks OOB.
2) YAFFS calls on nand_do_write_ops and provides both ops->oobbuf,
and ops->mode == MTD_OOB_AUTO to write it's tags to OOB area.
3) nand_do_write_ops code doesn't initialise chip->oob_poi buffer to all 0xff because YAFFS provided
the ops.oobbuf buffer.
4) Later in this method nand_fill_oob is called, and drops into the case MTD_OOB_AUTO.
This skips the first two bad block marker bytes in chip->oob_poi buffer leaving them as they
were from the previously read block (in this case a bad block with markers 0x00), and
then it copies over the YAFFS tag data that was provided to be written to the OOB.
Without knowing it YAFFS has now marked the block as bad, but is unaware of this
and it's checkpointing data is incorrect. This causes a world of pain for YAFFS.
Interestingly this issue was seen in 2007 on the following message thread:
http://www.aleph1.co.uk/lurker/message/20070702.153055.030a8b94.en.html
It's a very corner case scenario but shouldn't the chip->oob_poi buffer always be memset to all 0xff
even when ops.oobbuf is populated just so we don't write data to the OOB which is from a previously
read block? This scenario has been seen with YAFFS but given this could happen for other code that
uses the OOB area in a similar way using nand_do_write_ops, I believe the problem is with MTD NAND
code and not YAFFS.
Thoughts on this would be greatly appreciated. Apologies if I've rambled a little.
Thanks
Adam
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: nand_do_write_ops issue with writing OOB data
2011-05-24 10:13 nand_do_write_ops issue with writing OOB data THOMSON, Adam (Adam)
@ 2011-05-24 10:15 ` Artem Bityutskiy
0 siblings, 0 replies; 2+ messages in thread
From: Artem Bityutskiy @ 2011-05-24 10:15 UTC (permalink / raw)
To: THOMSON, Adam (Adam); +Cc: linux-mtd@lists.infradead.org
On Tue, 2011-05-24 at 12:13 +0200, THOMSON, Adam (Adam) wrote:
> Interestingly this issue was seen in 2007 on the following message thread:
>
> http://www.aleph1.co.uk/lurker/message/20070702.153055.030a8b94.en.html
Probably it is time to send a patch then, if this is discussed from
2007 :-)
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2011-05-24 10:20 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-05-24 10:13 nand_do_write_ops issue with writing OOB data THOMSON, Adam (Adam)
2011-05-24 10:15 ` Artem Bityutskiy
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).