Aufs3.19 #3

Signed-off-by: J. R. Okajima <[email protected]>

…aufs3.18/10static

…aufs3.19/10static

Signed-off-by: J. R. Okajima <[email protected]>

For linux-3.6 there was a commit 4a9d4b0 2012-07-22 switch fput to task_work_add which introduced the delayed fput. It is good for performance, but for aufs internal copy-up, a problem was born. The newly copied-up file is opened to be written and its inode's i_writecount is incremented (via get_write_access()). On the other hand, execve() rejects when the executable file inode's i_writecount is incremented. It is "actual" fput that decrements i_writecount. Introducing the delayed fput created a small window for execve() to return ETXTBSY. The copy-up is done by aufs workqueue kthread and fput() call from copy-up is postponed by the delayed fput feature. So before the actual fput is done, user could not run a just copied-up executable. This commit calls __fput_sync() which is a variation of fput() and put the file synchoronously, in order to make it possible to execeve() just after copy-up. Reported-by: James Burry <[email protected]> See-also: http://www.mail-archive.com/[email protected]/msg05257.html Signed-off-by: J. R. Okajima <[email protected]>

…aufs3.18/10static Signed-off-by: J. R. Okajima <[email protected]> Conflicts: Documentation/filesystems/aufs/design/01intro.txt Documentation/filesystems/aufs/design/02struct.txt Documentation/filesystems/aufs/design/03atomic_open.txt Documentation/filesystems/aufs/design/03lookup.txt Documentation/filesystems/aufs/design/04branch.txt Documentation/filesystems/aufs/design/05wbr_policy.txt Documentation/filesystems/aufs/design/06fhsm.txt Documentation/filesystems/aufs/design/06mmap.txt Documentation/filesystems/aufs/design/06xattr.txt Documentation/filesystems/aufs/design/07export.txt Documentation/filesystems/aufs/design/08shwh.txt Documentation/filesystems/aufs/design/10dynop.txt Documentation/filesystems/aufs/design/99plan.txt fs/aufs/aufs.h fs/aufs/branch.c fs/aufs/branch.h fs/aufs/cpup.c fs/aufs/cpup.h fs/aufs/dbgaufs.c fs/aufs/dbgaufs.h fs/aufs/dcsub.c fs/aufs/dcsub.h fs/aufs/debug.c fs/aufs/debug.h fs/aufs/dentry.c fs/aufs/dentry.h fs/aufs/dinfo.c fs/aufs/dir.c fs/aufs/dir.h fs/aufs/dynop.c fs/aufs/dynop.h fs/aufs/export.c fs/aufs/f_op.c fs/aufs/fhsm.c fs/aufs/file.c fs/aufs/file.h fs/aufs/finfo.c fs/aufs/fstype.h fs/aufs/hfsnotify.c fs/aufs/hfsplus.c fs/aufs/hnotify.c fs/aufs/i_op.c fs/aufs/i_op_add.c fs/aufs/i_op_del.c fs/aufs/i_op_ren.c fs/aufs/iinfo.c fs/aufs/inode.c fs/aufs/inode.h fs/aufs/ioctl.c fs/aufs/loop.c fs/aufs/loop.h fs/aufs/module.c fs/aufs/module.h fs/aufs/mvdown.c fs/aufs/opts.c fs/aufs/opts.h fs/aufs/plink.c fs/aufs/poll.c fs/aufs/posix_acl.c fs/aufs/procfs.c fs/aufs/rdu.c fs/aufs/rwsem.h fs/aufs/sbinfo.c fs/aufs/spl.h fs/aufs/super.c fs/aufs/super.h fs/aufs/sysaufs.c fs/aufs/sysaufs.h fs/aufs/sysfs.c fs/aufs/sysrq.c fs/aufs/vdir.c fs/aufs/vfsub.c fs/aufs/vfsub.h fs/aufs/wbr_policy.c fs/aufs/whout.c fs/aufs/whout.h fs/aufs/wkq.c fs/aufs/wkq.h fs/aufs/xattr.c fs/aufs/xino.c include/uapi/linux/aufs_type.h

…aufs3.19/10static

Due to a security reason. Signed-off-by: J. R. Okajima <[email protected]>

…aufs3.18/10static

…aufs3.19/10static

