oobavail issues

Matthew Reimer mreimer at vpop.net
Thu Mar 31 12:29:59 EST 2005

On Thursday 31 March 2005 03:52 am, Thomas Gleixner wrote:
> On Wed, 2005-03-30 at 20:18 -0500, Joshua Wise wrote:
> > We found that making our oobfree match up with oobavail seemed to do the
> > trick for avoiding this, and make JFFS2 work, to boot! Here's what we
> > did:
> >
> > I suspect that oobavail should be summing oobfree instead of doing that
> > arithmetic. Or is there something I'm not seeing?
> In general you're right. oobavail should be derived from oobfree, but in
> case of JFFS2 this does not matter at all.
> Which problem went away with your changes ?

We're using the nand_oobinfo structure from the s3c2410.c nand driver:

static struct nand_oobinfo nand_hw_eccoob = {
        .useecc         = MTD_NANDECC_AUTOPLACE,
        .eccbytes       = 3,
        .eccpos         = {0, 1, 2 },
        .oobfree        = { {8, 8} }

On our platform, it's hooked up to Samsung flash part (k9f5608u0a) with 512 
byte pages and 16 bytes of OOB. We were getting crashes in the memcpy() that 
nand_prepare_oobbuf() does because with the above definition mtd->oobavail = 
12, whereas the total number of oobfree bytes only equals 8. So the first 
memcpy() would be correct and len would advance by 8, but then since len (now 
8) < mtd->oobavail (now 12), it would iterate again. These subsequent 
iterations assume that there are more entries in the oobfree array, and would 
end up reading whatever values happened to follow the oobfree array and using 
those. In our case, it would read zeroes, which would result in len not 
advancing, and eventually it read some impossibly large number which memcpy() 
would choke on and crash the kernel.

We've worked around the crash by making sure that oobfree covers every free 

I'm not sure what is the correct fix--calculate oobavail differently, or to 
change the loop condition in nand_prepare_oobbuf, or to require 
nand_oobinfo.oobfree to cover every OOB byte. We just copied from the 
s3c2410.c, assuming it was correct.

What would you suggest?


More information about the linux-mtd mailing list