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