public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Matthew Reimer <mreimer@vpop.net>
To: tglx@linutronix.de
Cc: linux-mtd@lists.infradead.org
Subject: Re: oobavail issues
Date: Thu, 31 Mar 2005 09:29:59 -0800	[thread overview]
Message-ID: <200503310929.59763.mreimer@vpop.net> (raw)
In-Reply-To: <1112269966.4228.68.camel@tglx.tec.linutronix.de>

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 
byte.

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?

Matt

  reply	other threads:[~2005-03-31 17:30 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-31  1:18 oobavail issues Joshua Wise
2005-03-31 11:52 ` Thomas Gleixner
2005-03-31 17:29   ` Matthew Reimer [this message]
2005-03-31 19:20     ` Thomas Gleixner
2005-03-31 18:29       ` Matthew Reimer
2005-04-01  8:23         ` Thomas Gleixner
2005-04-01 17:27           ` Matthew Reimer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200503310929.59763.mreimer@vpop.net \
    --to=mreimer@vpop.net \
    --cc=linux-mtd@lists.infradead.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox