Ian
Can you clarify as per the question below...
On Wednesday 10 October 2007 09:55:12 Ian McDonnell wrote:
> 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.
That is not good. There should only be one of these.
Question: Is this object also in the deleted-files directory?
>
> 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.
Question: Does it looks like this directory should be a "live" object with
other files in it?
If so, it looks like the real problem is that the somehow the directory object
got created before the file object was deleted. I'll take a look as to how
that could have happened.
>
> 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
>
> _______________________________________________
> yaffs mailing list
> yaffs@lists.aleph1.co.uk
> http://lists.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs
(text/plain)