Re: [PATCH] Btrfs: fix loss of prealloc extents past i_size after fsync log replay
Hi,
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag,
fixing commit: c71bf099abdd Btrfs: Avoid orphan inodes cleanup while replaying
log.
The bot has also determined it's probably a bug fixing patch. (score: 6.2138)
The bot has tested the following trees: v4.16.1, v4.15.16, v4.14.33, v4.9.93,
v4.4.127.
v4.16.1: Build OK!
v4.15.16: Build OK!
v4.14.33: Build OK!
v4.9.93: Build failed! Errors:
tree-log.c:2367:24: error: ‘struct btrfs_fs_info’ has no member named
‘sectorsize’
tree-log.c:2367:24: error: ‘struct btrfs_fs_info’ has no member named
‘sectorsize’
tree-log.c:4224:13: error: ‘struct inode’ has no member named ‘flags’; did
you mean ‘i_flags’?
tree-log.c:4229:38: error: ‘struct inode’ has no member named ‘vfs_inode’
tree-log.c:4239:4: error: implicit declaration of function ‘refcount_inc’;
did you mean ‘i_readcount_inc’? [-Werror=implicit-function-declaration]
v4.4.127: Failed to apply! Possible dependencies:
0132761017e0 ("btrfs: fix string and comment grammatical issues and typos")
--
Thanks,
SashaN�r��yb�X��ǧv�^�){.n�+{�n�߲)w* jg��� �ݢj/���z�ޖ��2�ޙ&�)ߡ�a���� �G���h��j:+v���w��٥
Re: [PATCH] btrfs: Fix possible softlock on single core machines
Hi, [This is an automated email] This commit has been processed because it contains a "Fixes:" tag, fixing commit: 6d74119f1a3e Btrfs: avoid taking the chunk_mutex in do_chunk_alloc. The bot has also determined it's probably a bug fixing patch. (score: 55.2868) The bot has tested the following trees: v4.16, v4.15.15, v4.14.32, v4.9.92, v4.4.126. v4.16: Build OK! v4.15.15: Build OK! v4.14.32: Build OK! v4.9.92: Build OK! v4.4.126: Build OK! -- Thanks, Sasha-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/16] btrfs: add sanity check when resuming balance after mount
Hi,
[This is an automated email]
This commit has been processed by the -stable helper bot and determined
to be a high probability candidate for -stable trees. (score: 16.7330)
The bot has tested the following trees: v4.16, v4.15.15, v4.14.32, v4.9.92,
v4.4.126.
v4.16: Build OK!
v4.15.15: Build OK!
v4.14.32: Build OK!
v4.9.92: Failed to apply! Possible dependencies:
509cdd5c938a ("btrfs: add sanity check when resuming balance after mount")
v4.4.126: Failed to apply! Possible dependencies:
509cdd5c938a ("btrfs: add sanity check when resuming balance after mount")
Please let us know if you'd like to have this patch included in a stable tree.
--
Thanks,
Sasha--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bitmap: fix memset optimization on big-endian systems
Hi, [This is an automated email] This commit has been processed because it contains a "Fixes:" tag, fixing commit: 2a98dc028f91 include/linux/bitmap.h: turn bitmap_set and bitmap_clear into memset when possible. The bot has also determined it's probably a bug fixing patch. (score: 65.4067) The bot has tested the following trees: v4.16, v4.15.15, v4.14.32. v4.16: Build OK! v4.15.15: Build OK! v4.14.32: Build OK! -- Thanks, Sasha-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/16] btrfs: add proper safety check before resuming dev-replace
Hi,
[This is an automated email]
This commit has been processed by the -stable helper bot and determined
to be a high probability candidate for -stable trees. (score: 34.4419)
The bot has tested the following trees: v4.16, v4.15.15, v4.14.32, v4.9.92,
v4.4.126.
v4.16: Build OK!
v4.15.15: Build OK!
v4.14.32: Build OK!
v4.9.92: Failed to apply! Possible dependencies:
2799d90f3887 ("btrfs: add proper safety check before resuming dev-replace")
v4.4.126: Failed to apply! Possible dependencies:
2799d90f3887 ("btrfs: add proper safety check before resuming dev-replace")
Please let us know if you'd like to have this patch included in a stable tree.
--
Thanks,
Sasha--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] Btrfs: fix NULL pointer dereference in log_dir_items
On Thu, Apr 05, 2018 at 07:11:14PM +0200, David Sterba wrote: >On Thu, Apr 05, 2018 at 04:42:34PM +0000, Sasha Levin wrote: >> Hi. >> >> [This is an automated email] >> >> This commit has been processed by the -stable helper bot and determined >> to be a high probability candidate for -stable trees. (score: 9.9156) >> >> The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, >> v4.4.126, >> >> v4.15.15: Build OK! >> v4.14.32: Build OK! >> v4.9.92: Build OK! >> v4.4.126: Build OK! >> >> Please let us know if you'd like to have this patch included in a stable >> tree. > >Yes, in this case we expect that the Fixes: tag will let the patch flow >to stable after it gets applied to master. > >The automated stable candidate patch scanning would be helpful in cases >where the Fixes tag is not identified or we forget to add it. I don't >mind helping to train the bot, so I'll try respond to the messages. Just to clarify, having just the "Fixes:" tag is not necessarily an indicator that a patch should go into -stable. For example, if I fix up documentation and add a Fixes: tag to point to the commit that added the original documentation, it's not -stable material since we don't take documentation patches. Or, if the patch that the new commit fixes didn't make it into any releases, it's not stable material either.-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] Btrfs: fix NULL pointer dereference in log_dir_items
Hi. [This is an automated email] This commit has been processed by the -stable helper bot and determined to be a high probability candidate for -stable trees. (score: 9.9156) The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.4.126, v4.15.15: Build OK! v4.14.32: Build OK! v4.9.92: Build OK! v4.4.126: Build OK! Please let us know if you'd like to have this patch included in a stable tree. -- Thanks. Sasha-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Please add 9c4f61f01d269815bb7c37be3ede59c5587747c6 to stable
On 04/23/2015 02:34 PM, Sasha Levin wrote: On 04/23/2015 02:24 PM, Josh Boyer wrote: On Thu, Apr 23, 2015 at 2:16 PM, Rich Freeman r-bt...@thefreemanclan.net wrote: On Mon, Apr 13, 2015 at 12:58 PM, Greg KH gre...@linuxfoundation.org wrote: On Mon, Apr 13, 2015 at 07:28:38PM +0500, Roman Mamedov wrote: On Thu, 2 Apr 2015 10:17:47 -0400 Chris Mason c...@fb.com wrote: Hi stable friends, Can you please backport this one to 3.19.y. It fixes a bug introduced by: 381cf6587f8a8a8e981bc0c18859b51dc756, which was tagged for stable 3.14+ The symptoms of the bug are deadlocks during log reply after a crash. The patch wasn't intentionally fixing the deadlock, which is why we missed it when tagging fixes. Unfortunately still not fixed (no btrfs-related changes) in 3.14.38 and 3.18.11 released today. I have a few hundred stable backports left to sort through, don't worry, this is still in the queue, it's not lost. It looks like this still isn't in 3.18.12, though it looks like it is in 3.19.5. Sasha is maintaining the 3.18.y stable tree, not Greg. Added to CC. Um, that commit was shipped back in 3.18.9. Oh, bleh, I've looked the wrong commit. I've queued 9c4f61f01d269815bb7c37be3ede59c5587747c6 up for 3.18.13. Thanks! -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Please add 9c4f61f01d269815bb7c37be3ede59c5587747c6 to stable
On 04/23/2015 02:24 PM, Josh Boyer wrote: On Thu, Apr 23, 2015 at 2:16 PM, Rich Freeman r-bt...@thefreemanclan.net wrote: On Mon, Apr 13, 2015 at 12:58 PM, Greg KH gre...@linuxfoundation.org wrote: On Mon, Apr 13, 2015 at 07:28:38PM +0500, Roman Mamedov wrote: On Thu, 2 Apr 2015 10:17:47 -0400 Chris Mason c...@fb.com wrote: Hi stable friends, Can you please backport this one to 3.19.y. It fixes a bug introduced by: 381cf6587f8a8a8e981bc0c18859b51dc756, which was tagged for stable 3.14+ The symptoms of the bug are deadlocks during log reply after a crash. The patch wasn't intentionally fixing the deadlock, which is why we missed it when tagging fixes. Unfortunately still not fixed (no btrfs-related changes) in 3.14.38 and 3.18.11 released today. I have a few hundred stable backports left to sort through, don't worry, this is still in the queue, it's not lost. It looks like this still isn't in 3.18.12, though it looks like it is in 3.19.5. Sasha is maintaining the 3.18.y stable tree, not Greg. Added to CC. Um, that commit was shipped back in 3.18.9. Thanks, Sasha -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: btrfs: kernel BUG at fs/btrfs/extent_io.c:676!
On 10/14/2014 02:31 AM, Chris Mason wrote: On Sun, Oct 12, 2014 at 10:15 PM, Sasha Levin sasha.le...@oracle.com wrote: Ping? This BUG_ON()ing due to GFP_ATOMIC allocation failure is really silly :( Agreed, I have a patch for this in testing. It didn't make my first pull but I'll get it fixed up. I've re-enabled fs testing after the discussion at LSF/MM (but mostly due to Michal's patch), and this issue came right back up. Any updates? Thanks, Sasha -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: btrfs: kernel BUG at fs/btrfs/extent_io.c:676!
Ping? This BUG_ON()ing due to GFP_ATOMIC allocation failure is really silly :( On 03/23/2014 09:26 PM, Sasha Levin wrote: Hi all, While fuzzing with trinity inside KVM tools guest running latest -next kernel I've stumbled on the following spew. This is a result of a failed allocation in alloc_extent_state_atomic() which triggers a BUG_ON when the return value is NULL. It's a bit weird that it BUGs on failed allocations, since it's obviously not a critical failure. [ 447.705167] kernel BUG at fs/btrfs/extent_io.c:676! [ 447.706201] invalid opcode: [#1] PREEMPT SMP DEBUG_PAGEALLOC [ 447.707732] Dumping ftrace buffer: [ 447.708473](ftrace buffer empty) [ 447.709684] Modules linked in: [ 447.710246] CPU: 17 PID: 4195 Comm: kswapd17 Tainted: GW 3.14.0-rc7-next-20140321-sasha-00018-g0516fe6-dirty #265 [ 447.710253] task: 88066be9b000 ti: 88066be82000 task.ti: 88066be82000 [ 447.710253] RIP: clear_extent_bit (fs/btrfs/extent_io.c:676) [ 447.710253] RSP: :88066be83768 EFLAGS: 00010246 [ 447.710253] RAX: RBX: 00d00fff RCX: 0006 [ 447.710253] RDX: 58e0 RSI: 88066be9bd60 RDI: 0286 [ 447.710253] RBP: 88066be837e8 R08: R09: [ 447.710253] R10: 0001 R11: 454a4e495f544c55 R12: 01ff [ 447.710253] R13: R14: 88007b89fd08 R15: 00d0 [ 447.710253] FS: () GS:8804acc0() knlGS: [ 447.710253] CS: 0010 DS: ES: CR0: 8005003b [ 447.710253] CR2: 02aec968 CR3: 05e29000 CR4: 06a0 [ 447.710253] DR0: 00698000 DR1: 00698000 DR2: [ 447.710253] DR3: DR6: 0ff0 DR7: 0600 [ 447.710253] Stack: [ 447.710253] 88066be83788 844fc4d5 8804ab4800e8 [ 447.710253] 0001 8804ab4800c8 fbf7 [ 447.710253] 88066be837c8 0006 ea0007aaf340 [ 447.710253] Call Trace: [ 447.710253] ? _raw_spin_unlock (arch/x86/include/asm/preempt.h:98 include/linux/spinlock_api_smp.h:152 kernel/locking/spinlock.c:183) [ 447.710253] try_release_extent_mapping (fs/btrfs/extent_io.c:3998 fs/btrfs/extent_io.c:4058) [ 447.710253] __btrfs_releasepage (fs/btrfs/inode.c:7521) [ 447.710253] btrfs_releasepage (fs/btrfs/inode.c:7534) [ 447.710253] try_to_release_page (mm/filemap.c:2984) [ 447.710253] invalidate_inode_page (mm/truncate.c:165 mm/truncate.c:215) [ 447.710253] invalidate_mapping_pages (mm/truncate.c:517) [ 447.710253] inode_lru_isolate (arch/x86/include/asm/current.h:14 include/linux/swap.h:33 fs/inode.c:724) [ 447.710253] ? insert_inode_locked (fs/inode.c:687) [ 447.710253] list_lru_walk_node (mm/list_lru.c:89) [ 447.710253] prune_icache_sb (fs/inode.c:759) [ 447.710253] super_cache_scan (fs/super.c:96) [ 447.710253] shrink_slab_node (mm/vmscan.c:306) [ 447.710253] shrink_slab (mm/vmscan.c:381) [ 447.710253] kswapd_shrink_zone (mm/vmscan.c:2909) [ 447.710253] kswapd (mm/vmscan.c:3090 mm/vmscan.c:3296) [ 447.710253] ? mem_cgroup_shrink_node_zone (mm/vmscan.c:3213) [ 447.710253] kthread (kernel/kthread.c:219) [ 447.710253] ? __tick_nohz_task_switch (arch/x86/include/asm/paravirt.h:809 kernel/time/tick-sched.c:272) [ 447.710253] ? kthread_create_on_node (kernel/kthread.c:185) [ 447.710253] ret_from_fork (arch/x86/kernel/entry_64.S:555) [ 447.710253] ? kthread_create_on_node (kernel/kthread.c:185) [ 447.710253] Code: e9 a9 00 00 00 0f 1f 00 48 39 c3 0f 82 87 00 00 00 4c 39 e3 0f 83 7e 00 00 00 48 8b 7d a0 e8 45 ef ff ff 48 85 c0 49 89 c5 75 05 0f 0b 0f 1f 00 48 8b 7d b0 48 8d 4b 01 48 89 c2 4c 89 f6 e8 c5 [ 447.710253] RIP clear_extent_bit (fs/btrfs/extent_io.c:676) [ 447.710253] RSP 88066be83768 Thanks, Sasha -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
btrfs: hang on boot due to tests
Hi all, It seems that some recent changes to btrfs tests make it hang during boot: [ 49.730033] NMI watchdog: BUG: soft lockup - CPU#34 stuck for 23s! [swapper/0:1] [ 49.730033] Modules linked in: [ 49.730033] hardirqs last enabled at (6389143): restore_args (arch/x86/kernel/entry_64.S:829) [ 49.730033] hardirqs last disabled at (6389144): apic_timer_interrupt (arch/x86/kernel/entry_64.S:1021) [ 49.730033] softirqs last enabled at (6389142): __do_softirq (./arch/x86/include/asm/preempt.h:22 kernel/softirq.c:296) [ 49.730033] softirqs last disabled at (6389139): irq_exit (kernel/softirq.c:346 kernel/softirq.c:387) [ 49.730033] CPU: 34 PID: 1 Comm: swapper/0 Not tainted 3.15.0-rc8-next-20140606-sasha-00021-ga9d3a0b-dirty #597 [ 49.730033] task: 88062855 ti: 880036218000 task.ti: 880036218000 [ 49.730033] RIP: __write_lock_failed (arch/x86/lib/rwlock.S:20) [ 49.730033] RSP: :88003621b9e8 EFLAGS: 0297 [ 49.730033] RAX: 0022 RBX: 845658fb RCX: 00059e1d8462 [ 49.730033] RDX: 0003 RSI: 85907bf4 RDI: 8800365c00bc [ 49.730033] RBP: 88003621b9e8 R08: 1b48 R09: 819618b8 [ 49.730033] R10: 0001 R11: R12: 88003621b958 [ 49.730033] R13: 0001 R14: 880036218000 R15: 88062855 [ 49.730033] FS: () GS:8800a6e0() knlGS: [ 49.730033] CS: 0010 DS: ES: CR0: 8005003b [ 49.730033] CR2: CR3: 0602e000 CR4: 06a0 [ 49.730033] Stack: [ 49.730033] 88003621ba08 811d18de 88003621ba68 8800365c00b8 [ 49.730033] 88003621ba38 84563ac0 81961d7c 81b33a05 [ 49.730033] 8800365c 8800365c0100 88003621baa8 81961d7c [ 49.730033] Call Trace: [ 49.730033] do_raw_write_lock (kernel/locking/spinlock_debug.c:236 kernel/locking/spinlock_debug.c:280) [ 49.730033] _raw_write_lock (include/linux/rwlock_api_smp.h:211 kernel/locking/spinlock.c:295) [ 49.730033] ? btrfs_tree_lock (./arch/x86/include/asm/atomic.h:27 fs/btrfs/locking.c:219) [ 49.730033] ? delay_tsc (./arch/x86/include/asm/preempt.h:98 arch/x86/lib/delay.c:86) [ 49.730033] btrfs_tree_lock (./arch/x86/include/asm/atomic.h:27 fs/btrfs/locking.c:219) [ 49.730033] ? __const_udelay (arch/x86/lib/delay.c:126) [ 49.730033] ? __rcu_read_unlock (kernel/rcu/update.c:97) [ 49.730033] btrfs_lock_root_node (fs/btrfs/ctree.c:193) [ 49.730033] btrfs_search_slot (fs/btrfs/ctree.c:2768) [ 49.730033] btrfs_insert_empty_items (fs/btrfs/ctree.c:4836) [ 49.730033] ? dlm_init (fs/btrfs/super.c:1914) [ 49.730033] insert_normal_tree_ref.constprop.4 (fs/btrfs/tests/qgroup-tests.c:60) [ 49.730033] ? dlm_init (fs/btrfs/super.c:1914) [ 49.730033] test_no_shared_qgroup (fs/btrfs/tests/qgroup-tests.c:249) [ 49.730033] btrfs_test_qgroups (fs/btrfs/tests/qgroup-tests.c:462) [ 49.730033] init_btrfs_fs (fs/btrfs/super.c:1909 fs/btrfs/super.c:1969) [ 49.730033] ? dlm_init (fs/btrfs/super.c:1914) [ 49.730033] do_one_initcall (init/main.c:791) [ 49.730033] ? parse_args (kernel/params.c:120 kernel/params.c:205) [ 49.730033] kernel_init_freeable (init/main.c:856 init/main.c:865 init/main.c:884 init/main.c:1005) [ 49.730033] ? loglevel (init/main.c:241) [ 49.730033] ? rest_init (init/main.c:932) [ 49.730033] kernel_init (init/main.c:937) [ 49.730033] ret_from_fork (arch/x86/kernel/entry_64.S:349) [ 49.730033] ? rest_init (init/main.c:932) [ 49.730033] Code: 1f 00 48 89 01 31 c0 0f 1f 00 c3 b8 f2 ff ff ff 0f 1f 00 c3 90 90 90 90 90 90 90 90 90 90 90 90 90 90 55 48 89 e5 f0 ff 07 f3 90 83 3f 01 75 f9 f0 ff 0f 75 f1 5d c3 66 66 2e 0f 1f 84 00 00 00 All code 0: 1f (bad) 1: 00 48 89add%cl,-0x77(%rax) 4: 01 31 add%esi,(%rcx) 6: c0 0f 1frorb $0x1f,(%rdi) 9: 00 c3 add%al,%bl b: b8 f2 ff ff ff mov$0xfff2,%eax 10: 0f 1f 00nopl (%rax) 13: c3 retq 14: 90 nop 15: 90 nop 16: 90 nop 17: 90 nop 18: 90 nop 19: 90 nop 1a: 90 nop 1b: 90 nop 1c: 90 nop 1d: 90 nop 1e: 90 nop 1f: 90 nop 20: 90 nop 21: 90 nop 22: 55 push %rbp 23: 48 89 e5mov%rsp,%rbp 26: f0 ff 07lock incl (%rdi) 29: f3 90 pause 2b:* 83 3f 01cmpl $0x1,(%rdi) -- trapping
Re: btrfs: hang on boot due to tests
On 06/09/2014 11:59 AM, Chris Mason wrote: On 06/09/2014 11:16 AM, Sasha Levin wrote: Hi all, It seems that some recent changes to btrfs tests make it hang during boot: [ 49.730033] NMI watchdog: BUG: soft lockup - CPU#34 stuck for 23s! [swapper/0:1] [ 49.730033] Modules linked in: [ 49.730033] hardirqs last enabled at (6389143): restore_args (arch/x86/kernel/entry_64.S:829) [ 49.730033] hardirqs last disabled at (6389144): apic_timer_interrupt (arch/x86/kernel/entry_64.S:1021) [ 49.730033] softirqs last enabled at (6389142): __do_softirq (./arch/x86/include/asm/preempt.h:22 kernel/softirq.c:296) [ 49.730033] softirqs last disabled at (6389139): irq_exit (kernel/softirq.c:346 kernel/softirq.c:387) [ 49.730033] CPU: 34 PID: 1 Comm: swapper/0 Not tainted 3.15.0-rc8-next-20140606-sasha-00021-ga9d3a0b-dirty #597 This is 3.15-rc8 + linux-next? I'll try to reproduce here, but the tests were working for me. Yes, it's the latest -next tree available. Also note that it doesn't happen every time, so might be some sort of a race? Thanks, Sasha -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: btrfs: lock inversion between delayed_node-mutex and found-groups_sem
On 04/07/2014 01:17 PM, Chris Mason wrote: On 04/07/2014 12:54 PM, David Sterba wrote: On Fri, Apr 04, 2014 at 05:15:23PM -0400, Sasha Levin wrote: On 03/26/2014 01:01 PM, Jeff Mahoney wrote: On 3/17/14, 9:05 AM, David Sterba wrote: On Fri, Mar 14, 2014 at 08:12:16PM -0400, Sasha Levin wrote: While fuzzing with trinity inside a KVM tools guest running the latest -next kernel I've stumbled on the following: [ 788.458756]CPU0CPU1 [ 788.459188] [ 788.459625] lock(found-groups_sem); [ 788.460041] local_irq_disable(); [ 788.460041] lock(delayed_node-mutex); [ 788.460041] lock(found-groups_sem); [ 788.460041] Interrupt [ 788.460041] lock(delayed_node-mutex); [ 788.460041] [ 788.460041] *** DEADLOCK *** [ 788.460041] [ 788.460041] 2 locks held by kswapd3/4199: I've once (3.14-rc5) seen the same warning also caused by xfstests/generic/224 I think this is from my sysfs patches. We call kobject_add while holding the group_sem. kobject_add ultimately allocates with GFP_KERNEL, so it can enter reclaim. This particular case isn't dangerous, but it could hit while hot-adding a device. The fix should be pretty simple. Is that fix available anywhere? I'm still seeing the issue in -next. It is: https://urldefense.proofpoint.com/v1/url?u=https://patchwork.kernel.org/patch/3894781/k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0Ar=6%2FL0lzzDhu0Y1hL9xm%2BQyA%3D%3D%0Am=HQJVSK4wPTft1zWwI1cGvwj5OfdmN5UItVlucU1K31o%3D%0As=5113699a2e7345a779333c87dd5b1d88b4410a7c7fcd5fa424baeb838ad7d31b , will probably hit -rc2 Its in the integration branch now along with some other important fixes. We'll get it out shortly Chris, Can I suggest adding the integration branch to linux-next as well? That way all the folks who report issues coming out of -next would be able to test the fixes as well. Thanks, Sasha -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: btrfs: lock inversion between delayed_node-mutex and found-groups_sem
On 03/26/2014 01:01 PM, Jeff Mahoney wrote: On 3/17/14, 9:05 AM, David Sterba wrote: On Fri, Mar 14, 2014 at 08:12:16PM -0400, Sasha Levin wrote: While fuzzing with trinity inside a KVM tools guest running the latest -next kernel I've stumbled on the following: [ 788.458756]CPU0CPU1 [ 788.459188] [ 788.459625] lock(found-groups_sem); [ 788.460041] local_irq_disable(); [ 788.460041] lock(delayed_node-mutex); [ 788.460041] lock(found-groups_sem); [ 788.460041] Interrupt [ 788.460041] lock(delayed_node-mutex); [ 788.460041] [ 788.460041] *** DEADLOCK *** [ 788.460041] [ 788.460041] 2 locks held by kswapd3/4199: I've once (3.14-rc5) seen the same warning also caused by xfstests/generic/224 I think this is from my sysfs patches. We call kobject_add while holding the group_sem. kobject_add ultimately allocates with GFP_KERNEL, so it can enter reclaim. This particular case isn't dangerous, but it could hit while hot-adding a device. The fix should be pretty simple. Is that fix available anywhere? I'm still seeing the issue in -next. Thanks, Sasha -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
btrfs: kernel BUG at fs/btrfs/extent_io.c:676!
Hi all, While fuzzing with trinity inside KVM tools guest running latest -next kernel I've stumbled on the following spew. This is a result of a failed allocation in alloc_extent_state_atomic() which triggers a BUG_ON when the return value is NULL. It's a bit weird that it BUGs on failed allocations, since it's obviously not a critical failure. [ 447.705167] kernel BUG at fs/btrfs/extent_io.c:676! [ 447.706201] invalid opcode: [#1] PREEMPT SMP DEBUG_PAGEALLOC [ 447.707732] Dumping ftrace buffer: [ 447.708473](ftrace buffer empty) [ 447.709684] Modules linked in: [ 447.710246] CPU: 17 PID: 4195 Comm: kswapd17 Tainted: GW 3.14.0-rc7-next-20140321-sasha-00018-g0516fe6-dirty #265 [ 447.710253] task: 88066be9b000 ti: 88066be82000 task.ti: 88066be82000 [ 447.710253] RIP: clear_extent_bit (fs/btrfs/extent_io.c:676) [ 447.710253] RSP: :88066be83768 EFLAGS: 00010246 [ 447.710253] RAX: RBX: 00d00fff RCX: 0006 [ 447.710253] RDX: 58e0 RSI: 88066be9bd60 RDI: 0286 [ 447.710253] RBP: 88066be837e8 R08: R09: [ 447.710253] R10: 0001 R11: 454a4e495f544c55 R12: 01ff [ 447.710253] R13: R14: 88007b89fd08 R15: 00d0 [ 447.710253] FS: () GS:8804acc0() knlGS: [ 447.710253] CS: 0010 DS: ES: CR0: 8005003b [ 447.710253] CR2: 02aec968 CR3: 05e29000 CR4: 06a0 [ 447.710253] DR0: 00698000 DR1: 00698000 DR2: [ 447.710253] DR3: DR6: 0ff0 DR7: 0600 [ 447.710253] Stack: [ 447.710253] 88066be83788 844fc4d5 8804ab4800e8 [ 447.710253] 0001 8804ab4800c8 fbf7 [ 447.710253] 88066be837c8 0006 ea0007aaf340 [ 447.710253] Call Trace: [ 447.710253] ? _raw_spin_unlock (arch/x86/include/asm/preempt.h:98 include/linux/spinlock_api_smp.h:152 kernel/locking/spinlock.c:183) [ 447.710253] try_release_extent_mapping (fs/btrfs/extent_io.c:3998 fs/btrfs/extent_io.c:4058) [ 447.710253] __btrfs_releasepage (fs/btrfs/inode.c:7521) [ 447.710253] btrfs_releasepage (fs/btrfs/inode.c:7534) [ 447.710253] try_to_release_page (mm/filemap.c:2984) [ 447.710253] invalidate_inode_page (mm/truncate.c:165 mm/truncate.c:215) [ 447.710253] invalidate_mapping_pages (mm/truncate.c:517) [ 447.710253] inode_lru_isolate (arch/x86/include/asm/current.h:14 include/linux/swap.h:33 fs/inode.c:724) [ 447.710253] ? insert_inode_locked (fs/inode.c:687) [ 447.710253] list_lru_walk_node (mm/list_lru.c:89) [ 447.710253] prune_icache_sb (fs/inode.c:759) [ 447.710253] super_cache_scan (fs/super.c:96) [ 447.710253] shrink_slab_node (mm/vmscan.c:306) [ 447.710253] shrink_slab (mm/vmscan.c:381) [ 447.710253] kswapd_shrink_zone (mm/vmscan.c:2909) [ 447.710253] kswapd (mm/vmscan.c:3090 mm/vmscan.c:3296) [ 447.710253] ? mem_cgroup_shrink_node_zone (mm/vmscan.c:3213) [ 447.710253] kthread (kernel/kthread.c:219) [ 447.710253] ? __tick_nohz_task_switch (arch/x86/include/asm/paravirt.h:809 kernel/time/tick-sched.c:272) [ 447.710253] ? kthread_create_on_node (kernel/kthread.c:185) [ 447.710253] ret_from_fork (arch/x86/kernel/entry_64.S:555) [ 447.710253] ? kthread_create_on_node (kernel/kthread.c:185) [ 447.710253] Code: e9 a9 00 00 00 0f 1f 00 48 39 c3 0f 82 87 00 00 00 4c 39 e3 0f 83 7e 00 00 00 48 8b 7d a0 e8 45 ef ff ff 48 85 c0 49 89 c5 75 05 0f 0b 0f 1f 00 48 8b 7d b0 48 8d 4b 01 48 89 c2 4c 89 f6 e8 c5 [ 447.710253] RIP clear_extent_bit (fs/btrfs/extent_io.c:676) [ 447.710253] RSP 88066be83768 Thanks, Sasha -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
btrfs: lock inversion between delayed_node-mutex and found-groups_sem
Hi all,
While fuzzing with trinity inside a KVM tools guest running the latest -next
kernel I've stumbled on the following:
[ 788.451695] =
[ 788.452455] [ INFO: possible irq lock inversion dependency detected ]
[ 788.453020] 3.14.0-rc6-next-20140313-sasha-00010-gb8c1db1-dirty #217
Tainted: GW
[ 788.453827] -
[ 788.454371] kswapd3/4199 just changed the state of lock:
[ 788.454902] (delayed_node-mutex){+.+.-.}, at:
__btrfs_release_delayed_node+0x4f/0x140 (fs/btrfs/delayed-inode.c:263)
[ 788.455890] but this lock took another, RECLAIM_FS-unsafe lock in the past:
[ 788.456543] (found-groups_sem){+.}
and interrupts could create inverse lock ordering between them.
[ 788.457491]
[ 788.457491] other info that might help us debug this:
[ 788.458115] Possible interrupt unsafe locking scenario:
[ 788.458115]
[ 788.458756]CPU0CPU1
[ 788.459188]
[ 788.459625] lock(found-groups_sem);
[ 788.460041]local_irq_disable();
[ 788.460041]lock(delayed_node-mutex);
[ 788.460041]lock(found-groups_sem);
[ 788.460041] Interrupt
[ 788.460041] lock(delayed_node-mutex);
[ 788.460041]
[ 788.460041] *** DEADLOCK ***
[ 788.460041]
[ 788.460041] 2 locks held by kswapd3/4199:
[ 788.460041] #0: (shrinker_rwsem){..}, at: shrink_slab+0x3f/0x160
(mm/vmscan.c:360)
[ 788.460041] #1: (type-s_umount_key#108){.+.+..}, at:
grab_super_passive+0x56/0x90 (fs/super.c:361)
[ 788.460041]
[ 788.460041] the shortest dependencies between 2nd lock and 1st lock:
[ 788.460041] - (found-groups_sem){+.} ops: 46 {
[ 788.460041] HARDIRQ-ON-W at:
[ 788.460041] mark_irqflags+0xf0/0x170
(kernel/locking/lockdep.c:2800)
[ 788.460041] __lock_acquire+0x2de/0x5a0
(kernel/locking/lockdep.c:3138)
[ 788.460041] lock_acquire+0x182/0x1d0
(arch/x86/include/asm/current.h:14 kernel/locking/lockdep.c:3602)
[ 788.460041] down_write+0x5c/0xc0
(arch/x86/include/asm/rwsem.h:130 kernel/locking/rwsem.c:50)
[ 788.460041] __link_block_group+0x45/0x110
(fs/btrfs/extent-tree.c:8348)
[ 788.460041] btrfs_read_block_groups+0x3ae/0x700
(fs/btrfs/extent-tree.c:8533)
[ 788.460041] open_ctree+0x1abf/0x2210
(fs/btrfs/disk-io.c:2749)
[ 788.460041] btrfs_fill_super+0x81/0x140
(fs/btrfs/super.c:958)
[ 788.460041] btrfs_mount+0x26a/0x300
(fs/btrfs/super.c:1295)
[ 788.460041] mount_fs+0x8d/0x1a0 (fs/super.c:1091)
[ 788.460041] vfs_kern_mount+0x79/0x150
(fs/namespace.c:813)
[ 788.460041] do_new_mount+0xcd/0x1c0
(fs/namespace.c:2068)[ 788.460041] do_mount+0x15d/0x210
(fs/namespace.c:2392)
[ 788.460041] SyS_mount+0x9d/0xe0 (fs/namespace.c:2589
fs/namespace.c:2560)
[ 788.460041] tracesys+0xdd/0xe2
(arch/x86/kernel/entry_64.S:749)
[ 788.460041] HARDIRQ-ON-R at:
[ 788.460041] mark_irqflags+0xbc/0x170
(kernel/locking/lockdep.c:2792)
[ 788.460041] __lock_acquire+0x2de/0x5a0
(kernel/locking/lockdep.c:3138)
[ 788.460041] lock_acquire+0x182/0x1d0
(arch/x86/include/asm/current.h:14 kernel/locking/lockdep.c:3602)
[ 788.460041] down_read+0x4c/0xa0
(arch/x86/include/asm/rwsem.h:83 kernel/locking/rwsem.c:23)
[ 788.460041]
btrfs_calc_num_tolerated_disk_barrier_failures+0x2a7/0x3a0
(fs/btrfs/disk-io.c:3309)
[ 788.460041] open_ctree+0x1af7/0x2210
(fs/btrfs/disk-io.c:2755)
[ 788.460041] btrfs_fill_super+0x81/0x140
(fs/btrfs/super.c:958)
[ 788.460041] btrfs_mount+0x26a/0x300
(fs/btrfs/super.c:1295)
[ 788.460041] mount_fs+0x8d/0x1a0 (fs/super.c:1091)
[ 788.460041] vfs_kern_mount+0x79/0x150
(fs/namespace.c:813)
[ 788.460041] do_new_mount+0xcd/0x1c0
(fs/namespace.c:2068)
[ 788.460041] do_mount+0x15d/0x210 (fs/namespace.c:2392)
[ 788.460041] SyS_mount+0x9d/0xe0 (fs/namespace.c:2589
fs/namespace.c:2560)
[ 788.460041] tracesys+0xdd/0xe2
(arch/x86/kernel/entry_64.S:749)
[ 788.460041] SOFTIRQ-ON-W at:
[ 788.460041] mark_irqflags+0x110/0x170
(kernel/locking/lockdep.c:2804)
[ 788.460041] __lock_acquire+0x2de/0x5a0
(kernel/locking/lockdep.c:3138)
[ 788.460041] lock_acquire+0x182/0x1d0
(arch/x86/include/asm/current.h:14
