On 12/19/2012 03:51 PM, Dave Chinner wrote:
> On Wed, Dec 19, 2012 at 08:20:14AM -0600, Alex Elder wrote:
>> On 12/19/2012 08:15 AM, Alex Elder wrote:
>> . . .
>>
>>> And this:
>>> 1 lock held by kworker/0:1/17554:
>>> #0: (sb_internal#2){.+.+.+}, at: [<ffffffffa03a232b>]
>>> xfs_end_io+0x2b/0x110 [xfs]
>>>
>>> corresponds to this call to rwsem_acquire_read():
>>>
>>> if (ioend->io_append_trans) {
>>> /*
>>> * We've got freeze protection passed with the transaction.
>>> * Tell lockdep about it.
>>> */
>>> rwsem_acquire_read( <--------
>>>
>>> &ioend->io_inode->i_sb->s_writers.lock_map[SB_FREEZE_FS-1],
>>> 0, 1, _THIS_IP_);
>>> }
>>>
>>> So maybe it's a false report? I don't know.
>>
>> I suspect that lockdep-informational call has to be un-done
>> somehow in the error paths.
>>
>> I think the test to XFS_FORCED_SHUTDOWN() immediately following
>> that might have been taken and the proper cleanup didn't get
>> done before releasing the ioend structure.
>
> Yeah, that will be the cause - the transaction is not getting
> cancelled in this case.
>
> However, the code is different in the current 3.8 tree, and the
> transfer of the freeze status occurs after the shutdown check, so
> this particular problem is already fixed.
OK, great, thanks for confirming this. -Alex
> What is not fixed, however, is that the transaction is still leaked
> in this shutdown case. That's not a big deal, but still should be
> fixed....
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
