Help debugging a use after free

[Stuart MENEFY]

Dave Chinner wrote:
> On Fri, Apr 17, 2009 at 04:30:09PM +0100, Stuart MENEFY wrote:
>>> If you can instrument actually free that is causing the problem it
>>> would be good to print out the
>>> actually pid doing the free and as many return addresses that you can,
>>> so we can get an
>>> idea of the actual call chain.
>> The free is coming from the xfssyncd thread, the back trace looks like:
>>
>> [<8418d0e2>] xfs_idestroy+0x22/0x100
>> [<8418a1b0>] xfs_ireclaim+0x50/0x80
>> [<841ad7f2>] xfs_finish_reclaim+0x32/0x1c0
>> [<841ada30>] xfs_finish_reclaim_all+0xb0/0x100
>> [<8418a780>] xfs_ilock_nowait+0x0/0x160
>> [<841a9df2>] xfs_syncsub+0x52/0x360
>> [<84335108>] schedule_timeout+0x48/0x100
>> [<841ab684>] xfs_sync+0x24/0x40
>> [<841e0ce0>] list_add+0x0/0x20
>> [<841c041c>] vfs_sync+0x1c/0x40
>> [<841bf37c>] vfs_sync_worker+0x1c/0x60
>> [<841bf6b6>] xfssyncd+0xb6/0x140
>> [<8402f0dc>] kthread+0x3c/0x80
>> [<84012440>] complete+0x0/0x60
>> [<841bf600>] xfssyncd+0x0/0x140
>> [<8402f060>] kthread_should_stop+0x0/0x20
>> [<84003984>] kernel_thread_helper+0x4/0x20
>> [<8402f0a0>] kthread+0x0/0x80
>> [<84003980>] kernel_thread_helper+0x0/0x20
> 
> There were some use-after-free fixes in .27 timeframe to the inode
> reclaim code. Can you reeetest with a more recent kernel?

Possibly. I have a half-finished port of 2.6.27-rc4 to our hardware
which I could probably get going fairly quickly. Do you think that
would be sufficient to pick up the use-after-free fixes?

Thanks

Stuart