Yaffers,

[it's my turn to ask for help!]

We're using yaffs_guts.c revision 1.10 circa 2005/07/26 from 
yaffs2 cvs on a well established product. We are getting a few 
cases of a crash/oops during the scan (small page). It crashes 
in yaffs_AddObjectToDirectory called from yaffs_Scan -- there's 
a bad pointer in parent directory children list, so the call
to list_add() oops's.


NAND state is such that during the scan yaffs finds:

1) a file object header (call it object A) who's
   parent ID is 4, the deleted-file-dir.

2) further on several data chunks belonging to object A
   are seen -- the in-core data for object A created
   in (1) was freed (cuz the parent was deleted(id=4)),
   so now a new object A is created, and because this
   step has found data chunks, the new A has type=file.

3) further on a directory object is seen with the same
   ID as A.  This is not good, and deserves investigation
   of it's own, BUT I don't expect yaffs to crash.

When the scan gets to (3) is sees that the object has changed 
type and calls yaffs_DestroyObject(in) in the section with the 
comment "This should not happen..." to zap the existing object.

Scan the goes on and calls yaffs_FindOrCreateObjectByNumber with 
the second objectId 'A' now with type=dir.  Things go bad when 
yaffs_AddObjectToDirectory is later called because the directory 
object was incorrectly (re)initialized when it morphed from a 
file into a directory -- this is why the child list pointers are 
junk.

Now, I'd like to simply upgrade to the latest and greater version 
of Yaffs, but that's not so easy with thousands of units in the 
field at risk. I'd need to understand what should be happening 
during the scan when this situation arises and fix up the code 
to handle it better.  I'd also like to be sure this is fixed
appropriately in the current codebase -- the scan code handling
this case look unchanged.

-imcd