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.
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....
Cheers,
Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