Under a special condition, an executable on a malicous FUSE branch could escalate its privilege via aufs. In order to prevent this, here adds a test about mnt_ns into open(2) for FUSE branch only. (How can I describe the security detail before the issue will be opened on the coordinated release date (CRD)?) Reported-by: halfdog <[email protected]> Signed-off-by: J. R. Okajima <[email protected]>

This reverts commit 9497574. The bug was fixed by previous commit.

This bug was found while I was fixing another problem. No bug report was issued. By accident, it was born, and found. Signed-off-by: J. R. Okajima <[email protected]>

No changes in the behaviour. Signed-off-by: J. R. Okajima <[email protected]>

In ACL-aware world, the files processed by chmod or copy-up in aufs might have the incorrect ACL. Force synchronizing ACL to the mode/permission-bits so that the final ACL will be equivalent to the original one on the lower RO branch. Signed-off-by: J. R. Okajima <[email protected]>

In ACL world, a dir can have its "default ACL" which will be applied to all future children. It means that the copied-up entry will have its original ACL (set on the lower RO branch) plus the parent dir's default one (set on the upper RW branch). This mixture may cause a security problem, and this commit resets all ACL in copy-up, which will prevent inheriting the ACL from its parent dir. Reported-by: halfdog <[email protected]> Signed-off-by: J. R. Okajima <[email protected]>

…aufs3.18/10static

Signed-off-by: J. R. Okajima <[email protected]> Conflicts: fs/aufs/dir.c

…aufs3.19/10static

Signed-off-by: J. R. Okajima <[email protected]> Conflicts: fs/aufs/dir.c

Signed-off-by: J. R. Okajima <[email protected]>

…aufs3.19/10static

Already vfsub_acl_chmod() is a simple wrapper of posix_acl_chmod() to ignore EOPNOTSUPP. Signed-off-by: J. R. Okajima <[email protected]>

…aufs3.18/10static

…aufs3.19/10static

This is another editing failure. Signed-off-by: J. R. Okajima <[email protected]>

The permission bits of a regular file during the copy-up should be more secure, since there is a small time-window which anyone may exec the file with an incorrect privilege. Signed-off-by: J. R. Okajima <[email protected]>

…aufs3.18/10static

…aufs3.19/10static

In order to customize fcntl(F_SETFL) in filesystem, make the function ./fs/fcntl.c:setfl() a global generic VFS function as vfs_* file I/O functions, and add ->setfl() into struct file_operations. Signed-off-by: J. R. Okajima <[email protected]>

Propagate the file flags from the virtual aufs's file object to the real fs's file object. The exception is FASYNC/O_ASYNC since f_op already has ->fasync(). Reported-by: Akihiro Suda <[email protected]> Signed-off-by: J. R. Okajima <[email protected]>

…aufs3.18/10static

…aufs3.19/10static

Signed-off-by: J. R. Okajima <[email protected]>

…aufs3.19/10static

See-also: http://www.mail-archive.com/[email protected]/msg05298.html Signed-off-by: J. R. Okajima <[email protected]>

Signed-off-by: J. R. Okajima <[email protected]>

…aufs3.18/10static

…aufs3.19/10static

Hoping a little better performance when pid_max is customized as much greater than default. But I don't like the kcalloc loop approach. If we could get a notify when pid_max is changed, then we might be able to utilize the memory region a little better. But it is not a big deal. Signed-off-by: J. R. Okajima <[email protected]>

…aufs3.18/10static

…aufs3.19/10static

Signed-off-by: J. R. Okajima <[email protected]>

Instead of alloc/free struct pseudo_link which is just for an internal hlist, embed struct hlist_node into struct au_icntnr and link it directly. Signed-off-by: J. R. Okajima <[email protected]>

By converting to hlist, reduce consuming memory by just a pointer. Signed-off-by: J. R. Okajima <[email protected]>

…aufs3.18/10static

…aufs3.19/10static

Set the name of au_rwsem explicitly by resetting it using a macro, instead of the inlined function. Also reuse the original key instead of adding a new key. Signed-off-by: J. R. Okajima <[email protected]>

…licitly Reported-by: Santiago Gimeno <[email protected]> See-also: http://www.mail-archive.com/[email protected]/msg05313.html Signed-off-by: J. R. Okajima <[email protected]>

Without calling au_cache_fin(), au_cache_init() might destroy the kmem_cache just created. Signed-off-by: J. R. Okajima <[email protected]>

