Help needed with corruption detection/ubifs_wbuf_sync_nolock

[Artem Bityutskiy]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20120627/fb910571/attachment-0001.sig>