Charles,
Thanks for a quick reply.
On Tuesday 09 October 2007 21:03, Charles Manning wrote:
> 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?
No, I don't think so, this directory would have contained three
live files -- I had printed out the directory's name, so know
what it would have contained.
[I've now lost the NAND state and have to try to reproduce the
problem again. I had disabled NAND writes to avoid losing this
failed state, but I didn't disable erase (doh), so that's
propably the reason why I lost the error state. A while back,
when looking into another issue, I started out by taking a dump
of NAND but ran into problems trying to restore data/oob -- MTD
utils don't do this well. This time I thought disabling writes
would save me, ho-hum].
> > 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?
Yes, see above.
> 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.
I read it differently -- looks to me like the original file with
objectId A got relinked to the deleted-file directory when VFS
unlinked it and at this point it's on-NAND data was updated to
have ID 4 as the parent obj. But the data chunks belonging to
the file would not have been marked on-NAND, just soft deleted,
so they are seen during the scan, and a new 'prototype' file
object is created with objectId A. This then clashes with the
directory objectId A, which I presume was created after the
original file objectId A was (soft) deleted. Does this make any
sense?
-imcd
(text/plain)