From: Chris Mason <clm@fb.com>
To: Tsutomu Itoh <t-itoh@jp.fujitsu.com>
Cc: Linux Btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: [3.16-rc1] BUG: soft lockup - CPU#0 stuck for 23s! [kworker/u25:4:5189]
Date: Tue, 17 Jun 2014 00:48:22 -0400 [thread overview]
Message-ID: <539FC896.5010909@fb.com> (raw)
In-Reply-To: <539FB0AE.7010404@jp.fujitsu.com>
On 06/16/2014 11:06 PM, Tsutomu Itoh wrote:
> On 2014/06/17 11:10, Tsutomu Itoh wrote:
>> On 2014/06/17 9:47, Chris Mason wrote:
>>> On 06/16/2014 07:57 PM, Tsutomu Itoh wrote:
>>>> On 2014/06/17 8:52, Chris Mason wrote:
>>>>> On 06/16/2014 07:28 PM, Tsutomu Itoh wrote:
>>>>>> Hi Chris,
>>>>>>
>>>>>> On 2014/06/17 2:56, Chris Mason wrote:
>>>>>>> On 06/16/2014 02:35 AM, Tsutomu Itoh wrote:
>>>>>>>> I encountered soft lockup when executing 'xfstests btrfs/042' on 3.16-rc1.
>>>>>>>>
>>>>>>>
>>>>>>> Did we recover, or was it stuck forever?
>>>>>>
>>>>>> The following messages are repeatedly output.
>>>>>> And stuck forever.
>>>>>>
>>>>>> [ 1147.942181] BUG: soft lockup - CPU#0 stuck for 23s! [kworker/u25:4:5189]
>>>>>> [ 1147.967175] BUG: soft lockup - CPU#3 stuck for 23s! [kworker/u25:9:5194]
>>>>>> [ 1147.979172] BUG: soft lockup - CPU#4 stuck for 23s! [kworker/u25:15:5200]
>>>>>> [ 1147.991169] BUG: soft lockup - CPU#5 stuck for 23s! [kworker/u25:7:5192]
>>>>>> [ 1148.064153] BUG: soft lockup - CPU#6 stuck for 23s! [kworker/u26:3:3182]
>>>>>
>>>>> Can you please capture a stack trace from all the cpus?
>>>
>>> Very strange, please try to reproduce again, I'll dig through things here.
>>
>> I can reproduce it easily in my environment.
>
> This is my reproducer.
>
Great, I was able to trigger it here, but only with lockdep disabled.
When called from this part of btrfs_search_slot, the code for
btrfs_set_path_blocking goes through an extra step to set the lock on
the extent buffer we just found blocking before it is put into the path.
But this is only done with lockdep on. With lockdep off, we assume the
lock ordering inside the tree is protecting us and that we don't need to
worry about blocks that are not in the path yet.
Something is breaking this rule, probably in the quota code. I'll try
to nail down what is going on.
-chris
next prev parent reply other threads:[~2014-06-17 4:43 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-16 6:35 [3.16-rc1] BUG: soft lockup - CPU#0 stuck for 23s! [kworker/u25:4:5189] Tsutomu Itoh
2014-06-16 17:56 ` Chris Mason
2014-06-16 23:28 ` Tsutomu Itoh
2014-06-16 23:52 ` Chris Mason
2014-06-16 23:57 ` Tsutomu Itoh
2014-06-17 0:47 ` Chris Mason
2014-06-17 2:10 ` Tsutomu Itoh
2014-06-17 3:06 ` Tsutomu Itoh
2014-06-17 4:48 ` Chris Mason [this message]
2014-07-09 17:14 ` James Cloos
2014-06-17 4:52 ` Tsutomu Itoh
2014-06-17 1:11 ` Chris Mason
2014-06-17 1:36 ` Tsutomu Itoh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=539FC896.5010909@fb.com \
--to=clm@fb.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=t-itoh@jp.fujitsu.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).