Yes, In this case, yaffs will panic. But in my understand, in this case, the prev pointer of  "sc other(0xd6f0178c)", should be "6b6b6b6b", I can NOT see why it is "dc1e40c8."

Thanks for your help.

<4>[121614.927886] R2: 0xd6f01700:
<4>[121614.933044] 1700  d282d900 d7972980 00000000 d68e1000 00000001 ffffffff 5a5a0000 fffffffe
<4>[121614.944427] 1720  00000000 00000000 00000000 00000000 635688c0 d84156c5 00000000 c00c3a5c
<4>[121614.955596] 1740  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
<4>[121614.966735] 1760  00000000 00000000 00000000 00000000 00000000 00000000 9d74e35b 09f91102
<4>[121614.978118] 1780  6b6b6b6b 6b6b6b6b 6b6b6b6b 6b6b6b6b dc1e40c8 6b6b6b6b 6b6b6b6b a56b6b6b
<4>[121614.989501] 17a0  00000000 00000000 00000000 00000000 9d74e35b 09f91102 00000000 c0142a10
<4>[121615.000701] 17c0  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
<4>[121615.012084] 17e0  00000000 00000000 00000000 00000000 00000000 00000000 635688c0 d84156c5


On Thu, Jul 1, 2010 at 12:34 PM, Charles Manning <manningc2@actrix.gen.nz> wrote:
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



_______________________________________________
yaffs mailing list
yaffs@lists.aleph1.co.uk
http://lists.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs