INFO: possible circular locking dependency detected (v3.2-rc1)

Shawn Guo shawn.guo at freescale.com
Sat Nov 12 07:29:52 UTC 2011


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 at 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

https://lkml.org/lkml/2011/11/11/120




More information about the linaro-dev mailing list