The behaviour should not change. Signed-off-by: J. R. Okajima <[email protected]>

With a little hope to gain a better performance. Signed-off-by: J. R. Okajima <[email protected]>

Obviously it is unnecessary to write is_bad_inode() everywhere since the bad_inode will be passed very limited functions only. This commit clarify those functions. Signed-off-by: J. R. Okajima <[email protected]>

Signed-off-by: J. R. Okajima <[email protected]>

…aufs3.18/10static

Signed-off-by: J. R. Okajima <[email protected]> Conflicts: fs/aufs/dir.c fs/aufs/file.c

…aufs3.19/10static

Signed-off-by: J. R. Okajima <[email protected]> Conflicts: fs/aufs/dir.c fs/aufs/file.c

The lifetime of "fsnotify mark" is rather complicated, which is used to implement aufs's HNOTIFY/HFSNOTIFY feature. Aufs called fsnotify_put_mark() in its initilizing, but it was not a good approach and might cause the unexpectedly early call to mark->free_mark(). Signed-off-by: J. R. Okajima <[email protected]>

With a little hope to gain better performance. Potentially it has a risk to cause an overflow. Signed-off-by: J. R. Okajima <[email protected]>

With a little hope to gain better performance. Signed-off-by: J. R. Okajima <[email protected]>

…aufs3.18/10static

…aufs3.19/10static

exportfs_decode_fh() (actually reconnect_path()) acquires mutex, and this behaviour violates the locking order between aufs si_rwsem. This is not a problem since internal exportfs_decode_fh() is called for the branch fs. Simply use lockdep_off/on to silence the lockdep message. Signed-off-by: J. R. Okajima <[email protected]>

…aufs3.18/10static

…aufs3.19/10static

Essentially the behaviour doesn't change. Signed-off-by: J. R. Okajima <[email protected]>

Signed-off-by: J. R. Okajima <[email protected]>

The behaviour doesn't change. Signed-off-by: J. R. Okajima <[email protected]>

The behaviour doesn' change. Signed-off-by: J. R. Okajima <[email protected]>

There was a regression in the commit caeaab8 2016-05-19 aufs: minor, simplify the support for the bad inodes When a race happens in VFS iget_locked(), it calls destroy_inode(). Which means aufs_destroy_inode() is called for an inode which is not fully set its info (aufs inode info), eg. half bad inode. Here this commit handles such special case. Signed-off-by: J. R. Okajima <[email protected]>

…aufs3.18/10static

Signed-off-by: J. R. Okajima <[email protected]> Conflicts: fs/aufs/cpup.c

…aufs3.19/10static

Signed-off-by: J. R. Okajima <[email protected]> Conflicts: fs/aufs/cpup.c

After dput(), the variable 'd' (dentry) may be invalid ptr, and the debug-print function may cause a problem. Signed-off-by: J. R. Okajima <[email protected]>

Don't pass NULL inode to au_refresh_hinode(). Signed-off-by: J. R. Okajima <[email protected]>

…aufs3.18/10static

…aufs3.19/10static

…i_inode() Signed-off-by: J. R. Okajima <[email protected]>

The current parameter 'type' of au_lkup_dentry() has meaningless and is always 0. Instead of removing it simply, convert it into 'flags' especially representing 'allow negative dentry.' Signed-off-by: J. R. Okajima <[email protected]>

…aufs3.18/10static

…aufs3.19/10static

I didn't notice that it was fixed in linux-v3.3 by 6b520e0 2012-01-03 vfs: fix the stupidity with i_dentry in inode destructors Signed-off-by: J. R. Okajima <[email protected]>

Obviously this bug is harmless. Signed-off-by: J. R. Okajima <[email protected]>

The behaviour doesn't change. I hope this will be a little contribute to aufs performance, especially closing a dir. Signed-off-by: J. R. Okajima <[email protected]>

…aufs3.18/10static

Try calling kmem_cache_free() in RCU softirq. I am not sure how much it contributes the performance. At the same time, I am afraid it is not a well-behaviour, which means using RCU scheme for a RCU-unrelated work. But I hope it will be a little help for aufs performance. Why did I use RCU instead of Tasklet? Because call_rcu() interface is easier to call. Since VFS already supports the delayed free for struct file, aufs has to take care whether struct file should be freed at once or not. Signed-off-by: J. R. Okajima <[email protected]>

See previous commit aufs: minor, delayed free 1/2, kmem_cache_free in detail. Signed-off-by: J. R. Okajima <[email protected]>

With a little hope of gaining performance. Signed-off-by: J. R. Okajima <[email protected]>

…aufs3.18/10static

…aufs3.19/10static

The previous commit 2016-07-19 aufs: minor, delayed free 1/2, kmem_cache_free was wrong. Without llist_node (added by this commit), another member would be overwritten incorrectly. Also the RCU softirq based scheme is replaced by a timer based scheme, which is equivalent to the delayed fput scheme in VFS. This new scheme is also applied to kfree() and free_page() by the succeeding commits. Signed-off-by: J. R. Okajima <[email protected]>

For details, see previous commit aufs: fix, delayed free 1/3, kmem_cache_free() Signed-off-by: J. R. Okajima <[email protected]>

With a little hope to reduce the memory usage. This is the last user of aufs SPL (list with a spinlock), so it is commented-out. Signed-off-by: J. R. Okajima <[email protected]>

For details, see the commit in aufs-util.git 2016-07-25 auplink_ftw to support non-glibc Signed-off-by: J. R. Okajima <[email protected]>

The positive return value from ->atomic_open() has a special meaning. au_lkup_dentry() call in aufs_atomic_open() may return a positive return value, and aufs_atomic_open() shoule not return as it is. Signed-off-by: J. R. Okajima <[email protected]>

This reverts commit 68e2ed2. nw_len seems to be checked more times than I expected. In other words, I forgot about FLUSH flag for si_read_lock(). Since percpu_counter_sum() costs higher than simple atomic_read(), revert it. Signed-off-by: J. R. Okajima <[email protected]>

…aufs3.18/10static

…aufs3.19/10static

Signed-off-by: J. R. Okajima <[email protected]>

…aufs3.18/10static

…aufs3.19/10static

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 <[email protected]>

…aufs3.18/10static

…aufs3.19/10static

Signed-off-by: J. R. Okajima <[email protected]>

