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
>
(text/plain)