Messages in this thread | | | From | Sudeep Holla <> | Subject | fs/namespace: inconsistent lock state | Date | Tue, 13 Dec 2016 17:19:30 +0000 |
| |
Hi Al,
I started seeing these message this morning when I picked up today's linux-next. It could be due to commit a1de523a3197 ("move mnt_free_id() into free_vfsmnt()"). Reverting it makes this error disappear.
================================= [ INFO: inconsistent lock state ] 4.9.0-next-20161213-00006-g733bb9f77ddb #244 Not tainted --------------------------------- inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. swapper/4/0 [HC0[0]:SC1[1]:HE1:SE0] takes: (mnt_id_lock){+.?...}, at: [<ffff0000082d886c>] mnt_free_id.isra.7+0x2c/0x70 {SOFTIRQ-ON-W} state was registered at: mark_lock+0x1a0/0x698 __lock_acquire+0x4d4/0x690 lock_acquire+0xcc/0x298 _raw_spin_lock+0x4c/0x60 alloc_vfsmnt+0x80/0x248 vfs_kern_mount+0x3c/0x160 mnt_init+0x1a8/0x260 vfs_caches_init+0x78/0xe8 start_kernel+0x3ac/0x414 __primary_switched+0x64/0x6c irq event stamp: 23366 hardirqs last enabled at (23366): rcu_process_callbacks+0x56c/0x940 hardirqs last disabled at (23365): rcu_process_callbacks+0x160/0x940 softirqs last enabled at (23352): _local_bh_enable+0x28/0x50 softirqs last disabled at (23353): irq_exit+0xe8/0x148
other info that might help us debug this: Possible unsafe locking scenario:
CPU0 ---- lock(mnt_id_lock); <Interrupt> lock(mnt_id_lock);
*** DEADLOCK ***
1 lock held by swapper/4/0: #0: (rcu_callback){......}, at: rcu_process_callbacks+0x28c/0x940
stack backtrace: CPU: 4 PID: 0 Comm: swapper/4 Not tainted 4.9.0-next-20161213-00006-g733bb9f77ddb #244 Call trace: dump_backtrace+0x0/0x258 show_stack+0x24/0x30 dump_stack+0xac/0xe8 print_usage_bug+0x20c/0x2b0 mark_lock+0x5bc/0x698 __lock_acquire+0x530/0x690 lock_acquire+0xcc/0x298 _raw_spin_lock+0x4c/0x60 mnt_free_id.isra.7+0x2c/0x70 free_vfsmnt+0x20/0x50 delayed_free_vfsmnt+0x20/0x30 rcu_process_callbacks+0x2cc/0x940 __do_softirq+0x12c/0x63c irq_exit+0xe8/0x148 __handle_domain_irq+0x6c/0xc0 gic_handle_irq+0x5c/0xb0
| |