Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1471047 > unrolled thread
| Started by | Chris Mason <clm@fb.com> |
|---|---|
| First post | 2016-08-27 01:50 +0200 |
| Last post | 2016-09-09 03:00 +0200 |
| Articles | 4 — 3 participants |
Back to article view | Back to linux.kernel
[GIT PULL] Btrfs Chris Mason <clm@fb.com> - 2016-08-27 01:50 +0200
lockdep warning in btrfs in 4.8-rc3 Christian Borntraeger <borntraeger@de.ibm.com> - 2016-09-08 13:50 +0200
Re: lockdep warning in btrfs in 4.8-rc3 Christian Borntraeger <borntraeger@de.ibm.com> - 2016-09-08 14:00 +0200
Re: lockdep warning in btrfs in 4.8-rc3 Dave Jones <davej@codemonkey.org.uk> - 2016-09-09 03:00 +0200
| From | Chris Mason <clm@fb.com> |
|---|---|
| Date | 2016-08-27 01:50 +0200 |
| Subject | [GIT PULL] Btrfs |
| Message-ID | <saz2N-5kf-7@gated-at.bofh.it> |
Hi Linus,
Please pull my for-linus-4.8 branch:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus-4.8
We've queued up a few different fixes in here. These range from enospc
corners to fsync and quota fixes, and a few targeted at
error handling for corrupt metadata/fuzzing.
Liu Bo (5) commits (+60/-2):
Btrfs: detect corruption when non-root leaf has zero item (+22/-1)
Btrfs: add ASSERT for block group's memory leak (+5/-0)
Btrfs: clarify do_chunk_alloc()'s return value (+9/-0)
Btrfs: fix memory leak of reloc_root (+8/-1)
Btrfs: check btree node's nritems (+16/-0)
Qu Wenruo (4) commits (+191/-53):
btrfs: relocation: Fix leaking qgroups numbers on data extents (+103/-6)
btrfs: qgroup: Fix qgroup incorrectness caused by log replay (+16/-0)
btrfs: qgroup: Refactor btrfs_qgroup_insert_dirty_extent() (+71/-47)
btrfs: backref: Fix soft lockup in __merge_refs function (+1/-0)
Wang Xiaoguang (4) commits (+161/-108):
btrfs: use correct offset for reloc_inode in prealloc_file_extent_cluster() (+6/-4)
btrfs: divide btrfs_update_reserved_bytes() into two functions (+57/-40)
btrfs: update btrfs_space_info's bytes_may_use timely (+73/-63)
btrfs: fix fsfreeze hang caused by delayed iputs deal (+25/-1)
Jeff Mahoney (3) commits (+45/-18):
btrfs: don't create or leak aliased root while cleaning up orphans (+22/-11)
btrfs: waiting on qgroup rescan should not always be interruptible (+13/-6)
btrfs: properly track when rescan worker is running (+10/-1)
Filipe Manana (1) commits (+8/-4):
Btrfs: fix lockdep warning on deadlock against an inode's log mutex
Anand Jain (1) commits (+19/-8):
btrfs: do not background blkdev_put()
Alex Lyakas (1) commits (+1/-1):
btrfs: flush_space: treat return value of do_chunk_alloc properly
Josef Bacik (1) commits (+1/-0):
Btrfs: fix em leak in find_first_block_group
Total: (20) commits
fs/btrfs/backref.c | 1 +
fs/btrfs/ctree.h | 5 +-
fs/btrfs/delayed-ref.c | 7 +-
fs/btrfs/disk-io.c | 56 +++++++++++++--
fs/btrfs/disk-io.h | 2 +
fs/btrfs/extent-tree.c | 185 +++++++++++++++++++++++--------------------------
fs/btrfs/extent_io.h | 1 +
fs/btrfs/file.c | 28 ++++----
fs/btrfs/inode-map.c | 3 +-
fs/btrfs/inode.c | 37 +++++++---
fs/btrfs/ioctl.c | 2 +-
fs/btrfs/qgroup.c | 62 ++++++++++++++---
fs/btrfs/qgroup.h | 36 ++++++++--
fs/btrfs/relocation.c | 126 ++++++++++++++++++++++++++++++---
fs/btrfs/root-tree.c | 27 +++++---
fs/btrfs/super.c | 16 +++++
fs/btrfs/transaction.c | 7 +-
fs/btrfs/tree-log.c | 21 +++++-
fs/btrfs/tree-log.h | 5 +-
fs/btrfs/volumes.c | 27 +++++---
20 files changed, 473 insertions(+), 181 deletions(-)
[toc] | [next] | [standalone]
| From | Christian Borntraeger <borntraeger@de.ibm.com> |
|---|---|
| Date | 2016-09-08 13:50 +0200 |
| Subject | lockdep warning in btrfs in 4.8-rc3 |
| Message-ID | <sf60a-5gF-7@gated-at.bofh.it> |
| In reply to | #1471047 |
Chris,
with 4.8-rc3 I get the following on an s390 box:
[ 1094.009172] =============================================
[ 1094.009174] [ INFO: possible recursive locking detected ]
[ 1094.009177] 4.8.0-rc3 #126 Tainted: G W
[ 1094.009179] ---------------------------------------------
[ 1094.009180] vim/12891 is trying to acquire lock:
[ 1094.009182] (&ei->log_mutex){+.+...}, at: [<000003ff817e83c6>] btrfs_log_inode+0x126/0x1010 [btrfs]
[ 1094.009256]
but task is already holding lock:
[ 1094.009258] (&ei->log_mutex){+.+...}, at: [<000003ff817e83c6>] btrfs_log_inode+0x126/0x1010 [btrfs]
[ 1094.009276]
other info that might help us debug this:
[ 1094.009278] Possible unsafe locking scenario:
[ 1094.009280] CPU0
[ 1094.009281] ----
[ 1094.009282] lock(&ei->log_mutex);
[ 1094.009284] lock(&ei->log_mutex);
[ 1094.009286]
*** DEADLOCK ***
[ 1094.009288] May be due to missing lock nesting notation
[ 1094.009290] 3 locks held by vim/12891:
[ 1094.009291] #0: (&sb->s_type->i_mutex_key#15){+.+.+.}, at: [<000003ff817afbd6>] btrfs_sync_file+0x1de/0x5e8 [btrfs]
[ 1094.009311] #1: (sb_internal#2){.+.+..}, at: [<000000000035e0ba>] __sb_start_write+0x122/0x138
[ 1094.009320] #2: (&ei->log_mutex){+.+...}, at: [<000003ff817e83c6>] btrfs_log_inode+0x126/0x1010 [btrfs]
[ 1094.009370]
stack backtrace:
[ 1094.009375] CPU: 14 PID: 12891 Comm: vim Tainted: G W 4.8.0-rc3 #126
[ 1094.009377] Hardware name: IBM 2964 NC9 704 (LPAR)
[ 1094.009380] 000000f061367608 000000f061367698 0000000000000002 0000000000000000
000000f061367738 000000f0613676b0 000000f0613676b0 00000000001133ec
0000000000000000 0000000000000000 000000f70000000a 000000f70000000a
000000f0613676f8 000000f061367698 0000000000000000 0000000000000000
0400000001d821c8 00000000001133ec 000000f061367698 000000f0613676e8
[ 1094.009396] Call Trace:
[ 1094.009401] ([<0000000000113334>] show_trace+0xec/0xf0)
[ 1094.009403] ([<000000000011339a>] show_stack+0x62/0xe8)
[ 1094.009406] ([<000000000055211c>] dump_stack+0x9c/0xe0)
[ 1094.009411] ([<00000000001d9930>] validate_chain.isra.22+0xc00/0xd70)
[ 1094.009413] ([<00000000001dad9c>] __lock_acquire+0x39c/0x7d8)
[ 1094.009414] ([<00000000001db8d0>] lock_acquire+0x108/0x320)
[ 1094.009420] ([<00000000008845c6>] mutex_lock_nested+0x86/0x3f8)
[ 1094.009440] ([<000003ff817e83c6>] btrfs_log_inode+0x126/0x1010 [btrfs])
[ 1094.009457] ([<000003ff817e8fb2>] btrfs_log_inode+0xd12/0x1010 [btrfs])
[ 1094.009474] ([<000003ff817e95b4>] btrfs_log_inode_parent+0x244/0x980 [btrfs])
[ 1094.009490] ([<000003ff817eafea>] btrfs_log_dentry_safe+0x7a/0xa0 [btrfs])
[ 1094.009506] ([<000003ff817afe1a>] btrfs_sync_file+0x422/0x5e8 [btrfs])
[ 1094.009512] ([<000000000039e64e>] do_fsync+0x5e/0x90)
[ 1094.009514] ([<000000000039e9e2>] SyS_fsync+0x32/0x40)
[ 1094.009517] ([<000000000088a336>] system_call+0xd6/0x270)
[ 1094.009518] INFO: lockdep is turned off.
[toc] | [prev] | [next] | [standalone]
| From | Christian Borntraeger <borntraeger@de.ibm.com> |
|---|---|
| Date | 2016-09-08 14:00 +0200 |
| Subject | Re: lockdep warning in btrfs in 4.8-rc3 |
| Message-ID | <sf69Q-5kf-15@gated-at.bofh.it> |
| In reply to | #1479130 |
On 09/08/2016 01:48 PM, Christian Borntraeger wrote: > Chris, > > with 4.8-rc3 I get the following on an s390 box: Sorry for the noise, just saw the fix in your pull request.
[toc] | [prev] | [next] | [standalone]
| From | Dave Jones <davej@codemonkey.org.uk> |
|---|---|
| Date | 2016-09-09 03:00 +0200 |
| Subject | Re: lockdep warning in btrfs in 4.8-rc3 |
| Message-ID | <sfikF-4uk-1@gated-at.bofh.it> |
| In reply to | #1479138 |
On Thu, Sep 08, 2016 at 08:58:48AM -0400, Chris Mason wrote: > On 09/08/2016 07:50 AM, Christian Borntraeger wrote: > > On 09/08/2016 01:48 PM, Christian Borntraeger wrote: > >> Chris, > >> > >> with 4.8-rc3 I get the following on an s390 box: > > > > Sorry for the noise, just saw the fix in your pull request. > > > > The lockdep splat is still there, we'll need to annotate this one a little. Here's another one (unrelated?) that I've not seen before today: WARNING: CPU: 1 PID: 10664 at kernel/locking/lockdep.c:704 register_lock_class+0x33f/0x510 CPU: 1 PID: 10664 Comm: kworker/u8:5 Not tainted 4.8.0-rc5-think+ #2 Workqueue: writeback wb_workfn (flush-btrfs-1) 0000000000000097 00000000b97fbad3 ffff88013b8c3770 ffffffffa63d3ab1 0000000000000000 0000000000000000 ffffffffa6bf1792 ffffffffa60df22f ffff88013b8c37b0 ffffffffa60897a0 000002c0b97fbad3 ffffffffa6bf1792 Call Trace: [<ffffffffa63d3ab1>] dump_stack+0x6c/0x9b [<ffffffffa60df22f>] ? register_lock_class+0x33f/0x510 [<ffffffffa60897a0>] __warn+0x110/0x130 [<ffffffffa608992c>] warn_slowpath_null+0x2c/0x40 [<ffffffffa60df22f>] register_lock_class+0x33f/0x510 [<ffffffffa639d9ce>] ? bio_add_page+0x7e/0x120 [<ffffffffa60e082b>] __lock_acquire.isra.32+0x5b/0x8c0 [<ffffffffa60e1438>] lock_acquire+0x58/0x70 [<ffffffffc041c08a>] ? btrfs_try_tree_write_lock+0x4a/0xb0 [btrfs] [<ffffffffa69c5728>] _raw_write_lock+0x38/0x70 [<ffffffffc041c08a>] ? btrfs_try_tree_write_lock+0x4a/0xb0 [btrfs] [<ffffffffc041c08a>] btrfs_try_tree_write_lock+0x4a/0xb0 [btrfs] [<ffffffffc03f25f8>] lock_extent_buffer_for_io+0x28/0x2e0 [btrfs] [<ffffffffc03fc261>] btree_write_cache_pages+0x231/0x550 [btrfs] [<ffffffffc03c0cf0>] ? btree_set_page_dirty+0x20/0x20 [btrfs] [<ffffffffc03c0d64>] btree_writepages+0x74/0x90 [btrfs] [<ffffffffa619eb6e>] do_writepages+0x3e/0x80 [<ffffffffa6266ba2>] __writeback_single_inode+0x42/0x220 [<ffffffffa6267601>] writeback_sb_inodes+0x351/0x730 [<ffffffffa619aae1>] ? __wb_update_bandwidth+0x1c1/0x2b0 [<ffffffffa6267cd8>] wb_writeback+0x138/0x2a0 [<ffffffffa626854e>] wb_workfn+0x10e/0x340 [<ffffffffa60e099f>] ? __lock_acquire.isra.32+0x1cf/0x8c0 [<ffffffffa60aa05f>] process_one_work+0x24f/0x5d0 [<ffffffffa60a9ff0>] ? process_one_work+0x1e0/0x5d0 [<ffffffffa60aa433>] worker_thread+0x53/0x5b0 [<ffffffffa60aa3e0>] ? process_one_work+0x5d0/0x5d0 [<ffffffffa60b11a0>] kthread+0x120/0x140 [<ffffffffa60b782a>] ? finish_task_switch+0x6a/0x200 [<ffffffffa69c5d1f>] ret_from_fork+0x1f/0x40 [<ffffffffa60b1080>] ? kthread_create_on_node+0x270/0x270 ---[ end trace 7b39395c07435bf1 ]--- 700 /* 701 * Huh! same key, different name? Did someone trample 702 * on some memory? We're most confused. 703 */ 704 WARN_ON_ONCE(class->name != lock->name); That seems kinda scary. There was a trinity run going on at the same time, so this _might_ be a random scribble from something unrelated to btrfs, but just in case.. IWBNI that code printed out both cases so I could see if this was corruption or two unrelated keys. I'll make it do that in case it happens again. Dave
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web