Aufs3.19 #3
Open
Aufs3.19 #3
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
davelhml:
What do you want to me? J. R. Okajima |
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]>
Signed-off-by: J. R. Okajima <[email protected]>
Signed-off-by: J. R. Okajima <[email protected]>
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.