Re: BUG: workqueue leaked lock or atomic

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs


[Index of Archives]     [Linux XFS Devel]     [Linux Filesystem Development]     [Filesystem Testing]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux