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
next prev parent 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