This commit is very similar to a1e4589 2016-08-13 aufs: possible bugfix, temporary lockdep_off for debugfs_create_file but the trigger is debugfs_remove instead of debugfs_create_file. ====================================================== [ INFO: possible circular locking dependency detected ] 4.6.0aufsD+ #370 Not tainted ------------------------------------------------------- mount/11486 is trying to acquire lock: (&sb->s_type->i_mutex_key#2){+.+.+.}, at: [<ffffffff813720d9>] debugfs_remove+0x79/0xc0 but task is already holding lock: (&iinfo->ii_rwsem#2){+++++.}, at: [<ffffffffa00b9530>] do_ii_write_lock+0x170/0x190 [aufs] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (&iinfo->ii_rwsem#2){+++++.}: [<ffffffff810bf72e>] lock_acquire+0xbe/0x220 [<ffffffff810b96d2>] down_read_nested+0x52/0x70 [<ffffffffa00cdbbb>] aufs_permission+0x9b/0x760 [aufs] [<ffffffff811f7550>] __inode_permission+0xb0/0x140 [<ffffffff811f765a>] inode_permission+0x7a/0xa0 [<ffffffff811e780a>] SyS_access+0xda/0x220 [<ffffffff8182a725>] entry_SYSCALL_64_fastpath+0x18/0xa8 -> #2 (&sbinfo->si_rwsem){++++++}: [<ffffffff810bf72e>] lock_acquire+0xbe/0x220 [<ffffffff818282e7>] down_read+0x47/0x60 [<ffffffffa00a1797>] aufs_show_options+0x47/0x770 [aufs] [<ffffffff8123b0fc>] show_vfsmnt+0x10c/0x150 [<ffffffff812120b7>] m_show+0x17/0x20 [<ffffffff81218dd8>] seq_read+0x398/0x490 [<ffffffff811e9378>] __vfs_read+0x18/0x40 [<ffffffff811eb0e3>] vfs_read+0x143/0x1b0 [<ffffffff811eb1a2>] SyS_read+0x52/0xa0 [<ffffffff8182a725>] entry_SYSCALL_64_fastpath+0x18/0xa8 -> #1 (namespace_sem){++++++}: [<ffffffff810bf72e>] lock_acquire+0xbe/0x220 [<ffffffff81828264>] down_write+0x44/0x80 [<ffffffff81214ece>] lock_mount+0x8e/0x1e0 [<ffffffff81215522>] do_add_mount+0x32/0x130 [<ffffffff81215f7c>] finish_automount+0x6c/0xe0 [<ffffffff811f6f3a>] follow_managed+0x1aa/0x350 [<ffffffff811f87f2>] lookup_fast+0x3f2/0x530 [<ffffffff811f9557>] walk_component+0x87/0x360 [<ffffffff811faaf0>] path_lookupat+0x70/0x150 [<ffffffff811fd9e5>] filename_lookup.part.43+0xd5/0x230 [<ffffffff811fdba8>] filename_lookup+0x68/0x80 [<ffffffff811fdfb1>] user_path_at_empty+0x41/0x50 [<ffffffff8122b017>] user_statfs+0x37/0x90 [<ffffffff8122b0db>] SYSC_statfs+0x1b/0x40 [<ffffffff8122b20e>] SyS_statfs+0xe/0x10 [<ffffffff8182a725>] entry_SYSCALL_64_fastpath+0x18/0xa8 -> #0 (&sb->s_type->i_mutex_key#2){+.+.+.}: [<ffffffff810beb48>] __lock_acquire+0x1738/0x1dc0 [<ffffffff810bf72e>] lock_acquire+0xbe/0x220 [<ffffffff8182580e>] mutex_lock_nested+0x6e/0x500 [<ffffffff813720d9>] debugfs_remove+0x79/0xc0 [<ffffffffa00dd2f2>] dbgaufs_brs_del+0xe2/0x100 [aufs] [<ffffffffa00dc27f>] sysaufs_brs_del+0x2f/0x140 [aufs] [<ffffffffa00a4b27>] au_br_add+0x997/0xd00 [aufs] [<ffffffffa00abd27>] au_opt_br.isra.14+0x57/0x120 [aufs] [<ffffffffa00af044>] au_opts_remount+0xb4/0x290 [aufs] [<ffffffffa00a3762>] aufs_remount_fs+0x252/0x300 [aufs] [<ffffffff811ee3e1>] do_remount_sb+0x71/0x1c0 [<ffffffff81216b11>] do_mount+0x941/0xea0 [<ffffffff8121747a>] SyS_mount+0x10a/0x120 [<ffffffff8182a725>] entry_SYSCALL_64_fastpath+0x18/0xa8 other info that might help us debug this: Chain exists of: &sb->s_type->i_mutex_key#2 --> &sbinfo->si_rwsem --> &iinfo->ii_rwsem#2 Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&iinfo->ii_rwsem#2); lock(&sbinfo->si_rwsem); lock(&iinfo->ii_rwsem#2); lock(&sb->s_type->i_mutex_key#2); *** DEADLOCK *** 5 locks held by mount/11486: #0: (&type->s_umount_key#57){+.+.+.}, at: [<ffffffff812165a9>] do_mount+0x3d9/0xea0 #1: (&type->i_mutex_dir_key#7){+.+.+.}, at: [<ffffffffa00a3713>] aufs_remount_fs+0x203/0x300 [aufs] #2: (&sbinfo->si_rwsem){++++++}, at: [<ffffffffa009fd62>] si_write_lock+0x42/0x1e0 [aufs] #3: (&dinfo->di_rwsem){+++++.}, at: [<ffffffffa00b9fbf>] di_write_lock+0x2f/0x60 [aufs] #4: (&iinfo->ii_rwsem#2){+++++.}, at: [<ffffffffa00b9530>] do_ii_write_lock+0x170/0x190 [aufs] stack backtrace: CPU: 0 PID: 11486 Comm: mount Not tainted 4.6.0aufsD+ #370 Hardware name: Pegatron Pegatron/IPM41, BIOS 0001 02/05/2009 0000000000000000 ffff88002b793908 ffffffff814084e7 ffffffff86111170 ffffffff86178580 ffff88002b793958 ffffffff8116b125 ffff88002b793948 ffff88002b7939e8 ffff88002d543108 ffff88002d542940 ffff88002d543108 Call Trace: [<ffffffff814084e7>] dump_stack+0x67/0x90 [<ffffffff8116b125>] print_circular_bug+0x202/0x213 [<ffffffff810beb48>] __lock_acquire+0x1738/0x1dc0 [<ffffffff81827e3e>] ? mutex_unlock+0xe/0x10 [<ffffffff810bf72e>] lock_acquire+0xbe/0x220 [<ffffffff813720d9>] ? debugfs_remove+0x79/0xc0 [<ffffffff813720d9>] ? debugfs_remove+0x79/0xc0 [<ffffffff813720d9>] ? debugfs_remove+0x79/0xc0 [<ffffffff8182580e>] mutex_lock_nested+0x6e/0x500 [<ffffffff813720d9>] ? debugfs_remove+0x79/0xc0 [<ffffffff81418ff1>] ? lockref_get+0x11/0x30 [<ffffffff813720d9>] debugfs_remove+0x79/0xc0 [<ffffffffa00dd2f2>] dbgaufs_brs_del+0xe2/0x100 [aufs] [<ffffffffa00dc27f>] sysaufs_brs_del+0x2f/0x140 [aufs] [<ffffffffa00a4b27>] au_br_add+0x997/0xd00 [aufs] [<ffffffffa00abd27>] au_opt_br.isra.14+0x57/0x120 [aufs] [<ffffffffa00af044>] au_opts_remount+0xb4/0x290 [aufs] [<ffffffffa00b9530>] ? do_ii_write_lock+0x170/0x190 [aufs] [<ffffffffa00a3762>] aufs_remount_fs+0x252/0x300 [aufs] [<ffffffff811ee3e1>] do_remount_sb+0x71/0x1c0 [<ffffffff81216b11>] do_mount+0x941/0xea0 [<ffffffff812160ed>] ? copy_mount_options+0xfd/0x1c0 [<ffffffff812160d9>] ? copy_mount_options+0xe9/0x1c0 [<ffffffff8121747a>] SyS_mount+0x10a/0x120 [<ffffffff8182a725>] entry_SYSCALL_64_fastpath+0x18/0xa8

