[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Error in jffs2_read_dnode





After more data collection, I've found that the problem is when
jffs_read_dnode() is called from jffs2_getlink().

It looks as if jffs2_readlink() and jffs2_follow_link() don't lock
jffs2_inode_info::sem but should be.  Is this true?

I was a little concerned with jffs2_garbage_collect_metadata()
and how it orders the obsoletion of the old node and the update
of f->metadata to point to the new one.  But, it appears as if this
is only done with jffs2_inode_info::sem locked.

Chris Lesiak
clesiak@xxxxxxx.com



                                                                 
                                                                 
              David Woodhouse <dwmw2@xxxxxxx.org>              
              2002-01-14 11:02 AM                                
                                                                 



To:   Chris Lesiak/Li-cor@Li-cor
cc:   jffs-dev@xxxxxxx.com
Subject:  Re: Error in jffs2_read_dnode




clesiak@xxxxxxx.com said:
>  I get occasional errors in jffs2_read_dnode.  The "if (crc != ri->
> node_crc)" path is taken.  After adding some extra debugging, I've
> found that the magic number is correct (0x1985) and the nodetype is
> 0xc002; it is of type JFFS2_NODETYPE_INODE, except it is no longer
> accurate.

You should never be trying to read data from a node which has been marked
as obsolete. In the few cases where we _do_ want to look at an obsolete
node, we make sure we mask the obsolete back in before calculating the CRC.

You need to work out why it's trying to read from that node.

--
dwmw2







To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to majordomo@xxxxxxx.com