Re: [PATCH 0/1] btrfs lockdep annotation
On 01/24/2017 11:22 AM, Filipe Manana wrote: > On Tue, Jan 24, 2017 at 9:01 AM, Christian Borntraeger > wrote: >> Chris, >> >> since my bug report about this did not result in any fix and since > > It was fixed and the fix landed in 4.10-rc4: Thanks, I missed that last pull. > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=781feef7e6befafd4d9787d1f7ada1f9ccd504e4 > >> this disables lockdep before the the code that I want to debug runs >> here is my attempt to fix it. >> Please double check if the subclass looks right. It seems to work >> for me but I do not know enough about btrfs to decide if this is >> right or not. >> >> Christian Borntraeger (): >> btrfs: add lockdep annotation for btrfs_log_inode >> >> fs/btrfs/tree-log.c| 2 +- >> >> -- >> 2.7.4 >> >> -- >> 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 > > > -- 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
[PATCH 2/2] btrfs: add lockdep annotation for btrfs_log_inode
Add a proper subclass to get rid of the following lockdep
error.
[ INFO: possible recursive locking detected ]
4.9.0+ #279 Not tainted
-
vim/4801 is trying to acquire lock:
(&ei->log_mutex){+.+...}, at: [<03ff82057592>]
btrfs_log_inode+0x182/0xfa8 [btrfs]
(&ei->log_mutex){+.+...}, at: [<03ff82057592>]
btrfs_log_inode+0x182/0xfa8 [btrfs]
Possible unsafe locking scenario:
CPU0
lock(&ei->log_mutex);
lock(&ei->log_mutex);
*** DEADLOCK ***
May be due to missing lock nesting notation
3 locks held by vim/4801:
#0: (&sb->s_type->i_mutex_key#15){+.+.+.}, at: [<03ff81fc274c>]
btrfs_sync_file+0x204/0x728 [btrfs]
#1: (sb_internal#2){.+.+..}, at: [<03ff81fa38e0>]
start_transaction+0x318/0x770 [btrfs]
#2: (&ei->log_mutex){+.+...}, at: [<03ff82057592>]
[...]
Call Trace:
([<00115ffc>] show_trace+0xe4/0x108)
[<001160f8>] show_stack+0x68/0xe0
[<00652d52>] dump_stack+0x9a/0xd8
[<00209bb0>] __lock_acquire+0xac8/0x1bd0
[<0020b3c6>] lock_acquire+0x106/0x4a0
[<00a1fb36>] mutex_lock_nested+0xa6/0x428
[<03ff82057592>] btrfs_log_inode+0x182/0xfa8 [btrfs]
[<03ff82057c76>] btrfs_log_inode+0x866/0xfa8 [btrfs]
[<03ff81ffe278>] btrfs_log_inode_parent+0x218/0x988 [btrfs]
[<03ff81aa>] btrfs_log_dentry_safe+0x7a/0xa0 [btrfs]
[<03ff81fc29b6>] btrfs_sync_file+0x46e/0x728 [btrfs]
[<0044aeee>] do_fsync+0x5e/0x90
[<0044b2ba>] SyS_fsync+0x32/0x40
[<00a26786>] system_call+0xd6/0x288
Signed-off-by: Christian Borntraeger
---
fs/btrfs/tree-log.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index 3d33c4e..a3ec717 100644
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -4648,7 +4648,7 @@ static int btrfs_log_inode(struct btrfs_trans_handle
*trans,
return ret;
}
- mutex_lock(&BTRFS_I(inode)->log_mutex);
+ mutex_lock_nested(&BTRFS_I(inode)->log_mutex, inode_only);
/*
* a brute force approach to making sure we get the most uptodate
--
2.7.4
--
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
[PATCH 0/1] btrfs lockdep annotation
Chris, since my bug report about this did not result in any fix and since this disables lockdep before the the code that I want to debug runs here is my attempt to fix it. Please double check if the subclass looks right. It seems to work for me but I do not know enough about btrfs to decide if this is right or not. Christian Borntraeger (): btrfs: add lockdep annotation for btrfs_log_inode fs/btrfs/tree-log.c| 2 +- -- 2.7.4 -- 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: still lockdep splat for 4.9-rc5+ (btrfs_log_inode)
FWIW, I still see the lockdep splat in btrfs in 4.9-rc5+
[ 159.698343] =
[ 159.698345] [ INFO: possible recursive locking detected ]
[ 159.698347] 4.9.0-rc5+ #136 Tainted: GW
[ 159.698348] -
[ 159.698349] vim/6913 is trying to acquire lock:
[ 159.698350] (
[ 159.698351] &ei->log_mutex
[ 159.698352] ){+.+...}
[ 159.698353] , at:
[ 159.698445] [<03ff8202c3f4>] btrfs_log_inode+0x124/0x1048 [btrfs]
[ 159.698447]
but task is already holding lock:
[ 159.698448] (
[ 159.698449] &ei->log_mutex
[ 159.698449] ){+.+...}
[ 159.698450] , at:
[ 159.698469] [<03ff8202c3f4>] btrfs_log_inode+0x124/0x1048 [btrfs]
[ 159.698470]
other info that might help us debug this:
[ 159.698471] Possible unsafe locking scenario:
[ 159.698472]CPU0
[ 159.698473]
[ 159.698474] lock(
[ 159.698475] &ei->log_mutex
[ 159.698476] );
[ 159.698476] lock(
[ 159.698477] &ei->log_mutex
[ 159.698478] );
[ 159.698479]
*** DEADLOCK ***
[ 159.698480] May be due to missing lock nesting notation
[ 159.698482] 3 locks held by vim/6913:
[ 159.698483] #0:
[ 159.698483] (
[ 159.698484] &sb->s_type->i_mutex_key
[ 159.698508] #15
[ 159.698509] ){+.+.+.}
[ 159.698509] , at:
[ 159.698528] [<03ff81ff66f8>] btrfs_sync_file+0x1b8/0x560 [btrfs]
[ 159.698529] #1:
[ 159.698530] (
[ 159.698531] sb_internal
[ 159.698531] #2
[ 159.698532] ){.+.+..}
[ 159.698532] , at:
[ 159.698551] [<03ff81fdad2a>] start_transaction+0x312/0x600 [btrfs]
[ 159.698552] #2:
[ 159.698552] (
[ 159.698553] &ei->log_mutex
[ 159.698554] ){+.+...}
[ 159.698555] , at:
[ 159.698573] [<03ff8202c3f4>] btrfs_log_inode+0x124/0x1048 [btrfs]
[ 159.698574]
stack backtrace:
[ 159.698577] CPU: 22 PID: 6913 Comm: vim Tainted: GW 4.9.0-rc5+
#136
[ 159.698578] Hardware name: IBM 2964 NC9 704
(LPAR)
[ 159.698580] Stack:
[ 159.698581]00fae55635f0 00fae5563680 0003
[ 159.698584]00fae5563720 00fae5563698 00fae5563698
0020
[ 159.698587] 00fa0020 00fa000a
000a
[ 159.698589]000c 00fae55636e8
[ 159.698592]0400037e5c40 001127a4 00fae5563680
00fae55636d8
[ 159.698594] Call Trace:
[ 159.698599] ([<0011266a>] show_trace+0xea/0xf0)
[ 159.698601] [<00112748>] show_stack+0x68/0xe0
[ 159.698605] [<004ef502>] dump_stack+0x9a/0xd8
[ 159.698609] [<001a6078>] validate_chain.isra.22+0xbd8/0xd48
[ 159.698611] [<001a741c>] __lock_acquire+0x304/0x7f0
[ 159.698613] [<001a7fe6>] lock_acquire+0xfe/0x2d8
[ 159.698617] [<008c5216>] mutex_lock_nested+0x86/0x3e8
[ 159.698636] [<03ff8202c3f4>] btrfs_log_inode+0x124/0x1048 [btrfs]
[ 159.698655] [<03ff8202cfcc>] btrfs_log_inode+0xcfc/0x1048 [btrfs]
[ 159.698674] [<03ff8202d5bc>] btrfs_log_inode_parent+0x1fc/0x918 [btrfs]
[ 159.698693] [<03ff8202ef22>] btrfs_log_dentry_safe+0x7a/0xa0 [btrfs]
[ 159.698712] [<03ff81ff68fc>] btrfs_sync_file+0x3bc/0x560 [btrfs]
[ 159.698715] [<00349ade>] do_fsync+0x5e/0x90
[ 159.698716] [<00349e6a>] SyS_fsync+0x32/0x40
[ 159.698718] [<008cae8e>] system_call+0xd6/0x270
[ 159.698719] INFO: lockdep is turned off.
--
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: lockdep warning in btrfs in 4.8-rc3
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. -- 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
lockdep warning in btrfs in 4.8-rc3
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: GW
[ 1094.009179] -
[ 1094.009180] vim/12891 is trying to acquire lock:
[ 1094.009182] (&ei->log_mutex){+.+...}, at: [<03ff817e83c6>]
btrfs_log_inode+0x126/0x1010 [btrfs]
[ 1094.009256]
but task is already holding lock:
[ 1094.009258] (&ei->log_mutex){+.+...}, at: [<03ff817e83c6>]
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:
[<03ff817afbd6>] btrfs_sync_file+0x1de/0x5e8 [btrfs]
[ 1094.009311] #1: (sb_internal#2){.+.+..}, at: [<0035e0ba>]
__sb_start_write+0x122/0x138
[ 1094.009320] #2: (&ei->log_mutex){+.+...}, at: [<03ff817e83c6>]
btrfs_log_inode+0x126/0x1010 [btrfs]
[ 1094.009370]
stack backtrace:
[ 1094.009375] CPU: 14 PID: 12891 Comm: vim Tainted: GW 4.8.0-rc3
#126
[ 1094.009377] Hardware name: IBM 2964 NC9 704
(LPAR)
[ 1094.009380]00f061367608 00f061367698 0002
00f061367738 00f0613676b0 00f0613676b0
001133ec
00f7000a
00f7000a
00f0613676f8 00f061367698
040001d821c8 001133ec 00f061367698
00f0613676e8
[ 1094.009396] Call Trace:
[ 1094.009401] ([<00113334>] show_trace+0xec/0xf0)
[ 1094.009403] ([<0011339a>] show_stack+0x62/0xe8)
[ 1094.009406] ([<0055211c>] dump_stack+0x9c/0xe0)
[ 1094.009411] ([<001d9930>] validate_chain.isra.22+0xc00/0xd70)
[ 1094.009413] ([<001dad9c>] __lock_acquire+0x39c/0x7d8)
[ 1094.009414] ([<001db8d0>] lock_acquire+0x108/0x320)
[ 1094.009420] ([<008845c6>] mutex_lock_nested+0x86/0x3f8)
[ 1094.009440] ([<03ff817e83c6>] btrfs_log_inode+0x126/0x1010 [btrfs])
[ 1094.009457] ([<03ff817e8fb2>] btrfs_log_inode+0xd12/0x1010 [btrfs])
[ 1094.009474] ([<03ff817e95b4>] btrfs_log_inode_parent+0x244/0x980 [btrfs])
[ 1094.009490] ([<03ff817eafea>] btrfs_log_dentry_safe+0x7a/0xa0 [btrfs])
[ 1094.009506] ([<03ff817afe1a>] btrfs_sync_file+0x422/0x5e8 [btrfs])
[ 1094.009512] ([<0039e64e>] do_fsync+0x5e/0x90)
[ 1094.009514] ([<0039e9e2>] SyS_fsync+0x32/0x40)
[ 1094.009517] ([<0088a336>] system_call+0xd6/0x270)
[ 1094.009518] INFO: lockdep is turned off.
--
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
4.6.0-rc3+: WARNING: CPU: 16 PID: 17257 at fs/btrfs/inode.c:9261 btrfs_destroy_inode
Folks, I can sometimes trigger the following bug [ 244.493534] [ cut here ] [ 244.493624] WARNING: CPU: 16 PID: 17257 at fs/btrfs/inode.c:9261 btrfs_destroy_inode+0x288/0x2b0 [btrfs] [ 244.493626] Kernel panic - not syncing: panic_on_warn set ... [ 244.493629] CPU: 16 PID: 17257 Comm: dwz Not tainted 4.6.0-rc3+ #56 [ 244.493631]00fb3d8a3790 00fb3d8a3820 0002 00fb3d8a38c0 00fb3d8a3838 00fb3d8a3838 00239364 00528488 0080e46e 007f02c8 000b 00fb3d8a3880 00fb3d8a3820 040003ff8185a39e 00113c1e 00fb3d8a3820 00fb3d8a3880 [ 244.493641] Call Trace: [ 244.493646] ([<00113b0a>] show_trace+0x62/0x78) [ 244.493647] ([<00113bd2>] show_stack+0x72/0xf0) [ 244.493650] ([<0040a8ca>] dump_stack+0x9a/0xd8) [ 244.493652] ([<00238b9e>] panic+0xf6/0x230) [ 244.493656] ([<001398e2>] __warn+0x11a/0x120) [ 244.493657] ([<0040a010>] report_bug+0x90/0xf8) [ 244.493658] ([<00100a4a>] do_report_trap+0xea/0x108) [ 244.493660] ([<00100bcc>] illegal_op+0xd4/0x150) [ 244.493662] ([<0067b760>] pgm_check_handler+0x15c/0x1a4) [ 244.493678] ([<03ff817d0ff0>] btrfs_destroy_inode+0x288/0x2b0 [btrfs]) [ 244.493680] ([<00fb42aff1c8>] 0xfb42aff1c8) [ 244.493683] ([<002de5b6>] __dentry_kill+0x1c6/0x238) [ 244.493684] ([<002de7fc>] dput+0x1d4/0x298) [ 244.493687] ([<002c6d24>] __fput+0x144/0x1e8) [ 244.493689] ([<0015a806>] task_work_run+0xc6/0xe8) [ 244.493714] ([<0010923a>] do_notify_resume+0x5a/0x60) [ 244.493715] ([<0067b45c>] system_call+0xdc/0x24c) The WARN_ON is WARN_ON(BTRFS_I(inode)->csum_bytes); The file system is shared on 4 multipath target on scsi disks. In seem to be able to reproduce it on kvm/next (4.6.0-rc3+) but 4.5.0 seems fine. Any ideas? Christian -- 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
