Re: Help debugging a use after free

[Russell Cattelan <cattelan@thebarn.com>]

Stuart MENEFY wrote:
> Russell Cattelan wrote:
>   
>> Stuart MENEFY wrote:
>>     
>>> 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
>>>
>>>   
>>>       
>> Any reason you are using an rc4? vs 2.6.27?
>>     
>
> None, it just happened to be the latest at the time I did the work.
>
>   
>> I would simply run a diff over rc4 fs/xfs and 2.6.27 fs/xfs and see what
>> is different if anything.
>>     
>
> There are about 500 lines of diff. Tracking them back to the git commits its
> about 10 commits, most of which are self contained XFS specific changes,
> and a couple are simple changes which affect all users of a kernel wide API.
> So on a first glance bringing the XFS code upto 2.6.27 level wouldn't be a
> problem. One of these change is a use-after-free fix (in buffers, not inodes
> which appears to be the problem I'm seeing), so its probably worth the effort.
>
> OK, I'll give that a try, and see what happens.
>
> Stuart
>
>   
Ya I have not looked specifically to see what is there in terms of inode
use after free patches.

The problem will be to track down why the ref counting is out of wack,
and why it
is allowing for the inode to be released.

I wouldn't hurt to start with a more current xfs if possible to see if
it is still a problem.

-Russell

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs