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 08:20:14 -0600
Cc: xfs@xxxxxxxxxxx
In-reply-to: <50D1CBED.9000409@xxxxxxxxxxx>
References: <50D07CC2.3020508@xxxxxxxxxxx> <20121218204330.GD15182@dastard> <50D1CBED.9000409@xxxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0
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

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