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

Re: Unknown INCOMPAT nodetype C002 at 0196f9e0

clesiak@xxxxxxx.com said:
> jffs2_get_inode_nodes() is occasionally generating the message
> "Unknown INCOMPAT nodetype C002 at 0196f9e0".

> I think this could be caused by garbage collection moving the node out
> from under me again.

jffs2_get_inode_nodes() is called only from jffs2_do_read_inode(). The 
garbage-collection code would have to call iget() for the inode in 
question, and iget() wouldn't return until read_inode() had finished.

So there's no need for the init_MUTEX(&f-sem) at the beginning of 
jffs2_do_read_inode() to be init_MUTEX_LOCKED. 

> In this case, it seems as if there is no semaphore to protect the
> operation.  Is it true that the intent was to just recheck the
> obsolete flag in the low bit of the flash offset after the read of the
> node?

No, the intent was that if we know the node is obsolete (because the low 
bit of flash_offset is set) then we don't bother to read it from the flash 
at all.

And if it isn't marked obsolete in our own in-memory representation and we 
went ahead with reading it from the flash, I'm somewhat concerned by the 
fact that the node on the _flash_ says it's obsolete.

Can you take a snapshot of the offending filesystem, then do a complete 
debug run, logging all the KERN_DEBUG messages and mail it all to me?


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