linux-kernel - fs/namespace: inconsistent lock state

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <3237512f-7e38-89ba-314b-4a15c6c6812f@arm.com>
Date:   Tue, 13 Dec 2016 17:19:30 +0000
From:   Sudeep Holla <sudeep.holla@....com>
To:     Al Viro <viro@...iv.linux.org.uk>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Cc:     Sudeep Holla <sudeep.holla@....com>
Subject: fs/namespace: inconsistent lock state

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