RE: [RFC/PATCH] ARM: OMAP: OneNAND support for 2430SDP

Kyungmin Park
2007-03-22T04:50:07Z

> -----Original Message-----
> From: Kevin Hilman [mailto:khilman@mvista.com]
> Sent: Thursday, March 22, 2007 12:14 PM
> To: kmpark@infradead.org
> Cc: 'Jalori, Mohit'; linux-omap-open-source@linux.omap.com
> Subject: Re: [RFC/PATCH] ARM: OMAP: OneNAND support for 2430SDP
>
> Kyungmin Park wrote:
> >>>> RFC: Notice the change to onenand_base.c which comments
> >> out the last
> >>>> OOB chunk. Without this, it would not work.
> >> Previous drivers
> >>>> for this board such as the 2.6.10-based MV kernel have this
> >>>> same change. Anyone know what is going on here?
> >>>>
> >>> We got this change from MV in the patch he sent to fix an
> >> issue we were
> >>> seeing with mounting an empty jffs2 partition. Here are
> the comments
> >>> that came in with it
> >>>
> >>> " The oobfree list in the MTD OneNAND driver is of length 8. This
> >>> exceeds the maximum length of 7, because the eighth entry
> >> must be used
> >>> as a null terminator. The absence of a terminator causes a
> >> variety of
> >>> problems in various places (especially JFFS2 and YAFFS2) where the
> >>> oobfree list is scanned. The fix is to do without the
> >> eighth entry.
> >
> > Colud you point out the source code line where used the
> eightn entry used as a
> > null terminator?
> >
>
> There are several loops in both the NAND and the OneNAND code
> where the
> oobfree list is walked and the loop only terminates when it
> finds a NULL
> entry (specifically, one with a zero length.)
>
> For example, look in onenand_fill_auto_oob() where you have a couple
> loops like this:
>
> for (free = this->ecclayout->oobfree; free->length; ++free) {
> }
>
> In the case where there is 8 non-zero entries in the oobfree
> list, this
> loop will walk off the end of the list before it terminates,
> and having
> undefined results depending on what is after the oobfree list
> in memory.
>
> Instead, these loops should probably loop over
> MTD_MAX_OOBFREE_ENTRIES,
> and break out early if they find a zero-length entry.

Yes, you're right. It met the same problem in the previous mail [1].
Could you apply patch [2] and test again. it will be work.

Anyway I will fix it to check array length.

But I wonder it is only affected with OOB_AUTO. however the linux 2.6.10 kernel
don't use OOB_AUTO. but you said it has same problem.
Is there another point?

>
> I'm not sure why this works for you. For me, here's a simple way to
> trigger the bug using the OneNAND device on the OMAP2430SDP:

>
> # flash_eraseall /dev/mtd8
> Erasing 128 Kibyte @ 7e80000 -- 99 % complete.
> # mount -t jffs2 /dev/mtdblock8 /media/onenand
> Cowardly refusing to erase blocks on filesystem with no valid
> JFFS2 nodes
> empty_blocks 0, bad_blocks 0, c->nr_blocks 1013
> mount: /dev/mtdblock8: can't read superblock
>

Thank you,
Kyungmin Park

1. http://lists.infradead.org/pipermail/linux-mtd/2007-February/017418.html
2. http://git.infradead.org/?p=users/kmpark/onenand-mtd-
2.6.git;a=commitdiff;h=5bc399e9ef430efd5725b66aa2ad7ad2d81e372b;hp=81280d5879761
f90b3a341d52371d03998730d8e