| 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> |
|---|---|---|
| ||
| Previous by Date: | Re: BUG: workqueue leaked lock or atomic, Alex Elder |
|---|---|
| Next by Date: | ThÄm dà à kián vá cÃc hÃng vián thÃng tái Viát Nam, vietnammarketsurvey@xxxxxxxxx via surveymonkey.com |
| Previous by Thread: | Re: BUG: workqueue leaked lock or atomic, Alex Elder |
| Next by Thread: | Re: BUG: workqueue leaked lock or atomic, Dave Chinner |
| Indexes: | [Date] [Thread] [Top] [All Lists] |