xfs
[Top] [All Lists]

Re: BUG: workqueue leaked lock or atomic

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: BUG: workqueue leaked lock or atomic
From: Alex Elder <elder@xxxxxxxxxxx>
Date: Wed, 19 Dec 2012 16:58:01 -0600
Cc: xfs@xxxxxxxxxxx
In-reply-to: <20121219215143.GL15182@dastard>
References: <50D07CC2.3020508@xxxxxxxxxxx> <20121218204330.GD15182@dastard> <50D1CBED.9000409@xxxxxxxxxxx> <50D1CD1E.4030406@xxxxxxxxxxx> <20121219215143.GL15182@dastard>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0
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....

<Prev in Thread] Current Thread [Next in Thread>