public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind1@gmail.com>
To: Reginald Perrin <reggyperrin@yahoo.com>
Cc: MTD Mailing List <linux-mtd@lists.infradead.org>
Subject: Re: Help needed with corruption detection/ubifs_wbuf_sync_nolock
Date: Wed, 27 Jun 2012 17:22:31 +0300	[thread overview]
Message-ID: <1340806951.3070.33.camel@sauron.fi.intel.com> (raw)
In-Reply-To: <1340632690.58836.YahooMailNeo@web114616.mail.gq1.yahoo.com>

[-- Attachment #1: Type: text/plain, Size: 1842 bytes --]

Hi,

On Mon, 2012-06-25 at 06:58 -0700, Reginald Perrin wrote:
> I'm tracking down a corruption issue, and trying to trace back where
> LEB's are getting randomly corrupted in our system (a very rare event,
> but it can happen).  I'm focusing on ubifs/io.c, and trying to
> validate data before we send to ubi_leb_write().

You are not using MLC NAND, right? Did you validate your flash using MTD
tests?

> Can somebody please clarify something for me
> on ubifs_wbuf_sync_nolock()?  I'm trying to validate that the data
> we're writing hasn't been corrupted.  I thought I could just check
> that the node-type was valid, such as:
> 
>     if ( ((struct ubifs_ch *)wbuf->buf)->node_type > UBIFS_ORPH_NODE )
> {
> 
>         // ABORT WRITE
>     }
> 
>     err = ubi_leb_write(c->ubi, wbuf->lnum, wbuf->buf, wbuf->offs,
> 
The above code assumes the contents of the write-buffer always starts
with an UBIFS node, which is not true. 'wbuf->buf[0]' may be the middle
or the end of a node. If you want to add a check, you need to write a
helper function which _scans_ the write-buffer and searches for
UBIFS_NODE_MAGIC, and _then_ may be the start of a node. Then you go
check the common header CRC. And the write-buffer may contain more than
one node, so you need to iterate. And you need to take into account the
case when this is the end of the write-buffer and the common header does
not fit.
> 
> Can anybody help me understand how to check to see if the LEB is
> corrupted before we write?  I'm trying to get close enough to the
> corruption to get a backtrace.

Corrupted how - the CRC is corrupted? You can try to scan the LEB in the
previoius LEB using 'ubifs_scan()' in before switching to the new one in
the 'ubifs_wbuf_seek_nolock()' function, I guess.

-- 
Best Regards,
Artem Bityutskiy

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  parent reply	other threads:[~2012-06-27 14:18 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-25 13:58 Help needed with corruption detection/ubifs_wbuf_sync_nolock Reginald Perrin
2012-06-25 14:48 ` Reginald Perrin
2012-06-27 14:23   ` Artem Bityutskiy
2012-06-27 14:22 ` Artem Bityutskiy [this message]
2012-06-29 13:40   ` Reginald Perrin

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=1340806951.3070.33.camel@sauron.fi.intel.com \
    --to=dedekind1@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=reggyperrin@yahoo.com \
    /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