On Thursday 01 July 2010 16:10:16 YingChao LI wrote:
> Thanks for your quickly responds.
>
> One concern is that why sc buffer(0xd6f01780) is still in search context
> doubly linked list after freed. In another word, who modified the prev
> pointer of "sc other(0xd6f0178c)" and the next pointer of "sc
> other(0xdc1e40c8)" after sc buffer(0xd6f01780) is freed.
The problem was caused by the end part of yaffs_readdir unlocking before
cleaning up the search context. That means the ordering of the free and the
iteration of the yaffs_RemoveObjectCallback() is not controlled.
This can result in the following:
task 1 does read_dir() up to the Unlock()
task2 locks and calls RemoveObjectCallback() getting a pointer to sc
task 1 resumes and frees sc
task2 tries to use sc pointer
As you can see, it requires taks switching at extremely precise points of
execution making it hard to reproduce.
This has been fixed by ensuring that the free is done under the control of the
lock. Now it is impossible to iterate the list while the free is happening.
I hope that helps....
-- Charles
>
> Thanks a lot.
>
> On Thu, Jul 1, 2010 at 10:34 AM, Charles Manning
<
manningc2@actrix.gen.nz>wrote:
> > On Wednesday 30 June 2010 18:49:57 YingChao LI wrote:
> > [snip]
> >
> > > Panic occurs when call yaffs_RemoveObjectCallback at line:
> > > if(sc->nextReturn == obj), because referred the buffer has been freed
> > > by yaffs_readdir. Seems sc buffer(*0xd6f01780*) has been freed, but
> > > still in search context doubly linked list(the next pointer of "sc**
> > > other(*0xdc1e40c8)*" is* 0xd6f0178c*, the prev pointer of
> > > "*0xd6f0178c*" is *0xdc1e40c8*). Is it possible that the search context
> > > lock mechanism
> >
> > has
> >
> > > some issue or other reason?
> > >
> > > I only met this panic once, and can NOT reproduce it. Any suggestion
> >
> > about
> >
> > > this? Thanks a lot.
> >
> > Thanks for pointing that out.
> >
> > This will be hard to reproduce.
> >
> > There was indeed a problem in the locking of the search context. This
> > has been fixed.
> >
> > http://yaffs.net/gitweb?p=yaffs2/.git;a=commit;h=c1399b62aaa71a3da498b5fa
> >67adb25e59181ab0
(text/plain)