Inode lockdep problem observed on 2.6.37.6 xfs with RT subvolume

[Kamal Dasu]

On Thu, Feb 2, 2012 at 4:13 AM, Christoph Hellwig <hch at infradead.org> wrote:
> On Wed, Feb 01, 2012 at 07:44:13PM -0500, Kamal Dasu wrote:
>> Need some help understanding the state of xfs with rt subvolume
>> support on 2.6.37.
>>
>> When using xfs rt subvolume on a harddisk partition with kernel
>> 2.6.37.6,and normal r/w/delete file operations? causes deadlock
>> like hangs .? Failure? symptoms are lockups and mount failure on reboot.
>>
>> On further investigation it was found that one of the changes could be
>> the cause.
>> The same tests seem to pass with xfs in 2.6.31 kernel.
>>
>> xfs: simplify xfs_trans_iget? : aa72a5cf00001d0b952c7c755be404b9118ceb2e
>> http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commitdiff;h=aa72a5cf00001d0b952c7c755be404b9118ceb2e
>>
>> Reverting the change and forward porting to the xfs_trans_inode() seems to
>> get rid of the deadlock and mount issues .
>>
>> Below is the change
>
> Please just upgrade to Linux 2.6.39 or better Linux 3.0 which is the
> long term support release. RT subvolume support has been fixed in 2.6.39
> by the following changes:
>
>  xfs: only lock the rt bitmap inode once per allocation
>  xfs: fix xfs_get_extsz_hint for a zero extent size hint
>  xfs: add lockdep annotations for the rt inodes
>
> But in general the RT subvolume code is not regularly tested and only
> fixed when issues arise.


Thanks for quick reply and clarifying this, if upgrading the kernel is
not an option, should I be
considering backporting  changes to 2.6.37,  should I  use the entire
2.6.39 or 3.0
xfs implementation as is of cherry pick the above three changes ?.

Regards
Kamal