From: Chris Mason <clm@fb.com>
To: Fengguang Wu <fengguang.wu@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>, LKP <lkp@01.org>,
<linux-kernel@vger.kernel.org>, <linux-fsdevel@vger.kernel.org>,
Shaohua Li <shli@kernel.org>,
Dan Williams <dan.j.williams@intel.com>,
NeilBrown <neilb@suse.de>,
"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: __might_sleep() warnings on v3.19-rc6
Date: Thu, 5 Feb 2015 11:16:03 -0500 [thread overview]
Message-ID: <20150205161603.GA6561@ret.masoncoding.com> (raw)
In-Reply-To: <20150201034315.GA20124@wfg-t540p.sh.intel.com>
On Sat, Jan 31, 2015 at 07:43:15PM -0800, Fengguang Wu wrote:
> Hi all,
>
> I see 2 __might_sleep() warnings on when running LKP tests on
> v3.19-rc6, one related to raid5 and another related to btrfs.
>
> They might be exposed by this patch.
> FSUse% Count Size Files/sec App Overhead
> [ 101.678419] ------------[ cut here ]------------
> [ 101.684612] WARNING: CPU: 4 PID: 2153 at kernel/sched/core.c:7300 __might_sleep+0xbd/0xd0()
> [ 101.696412] do not call blocking ops when !TASK_RUNNING; state=2 set at [<ffffffff810b63ff>] prepare_to_wait+0x2f/0x90
> [ 101.709259] Modules linked in: ipmi_watchdog btrfs sr_mod cdrom xor raid6_pq sg sd_mod snd_pcm snd_timer snd soundcore pcspkr mgag200 syscopyarea sysfillrect sysimgblt ttm ahci drm_kms_helper libahci drm libata usb_storage i2c_i801 ipmi_si ipmi_msghandler i7core_edac edac_core acpi_cpufreq
> [ 101.741823] CPU: 4 PID: 2153 Comm: fs_mark Not tainted 3.19.0-rc6-g26bc420b #1
> [ 101.750851] Hardware name: Intel Corporation S5520UR/S5520UR, BIOS S5500.86B.01.00.0050.050620101605 05/06/2010
> [ 101.763101] ffffffff81b75d50 ffff8801dd947c78 ffffffff818a38f0 ffff8801e9c500f8
> [ 101.772473] ffff8801dd947cc8 ffff8801dd947cb8 ffffffff8107260a 0000000000000004
> [ 101.781793] ffffffff81b76780 0000000000000061 0000000000000000 ffff8801e8438000
> [ 101.791140] Call Trace:
> [ 101.794751] [<ffffffff818a38f0>] dump_stack+0x4c/0x65
> [ 101.801386] [<ffffffff8107260a>] warn_slowpath_common+0x8a/0xc0
> [ 101.809003] [<ffffffff81072686>] warn_slowpath_fmt+0x46/0x50
> [ 101.816335] [<ffffffff810b63ff>] ? prepare_to_wait+0x2f/0x90
> [ 101.823616] [<ffffffff810b63ff>] ? prepare_to_wait+0x2f/0x90
> [ 101.830875] [<ffffffff8109874d>] __might_sleep+0xbd/0xd0
> [ 101.837766] [<ffffffff818a9364>] mutex_lock+0x24/0x50
> [ 101.844399] [<ffffffffa0285e88>] wait_for_writer+0x68/0xc0 [btrfs]
> [ 101.853029] [<ffffffff810b67e0>] ? wait_woken+0xc0/0xc0
> [ 101.859849] [<ffffffffa028b918>] btrfs_sync_log+0xf8/0xa70 [btrfs]
> [ 101.867740] [<ffffffffa028c7bd>] ? btrfs_log_dentry_safe+0x6d/0x80 [btrfs]
> [ 101.876395] [<ffffffffa02605d2>] btrfs_sync_file+0x2f2/0x330 [btrfs]
> [ 101.884375] [<ffffffff81218101>] do_fsync+0x51/0x80
> [ 101.890737] [<ffffffff81197977>] ? might_fault+0x47/0x50
> [ 101.897610] [<ffffffff812183a0>] SyS_fsync+0x10/0x20
> [ 101.904096] [<ffffffff818ac029>] system_call_fastpath+0x12/0x17
> [ 101.911647] ---[ end trace 77681997f1c4e23f ]---
> 1 51200 8192 365.3 2076332
The btrfs one will only trigger when we don't actually schedule:
while (atomic_read(&root->log_writers)) {
prepare_to_wait(&root->log_writer_wait,
&wait, TASK_UNINTERRUPTIBLE);
mutex_unlock(&root->log_mutex);
if (atomic_read(&root->log_writers))
schedule();
mutex_lock(&root->log_mutex);
finish_wait(&root->log_writer_wait, &wait);
}
I'll switch things around.
-chris
WARNING: multiple messages have this Message-ID (diff)
From: Chris Mason <clm@fb.com>
To: lkp@lists.01.org
Subject: Re: __might_sleep() warnings on v3.19-rc6
Date: Thu, 05 Feb 2015 11:16:03 -0500 [thread overview]
Message-ID: <20150205161603.GA6561@ret.masoncoding.com> (raw)
In-Reply-To: <20150201034315.GA20124@wfg-t540p.sh.intel.com>
[-- Attachment #1: Type: text/plain, Size: 3132 bytes --]
On Sat, Jan 31, 2015 at 07:43:15PM -0800, Fengguang Wu wrote:
> Hi all,
>
> I see 2 __might_sleep() warnings on when running LKP tests on
> v3.19-rc6, one related to raid5 and another related to btrfs.
>
> They might be exposed by this patch.
> FSUse% Count Size Files/sec App Overhead
> [ 101.678419] ------------[ cut here ]------------
> [ 101.684612] WARNING: CPU: 4 PID: 2153 at kernel/sched/core.c:7300 __might_sleep+0xbd/0xd0()
> [ 101.696412] do not call blocking ops when !TASK_RUNNING; state=2 set at [<ffffffff810b63ff>] prepare_to_wait+0x2f/0x90
> [ 101.709259] Modules linked in: ipmi_watchdog btrfs sr_mod cdrom xor raid6_pq sg sd_mod snd_pcm snd_timer snd soundcore pcspkr mgag200 syscopyarea sysfillrect sysimgblt ttm ahci drm_kms_helper libahci drm libata usb_storage i2c_i801 ipmi_si ipmi_msghandler i7core_edac edac_core acpi_cpufreq
> [ 101.741823] CPU: 4 PID: 2153 Comm: fs_mark Not tainted 3.19.0-rc6-g26bc420b #1
> [ 101.750851] Hardware name: Intel Corporation S5520UR/S5520UR, BIOS S5500.86B.01.00.0050.050620101605 05/06/2010
> [ 101.763101] ffffffff81b75d50 ffff8801dd947c78 ffffffff818a38f0 ffff8801e9c500f8
> [ 101.772473] ffff8801dd947cc8 ffff8801dd947cb8 ffffffff8107260a 0000000000000004
> [ 101.781793] ffffffff81b76780 0000000000000061 0000000000000000 ffff8801e8438000
> [ 101.791140] Call Trace:
> [ 101.794751] [<ffffffff818a38f0>] dump_stack+0x4c/0x65
> [ 101.801386] [<ffffffff8107260a>] warn_slowpath_common+0x8a/0xc0
> [ 101.809003] [<ffffffff81072686>] warn_slowpath_fmt+0x46/0x50
> [ 101.816335] [<ffffffff810b63ff>] ? prepare_to_wait+0x2f/0x90
> [ 101.823616] [<ffffffff810b63ff>] ? prepare_to_wait+0x2f/0x90
> [ 101.830875] [<ffffffff8109874d>] __might_sleep+0xbd/0xd0
> [ 101.837766] [<ffffffff818a9364>] mutex_lock+0x24/0x50
> [ 101.844399] [<ffffffffa0285e88>] wait_for_writer+0x68/0xc0 [btrfs]
> [ 101.853029] [<ffffffff810b67e0>] ? wait_woken+0xc0/0xc0
> [ 101.859849] [<ffffffffa028b918>] btrfs_sync_log+0xf8/0xa70 [btrfs]
> [ 101.867740] [<ffffffffa028c7bd>] ? btrfs_log_dentry_safe+0x6d/0x80 [btrfs]
> [ 101.876395] [<ffffffffa02605d2>] btrfs_sync_file+0x2f2/0x330 [btrfs]
> [ 101.884375] [<ffffffff81218101>] do_fsync+0x51/0x80
> [ 101.890737] [<ffffffff81197977>] ? might_fault+0x47/0x50
> [ 101.897610] [<ffffffff812183a0>] SyS_fsync+0x10/0x20
> [ 101.904096] [<ffffffff818ac029>] system_call_fastpath+0x12/0x17
> [ 101.911647] ---[ end trace 77681997f1c4e23f ]---
> 1 51200 8192 365.3 2076332
The btrfs one will only trigger when we don't actually schedule:
while (atomic_read(&root->log_writers)) {
prepare_to_wait(&root->log_writer_wait,
&wait, TASK_UNINTERRUPTIBLE);
mutex_unlock(&root->log_mutex);
if (atomic_read(&root->log_writers))
schedule();
mutex_lock(&root->log_mutex);
finish_wait(&root->log_writer_wait, &wait);
}
I'll switch things around.
-chris
next prev parent reply other threads:[~2015-02-05 16:17 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-28 14:25 WARNING: CPU: 0 PID: 61 at kernel/sched/core.c:7312 __might_sleep() Fengguang Wu
2014-10-28 14:25 ` Fengguang Wu
2014-10-29 16:16 ` [PATCH] netdev: Fix sleeping inside wait event Peter Zijlstra
2014-10-29 16:16 ` Peter Zijlstra
2014-10-29 16:29 ` Cong Wang
2014-10-29 16:29 ` Cong Wang
2014-10-29 17:13 ` Peter Zijlstra
2014-10-29 17:13 ` Peter Zijlstra
2014-10-29 17:31 ` Peter Zijlstra
2014-10-29 17:31 ` Peter Zijlstra
2014-10-29 17:38 ` David Miller
2014-10-29 17:38 ` David Miller
2014-11-04 16:09 ` [tip:sched/core] netdev, sched/wait: " tip-bot for Peter Zijlstra
2014-10-29 17:37 ` [PATCH] netdev: " David Miller
2014-10-29 17:37 ` David Miller
2015-02-01 3:43 ` __might_sleep() warnings on v3.19-rc6 Fengguang Wu
2015-02-01 3:43 ` Fengguang Wu
2015-02-01 23:03 ` NeilBrown
2015-02-01 23:03 ` NeilBrown
2015-02-02 4:58 ` NeilBrown
2015-02-02 4:58 ` NeilBrown
2015-02-02 5:08 ` Linus Torvalds
2015-02-02 5:08 ` Linus Torvalds
2015-02-02 6:09 ` NeilBrown
2015-02-02 6:09 ` NeilBrown
2015-02-05 16:16 ` Chris Mason [this message]
2015-02-05 16:16 ` Chris Mason
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=20150205161603.GA6561@ret.masoncoding.com \
--to=clm@fb.com \
--cc=dan.j.williams@intel.com \
--cc=fengguang.wu@intel.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@01.org \
--cc=neilb@suse.de \
--cc=peterz@infradead.org \
--cc=shli@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.