BUG: workqueue leaked lock or atomic
Alex Elder
elder at inktank.com
Wed Dec 19 08:20:14 CST 2012
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.
Just a hunch...
-Alex
More information about the xfs
mailing list