…aufs3.18/10static

…aufs3.19/10static

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Aufs3.19 #3

Aufs3.19 #3

Commits on Jan 27, 2016

Commits on Feb 5, 2016

Commits on Feb 6, 2016

Commits on Feb 7, 2016

Commits on Feb 14, 2016

Commits on Feb 17, 2016

Commits on Feb 19, 2016

Commits on Feb 21, 2016

Commits on Feb 28, 2016

Commits on Feb 29, 2016

Commits on Mar 1, 2016

Commits on Mar 16, 2016

Commits on Mar 21, 2016

Commits on Apr 5, 2016

Commits on May 4, 2016

Commits on May 18, 2016

Commits on May 19, 2016

Commits on May 24, 2016

Commits on May 25, 2016

Commits on May 27, 2016

Commits on Jun 8, 2016

Commits on Jun 14, 2016

Commits on Jun 15, 2016

Commits on Jun 20, 2016

Commits on Jul 18, 2016

Commits on Jul 19, 2016

Commits on Jul 27, 2016

Commits on Aug 3, 2016

Commits on Aug 5, 2016

Commits on Aug 13, 2016

Commits on Aug 14, 2016

Commits on Aug 18, 2016

Commits on Aug 19, 2016

Aufs3.19 #3

Are you sure you want to change the base?

Aufs3.19 #3

Commits on Jan 27, 2016

Commits on Feb 5, 2016

Commits on Feb 6, 2016

Commits on Feb 7, 2016

Commits on Feb 14, 2016

Commits on Feb 17, 2016

Commits on Feb 19, 2016

Commits on Feb 21, 2016

Commits on Feb 28, 2016

Commits on Feb 29, 2016

Commits on Mar 1, 2016

Commits on Mar 16, 2016

Commits on Mar 21, 2016

Commits on Apr 5, 2016

Commits on May 4, 2016

Commits on May 18, 2016

Commits on May 19, 2016

Commits on May 24, 2016

Commits on May 25, 2016

Commits on May 27, 2016

Commits on Jun 8, 2016

Commits on Jun 14, 2016

Commits on Jun 15, 2016

Commits on Jun 20, 2016

Commits on Jul 18, 2016

Commits on Jul 19, 2016

Commits on Jul 27, 2016

Commits on Aug 3, 2016

Commits on Aug 5, 2016

Commits on Aug 13, 2016

Commits on Aug 14, 2016

Commits on Aug 18, 2016

Commits on Aug 19, 2016