* [f2fs-dev] circular locking dependency warning in f2fs
@ 2023-08-16 5:09 Guenter Roeck
2023-08-16 17:25 ` Jaegeuk Kim
0 siblings, 1 reply; 14+ messages in thread
From: Guenter Roeck @ 2023-08-16 5:09 UTC (permalink / raw)
To: Jaegeuk Kim, Chao Yu; +Cc: linux-f2fs-devel
Hi,
when trying to boot from an f2fs file system with lock debugging enabled,
I get the attached circular locking dependency warning. Is this a known
problem ?
Thanks,
Guenter
---
[ 10.315522] ======================================================
[ 10.315620] WARNING: possible circular locking dependency detected
[ 10.315753] 6.5.0-rc6-00027-g91aa6c412d7f #1 Tainted: G N
[ 10.315843] ------------------------------------------------------
[ 10.315922] seedrng/717 is trying to acquire lock:
[ 10.316010] ffff8e0e02c6b868 (&fi->i_sem){+.+.}-{3:3}, at: f2fs_add_inline_entry+0x134/0x2d0
[ 10.316315]
[ 10.316315] but task is already holding lock:
[ 10.316391] ffff8e0e02c6b278 (&fi->i_xattr_sem){.+.+}-{3:3}, at: f2fs_add_dentry+0x41/0xc0
[ 10.316543]
[ 10.316543] which lock already depends on the new lock.
[ 10.316543]
[ 10.316641]
[ 10.316641] the existing dependency chain (in reverse order) is:
[ 10.316745]
[ 10.316745] -> #1 (&fi->i_xattr_sem){.+.+}-{3:3}:
[ 10.316883] down_read+0x3d/0x170
[ 10.316973] f2fs_getxattr+0x370/0x440
[ 10.317036] __f2fs_get_acl+0x38/0x1e0
[ 10.317094] f2fs_init_acl+0x69/0x420
[ 10.317151] f2fs_init_inode_metadata+0x72/0x450
[ 10.317218] f2fs_add_regular_entry+0x372/0x510
[ 10.317283] f2fs_add_dentry+0xb8/0xc0
[ 10.317340] f2fs_do_add_link+0xd9/0x110
[ 10.317399] f2fs_mkdir+0xdf/0x180
[ 10.317453] vfs_mkdir+0x142/0x220
[ 10.317508] do_mkdirat+0x7c/0x120
[ 10.317561] __x64_sys_mkdir+0x47/0x70
[ 10.317617] do_syscall_64+0x3f/0x90
[ 10.317673] entry_SYSCALL_64_after_hwframe+0x73/0xdd
[ 10.317757]
[ 10.317757] -> #0 (&fi->i_sem){+.+.}-{3:3}:
[ 10.317843] __lock_acquire+0x16bf/0x2860
[ 10.317907] lock_acquire+0xcc/0x2c0
[ 10.317962] down_write+0x3a/0xc0
[ 10.318014] f2fs_add_inline_entry+0x134/0x2d0
[ 10.318077] f2fs_add_dentry+0x55/0xc0
[ 10.318141] f2fs_do_add_link+0xd9/0x110
[ 10.318201] f2fs_create+0xe8/0x170
[ 10.318255] lookup_open.isra.0+0x58e/0x6c0
[ 10.318317] path_openat+0x2af/0xa40
[ 10.318372] do_filp_open+0xb1/0x160
[ 10.318428] do_sys_openat2+0x91/0xc0
[ 10.318485] __x64_sys_open+0x54/0xa0
[ 10.318541] do_syscall_64+0x3f/0x90
[ 10.318597] entry_SYSCALL_64_after_hwframe+0x73/0xdd
[ 10.318676]
[ 10.318676] other info that might help us debug this:
[ 10.318676]
[ 10.318799] Possible unsafe locking scenario:
[ 10.318799]
[ 10.318875] CPU0 CPU1
[ 10.318935] ---- ----
[ 10.318999] rlock(&fi->i_xattr_sem);
[ 10.319068] lock(&fi->i_sem);
[ 10.319166] lock(&fi->i_xattr_sem);
[ 10.319264] lock(&fi->i_sem);
[ 10.319325]
[ 10.319325] *** DEADLOCK ***
[ 10.319325]
[ 10.319413] 4 locks held by seedrng/717:
[ 10.319500] #0: ffff8e0e049693e8 (sb_writers#4){.+.+}-{0:0}, at: path_openat+0xa08/0xa40
[ 10.319645] #1: ffff8e0e02c6ac28 (&type->i_mutex_dir_key#3){++++}-{3:3}, at: path_openat+0x29b/0xa40
[ 10.319783] #2: ffff8e0e050623a8 (&sbi->cp_rwsem){.+.+}-{3:3}, at: f2fs_create+0xcc/0x170
[ 10.319899] #3: ffff8e0e02c6b278 (&fi->i_xattr_sem){.+.+}-{3:3}, at: f2fs_add_dentry+0x41/0xc0
[ 10.320029]
[ 10.320029] stack backtrace:
[ 10.320166] CPU: 7 PID: 717 Comm: seedrng Tainted: G N 6.5.0-rc6-00027-g91aa6c412d7f #1
[ 10.320302] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014
[ 10.320499] Call Trace:
[ 10.320579] <TASK>
[ 10.320665] dump_stack_lvl+0x64/0xb0
[ 10.320766] check_noncircular+0x151/0x170
[ 10.320834] ? register_lock_class+0x42/0x7a0
[ 10.320906] __lock_acquire+0x16bf/0x2860
[ 10.320974] lock_acquire+0xcc/0x2c0
[ 10.321026] ? f2fs_add_inline_entry+0x134/0x2d0
[ 10.321098] down_write+0x3a/0xc0
[ 10.321156] ? f2fs_add_inline_entry+0x134/0x2d0
[ 10.321220] f2fs_add_inline_entry+0x134/0x2d0
[ 10.321290] f2fs_add_dentry+0x55/0xc0
[ 10.321348] f2fs_do_add_link+0xd9/0x110
[ 10.321410] f2fs_create+0xe8/0x170
[ 10.321464] lookup_open.isra.0+0x58e/0x6c0
[ 10.321536] ? verify_cpu+0x20/0x100
[ 10.321605] ? verify_cpu+0x20/0x100
[ 10.321662] path_openat+0x2af/0xa40
[ 10.321722] do_filp_open+0xb1/0x160
[ 10.321777] ? alloc_fd+0x3c/0x220
[ 10.321838] ? _raw_spin_unlock+0x1e/0x40
[ 10.321901] do_sys_openat2+0x91/0xc0
[ 10.321959] __x64_sys_open+0x54/0xa0
[ 10.322014] do_syscall_64+0x3f/0x90
[ 10.322066] entry_SYSCALL_64_after_hwframe+0x73/0xdd
[ 10.322182] RIP: 0033:0x7ffbe94532de
[ 10.322384] Code: c3 8b 07 85 c0 75 24 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 <c3> e9 4b ce ff ff 41 54 4
9 89 f4 be 00 88 08 00 55 53 48 81 ec a0
[ 10.322619] RSP: 002b:00007ffc0cfc7ed8 EFLAGS: 00000246 ORIG_RAX: 0000000000000002
[ 10.322730] RAX: ffffffffffffffda RBX: 00007ffbe9495b48 RCX: 00007ffbe94532de
[ 10.322821] RDX: 0000000000000100 RSI: 0000000000008241 RDI: 000055f2b0816001
[ 10.322910] RBP: 000055f2b0816001 R08: 0000000000000000 R09: 0000000000000000
[ 10.322999] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000002
[ 10.323089] R13: 000055f2b0816001 R14: 000055f2b0816059 R15: 00007ffc0cfc8148
[ 10.323221] </TASK>
[ 10.383174] seedrng (717) used greatest stack depth: 12624 bytes left
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [f2fs-dev] circular locking dependency warning in f2fs
2023-08-16 5:09 [f2fs-dev] circular locking dependency warning in f2fs Guenter Roeck
@ 2023-08-16 17:25 ` Jaegeuk Kim
2023-08-17 2:11 ` Guenter Roeck
0 siblings, 1 reply; 14+ messages in thread
From: Jaegeuk Kim @ 2023-08-16 17:25 UTC (permalink / raw)
To: Guenter Roeck; +Cc: Jaegeuk Kim, linux-f2fs-devel
Hi,
On Tue, Aug 15, 2023 at 10:09 PM Guenter Roeck <linux@roeck-us.net> wrote:
>
> Hi,
>
> when trying to boot from an f2fs file system with lock debugging enabled,
> I get the attached circular locking dependency warning. Is this a known
> problem ?
>
> Thanks,
> Guenter
>
> ---
> [ 10.315522] ======================================================
> [ 10.315620] WARNING: possible circular locking dependency detected
> [ 10.315753] 6.5.0-rc6-00027-g91aa6c412d7f #1 Tainted: G N
> [ 10.315843] ------------------------------------------------------
> [ 10.315922] seedrng/717 is trying to acquire lock:
> [ 10.316010] ffff8e0e02c6b868 (&fi->i_sem){+.+.}-{3:3}, at: f2fs_add_inline_entry+0x134/0x2d0
> [ 10.316315]
> [ 10.316315] but task is already holding lock:
> [ 10.316391] ffff8e0e02c6b278 (&fi->i_xattr_sem){.+.+}-{3:3}, at: f2fs_add_dentry+0x41/0xc0
> [ 10.316543]
> [ 10.316543] which lock already depends on the new lock.
> [ 10.316543]
> [ 10.316641]
> [ 10.316641] the existing dependency chain (in reverse order) is:
> [ 10.316745]
> [ 10.316745] -> #1 (&fi->i_xattr_sem){.+.+}-{3:3}:
> [ 10.316883] down_read+0x3d/0x170
> [ 10.316973] f2fs_getxattr+0x370/0x440
> [ 10.317036] __f2fs_get_acl+0x38/0x1e0
> [ 10.317094] f2fs_init_acl+0x69/0x420
> [ 10.317151] f2fs_init_inode_metadata+0x72/0x450
> [ 10.317218] f2fs_add_regular_entry+0x372/0x510
> [ 10.317283] f2fs_add_dentry+0xb8/0xc0
> [ 10.317340] f2fs_do_add_link+0xd9/0x110
> [ 10.317399] f2fs_mkdir+0xdf/0x180
> [ 10.317453] vfs_mkdir+0x142/0x220
> [ 10.317508] do_mkdirat+0x7c/0x120
> [ 10.317561] __x64_sys_mkdir+0x47/0x70
> [ 10.317617] do_syscall_64+0x3f/0x90
> [ 10.317673] entry_SYSCALL_64_after_hwframe+0x73/0xdd
> [ 10.317757]
> [ 10.317757] -> #0 (&fi->i_sem){+.+.}-{3:3}:
> [ 10.317843] __lock_acquire+0x16bf/0x2860
> [ 10.317907] lock_acquire+0xcc/0x2c0
> [ 10.317962] down_write+0x3a/0xc0
> [ 10.318014] f2fs_add_inline_entry+0x134/0x2d0
> [ 10.318077] f2fs_add_dentry+0x55/0xc0
> [ 10.318141] f2fs_do_add_link+0xd9/0x110
> [ 10.318201] f2fs_create+0xe8/0x170
> [ 10.318255] lookup_open.isra.0+0x58e/0x6c0
> [ 10.318317] path_openat+0x2af/0xa40
> [ 10.318372] do_filp_open+0xb1/0x160
> [ 10.318428] do_sys_openat2+0x91/0xc0
> [ 10.318485] __x64_sys_open+0x54/0xa0
> [ 10.318541] do_syscall_64+0x3f/0x90
> [ 10.318597] entry_SYSCALL_64_after_hwframe+0x73/0xdd
> [ 10.318676]
> [ 10.318676] other info that might help us debug this:
> [ 10.318676]
> [ 10.318799] Possible unsafe locking scenario:
> [ 10.318799]
> [ 10.318875] CPU0 CPU1
> [ 10.318935] ---- ----
> [ 10.318999] rlock(&fi->i_xattr_sem);
> [ 10.319068] lock(&fi->i_sem);
> [ 10.319166] lock(&fi->i_xattr_sem);
> [ 10.319264] lock(&fi->i_sem);
It looks like the same one reported by syzbot.
https://syzkaller.appspot.com/bug?extid=a4976ce949df66b1ddf1
However, I suspect it's a false alarm, since I'm interpreting the loop as below.
CPU0 CPU1
lock(new_inode#1->i_xattr_sem)
lock(new_inode#2->i_sem)
lock(dir->i_xattr_sem)
lock(new_inode#1->i_sem)
This looks fine to me.
> [ 10.319325]
> [ 10.319325] *** DEADLOCK ***
> [ 10.319325]
> [ 10.319413] 4 locks held by seedrng/717:
> [ 10.319500] #0: ffff8e0e049693e8 (sb_writers#4){.+.+}-{0:0}, at: path_openat+0xa08/0xa40
> [ 10.319645] #1: ffff8e0e02c6ac28 (&type->i_mutex_dir_key#3){++++}-{3:3}, at: path_openat+0x29b/0xa40
> [ 10.319783] #2: ffff8e0e050623a8 (&sbi->cp_rwsem){.+.+}-{3:3}, at: f2fs_create+0xcc/0x170
> [ 10.319899] #3: ffff8e0e02c6b278 (&fi->i_xattr_sem){.+.+}-{3:3}, at: f2fs_add_dentry+0x41/0xc0
> [ 10.320029]
> [ 10.320029] stack backtrace:
> [ 10.320166] CPU: 7 PID: 717 Comm: seedrng Tainted: G N 6.5.0-rc6-00027-g91aa6c412d7f #1
> [ 10.320302] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014
> [ 10.320499] Call Trace:
> [ 10.320579] <TASK>
> [ 10.320665] dump_stack_lvl+0x64/0xb0
> [ 10.320766] check_noncircular+0x151/0x170
> [ 10.320834] ? register_lock_class+0x42/0x7a0
> [ 10.320906] __lock_acquire+0x16bf/0x2860
> [ 10.320974] lock_acquire+0xcc/0x2c0
> [ 10.321026] ? f2fs_add_inline_entry+0x134/0x2d0
> [ 10.321098] down_write+0x3a/0xc0
> [ 10.321156] ? f2fs_add_inline_entry+0x134/0x2d0
> [ 10.321220] f2fs_add_inline_entry+0x134/0x2d0
> [ 10.321290] f2fs_add_dentry+0x55/0xc0
> [ 10.321348] f2fs_do_add_link+0xd9/0x110
> [ 10.321410] f2fs_create+0xe8/0x170
> [ 10.321464] lookup_open.isra.0+0x58e/0x6c0
> [ 10.321536] ? verify_cpu+0x20/0x100
> [ 10.321605] ? verify_cpu+0x20/0x100
> [ 10.321662] path_openat+0x2af/0xa40
> [ 10.321722] do_filp_open+0xb1/0x160
> [ 10.321777] ? alloc_fd+0x3c/0x220
> [ 10.321838] ? _raw_spin_unlock+0x1e/0x40
> [ 10.321901] do_sys_openat2+0x91/0xc0
> [ 10.321959] __x64_sys_open+0x54/0xa0
> [ 10.322014] do_syscall_64+0x3f/0x90
> [ 10.322066] entry_SYSCALL_64_after_hwframe+0x73/0xdd
> [ 10.322182] RIP: 0033:0x7ffbe94532de
> [ 10.322384] Code: c3 8b 07 85 c0 75 24 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 <c3> e9 4b ce ff ff 41 54 4
> 9 89 f4 be 00 88 08 00 55 53 48 81 ec a0
> [ 10.322619] RSP: 002b:00007ffc0cfc7ed8 EFLAGS: 00000246 ORIG_RAX: 0000000000000002
> [ 10.322730] RAX: ffffffffffffffda RBX: 00007ffbe9495b48 RCX: 00007ffbe94532de
> [ 10.322821] RDX: 0000000000000100 RSI: 0000000000008241 RDI: 000055f2b0816001
> [ 10.322910] RBP: 000055f2b0816001 R08: 0000000000000000 R09: 0000000000000000
> [ 10.322999] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000002
> [ 10.323089] R13: 000055f2b0816001 R14: 000055f2b0816059 R15: 00007ffc0cfc8148
> [ 10.323221] </TASK>
> [ 10.383174] seedrng (717) used greatest stack depth: 12624 bytes left
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [f2fs-dev] circular locking dependency warning in f2fs
2023-08-16 17:25 ` Jaegeuk Kim
@ 2023-08-17 2:11 ` Guenter Roeck
2023-08-17 3:52 ` Jaegeuk Kim
0 siblings, 1 reply; 14+ messages in thread
From: Guenter Roeck @ 2023-08-17 2:11 UTC (permalink / raw)
To: Jaegeuk Kim; +Cc: Jaegeuk Kim, linux-f2fs-devel
On Wed, Aug 16, 2023 at 10:25:06AM -0700, Jaegeuk Kim wrote:
> Hi,
>
> On Tue, Aug 15, 2023 at 10:09 PM Guenter Roeck <linux@roeck-us.net> wrote:
> >
> > Hi,
> >
> > when trying to boot from an f2fs file system with lock debugging enabled,
> > I get the attached circular locking dependency warning. Is this a known
> > problem ?
> >
> > Thanks,
> > Guenter
> >
> > ---
> > [ 10.315522] ======================================================
> > [ 10.315620] WARNING: possible circular locking dependency detected
> > [ 10.315753] 6.5.0-rc6-00027-g91aa6c412d7f #1 Tainted: G N
> > [ 10.315843] ------------------------------------------------------
> > [ 10.315922] seedrng/717 is trying to acquire lock:
> > [ 10.316010] ffff8e0e02c6b868 (&fi->i_sem){+.+.}-{3:3}, at: f2fs_add_inline_entry+0x134/0x2d0
> > [ 10.316315]
> > [ 10.316315] but task is already holding lock:
> > [ 10.316391] ffff8e0e02c6b278 (&fi->i_xattr_sem){.+.+}-{3:3}, at: f2fs_add_dentry+0x41/0xc0
> > [ 10.316543]
> > [ 10.316543] which lock already depends on the new lock.
> > [ 10.316543]
> > [ 10.316641]
> > [ 10.316641] the existing dependency chain (in reverse order) is:
> > [ 10.316745]
> > [ 10.316745] -> #1 (&fi->i_xattr_sem){.+.+}-{3:3}:
> > [ 10.316883] down_read+0x3d/0x170
> > [ 10.316973] f2fs_getxattr+0x370/0x440
> > [ 10.317036] __f2fs_get_acl+0x38/0x1e0
> > [ 10.317094] f2fs_init_acl+0x69/0x420
> > [ 10.317151] f2fs_init_inode_metadata+0x72/0x450
> > [ 10.317218] f2fs_add_regular_entry+0x372/0x510
> > [ 10.317283] f2fs_add_dentry+0xb8/0xc0
> > [ 10.317340] f2fs_do_add_link+0xd9/0x110
> > [ 10.317399] f2fs_mkdir+0xdf/0x180
> > [ 10.317453] vfs_mkdir+0x142/0x220
> > [ 10.317508] do_mkdirat+0x7c/0x120
> > [ 10.317561] __x64_sys_mkdir+0x47/0x70
> > [ 10.317617] do_syscall_64+0x3f/0x90
> > [ 10.317673] entry_SYSCALL_64_after_hwframe+0x73/0xdd
> > [ 10.317757]
> > [ 10.317757] -> #0 (&fi->i_sem){+.+.}-{3:3}:
> > [ 10.317843] __lock_acquire+0x16bf/0x2860
> > [ 10.317907] lock_acquire+0xcc/0x2c0
> > [ 10.317962] down_write+0x3a/0xc0
> > [ 10.318014] f2fs_add_inline_entry+0x134/0x2d0
> > [ 10.318077] f2fs_add_dentry+0x55/0xc0
> > [ 10.318141] f2fs_do_add_link+0xd9/0x110
> > [ 10.318201] f2fs_create+0xe8/0x170
> > [ 10.318255] lookup_open.isra.0+0x58e/0x6c0
> > [ 10.318317] path_openat+0x2af/0xa40
> > [ 10.318372] do_filp_open+0xb1/0x160
> > [ 10.318428] do_sys_openat2+0x91/0xc0
> > [ 10.318485] __x64_sys_open+0x54/0xa0
> > [ 10.318541] do_syscall_64+0x3f/0x90
> > [ 10.318597] entry_SYSCALL_64_after_hwframe+0x73/0xdd
> > [ 10.318676]
> > [ 10.318676] other info that might help us debug this:
> > [ 10.318676]
> > [ 10.318799] Possible unsafe locking scenario:
> > [ 10.318799]
> > [ 10.318875] CPU0 CPU1
> > [ 10.318935] ---- ----
> > [ 10.318999] rlock(&fi->i_xattr_sem);
> > [ 10.319068] lock(&fi->i_sem);
> > [ 10.319166] lock(&fi->i_xattr_sem);
> > [ 10.319264] lock(&fi->i_sem);
>
> It looks like the same one reported by syzbot.
> https://syzkaller.appspot.com/bug?extid=a4976ce949df66b1ddf1
>
> However, I suspect it's a false alarm, since I'm interpreting the loop as below.
>
> CPU0 CPU1
> lock(new_inode#1->i_xattr_sem)
> lock(new_inode#2->i_sem)
> lock(dir->i_xattr_sem)
> lock(new_inode#1->i_sem)
>
> This looks fine to me.
>
Based on your feedback, am I correct assuming that you don't plan
to fix this ?
Thanks,
Guenter
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [f2fs-dev] circular locking dependency warning in f2fs
2023-08-17 2:11 ` Guenter Roeck
@ 2023-08-17 3:52 ` Jaegeuk Kim
2023-08-17 5:22 ` Guenter Roeck
2023-08-17 14:26 ` Chao Yu
0 siblings, 2 replies; 14+ messages in thread
From: Jaegeuk Kim @ 2023-08-17 3:52 UTC (permalink / raw)
To: Guenter Roeck; +Cc: Jaegeuk Kim, linux-f2fs-devel
On Wed, Aug 16, 2023 at 7:11 PM Guenter Roeck <linux@roeck-us.net> wrote:
>
> On Wed, Aug 16, 2023 at 10:25:06AM -0700, Jaegeuk Kim wrote:
> > Hi,
> >
> > On Tue, Aug 15, 2023 at 10:09 PM Guenter Roeck <linux@roeck-us.net> wrote:
> > >
> > > Hi,
> > >
> > > when trying to boot from an f2fs file system with lock debugging enabled,
> > > I get the attached circular locking dependency warning. Is this a known
> > > problem ?
> > >
> > > Thanks,
> > > Guenter
> > >
> > > ---
> > > [ 10.315522] ======================================================
> > > [ 10.315620] WARNING: possible circular locking dependency detected
> > > [ 10.315753] 6.5.0-rc6-00027-g91aa6c412d7f #1 Tainted: G N
> > > [ 10.315843] ------------------------------------------------------
> > > [ 10.315922] seedrng/717 is trying to acquire lock:
> > > [ 10.316010] ffff8e0e02c6b868 (&fi->i_sem){+.+.}-{3:3}, at: f2fs_add_inline_entry+0x134/0x2d0
> > > [ 10.316315]
> > > [ 10.316315] but task is already holding lock:
> > > [ 10.316391] ffff8e0e02c6b278 (&fi->i_xattr_sem){.+.+}-{3:3}, at: f2fs_add_dentry+0x41/0xc0
> > > [ 10.316543]
> > > [ 10.316543] which lock already depends on the new lock.
> > > [ 10.316543]
> > > [ 10.316641]
> > > [ 10.316641] the existing dependency chain (in reverse order) is:
> > > [ 10.316745]
> > > [ 10.316745] -> #1 (&fi->i_xattr_sem){.+.+}-{3:3}:
> > > [ 10.316883] down_read+0x3d/0x170
> > > [ 10.316973] f2fs_getxattr+0x370/0x440
> > > [ 10.317036] __f2fs_get_acl+0x38/0x1e0
> > > [ 10.317094] f2fs_init_acl+0x69/0x420
> > > [ 10.317151] f2fs_init_inode_metadata+0x72/0x450
> > > [ 10.317218] f2fs_add_regular_entry+0x372/0x510
> > > [ 10.317283] f2fs_add_dentry+0xb8/0xc0
> > > [ 10.317340] f2fs_do_add_link+0xd9/0x110
> > > [ 10.317399] f2fs_mkdir+0xdf/0x180
> > > [ 10.317453] vfs_mkdir+0x142/0x220
> > > [ 10.317508] do_mkdirat+0x7c/0x120
> > > [ 10.317561] __x64_sys_mkdir+0x47/0x70
> > > [ 10.317617] do_syscall_64+0x3f/0x90
> > > [ 10.317673] entry_SYSCALL_64_after_hwframe+0x73/0xdd
> > > [ 10.317757]
> > > [ 10.317757] -> #0 (&fi->i_sem){+.+.}-{3:3}:
> > > [ 10.317843] __lock_acquire+0x16bf/0x2860
> > > [ 10.317907] lock_acquire+0xcc/0x2c0
> > > [ 10.317962] down_write+0x3a/0xc0
> > > [ 10.318014] f2fs_add_inline_entry+0x134/0x2d0
> > > [ 10.318077] f2fs_add_dentry+0x55/0xc0
> > > [ 10.318141] f2fs_do_add_link+0xd9/0x110
> > > [ 10.318201] f2fs_create+0xe8/0x170
> > > [ 10.318255] lookup_open.isra.0+0x58e/0x6c0
> > > [ 10.318317] path_openat+0x2af/0xa40
> > > [ 10.318372] do_filp_open+0xb1/0x160
> > > [ 10.318428] do_sys_openat2+0x91/0xc0
> > > [ 10.318485] __x64_sys_open+0x54/0xa0
> > > [ 10.318541] do_syscall_64+0x3f/0x90
> > > [ 10.318597] entry_SYSCALL_64_after_hwframe+0x73/0xdd
> > > [ 10.318676]
> > > [ 10.318676] other info that might help us debug this:
> > > [ 10.318676]
> > > [ 10.318799] Possible unsafe locking scenario:
> > > [ 10.318799]
> > > [ 10.318875] CPU0 CPU1
> > > [ 10.318935] ---- ----
> > > [ 10.318999] rlock(&fi->i_xattr_sem);
> > > [ 10.319068] lock(&fi->i_sem);
> > > [ 10.319166] lock(&fi->i_xattr_sem);
> > > [ 10.319264] lock(&fi->i_sem);
> >
> > It looks like the same one reported by syzbot.
> > https://syzkaller.appspot.com/bug?extid=a4976ce949df66b1ddf1
> >
> > However, I suspect it's a false alarm, since I'm interpreting the loop as below.
> >
> > CPU0 CPU1
> > lock(new_inode#1->i_xattr_sem)
> > lock(new_inode#2->i_sem)
> > lock(dir->i_xattr_sem)
> > lock(new_inode#1->i_sem)
> >
> > This looks fine to me.
> >
>
> Based on your feedback, am I correct assuming that you don't plan
> to fix this ?
I'm quite open to something that I may miss. Chao, what do you think?
>
> Thanks,
> Guenter
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [f2fs-dev] circular locking dependency warning in f2fs
2023-08-17 3:52 ` Jaegeuk Kim
@ 2023-08-17 5:22 ` Guenter Roeck
2023-08-17 14:26 ` Chao Yu
1 sibling, 0 replies; 14+ messages in thread
From: Guenter Roeck @ 2023-08-17 5:22 UTC (permalink / raw)
To: Jaegeuk Kim; +Cc: Jaegeuk Kim, linux-f2fs-devel
On Wed, Aug 16, 2023 at 08:52:19PM -0700, Jaegeuk Kim wrote:
> On Wed, Aug 16, 2023 at 7:11 PM Guenter Roeck <linux@roeck-us.net> wrote:
> >
> > On Wed, Aug 16, 2023 at 10:25:06AM -0700, Jaegeuk Kim wrote:
> > > Hi,
> > >
> > > On Tue, Aug 15, 2023 at 10:09 PM Guenter Roeck <linux@roeck-us.net> wrote:
> > > >
> > > > Hi,
> > > >
> > > > when trying to boot from an f2fs file system with lock debugging enabled,
> > > > I get the attached circular locking dependency warning. Is this a known
> > > > problem ?
> > > >
> > > > Thanks,
> > > > Guenter
> > > >
> > > > ---
> > > > [ 10.315522] ======================================================
> > > > [ 10.315620] WARNING: possible circular locking dependency detected
> > > > [ 10.315753] 6.5.0-rc6-00027-g91aa6c412d7f #1 Tainted: G N
> > > > [ 10.315843] ------------------------------------------------------
> > > > [ 10.315922] seedrng/717 is trying to acquire lock:
> > > > [ 10.316010] ffff8e0e02c6b868 (&fi->i_sem){+.+.}-{3:3}, at: f2fs_add_inline_entry+0x134/0x2d0
> > > > [ 10.316315]
> > > > [ 10.316315] but task is already holding lock:
> > > > [ 10.316391] ffff8e0e02c6b278 (&fi->i_xattr_sem){.+.+}-{3:3}, at: f2fs_add_dentry+0x41/0xc0
> > > > [ 10.316543]
> > > > [ 10.316543] which lock already depends on the new lock.
> > > > [ 10.316543]
> > > > [ 10.316641]
> > > > [ 10.316641] the existing dependency chain (in reverse order) is:
> > > > [ 10.316745]
> > > > [ 10.316745] -> #1 (&fi->i_xattr_sem){.+.+}-{3:3}:
> > > > [ 10.316883] down_read+0x3d/0x170
> > > > [ 10.316973] f2fs_getxattr+0x370/0x440
> > > > [ 10.317036] __f2fs_get_acl+0x38/0x1e0
> > > > [ 10.317094] f2fs_init_acl+0x69/0x420
> > > > [ 10.317151] f2fs_init_inode_metadata+0x72/0x450
> > > > [ 10.317218] f2fs_add_regular_entry+0x372/0x510
> > > > [ 10.317283] f2fs_add_dentry+0xb8/0xc0
> > > > [ 10.317340] f2fs_do_add_link+0xd9/0x110
> > > > [ 10.317399] f2fs_mkdir+0xdf/0x180
> > > > [ 10.317453] vfs_mkdir+0x142/0x220
> > > > [ 10.317508] do_mkdirat+0x7c/0x120
> > > > [ 10.317561] __x64_sys_mkdir+0x47/0x70
> > > > [ 10.317617] do_syscall_64+0x3f/0x90
> > > > [ 10.317673] entry_SYSCALL_64_after_hwframe+0x73/0xdd
> > > > [ 10.317757]
> > > > [ 10.317757] -> #0 (&fi->i_sem){+.+.}-{3:3}:
> > > > [ 10.317843] __lock_acquire+0x16bf/0x2860
> > > > [ 10.317907] lock_acquire+0xcc/0x2c0
> > > > [ 10.317962] down_write+0x3a/0xc0
> > > > [ 10.318014] f2fs_add_inline_entry+0x134/0x2d0
> > > > [ 10.318077] f2fs_add_dentry+0x55/0xc0
> > > > [ 10.318141] f2fs_do_add_link+0xd9/0x110
> > > > [ 10.318201] f2fs_create+0xe8/0x170
> > > > [ 10.318255] lookup_open.isra.0+0x58e/0x6c0
> > > > [ 10.318317] path_openat+0x2af/0xa40
> > > > [ 10.318372] do_filp_open+0xb1/0x160
> > > > [ 10.318428] do_sys_openat2+0x91/0xc0
> > > > [ 10.318485] __x64_sys_open+0x54/0xa0
> > > > [ 10.318541] do_syscall_64+0x3f/0x90
> > > > [ 10.318597] entry_SYSCALL_64_after_hwframe+0x73/0xdd
> > > > [ 10.318676]
> > > > [ 10.318676] other info that might help us debug this:
> > > > [ 10.318676]
> > > > [ 10.318799] Possible unsafe locking scenario:
> > > > [ 10.318799]
> > > > [ 10.318875] CPU0 CPU1
> > > > [ 10.318935] ---- ----
> > > > [ 10.318999] rlock(&fi->i_xattr_sem);
> > > > [ 10.319068] lock(&fi->i_sem);
> > > > [ 10.319166] lock(&fi->i_xattr_sem);
> > > > [ 10.319264] lock(&fi->i_sem);
> > >
> > > It looks like the same one reported by syzbot.
> > > https://syzkaller.appspot.com/bug?extid=a4976ce949df66b1ddf1
> > >
> > > However, I suspect it's a false alarm, since I'm interpreting the loop as below.
> > >
> > > CPU0 CPU1
> > > lock(new_inode#1->i_xattr_sem)
> > > lock(new_inode#2->i_sem)
> > > lock(dir->i_xattr_sem)
> > > lock(new_inode#1->i_sem)
> > >
> > > This looks fine to me.
> > >
> >
> > Based on your feedback, am I correct assuming that you don't plan
> > to fix this ?
>
> I'm quite open to something that I may miss. Chao, what do you think?
>
Just to give you a background: Recently I started boot testing from f2fs.
Apparently my test bed is the only one testing f2fs, meaning I was the
only one reporting that f2fs crashes in v6.1.y. I then extended my j2fs
test coverage to multiple architectures, only to discover that a recent
commit introduced this lockdep splatch.
My tests always run with lockdep debugging enabled. At the same time,
I can not tolerate persistent warnings because those would hide real
problems. As consequence, I disable any feature generating such warnings
if the reponsible maintainer(s) tell me that they won't fix it. In this
context, it doesn't matter if the warning is a false positive or not.
Ultimately I am quite neutral in this regard; it is up to you if you are
going to address the warning or not. I would just like to know if the
above warning is going to be fixed so I can adjust my test coverage
accordingly.
Side question: Does this possibly need down_read_nested() ?
Thanks,
Guenter
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [f2fs-dev] circular locking dependency warning in f2fs
2023-08-17 3:52 ` Jaegeuk Kim
2023-08-17 5:22 ` Guenter Roeck
@ 2023-08-17 14:26 ` Chao Yu
2023-08-17 15:53 ` Eric Biggers
1 sibling, 1 reply; 14+ messages in thread
From: Chao Yu @ 2023-08-17 14:26 UTC (permalink / raw)
To: Jaegeuk Kim, Guenter Roeck; +Cc: Jaegeuk Kim, linux-f2fs-devel
On 2023/8/17 11:52, Jaegeuk Kim wrote:
> On Wed, Aug 16, 2023 at 7:11 PM Guenter Roeck <linux@roeck-us.net> wrote:
>>
>> On Wed, Aug 16, 2023 at 10:25:06AM -0700, Jaegeuk Kim wrote:
>>> Hi,
>>>
>>> On Tue, Aug 15, 2023 at 10:09 PM Guenter Roeck <linux@roeck-us.net> wrote:
>>>>
>>>> Hi,
>>>>
>>>> when trying to boot from an f2fs file system with lock debugging enabled,
>>>> I get the attached circular locking dependency warning. Is this a known
>>>> problem ?
>>>>
>>>> Thanks,
>>>> Guenter
>>>>
>>>> ---
>>>> [ 10.315522] ======================================================
>>>> [ 10.315620] WARNING: possible circular locking dependency detected
>>>> [ 10.315753] 6.5.0-rc6-00027-g91aa6c412d7f #1 Tainted: G N
>>>> [ 10.315843] ------------------------------------------------------
>>>> [ 10.315922] seedrng/717 is trying to acquire lock:
>>>> [ 10.316010] ffff8e0e02c6b868 (&fi->i_sem){+.+.}-{3:3}, at: f2fs_add_inline_entry+0x134/0x2d0
>>>> [ 10.316315]
>>>> [ 10.316315] but task is already holding lock:
>>>> [ 10.316391] ffff8e0e02c6b278 (&fi->i_xattr_sem){.+.+}-{3:3}, at: f2fs_add_dentry+0x41/0xc0
>>>> [ 10.316543]
>>>> [ 10.316543] which lock already depends on the new lock.
>>>> [ 10.316543]
>>>> [ 10.316641]
>>>> [ 10.316641] the existing dependency chain (in reverse order) is:
>>>> [ 10.316745]
>>>> [ 10.316745] -> #1 (&fi->i_xattr_sem){.+.+}-{3:3}:
>>>> [ 10.316883] down_read+0x3d/0x170
>>>> [ 10.316973] f2fs_getxattr+0x370/0x440
>>>> [ 10.317036] __f2fs_get_acl+0x38/0x1e0
>>>> [ 10.317094] f2fs_init_acl+0x69/0x420
>>>> [ 10.317151] f2fs_init_inode_metadata+0x72/0x450
>>>> [ 10.317218] f2fs_add_regular_entry+0x372/0x510
>>>> [ 10.317283] f2fs_add_dentry+0xb8/0xc0
>>>> [ 10.317340] f2fs_do_add_link+0xd9/0x110
>>>> [ 10.317399] f2fs_mkdir+0xdf/0x180
>>>> [ 10.317453] vfs_mkdir+0x142/0x220
>>>> [ 10.317508] do_mkdirat+0x7c/0x120
>>>> [ 10.317561] __x64_sys_mkdir+0x47/0x70
>>>> [ 10.317617] do_syscall_64+0x3f/0x90
>>>> [ 10.317673] entry_SYSCALL_64_after_hwframe+0x73/0xdd
>>>> [ 10.317757]
>>>> [ 10.317757] -> #0 (&fi->i_sem){+.+.}-{3:3}:
>>>> [ 10.317843] __lock_acquire+0x16bf/0x2860
>>>> [ 10.317907] lock_acquire+0xcc/0x2c0
>>>> [ 10.317962] down_write+0x3a/0xc0
>>>> [ 10.318014] f2fs_add_inline_entry+0x134/0x2d0
>>>> [ 10.318077] f2fs_add_dentry+0x55/0xc0
>>>> [ 10.318141] f2fs_do_add_link+0xd9/0x110
>>>> [ 10.318201] f2fs_create+0xe8/0x170
>>>> [ 10.318255] lookup_open.isra.0+0x58e/0x6c0
>>>> [ 10.318317] path_openat+0x2af/0xa40
>>>> [ 10.318372] do_filp_open+0xb1/0x160
>>>> [ 10.318428] do_sys_openat2+0x91/0xc0
>>>> [ 10.318485] __x64_sys_open+0x54/0xa0
>>>> [ 10.318541] do_syscall_64+0x3f/0x90
>>>> [ 10.318597] entry_SYSCALL_64_after_hwframe+0x73/0xdd
>>>> [ 10.318676]
>>>> [ 10.318676] other info that might help us debug this:
>>>> [ 10.318676]
>>>> [ 10.318799] Possible unsafe locking scenario:
>>>> [ 10.318799]
>>>> [ 10.318875] CPU0 CPU1
>>>> [ 10.318935] ---- ----
>>>> [ 10.318999] rlock(&fi->i_xattr_sem);
>>>> [ 10.319068] lock(&fi->i_sem);
>>>> [ 10.319166] lock(&fi->i_xattr_sem);
>>>> [ 10.319264] lock(&fi->i_sem);
>>>
>>> It looks like the same one reported by syzbot.
>>> https://syzkaller.appspot.com/bug?extid=a4976ce949df66b1ddf1
>>>
>>> However, I suspect it's a false alarm, since I'm interpreting the loop as below.
>>>
>>> CPU0 CPU1
>>> lock(new_inode#1->i_xattr_sem)
The call path is as below:
CPU0 CPU1
- f2fs_create
- f2fs_do_add_link
- f2fs_down_read(&F2FS_I(dir)->i_xattr_sem);
lock(dir#1->i_xattr_sem)
- f2fs_mkdir
- f2fs_do_add_link
- f2fs_add_regular_entry
- f2fs_down_write(&F2FS_I(inode)->i_sem);
lock(new_dir_inode->i_sem)
- f2fs_init_inode_metadata
- __f2fs_get_acl
- f2fs_getxattr
- f2fs_down_read(&F2FS_I(inode)->i_xattr_sem);
lock(dir#2->i_xattr_sem)
- f2fs_down_write(&F2FS_I(inode)->i_sem);
lock(new_reg_inode->i_sem)
1. i_xattr_sems were from different directories, otherwise, create and
mkdir may race on dir->i_rwsem.
2. fi->i_sems were from different type of inodes, one is regular, and
another is directory.
>>> lock(new_inode#2->i_sem)
>>> lock(dir->i_xattr_sem)
>>> lock(new_inode#1->i_sem)
>>>
>>> This looks fine to me.
>>>
>>
>> Based on your feedback, am I correct assuming that you don't plan
>> to fix this ?
>
> I'm quite open to something that I may miss. Chao, what do you think?
Jaegeuk, I agree with you, it looks like a false alarm.
Thanks,
>
>>
>> Thanks,
>> Guenter
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [f2fs-dev] circular locking dependency warning in f2fs
2023-08-17 14:26 ` Chao Yu
@ 2023-08-17 15:53 ` Eric Biggers
2023-08-18 13:15 ` Guenter Roeck
0 siblings, 1 reply; 14+ messages in thread
From: Eric Biggers @ 2023-08-17 15:53 UTC (permalink / raw)
To: Chao Yu; +Cc: Jaegeuk Kim, Guenter Roeck, linux-f2fs-devel
On Thu, Aug 17, 2023 at 10:26:12PM +0800, Chao Yu wrote:
> > > > lock(new_inode#2->i_sem)
> > > > lock(dir->i_xattr_sem)
> > > > lock(new_inode#1->i_sem)
> > > >
> > > > This looks fine to me.
> > > >
> > >
> > > Based on your feedback, am I correct assuming that you don't plan
> > > to fix this ?
> >
> > I'm quite open to something that I may miss. Chao, what do you think?
>
> Jaegeuk, I agree with you, it looks like a false alarm.
>
False positive lockdep reports still need to be eliminated, for example by
fixing the lockdep annotations. Otherwise it's impossible to distinguish them
from true positives.
- Eric
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [f2fs-dev] circular locking dependency warning in f2fs
2023-08-17 15:53 ` Eric Biggers
@ 2023-08-18 13:15 ` Guenter Roeck
2023-08-18 17:28 ` Jaegeuk Kim
0 siblings, 1 reply; 14+ messages in thread
From: Guenter Roeck @ 2023-08-18 13:15 UTC (permalink / raw)
To: Eric Biggers; +Cc: Jaegeuk Kim, linux-f2fs-devel
On Thu, Aug 17, 2023 at 08:53:19AM -0700, Eric Biggers wrote:
> On Thu, Aug 17, 2023 at 10:26:12PM +0800, Chao Yu wrote:
> > > > > lock(new_inode#2->i_sem)
> > > > > lock(dir->i_xattr_sem)
> > > > > lock(new_inode#1->i_sem)
> > > > >
> > > > > This looks fine to me.
> > > > >
> > > >
> > > > Based on your feedback, am I correct assuming that you don't plan
> > > > to fix this ?
> > >
> > > I'm quite open to something that I may miss. Chao, what do you think?
> >
> > Jaegeuk, I agree with you, it looks like a false alarm.
> >
>
> False positive lockdep reports still need to be eliminated, for example by
> fixing the lockdep annotations. Otherwise it's impossible to distinguish them
> from true positives.
>
Exactly, and that is why I don't test features with known lockdep annotation
issues. I'll drop f2fs from my list of features to test for the time being.
Guenter
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [f2fs-dev] circular locking dependency warning in f2fs
2023-08-18 13:15 ` Guenter Roeck
@ 2023-08-18 17:28 ` Jaegeuk Kim
2023-08-19 0:35 ` Jaegeuk Kim
2023-08-21 0:43 ` Chao Yu
0 siblings, 2 replies; 14+ messages in thread
From: Jaegeuk Kim @ 2023-08-18 17:28 UTC (permalink / raw)
To: Guenter Roeck; +Cc: Eric Biggers, Jaegeuk Kim, linux-f2fs-devel
Chao,
Do you have some bandwidth to address this? Otherwise, I'll do some.
Thanks,
On Fri, Aug 18, 2023 at 6:15 AM Guenter Roeck <linux@roeck-us.net> wrote:
>
> On Thu, Aug 17, 2023 at 08:53:19AM -0700, Eric Biggers wrote:
> > On Thu, Aug 17, 2023 at 10:26:12PM +0800, Chao Yu wrote:
> > > > > > lock(new_inode#2->i_sem)
> > > > > > lock(dir->i_xattr_sem)
> > > > > > lock(new_inode#1->i_sem)
> > > > > >
> > > > > > This looks fine to me.
> > > > > >
> > > > >
> > > > > Based on your feedback, am I correct assuming that you don't plan
> > > > > to fix this ?
> > > >
> > > > I'm quite open to something that I may miss. Chao, what do you think?
> > >
> > > Jaegeuk, I agree with you, it looks like a false alarm.
> > >
> >
> > False positive lockdep reports still need to be eliminated, for example by
> > fixing the lockdep annotations. Otherwise it's impossible to distinguish them
> > from true positives.
> >
>
> Exactly, and that is why I don't test features with known lockdep annotation
> issues. I'll drop f2fs from my list of features to test for the time being.
>
> Guenter
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [f2fs-dev] circular locking dependency warning in f2fs
2023-08-18 17:28 ` Jaegeuk Kim
@ 2023-08-19 0:35 ` Jaegeuk Kim
2023-08-19 2:06 ` Guenter Roeck
2023-08-21 0:43 ` Chao Yu
1 sibling, 1 reply; 14+ messages in thread
From: Jaegeuk Kim @ 2023-08-19 0:35 UTC (permalink / raw)
To: Jaegeuk Kim; +Cc: Eric Biggers, Guenter Roeck, linux-f2fs-devel
May I know if this works?
https://lore.kernel.org/linux-f2fs-devel/20230819003012.3473675-1-jaegeuk@kernel.org/T/#u
On 08/18, Jaegeuk Kim wrote:
> Chao,
>
> Do you have some bandwidth to address this? Otherwise, I'll do some.
>
> Thanks,
>
> On Fri, Aug 18, 2023 at 6:15 AM Guenter Roeck <linux@roeck-us.net> wrote:
> >
> > On Thu, Aug 17, 2023 at 08:53:19AM -0700, Eric Biggers wrote:
> > > On Thu, Aug 17, 2023 at 10:26:12PM +0800, Chao Yu wrote:
> > > > > > > lock(new_inode#2->i_sem)
> > > > > > > lock(dir->i_xattr_sem)
> > > > > > > lock(new_inode#1->i_sem)
> > > > > > >
> > > > > > > This looks fine to me.
> > > > > > >
> > > > > >
> > > > > > Based on your feedback, am I correct assuming that you don't plan
> > > > > > to fix this ?
> > > > >
> > > > > I'm quite open to something that I may miss. Chao, what do you think?
> > > >
> > > > Jaegeuk, I agree with you, it looks like a false alarm.
> > > >
> > >
> > > False positive lockdep reports still need to be eliminated, for example by
> > > fixing the lockdep annotations. Otherwise it's impossible to distinguish them
> > > from true positives.
> > >
> >
> > Exactly, and that is why I don't test features with known lockdep annotation
> > issues. I'll drop f2fs from my list of features to test for the time being.
> >
> > Guenter
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [f2fs-dev] circular locking dependency warning in f2fs
2023-08-19 0:35 ` Jaegeuk Kim
@ 2023-08-19 2:06 ` Guenter Roeck
2023-08-21 19:37 ` Jaegeuk Kim
0 siblings, 1 reply; 14+ messages in thread
From: Guenter Roeck @ 2023-08-19 2:06 UTC (permalink / raw)
To: Jaegeuk Kim; +Cc: Eric Biggers, linux-f2fs-devel
On Fri, Aug 18, 2023 at 05:35:25PM -0700, Jaegeuk Kim wrote:
> May I know if this works?
>
> https://lore.kernel.org/linux-f2fs-devel/20230819003012.3473675-1-jaegeuk@kernel.org/T/#u
>
Yes, that fixes the problem for me. That makes me wonder, though:
Why not just use the _nested functions unconditionally ?
Thanks,
Guenter
> On 08/18, Jaegeuk Kim wrote:
> > Chao,
> >
> > Do you have some bandwidth to address this? Otherwise, I'll do some.
> >
> > Thanks,
> >
> > On Fri, Aug 18, 2023 at 6:15 AM Guenter Roeck <linux@roeck-us.net> wrote:
> > >
> > > On Thu, Aug 17, 2023 at 08:53:19AM -0700, Eric Biggers wrote:
> > > > On Thu, Aug 17, 2023 at 10:26:12PM +0800, Chao Yu wrote:
> > > > > > > > lock(new_inode#2->i_sem)
> > > > > > > > lock(dir->i_xattr_sem)
> > > > > > > > lock(new_inode#1->i_sem)
> > > > > > > >
> > > > > > > > This looks fine to me.
> > > > > > > >
> > > > > > >
> > > > > > > Based on your feedback, am I correct assuming that you don't plan
> > > > > > > to fix this ?
> > > > > >
> > > > > > I'm quite open to something that I may miss. Chao, what do you think?
> > > > >
> > > > > Jaegeuk, I agree with you, it looks like a false alarm.
> > > > >
> > > >
> > > > False positive lockdep reports still need to be eliminated, for example by
> > > > fixing the lockdep annotations. Otherwise it's impossible to distinguish them
> > > > from true positives.
> > > >
> > >
> > > Exactly, and that is why I don't test features with known lockdep annotation
> > > issues. I'll drop f2fs from my list of features to test for the time being.
> > >
> > > Guenter
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [f2fs-dev] circular locking dependency warning in f2fs
2023-08-18 17:28 ` Jaegeuk Kim
2023-08-19 0:35 ` Jaegeuk Kim
@ 2023-08-21 0:43 ` Chao Yu
1 sibling, 0 replies; 14+ messages in thread
From: Chao Yu @ 2023-08-21 0:43 UTC (permalink / raw)
To: Jaegeuk Kim, Guenter Roeck; +Cc: Eric Biggers, Jaegeuk Kim, linux-f2fs-devel
On 2023/8/19 1:28, Jaegeuk Kim wrote:
> Chao,
>
> Do you have some bandwidth to address this? Otherwise, I'll do some.
Jaegeuk, it seems I'm late... anyway, the fix looks good to me.
Thanks,
>
> Thanks,
>
> On Fri, Aug 18, 2023 at 6:15 AM Guenter Roeck <linux@roeck-us.net> wrote:
>>
>> On Thu, Aug 17, 2023 at 08:53:19AM -0700, Eric Biggers wrote:
>>> On Thu, Aug 17, 2023 at 10:26:12PM +0800, Chao Yu wrote:
>>>>>>> lock(new_inode#2->i_sem)
>>>>>>> lock(dir->i_xattr_sem)
>>>>>>> lock(new_inode#1->i_sem)
>>>>>>>
>>>>>>> This looks fine to me.
>>>>>>>
>>>>>>
>>>>>> Based on your feedback, am I correct assuming that you don't plan
>>>>>> to fix this ?
>>>>>
>>>>> I'm quite open to something that I may miss. Chao, what do you think?
>>>>
>>>> Jaegeuk, I agree with you, it looks like a false alarm.
>>>>
>>>
>>> False positive lockdep reports still need to be eliminated, for example by
>>> fixing the lockdep annotations. Otherwise it's impossible to distinguish them
>>> from true positives.
>>>
>>
>> Exactly, and that is why I don't test features with known lockdep annotation
>> issues. I'll drop f2fs from my list of features to test for the time being.
>>
>> Guenter
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [f2fs-dev] circular locking dependency warning in f2fs
2023-08-19 2:06 ` Guenter Roeck
@ 2023-08-21 19:37 ` Jaegeuk Kim
2023-08-21 20:43 ` Guenter Roeck
0 siblings, 1 reply; 14+ messages in thread
From: Jaegeuk Kim @ 2023-08-21 19:37 UTC (permalink / raw)
To: Guenter Roeck; +Cc: Eric Biggers, linux-f2fs-devel
On 08/18, Guenter Roeck wrote:
> On Fri, Aug 18, 2023 at 05:35:25PM -0700, Jaegeuk Kim wrote:
> > May I know if this works?
> >
> > https://lore.kernel.org/linux-f2fs-devel/20230819003012.3473675-1-jaegeuk@kernel.org/T/#u
> >
>
> Yes, that fixes the problem for me. That makes me wonder, though:
> Why not just use the _nested functions unconditionally ?
I think we should ignore that in this case only.
>
> Thanks,
> Guenter
>
> > On 08/18, Jaegeuk Kim wrote:
> > > Chao,
> > >
> > > Do you have some bandwidth to address this? Otherwise, I'll do some.
> > >
> > > Thanks,
> > >
> > > On Fri, Aug 18, 2023 at 6:15 AM Guenter Roeck <linux@roeck-us.net> wrote:
> > > >
> > > > On Thu, Aug 17, 2023 at 08:53:19AM -0700, Eric Biggers wrote:
> > > > > On Thu, Aug 17, 2023 at 10:26:12PM +0800, Chao Yu wrote:
> > > > > > > > > lock(new_inode#2->i_sem)
> > > > > > > > > lock(dir->i_xattr_sem)
> > > > > > > > > lock(new_inode#1->i_sem)
> > > > > > > > >
> > > > > > > > > This looks fine to me.
> > > > > > > > >
> > > > > > > >
> > > > > > > > Based on your feedback, am I correct assuming that you don't plan
> > > > > > > > to fix this ?
> > > > > > >
> > > > > > > I'm quite open to something that I may miss. Chao, what do you think?
> > > > > >
> > > > > > Jaegeuk, I agree with you, it looks like a false alarm.
> > > > > >
> > > > >
> > > > > False positive lockdep reports still need to be eliminated, for example by
> > > > > fixing the lockdep annotations. Otherwise it's impossible to distinguish them
> > > > > from true positives.
> > > > >
> > > >
> > > > Exactly, and that is why I don't test features with known lockdep annotation
> > > > issues. I'll drop f2fs from my list of features to test for the time being.
> > > >
> > > > Guenter
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [f2fs-dev] circular locking dependency warning in f2fs
2023-08-21 19:37 ` Jaegeuk Kim
@ 2023-08-21 20:43 ` Guenter Roeck
0 siblings, 0 replies; 14+ messages in thread
From: Guenter Roeck @ 2023-08-21 20:43 UTC (permalink / raw)
To: Jaegeuk Kim; +Cc: Eric Biggers, linux-f2fs-devel
On Mon, Aug 21, 2023 at 12:37:12PM -0700, Jaegeuk Kim wrote:
> On 08/18, Guenter Roeck wrote:
> > On Fri, Aug 18, 2023 at 05:35:25PM -0700, Jaegeuk Kim wrote:
> > > May I know if this works?
> > >
> > > https://lore.kernel.org/linux-f2fs-devel/20230819003012.3473675-1-jaegeuk@kernel.org/T/#u
> > >
> >
> > Yes, that fixes the problem for me. That makes me wonder, though:
> > Why not just use the _nested functions unconditionally ?
>
> I think we should ignore that in this case only.
>
Not sure I understand. If CONFIG_DEBUG_LOCK_ALLOC is not enabled,
the _nested functions map to the standard (unnested) functions.
From include/linux/rwsem.h:
#ifdef CONFIG_DEBUG_LOCK_ALLOC
...
#else
# define down_read_nested(sem, subclass) down_read(sem)
# define down_read_killable_nested(sem, subclass) down_read_killable(sem)
# define down_write_nest_lock(sem, nest_lock) down_write(sem)
# define down_write_nested(sem, subclass) down_write(sem)
# define down_write_killable_nested(sem, subclass) down_write_killable(sem)
# define down_read_non_owner(sem) down_read(sem)
# define up_read_non_owner(sem) up_read(sem)
#endif
All you accomplish with the additional set of #ifdefs is to make the
code more difficult to read.
Never mind, I guess this is your call to make.
Guenter
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2023-08-21 20:43 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-08-16 5:09 [f2fs-dev] circular locking dependency warning in f2fs Guenter Roeck
2023-08-16 17:25 ` Jaegeuk Kim
2023-08-17 2:11 ` Guenter Roeck
2023-08-17 3:52 ` Jaegeuk Kim
2023-08-17 5:22 ` Guenter Roeck
2023-08-17 14:26 ` Chao Yu
2023-08-17 15:53 ` Eric Biggers
2023-08-18 13:15 ` Guenter Roeck
2023-08-18 17:28 ` Jaegeuk Kim
2023-08-19 0:35 ` Jaegeuk Kim
2023-08-19 2:06 ` Guenter Roeck
2023-08-21 19:37 ` Jaegeuk Kim
2023-08-21 20:43 ` Guenter Roeck
2023-08-21 0:43 ` Chao Yu
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.