aufs: possible bugfix, temporary lockdep_off for debugfs_create_file

The plain i_mutex lock under si_rwsem acquired may cause a lockdep
message. I've seen it on aufs4.1 for linux-v4.1-rc1, and I am afraid it
is a false positive. The message shows the lockdep chain of
namespace_sem -- si_resem -- i_mutex. Investigating the changes between
v4.0 and v4.1-rc1, I could not find the related commit in it. It may be
related to automount too. I'm afraid it could happen before v4.1-rc1.

======================================================
[ INFO: possible circular locking dependency detected ]
4.1.0aufsD+ #363 Not tainted
-------------------------------------------------------
perf/4110 is trying to acquire lock:
 (namespace_sem){++++++}, at: [<ffffffff811f597e>] lock_mount+0x8e/0x1e0

but task is already holding lock:
 (&sb->s_type->i_mutex_key#2){+.+.+.}, at: [<ffffffff811f5927>] lock_mount+0x37/0x1e0

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #2 (&sb->s_type->i_mutex_key#2){+.+.+.}:
       [<ffffffff810b4248>] lock_acquire+0xc8/0x2a0
       [<ffffffff8179b563>] mutex_lock_nested+0x63/0x510
       [<ffffffff8130f900>] start_creating+0xa0/0x1a0
       [<ffffffff8130fa5d>] debugfs_create_file+0x5d/0x1f0
       [<ffffffffa00dc74c>] dbgaufs_brs_add+0x9c/0x240 [aufs]
       [<ffffffffa00db705>] sysaufs_brs_add+0x25/0x200 [aufs]
       [<ffffffffa009ee7c>] aufs_mount+0x8c/0x1b0 [aufs]
       [<ffffffff811ced88>] mount_fs+0x48/0x260
       [<ffffffff811f434b>] vfs_kern_mount+0x7b/0x190
       [<ffffffff811f6f88>] do_mount+0x228/0xca0
       [<ffffffff811f7e39>] SyS_mount+0xe9/0x110
       [<ffffffff8179fed7>] system_call_fastpath+0x12/0x6f

-> #1 (&sbinfo->si_rwsem){++++++}:
       [<ffffffff810b4248>] lock_acquire+0xc8/0x2a0
       [<ffffffff8179d4d7>] down_read+0x47/0x60
       [<ffffffffa009efe7>] aufs_show_options+0x47/0x7e0 [aufs]
       [<ffffffff8121b670>] show_vfsmnt+0x110/0x160
       [<ffffffff811f2b56>] m_show+0x16/0x20
       [<ffffffff811f9c61>] seq_read+0x3b1/0x4a0
       [<ffffffff811c9fb8>] __vfs_read+0x18/0x40
       [<ffffffff811cb392>] vfs_read+0x122/0x190
       [<ffffffff811cb452>] SyS_read+0x52/0xb0
       [<ffffffff8179fed7>] system_call_fastpath+0x12/0x6f

-> #0 (namespace_sem){++++++}:
       [<ffffffff810b349b>] __lock_acquire+0x181b/0x1e30
       [<ffffffff810b4248>] lock_acquire+0xc8/0x2a0
       [<ffffffff8179d454>] down_write+0x44/0x80
       [<ffffffff811f597e>] lock_mount+0x8e/0x1e0
       [<ffffffff811f6012>] do_add_mount+0x32/0x130
       [<ffffffff811f6afc>] finish_automount+0x6c/0xe0
       [<ffffffff811d78f6>] follow_managed+0x1c6/0x320
       [<ffffffff811d987f>] lookup_fast+0x4ff/0x560
       [<ffffffff811dbf37>] path_lookupat+0xc7/0x8a0
       [<ffffffff811dc745>] filename_lookup+0x35/0x170
       [<ffffffff811dfd46>] user_path_at_empty+0x96/0xe0
       [<ffffffff811dfda1>] user_path_at+0x11/0x20
       [<ffffffff8120c034>] user_statfs+0x34/0x90
       [<ffffffff8120c10b>] SYSC_statfs+0x1b/0x40
       [<ffffffff8120c24e>] SyS_statfs+0xe/0x10
       [<ffffffff8179fed7>] system_call_fastpath+0x12/0x6f

other info that might help us debug this:

Chain exists of:
  namespace_sem --> &sbinfo->si_rwsem --> &sb->s_type->i_mutex_key#2

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(&sb->s_type->i_mutex_key#2);
                               lock(&sbinfo->si_rwsem);
                               lock(&sb->s_type->i_mutex_key#2);
  lock(namespace_sem);

 *** DEADLOCK ***

1 lock held by perf/4110:
 #0:  (&sb->s_type->i_mutex_key#2){+.+.+.}, at: [<ffffffff811f5927>] lock_mount+0x37/0x1e0

stack backtrace:
CPU: 0 PID: 4110 Comm: perf Not tainted 4.1.0aufsD+ #363
Hardware name: Pegatron Pegatron/IPM41, BIOS 0001 02/05/2009
 ffffffff85f22880 ffff880021e93908 ffffffff81793ee6 0000000000000000
 ffffffff85eed2a0 ffff880021e93958 ffffffff8178fece ffff880021e93958
 ffff880021e939c8 ffff880021e8e510 ffff880021e8ec58 ffff880021e8e510
Call Trace:
 [<ffffffff81793ee6>] dump_stack+0x4f/0xa2
 [<ffffffff8178fece>] print_circular_bug+0x1fb/0x20c
 [<ffffffff810b349b>] __lock_acquire+0x181b/0x1e30
 [<ffffffff810b4248>] lock_acquire+0xc8/0x2a0
 [<ffffffff811f597e>] ? lock_mount+0x8e/0x1e0
 [<ffffffff8179d454>] down_write+0x44/0x80
 [<ffffffff811f597e>] ? lock_mount+0x8e/0x1e0
 [<ffffffff811f597e>] lock_mount+0x8e/0x1e0
 [<ffffffff811f6012>] do_add_mount+0x32/0x130
 [<ffffffff813b7708>] ? find_next_bit+0x18/0x20
 [<ffffffff811f6afc>] finish_automount+0x6c/0xe0
 [<ffffffff811d78f6>] follow_managed+0x1c6/0x320
 [<ffffffff811d987f>] lookup_fast+0x4ff/0x560
 [<ffffffff811da64f>] ? path_init+0xbf/0x8d0
 [<ffffffff811dbe00>] ? complete_walk+0x1e0/0x250
 [<ffffffff811dbf37>] path_lookupat+0xc7/0x8a0
 [<ffffffff811dc745>] filename_lookup+0x35/0x170
 [<ffffffff811dfd46>] user_path_at_empty+0x96/0xe0
 [<ffffffff8118dce8>] ? might_fault+0xa8/0xb0
 [<ffffffff8118dc9f>] ? might_fault+0x5f/0xb0
 [<ffffffff8120bf27>] ? do_statfs_native+0xa7/0xc0
 [<ffffffff811dfda1>] user_path_at+0x11/0x20
 [<ffffffff8120c034>] user_statfs+0x34/0x90
 [<ffffffff8120c10b>] SYSC_statfs+0x1b/0x40
 [<ffffffff813ae808>] ? lockdep_sys_exit_thunk+0x12/0x14
 [<ffffffff8120c24e>] SyS_statfs+0xe/0x10
 [<ffffffff8179fed7>] system_call_fastpath+0x12/0x6f

Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
(cherry picked from commit f440be7d4ac14d1ae004adaee072114fd31e8d83)

Author: sfjro

fs/aufs/dbgaufs.c

@@ -294,8 +294,11 @@ void dbgaufs_brs_add(struct super_block *sb, aufs_bindex_t bindex)
 		br = au_sbr(sb, bindex);
 		xi = &br->br_xino;
 		AuDebugOn(xi->xi_dbgaufs);
+		/* debugfs acquires the parent i_mutex */
+		lockdep_off();
 		xi->xi_dbgaufs = debugfs_create_file(name, dbgaufs_mode, parent,
 						     sbinfo, &dbgaufs_xino_fop);
+		lockdep_on();
 		/* ignore an error */
 		if (unlikely(!xi->xi_dbgaufs))
 			AuWarn1("failed %s under debugfs\n", name);