[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <202210271500.731e3808-yujie.liu@intel.com>
Date: Thu, 27 Oct 2022 15:50:17 +0800
From: kernel test robot <yujie.liu@...el.com>
To: Stephen Brennan <stephen.s.brennan@...cle.com>
CC: <oe-lkp@...ts.linux.dev>, <lkp@...el.com>,
<linux-fsdevel@...r.kernel.org>, Jan Kara <jack@...e.cz>,
Alexander Viro <viro@...iv.linux.org.uk>,
Amir Goldstein <amir73il@...il.com>,
<linux-kernel@...r.kernel.org>,
Stephen Brennan <stephen.s.brennan@...cle.com>
Subject: Re: [PATCH 2/2] fsnotify: allow sleepable child flag update
Greeting,
FYI, we noticed WARNING:possible_recursive_locking_detected due to commit (built with clang-14):
commit: bed2685d9557ff9a7705f4172651a138e5f705af ("[PATCH 2/2] fsnotify: allow sleepable child flag update")
url: https://github.com/intel-lab-lkp/linux/commits/Stephen-Brennan/fsnotify-Protect-i_fsnotify_mask-and-child-flags-with-inode-rwsem/20221018-131326
base: https://git.kernel.org/cgit/linux/kernel/git/jack/linux-fs.git fsnotify
patch link: https://lore.kernel.org/linux-fsdevel/20221018041233.376977-3-stephen.s.brennan@oracle.com
patch subject: [PATCH 2/2] fsnotify: allow sleepable child flag update
in testcase: boot
on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 16G
caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):
[ 31.979147][ T1]
[ 31.979446][ T1] ============================================
[ 31.980051][ T1] WARNING: possible recursive locking detected
[ 31.980674][ T1] 6.0.0-rc4-00066-gbed2685d9557 #1 Not tainted
[ 31.981286][ T1] --------------------------------------------
[ 31.981889][ T1] systemd/1 is trying to acquire lock:
[ 31.982432][ T1] ffff88813f542510 (&dentry->d_lock){+.+.}-{2:2}, at: lockref_get+0xd/0x80
[ 31.983314][ T1]
[ 31.983314][ T1] but task is already holding lock:
[ 31.984040][ T1] ffff888100441b18 (&dentry->d_lock){+.+.}-{2:2}, at: __fsnotify_update_child_dentry_flags+0x85/0x2c0
[ 31.985132][ T1]
[ 31.985132][ T1] other info that might help us debug this:
[ 31.985967][ T1] Possible unsafe locking scenario:
[ 31.985967][ T1]
[ 31.986694][ T1] CPU0
[ 31.987025][ T1] ----
[ 31.987366][ T1] lock(&dentry->d_lock);
[ 31.987828][ T1] lock(&dentry->d_lock);
[ 31.988283][ T1]
[ 31.988283][ T1] *** DEADLOCK ***
[ 31.988283][ T1]
[ 31.989061][ T1] May be due to missing lock nesting notation
[ 31.989061][ T1]
[ 31.989888][ T1] 3 locks held by systemd/1:
[ 31.990361][ T1] #0: ffff88815249e128 (&group->mark_mutex){+.+.}-{3:3}, at: __x64_sys_inotify_add_watch+0x2fc/0xc00
[ 31.991473][ T1] #1: ffff888100480af8 (&sb->s_type->i_mutex_key){++++}-{3:3}, at: fsnotify_recalc_mask+0xf1/0x1c0
[ 31.992528][ T1] #2: ffff888100441b18 (&dentry->d_lock){+.+.}-{2:2}, at: __fsnotify_update_child_dentry_flags+0x85/0x2c0
[ 31.993671][ T1]
[ 31.993671][ T1] stack backtrace:
[ 31.994260][ T1] CPU: 0 PID: 1 Comm: systemd Not tainted 6.0.0-rc4-00066-gbed2685d9557 #1 1afcec0fe797aeed18cb95313bac4a75fb6852d3
[ 31.995440][ T1] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-4 04/01/2014
[ 31.996441][ T1] Call Trace:
[ 31.996791][ T1] <TASK>
[ 31.997101][ T1] dump_stack_lvl+0x6a/0x100
[ 31.997590][ T1] __lock_acquire+0x1110/0x7480
[ 31.998105][ T1] ? mark_lock+0x9a/0x380
[ 31.998560][ T1] ? mark_held_locks+0xad/0x1c0
[ 31.999056][ T1] ? lockdep_hardirqs_on_prepare+0x1a8/0x400
[ 31.999650][ T1] ? asm_sysvec_apic_timer_interrupt+0x1a/0x20
[ 32.000276][ T1] lock_acquire+0x177/0x480
[ 32.000739][ T1] ? lockref_get+0xd/0x80
[ 32.001178][ T1] _raw_spin_lock+0x2f/0x40
[ 32.001656][ T1] ? lockref_get+0xd/0x80
[ 32.002093][ T1] lockref_get+0xd/0x80
[ 32.002529][ T1] __fsnotify_update_child_dentry_flags+0x142/0x2c0
[ 32.003178][ T1] fsnotify_recalc_mask+0x126/0x1c0
[ 32.003711][ T1] fsnotify_add_mark_locked+0xd9e/0x1280
[ 32.004292][ T1] __x64_sys_inotify_add_watch+0x755/0xc00
[ 32.004898][ T1] ? syscall_enter_from_user_mode+0x26/0x180
[ 32.005660][ T1] do_syscall_64+0x6d/0xc0
[ 32.006125][ T1] entry_SYSCALL_64_after_hwframe+0x46/0xb0
[ 32.006735][ T1] RIP: 0033:0x7f839dd0a8f7
[ 32.007188][ T1] Code: f0 ff ff 73 01 c3 48 8b 0d 96 f5 0b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 b8 fe 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 69 f5 0b 00 f7 d8 64 89 01 48
[ 32.009103][ T1] RSP: 002b:00007ffe52095c98 EFLAGS: 00000202 ORIG_RAX: 00000000000000fe
[ 32.009945][ T1] RAX: ffffffffffffffda RBX: 0000555bc72cf930 RCX: 00007f839dd0a8f7
[ 32.010685][ T1] RDX: 0000000000000d84 RSI: 0000555bc72cf930 RDI: 000000000000001a
[ 32.011469][ T1] RBP: 0000555bc72cf931 R08: 00000000fe000000 R09: 0000555bc72a1e90
[ 32.012266][ T1] R10: 00007ffe52095c2c R11: 0000000000000202 R12: 0000000000000000
[ 32.012976][ T1] R13: 0000555bc72a1e90 R14: 0000000000000d84 R15: 0000555bc72cf930
[ 32.013705][ T1] </TASK>
If you fix the issue, kindly add following tag
| Reported-by: kernel test robot <yujie.liu@...el.com>
| Link: https://lore.kernel.org/oe-lkp/202210271500.731e3808-yujie.liu@intel.com
To reproduce:
# build kernel
cd linux
cp config-6.0.0-rc4-00066-gbed2685d9557 .config
make HOSTCC=clang-14 CC=clang-14 ARCH=x86_64 olddefconfig prepare modules_prepare bzImage modules
make HOSTCC=clang-14 CC=clang-14 ARCH=x86_64 INSTALL_MOD_PATH=<mod-install-dir> modules_install
cd <mod-install-dir>
find lib/ | cpio -o -H newc --quiet | gzip > modules.cgz
git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k <bzImage> -m modules.cgz job-script # job-script is attached in this email
# if come across any failure that blocks the test,
# please remove ~/.lkp and /lkp dir to run from a clean state.
--
0-DAY CI Kernel Test Service
https://01.org/lkp
View attachment "config-6.0.0-rc4-00066-gbed2685d9557" of type "text/plain" (169925 bytes)
View attachment "job-script" of type "text/plain" (4967 bytes)
Download attachment "dmesg.xz" of type "application/x-xz" (57000 bytes)
Powered by blists - more mailing lists