I'm running v3.2-rc1 kernel with CONFIG_PROVE_LOCKING enabled on imx6 and imx5 with Linaro rootfs (nano, developer) and seeing a circular locking dependency warning.
---8<---- [ 3.520947] Freeing init memory: 260K Loading, please wait... [ 3.713140] [ 3.714647] ====================================================== [ 3.720836] [ INFO: possible circular locking dependency detected ] [ 3.727112] 3.2.0-rc1+ #54 [ 3.729825] ------------------------------------------------------- [ 3.736102] udevd/368 is trying to acquire lock: [ 3.740728] (&sig->cred_guard_mutex){+.+.+.}, at: [<8013c688>] lock_trace+0x 28/0x5c [ 3.748544] [ 3.748547] but task is already holding lock: [ 3.754398] (&sb->s_type->i_mutex_key#6){+.+.+.}, at: [<800fc954>] do_lookup +0x1e4/0x32c [ 3.762665] [ 3.762668] which lock already depends on the new lock. [ 3.762674] [ 3.770879] [ 3.770882] the existing dependency chain (in reverse order) is: [ 3.778383] [ 3.778386] -> #1 (&sb->s_type->i_mutex_key#6){+.+.+.}: [ 3.785170] [<8006a7d8>] __lock_acquire+0x14c4/0x1a04 [ 3.790871] [<8006b34c>] lock_acquire+0x124/0x148 [ 3.796211] [<8047999c>] mutex_lock_nested+0x5c/0x394 [ 3.801903] [<800fc954>] do_lookup+0x1e4/0x32c [ 3.806982] [<800fcc6c>] link_path_walk+0x1d0/0x7d0 [ 3.812495] [<800fe750>] path_openat+0xac/0x374 [ 3.817661] [<800feb48>] do_filp_open+0x3c/0x88 [ 3.822826] [<800f5e98>] open_exec+0x2c/0x100 [ 3.827818] [<800f7544>] do_execve+0xd4/0x2a8 [ 3.832810] [<80011790>] sys_execve+0x44/0x64 [ 3.837815] [<8000db00>] ret_fast_syscall+0x0/0x3c [ 3.843245] [ 3.843248] -> #0 (&sig->cred_guard_mutex){+.+.+.}: [ 3.849667] [<80067aa4>] print_circular_bug+0x68/0x2b8 [ 3.855445] [<8006a5ac>] __lock_acquire+0x1298/0x1a04 [ 3.861132] [<8006b34c>] lock_acquire+0x124/0x148 [ 3.866470] [<804791a8>] mutex_lock_killable_nested+0x60/0x464 [ 3.872940] [<8013c688>] lock_trace+0x28/0x5c [ 3.877932] [<8013e79c>] proc_lookupfd_common+0x60/0xc8 [ 3.883795] [<8013e844>] proc_lookupfd+0x1c/0x24 [ 3.889047] [<800fa96c>] d_alloc_and_lookup+0x54/0x70 [ 3.894738] [<800fc978>] do_lookup+0x208/0x32c [ 3.899816] [<800fd434>] path_lookupat+0xfc/0x6c8 [ 3.905155] [<800fda2c>] do_path_lookup+0x2c/0x68 [ 3.910495] [<800feab0>] user_path_at_empty+0x68/0x98 [ 3.916181] [<800feb04>] user_path_at+0x24/0x2c [ 3.921346] [<800f4eb4>] vfs_fstatat+0x44/0x74 [ 3.926425] [<800f4f40>] vfs_stat+0x2c/0x30 [ 3.931243] [<800f5164>] sys_stat64+0x24/0x40 [ 3.936234] [<8000db00>] ret_fast_syscall+0x0/0x3c [ 3.941662] [ 3.941666] other info that might help us debug this: [ 3.941671] [ 3.949702] Possible unsafe locking scenario: [ 3.949708] [ 3.955644] CPU0 CPU1 [ 3.960181] ---- ---- [ 3.964718] lock(&sb->s_type->i_mutex_key); [ 3.969114] lock(&sig->cred_guard_mutex); [ 3.975853] lock(&sb->s_type->i_mutex_key); [ 3.982766] lock(&sig->cred_guard_mutex); [ 3.986984] [ 3.986987] *** DEADLOCK *** [ 3.986991] [ 3.992941] 1 lock held by udevd/368: [ 3.996609] #0: (&sb->s_type->i_mutex_key#6){+.+.+.}, at: [<800fc954>] do_l ookup+0x1e4/0x32c [ 4.005314] [ 4.005317] stack backtrace: [ 4.009712] [<800151dc>] (unwind_backtrace+0x0/0xec) from [<80477088>] (dump_ stack+0x20/0x24) [ 4.018260] [<80477088>] (dump_stack+0x20/0x24) from [<80067ca8>] (print_circ ular_bug+0x26c/0x2b8) [ 4.027242] [<80067ca8>] (print_circular_bug+0x26c/0x2b8) from [<8006a5ac>] ( __lock_acquire+0x1298/0x1a04) [ 4.036918] [<8006a5ac>] (__lock_acquire+0x1298/0x1a04) from [<8006b34c>] (lo ck_acquire+0x124/0x148) [ 4.046072] [<8006b34c>] (lock_acquire+0x124/0x148) from [<804791a8>] (mutex_ lock_killable_nested+0x60/0x464) [ 4.056007] [<804791a8>] (mutex_lock_killable_nested+0x60/0x464) from [<8013c 688>] (lock_trace+0x28/0x5c) [ 4.065593] [<8013c688>] (lock_trace+0x28/0x5c) from [<8013e79c>] (proc_looku pfd_common+0x60/0xc8) [ 4.074572] [<8013e79c>] (proc_lookupfd_common+0x60/0xc8) from [<8013e844>] ( proc_lookupfd+0x1c/0x24) [ 4.083812] [<8013e844>] (proc_lookupfd+0x1c/0x24) from [<800fa96c>] (d_alloc _and_lookup+0x54/0x70) [ 4.092878] [<800fa96c>] (d_alloc_and_lookup+0x54/0x70) from [<800fc978>] (do _lookup+0x208/0x32c) [ 4.101771] [<800fc978>] (do_lookup+0x208/0x32c) from [<800fd434>] (path_look upat+0xfc/0x6c8) [ 4.110317] [<800fd434>] (path_lookupat+0xfc/0x6c8) from [<800fda2c>] (do_pat h_lookup+0x2c/0x68) [ 4.119123] [<800fda2c>] (do_path_lookup+0x2c/0x68) from [<800feab0>] (user_p ath_at_empty+0x68/0x98) [ 4.128275] [<800feab0>] (user_path_at_empty+0x68/0x98) from [<800feb04>] (us er_path_at+0x24/0x2c) [ 4.137253] [<800feb04>] (user_path_at+0x24/0x2c) from [<800f4eb4>] (vfs_fsta tat+0x44/0x74) [ 4.145621] [<800f4eb4>] (vfs_fstatat+0x44/0x74) from [<800f4f40>] (vfs_stat+ 0x2c/0x30) [ 4.153642] [<800f4f40>] (vfs_stat+0x2c/0x30) from [<800f5164>] (sys_stat64+0 x24/0x40) [ 4.161579] [<800f5164>] (sys_stat64+0x24/0x40) from [<8000db00>] (ret_fast_s yscall+0x0/0x3c) [ 4.173173] udevd[369]: starting version 173 [ 4.585095] mmc0: new high speed SDHC card at address aaaa [ 4.591330] mmcblk0: mmc0:aaaa SD04G 3.69 GiB [ 4.597998] mmcblk0: p1 p2 p3 [ 5.384460] mmc1: host does not support reading read-only switch. assuming wr ite-enable. [ 5.796502] mmc1: new high speed SDHC card at address 1234 [ 5.803063] mmcblk1: mmc1:1234 SA04G 3.68 GiB [ 5.810156] mmcblk1: p1 p2 p3 [ 6.032487] EXT4-fs (mmcblk0p3): INFO: recovery required on readonly filesyst em [ 6.039849] EXT4-fs (mmcblk0p3): write access will be enabled during recovery [ 6.064099] EXT4-fs (mmcblk0p3): recovery complete [ 6.074078] EXT4-fs (mmcblk0p3): mounted filesystem with ordered data mode. O pts: (null)
Last login: Thu Jan 1 00:00:27 UTC 1970 on tty1 Welcome to Linaro 11.10 (development branch) (GNU/Linux 3.2.0-rc1+ armv7l)
* Documentation: https://wiki.linaro.org/ root@linaro-nano:~# ---->8---
As I see this only on v3.2-rc1 kernel, I suspect it's a v3.2-rc1 kernel issue and have reported on LKML[1]. I post it here for information and hope people running other platforms can try to reproduce the issue and confirm it's a common rather than imx only issue.
Regards, Shawn