* [GIT PULL] Btrfs
@ 2016-08-26 23:36 Chris Mason
2016-09-08 11:48 ` lockdep warning in btrfs in 4.8-rc3 Christian Borntraeger
0 siblings, 1 reply; 6+ messages in thread
From: Chris Mason @ 2016-08-26 23:36 UTC (permalink / raw)
To: Linus Torvalds, LKML, linux-btrfs
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(-)
^ permalink raw reply [flat|nested] 6+ messages in thread
* lockdep warning in btrfs in 4.8-rc3
2016-08-26 23:36 [GIT PULL] Btrfs Chris Mason
@ 2016-09-08 11:48 ` Christian Borntraeger
2016-09-08 11:50 ` Christian Borntraeger
0 siblings, 1 reply; 6+ messages in thread
From: Christian Borntraeger @ 2016-09-08 11:48 UTC (permalink / raw)
To: Chris Mason, LKML, linux-btrfs
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: lockdep warning in btrfs in 4.8-rc3
2016-09-08 11:48 ` lockdep warning in btrfs in 4.8-rc3 Christian Borntraeger
@ 2016-09-08 11:50 ` Christian Borntraeger
2016-09-08 12:58 ` Chris Mason
0 siblings, 1 reply; 6+ messages in thread
From: Christian Borntraeger @ 2016-09-08 11:50 UTC (permalink / raw)
To: Chris Mason, LKML, linux-btrfs
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: lockdep warning in btrfs in 4.8-rc3
2016-09-08 11:50 ` Christian Borntraeger
@ 2016-09-08 12:58 ` Chris Mason
2016-09-09 0:50 ` Dave Jones
0 siblings, 1 reply; 6+ messages in thread
From: Chris Mason @ 2016-09-08 12:58 UTC (permalink / raw)
To: Christian Borntraeger, LKML, linux-btrfs
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.
-chris
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: lockdep warning in btrfs in 4.8-rc3
2016-09-08 12:58 ` Chris Mason
@ 2016-09-09 0:50 ` Dave Jones
2016-09-09 15:19 ` Chris Mason
0 siblings, 1 reply; 6+ messages in thread
From: Dave Jones @ 2016-09-09 0:50 UTC (permalink / raw)
To: Chris Mason; +Cc: Christian Borntraeger, LKML, linux-btrfs
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: lockdep warning in btrfs in 4.8-rc3
2016-09-09 0:50 ` Dave Jones
@ 2016-09-09 15:19 ` Chris Mason
0 siblings, 0 replies; 6+ messages in thread
From: Chris Mason @ 2016-09-09 15:19 UTC (permalink / raw)
To: Dave Jones, Christian Borntraeger, LKML, linux-btrfs
On 09/08/2016 08:50 PM, Dave Jones wrote:
> 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.
I haven't seen this one before, if you could make it happen again, that
would be great ;)
-chris
>
> Dave
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-09-09 15:19 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-08-26 23:36 [GIT PULL] Btrfs Chris Mason
2016-09-08 11:48 ` lockdep warning in btrfs in 4.8-rc3 Christian Borntraeger
2016-09-08 11:50 ` Christian Borntraeger
2016-09-08 12:58 ` Chris Mason
2016-09-09 0:50 ` Dave Jones
2016-09-09 15:19 ` Chris Mason
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.