commit 8c596d17b461638be9b12d096e8274b6bd3dd6b6 Author: Greg Kroah-Hartman Date: Tue Jun 7 18:20:47 2016 -0700 Linux 4.5.7 commit c396d335d89fc0fc21032b478ef610fdd0b08906 Author: David Sterba Date: Wed Apr 27 01:03:45 2016 +0200 btrfs: make state preallocation more speculative in __set_extent_bit commit 059f791c6bbaba72dc3c1bd6e2657aacc8552849 upstream. Similar to __clear_extent_bit, do not fail if the state preallocation fails as we might not need it. One less BUG_ON. Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit f8f2b9dd9ccb165fa472855ef98e624e3173f8dd Author: Zhao Lei Date: Tue May 17 17:37:38 2016 +0800 btrfs: scrub: Set bbio to NULL before calling btrfs_map_block commit f1fee6534dcfbf468a159789aa202db2bce8c200 upstream. We usually call btrfs_put_bbio() when btrfs_map_block() failed, btrfs_put_bbio() works right whether bbio is a valid value, or NULL. But there is a exception, in some case, btrfs_map_block() will return fail without touching *bbio(keeping its original value), and if bbio was not initialized yet, invalid memory accessing will happened. Above case is in scrub_missing_raid56_pages(), and similar case in scrub_raid56_parity(). Signed-off-by: Zhao Lei Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 327b1cf89e87607cf1d999a27481245b2610149c Author: Liu Bo Date: Tue May 17 17:21:48 2016 -0700 Btrfs: fix unexpected return value of fiemap commit 2d324f59f343967a03eeb2690f0ff178304d0687 upstream. btrfs's fiemap is supposed to return 0 on success and return < 0 on error. however, ret becomes 1 after looking up the last file extent: btrfs_lookup_file_extent -> btrfs_search_slot(..., ins_len=0, cow=0) and if the offset is beyond EOF, we'll get 'path' pointed to the place of potentail insertion, and ret == 1. This may confuse applications using ioctl(FIEL_IOC_FIEMAP). Signed-off-by: Liu Bo Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit ac5414fc59a48c5a9fb7b1f0e98251dbd4f2f0f4 Author: Filipe Manana Date: Mon Apr 25 04:45:02 2016 +0100 Btrfs: fix empty symlink after creating symlink and fsync parent dir commit 3f9749f6e9edcf8ec569fb542efc3be35e06e84a upstream. If we create a symlink, fsync its parent directory, crash/power fail and mount the filesystem, we end up with an empty symlink, which not only is useless it's also not allowed in linux (the man page symlink(2) is well explicit about that). So we just need to make sure to fully log an inode if it's a symlink, to ensure its inline extent gets logged, ensuring the same behaviour as ext3, ext4, xfs, reiserfs, f2fs, nilfs2, etc. Example reproducer: $ mkfs.btrfs -f /dev/sdb $ mount /dev/sdb /mnt $ mkdir /mnt/testdir $ sync $ ln -s /mnt/foo /mnt/testdir/bar $ xfs_io -c fsync /mnt/testdir $ mount /dev/sdb /mnt $ readlink /mnt/testdir/bar A test case for fstests follows soon. Signed-off-by: Filipe Manana Signed-off-by: Greg Kroah-Hartman commit ec450cd597ef50e2ebcf8e11ed12130d8a19fec9 Author: Filipe Manana Date: Wed Apr 6 17:11:56 2016 +0100 Btrfs: fix for incorrect directory entries after fsync log replay commit 657ed1aa4898c8304500e0d13f240d5a67e8be5f upstream. If we move a directory to a new parent and later log that parent and don't explicitly log the old parent, when we replay the log we can end up with entries for the moved directory in both the old and new parent directories. Besides being ilegal to have directories with multiple hard links in linux, it also resulted in the leaving the inode item with a link count of 1. A similar issue also happens if we move a regular file - after the log tree is replayed the file has a link in both the old and new parent directories, when it should be only at the new directory. Sample reproducer: $ mkfs.btrfs -f /dev/sdc $ mount /dev/sdc /mnt $ mkdir /mnt/x $ mkdir /mnt/y $ touch /mnt/x/foo $ mkdir /mnt/y/z $ sync $ ln /mnt/x/foo /mnt/x/bar $ mv /mnt/y/z /mnt/x/z < power fail > $ mount /dev/sdc /mnt $ ls -1Ri /mnt /mnt: 257 x 258 y /mnt/x: 259 bar 259 foo 260 z /mnt/x/z: /mnt/y: 260 z /mnt/y/z: $ umount /dev/sdc $ btrfs check /dev/sdc Checking filesystem on /dev/sdc UUID: a67e2c4a-a4b4-4fdc-b015-9d9af1e344be checking extents checking free space cache checking fs roots root 5 inode 260 errors 2000, link count wrong unresolved ref dir 257 index 4 namelen 1 name z filetype 2 errors 0 unresolved ref dir 258 index 2 namelen 1 name z filetype 2 errors 0 (...) Attempting to remove the directory becomes impossible: $ mount /dev/sdc /mnt $ rmdir /mnt/y/z $ ls -lh /mnt/y ls: cannot access /mnt/y/z: No such file or directory total 0 d????????? ? ? ? ? ? z $ rmdir /mnt/x/z rmdir: failed to remove ‘/mnt/x/z’: Stale file handle $ ls -lh /mnt/x ls: cannot access /mnt/x/z: Stale file handle total 0 -rw-r--r-- 2 root root 0 Apr 6 18:06 bar -rw-r--r-- 2 root root 0 Apr 6 18:06 foo d????????? ? ? ? ? ? z So make sure that on rename we set the last_unlink_trans value for our inode, even if it's a directory, to the value of the current transaction's ID and that if the new parent directory is logged that we fallback to a transaction commit. A test case for fstests is being submitted as well. Signed-off-by: Filipe Manana Signed-off-by: Greg Kroah-Hartman commit 5ea5cce51c0a9a22aa016e1c7b7c62452124ae12 Author: Anand Jain Date: Thu Mar 10 12:22:15 2016 +0800 btrfs: pass the right error code to the btrfs_std_error commit ad8403df054c9b5dc3175a26c6179571b9cafa4e upstream. Also drop the newline from the message. Signed-off-by: Anand Jain Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 7281989d24e3e286ab745f0f5a75ab8ac761854d Author: Scott Talbert Date: Mon May 9 09:14:28 2016 -0400 btrfs: fix memory leak during RAID 5/6 device replacement commit 4673272f43ae790ab9ec04e38a7542f82bb8f020 upstream. A 'struct bio' is allocated in scrub_missing_raid56_pages(), but it was never freed anywhere. Signed-off-by: Scott Talbert Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit b9cd7ba4dd03492246c2a717854803699bcad174 Author: Vincent Stehlé Date: Tue May 10 14:56:20 2016 +0200 Btrfs: fix fspath error deallocation commit 72928f2476d08c79f132b4f44a17c9a011dd98e3 upstream. Make sure to deallocate fspath with vfree() in case of error in init_ipath(). fspath is allocated with vmalloc() in init_data_container() since commit 425d17a290c0 ("Btrfs: use larger limit for translation of logical to inode"). Signed-off-by: Vincent Stehlé Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit f97bce9f0c792712767dcff09e46b0617c1462a4 Author: Adam Borowski Date: Sun May 8 15:08:00 2016 +0200 btrfs: fix int32 overflow in shrink_delalloc(). commit 8eb0dfdbda3f56bf7d248ed87fcc383df114ecbb upstream. UBSAN: Undefined behaviour in fs/btrfs/extent-tree.c:4623:21 signed integer overflow: 10808 * 262144 cannot be represented in type 'int [8]' If 8192<=items<16384, we request a writeback of an insane number of pages which is benign (everything will be written). But if items>=16384, the space reservation won't be enough. Signed-off-by: Adam Borowski Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit e5788f9679c122730e1f9978aa8413516dca7b17 Author: David Sterba Date: Wed May 4 11:32:00 2016 +0200 btrfs: add write protection to SET_FEATURES ioctl commit 7ab19625a911f7568ec85302e3aa7a64186006c8 upstream. Perform the want_write check if we get far enough to do any writes. Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 686d38c651290aa6f1ede263ac2b2542a5a62791 Author: Anand Jain Date: Tue Apr 12 21:36:16 2016 +0800 btrfs: fix lock dep warning move scratch super outside of chunk_mutex commit 48b3b9d401ec86899a52003b37331190a35a81a6 upstream. Move scratch super outside of the chunk lock to avoid below lockdep warning. The better place to scratch super is in the function btrfs_rm_dev_replace_free_srcdev() just before free_device, which is outside of the chunk lock as well. To reproduce: (fresh boot) mkfs.btrfs -f -draid5 -mraid5 /dev/sdc /dev/sdd /dev/sde mount /dev/sdc /btrfs dd if=/dev/zero of=/btrfs/tf1 bs=4096 count=100 (get devmgt from https://github.com/asj/devmgt.git) devmgt detach /dev/sde dd if=/dev/zero of=/btrfs/tf1 bs=4096 count=100 sync btrfs replace start -Brf 3 /dev/sdf /btrfs <-- devmgt attach host7 ====================================================== [ INFO: possible circular locking dependency detected ] 4.6.0-rc2asj+ #1 Not tainted --------------------------------------------------- btrfs/2174 is trying to acquire lock: (sb_writers){.+.+.+}, at: [] __sb_start_write+0xb4/0xf0 but task is already holding lock: (&fs_info->chunk_mutex){+.+.+.}, at: [] btrfs_dev_replace_finishing+0x145/0x980 [btrfs] which lock already depends on the new lock. Chain exists of: sb_writers --> &fs_devs->device_list_mutex --> &fs_info->chunk_mutex Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&fs_info->chunk_mutex); lock(&fs_devs->device_list_mutex); lock(&fs_info->chunk_mutex); lock(sb_writers); commit d7f27d079b583d2d7db5ad498b16fd3d097da424 Author: Josef Bacik Date: Tue Apr 12 12:54:40 2016 -0400 Btrfs: remove BUG_ON()'s in btrfs_map_block commit e042d1ec4417981dfe9331e47b76f17929bc2ffe upstream. btrfs_map_block can go horribly wrong in the face of fs corruption, lets agree to not be assholes and panic at any possible chance things are all fucked up. Signed-off-by: Josef Bacik [ removed type casts ] Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit b737cf51eeb14e6bfd3a87264c72835693bba3ec Author: Liu Bo Date: Tue Apr 26 17:53:31 2016 -0700 Btrfs: fix divide error upon chunk's stripe_len commit 3d8da67817606380fdadfa483d4dba5c3a5446c6 upstream. The struct 'map_lookup' uses type int for @stripe_len, while btrfs_chunk_stripe_len() can return a u64 value, and it may end up with @stripe_len being undefined value and it can lead to 'divide error' in __btrfs_map_block(). This changes 'map_lookup' to use type u64 for stripe_len, also right now we only use BTRFS_STRIPE_LEN for stripe_len, so this adds a valid checker for BTRFS_STRIPE_LEN. Reported-by: Vegard Nossum Reported-by: Quentin Casasnovas Signed-off-by: Liu Bo Reviewed-by: David Sterba [ folded division fix to scrub_raid56_parity ] Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 1a0608e8df73a6b6902d5d154ab3abb546b43d8e Author: David Sterba Date: Tue Apr 26 16:03:57 2016 +0200 btrfs: add check to sysfs handler of label commit 66ac9fe7bacf9fa76c472efc7a7aaa590c7bce6a upstream. Add a sanity check for the fs_info as we will dereference it, similar to what the 'store features' handler does. Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 296f8da334a009ea2ec8112c2a1ac318872eff87 Author: David Sterba Date: Fri Jan 23 18:43:31 2015 +0100 btrfs: add read-only check to sysfs handler of features commit ee6111386a1b304f8bf589d36810d53e3b27ee20 upstream. We don't want to trigger the change on a read-only filesystem, similar to what the label handler does. Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 72de21b004d05eff15ca7315cd2be16b18fb20d2 Author: Anand Jain Date: Mon Apr 18 16:51:23 2016 +0800 btrfs: fix lock dep warning, move scratch dev out of device_list_mutex and uuid_mutex commit 779bf3fefa835cb52a07457c8acac6f2f66f2493 upstream. When the replace target fails, the target device will be taken out of fs device list, scratch + update_dev_time and freed. However we could do the scratch + update_dev_time and free part after the device has been taken out of device list, so that we don't have to hold the device_list_mutex and uuid_mutex locks. Reported issue: [ 5375.718845] ====================================================== [ 5375.718846] [ INFO: possible circular locking dependency detected ] [ 5375.718849] 4.4.5-scst31x-debug-11+ #40 Not tainted [ 5375.718849] ------------------------------------------------------- [ 5375.718851] btrfs-health/4662 is trying to acquire lock: [ 5375.718861] (sb_writers){.+.+.+}, at: [] __sb_start_write+0xb7/0xf0 [ 5375.718862] [ 5375.718862] but task is already holding lock: [ 5375.718907] (&fs_devs->device_list_mutex){+.+.+.}, at: [] btrfs_destroy_dev_replace_tgtdev+0x3c/0x150 [btrfs] [ 5375.718907] [ 5375.718907] which lock already depends on the new lock. [ 5375.718907] [ 5375.718908] [ 5375.718908] the existing dependency chain (in reverse order) is: [ 5375.718911] [ 5375.718911] -> #3 (&fs_devs->device_list_mutex){+.+.+.}: [ 5375.718917] [] lock_acquire+0xce/0x1e0 [ 5375.718921] [] mutex_lock_nested+0x69/0x3c0 [ 5375.718940] [] btrfs_show_devname+0x36/0x210 [btrfs] [ 5375.718945] [] show_vfsmnt+0x49/0x150 [ 5375.718948] [] m_show+0x17/0x20 [ 5375.718951] [] seq_read+0x2d8/0x3b0 [ 5375.718955] [] __vfs_read+0x28/0xd0 [ 5375.718959] [] vfs_read+0x86/0x130 [ 5375.718962] [] SyS_read+0x49/0xa0 [ 5375.718966] [] entry_SYSCALL_64_fastpath+0x16/0x7a [ 5375.718968] [ 5375.718968] -> #2 (namespace_sem){+++++.}: [ 5375.718971] [] lock_acquire+0xce/0x1e0 [ 5375.718974] [] down_write+0x49/0x80 [ 5375.718977] [] lock_mount+0x43/0x1c0 [ 5375.718979] [] do_add_mount+0x23/0xd0 [ 5375.718982] [] do_mount+0x27b/0xe30 [ 5375.718985] [] SyS_mount+0x8c/0xd0 [ 5375.718988] [] entry_SYSCALL_64_fastpath+0x16/0x7a [ 5375.718991] [ 5375.718991] -> #1 (&sb->s_type->i_mutex_key#5){+.+.+.}: [ 5375.718994] [] lock_acquire+0xce/0x1e0 [ 5375.718996] [] mutex_lock_nested+0x69/0x3c0 [ 5375.719001] [] path_openat+0x468/0x1360 [ 5375.719004] [] do_filp_open+0x7e/0xe0 [ 5375.719007] [] do_sys_open+0x12b/0x210 [ 5375.719010] [] SyS_open+0x1e/0x20 [ 5375.719013] [] entry_SYSCALL_64_fastpath+0x16/0x7a [ 5375.719015] [ 5375.719015] -> #0 (sb_writers){.+.+.+}: [ 5375.719018] [] __lock_acquire+0x17ba/0x1ae0 [ 5375.719021] [] lock_acquire+0xce/0x1e0 [ 5375.719026] [] percpu_down_read+0x4f/0xa0 [ 5375.719028] [] __sb_start_write+0xb7/0xf0 [ 5375.719031] [] mnt_want_write+0x24/0x50 [ 5375.719035] [] path_openat+0xd32/0x1360 [ 5375.719037] [] do_filp_open+0x7e/0xe0 [ 5375.719040] [] file_open_name+0xe4/0x130 [ 5375.719043] [] filp_open+0x33/0x60 [ 5375.719073] [] update_dev_time+0x16/0x40 [btrfs] [ 5375.719099] [] btrfs_scratch_superblocks+0x4e/0x90 [btrfs] [ 5375.719123] [] btrfs_destroy_dev_replace_tgtdev+0x65/0x150 [btrfs] [ 5375.719150] [] btrfs_dev_replace_finishing+0x6b0/0x990 [btrfs] [ 5375.719175] [] btrfs_dev_replace_start+0x33e/0x540 [btrfs] [ 5375.719199] [] btrfs_auto_replace_start+0xf8/0x140 [btrfs] [ 5375.719222] [] health_kthread+0x246/0x490 [btrfs] [ 5375.719225] [] kthread+0xef/0x110 [ 5375.719229] [] ret_from_fork+0x3f/0x70 [ 5375.719230] [ 5375.719230] other info that might help us debug this: [ 5375.719230] [ 5375.719233] Chain exists of: [ 5375.719233] sb_writers --> namespace_sem --> &fs_devs->device_list_mutex [ 5375.719233] [ 5375.719234] Possible unsafe locking scenario: [ 5375.719234] [ 5375.719234] CPU0 CPU1 [ 5375.719235] ---- ---- [ 5375.719236] lock(&fs_devs->device_list_mutex); [ 5375.719238] lock(namespace_sem); [ 5375.719239] lock(&fs_devs->device_list_mutex); [ 5375.719241] lock(sb_writers); [ 5375.719241] [ 5375.719241] *** DEADLOCK *** [ 5375.719241] [ 5375.719243] 4 locks held by btrfs-health/4662: [ 5375.719266] #0: (&fs_info->health_mutex){+.+.+.}, at: [] health_kthread+0x63/0x490 [btrfs] [ 5375.719293] #1: (&fs_info->dev_replace.lock_finishing_cancel_unmount){+.+.+.}, at: [] btrfs_dev_replace_finishing+0x41/0x990 [btrfs] [ 5375.719319] #2: (uuid_mutex){+.+.+.}, at: [] btrfs_destroy_dev_replace_tgtdev+0x20/0x150 [btrfs] [ 5375.719343] #3: (&fs_devs->device_list_mutex){+.+.+.}, at: [] btrfs_destroy_dev_replace_tgtdev+0x3c/0x150 [btrfs] [ 5375.719343] [ 5375.719343] stack backtrace: [ 5375.719347] CPU: 2 PID: 4662 Comm: btrfs-health Not tainted 4.4.5-scst31x-debug-11+ #40 [ 5375.719348] Hardware name: Supermicro SYS-6018R-WTRT/X10DRW-iT, BIOS 1.0c 01/07/2015 [ 5375.719352] 0000000000000000 ffff880856f73880 ffffffff813529e3 ffffffff826182a0 [ 5375.719354] ffffffff8260c090 ffff880856f738c0 ffffffff810d667c ffff880856f73930 [ 5375.719357] ffff880861f32b40 ffff880861f32b68 0000000000000003 0000000000000004 [ 5375.719357] Call Trace: [ 5375.719363] [] dump_stack+0x85/0xc2 [ 5375.719366] [] print_circular_bug+0x1ec/0x260 [ 5375.719369] [] __lock_acquire+0x17ba/0x1ae0 [ 5375.719373] [] ? debug_lockdep_rcu_enabled+0x1d/0x20 [ 5375.719376] [] lock_acquire+0xce/0x1e0 [ 5375.719378] [] ? __sb_start_write+0xb7/0xf0 [ 5375.719383] [] percpu_down_read+0x4f/0xa0 [ 5375.719385] [] ? __sb_start_write+0xb7/0xf0 [ 5375.719387] [] __sb_start_write+0xb7/0xf0 [ 5375.719389] [] mnt_want_write+0x24/0x50 [ 5375.719393] [] path_openat+0xd32/0x1360 [ 5375.719415] [] ? btrfs_congested_fn+0x180/0x180 [btrfs] [ 5375.719418] [] ? debug_lockdep_rcu_enabled+0x1d/0x20 [ 5375.719420] [] do_filp_open+0x7e/0xe0 [ 5375.719423] [] ? rcu_read_lock_sched_held+0x6d/0x80 [ 5375.719426] [] ? kmem_cache_alloc+0x26b/0x5d0 [ 5375.719430] [] ? getname_kernel+0x34/0x120 [ 5375.719433] [] file_open_name+0xe4/0x130 [ 5375.719436] [] filp_open+0x33/0x60 [ 5375.719462] [] update_dev_time+0x16/0x40 [btrfs] [ 5375.719485] [] btrfs_scratch_superblocks+0x4e/0x90 [btrfs] [ 5375.719506] [] btrfs_destroy_dev_replace_tgtdev+0x65/0x150 [btrfs] [ 5375.719530] [] btrfs_dev_replace_finishing+0x6b0/0x990 [btrfs] [ 5375.719554] [] ? btrfs_dev_replace_finishing+0x553/0x990 [btrfs] [ 5375.719576] [] btrfs_dev_replace_start+0x33e/0x540 [btrfs] [ 5375.719598] [] btrfs_auto_replace_start+0xf8/0x140 [btrfs] [ 5375.719621] [] health_kthread+0x246/0x490 [btrfs] [ 5375.719641] [] ? health_kthread+0x138/0x490 [btrfs] [ 5375.719661] [] ? btrfs_congested_fn+0x180/0x180 [btrfs] [ 5375.719663] [] kthread+0xef/0x110 [ 5375.719666] [] ? kthread_create_on_node+0x200/0x200 [ 5375.719669] [] ret_from_fork+0x3f/0x70 [ 5375.719672] [] ? kthread_create_on_node+0x200/0x200 [ 5375.719697] ------------[ cut here ]------------ Signed-off-by: Anand Jain Reported-by: Yauhen Kharuzhy Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 30083555110d34cff755fb7845085b5c2adeb26a Author: Luis de Bethencourt Date: Wed Mar 30 23:18:14 2016 +0100 btrfs: avoid overflowing f_bfree commit 41b34accb265e3a20211a7a8ef3625678f1c6ec7 upstream. Since mixed block groups accounting isn't byte-accurate and f_bree is an unsigned integer, it could overflow. Avoid this. Signed-off-by: Luis de Bethencourt Suggested-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 12e137029ba089da7cdef2f7ada60d8fd122c724 Author: Luis de Bethencourt Date: Wed Mar 30 21:53:38 2016 +0100 btrfs: fix mixed block count of available space commit ae02d1bd070767e109f4a6f1bb1f466e9698a355 upstream. Metadata for mixed block is already accounted in total data and should not be counted as part of the free metadata space. Signed-off-by: Luis de Bethencourt Link: https://bugzilla.kernel.org/show_bug.cgi?id=114281 Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit fd76c86b672d8971ec708977902f657e0a1d7af8 Author: Austin S. Hemmelgarn Date: Wed Mar 23 14:22:59 2016 -0400 btrfs: allow balancing to dup with multi-device commit 88be159c905a2b4f6d59afa352bef410afb6af02 upstream. Currently, we don't allow the user to try and rebalance to a dup profile on a multi-device filesystem. In most cases, this is a perfectly sensible restriction as raid1 uses the same amount of space and provides better protection. However, when reshaping a multi-device filesystem down to a single device filesystem, this requires the user to convert metadata and system chunks to single profile before deleting devices, and then convert again to dup, which leaves a period of time where metadata integrity is reduced. This patch removes the single-device-only restriction from converting to dup profile to remove this potential data integrity reduction. Signed-off-by: Austin S. Hemmelgarn Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit aaef5d1d931b7f5ab452773b2df495a37321185e Author: Liu Bo Date: Mon Dec 14 18:29:32 2015 -0800 Btrfs: do not create empty block group if we have allocated data commit cf25ce518e8ef9d59b292e51193bed2b023a32da upstream. Now we force to create empty block group to keep data profile alive, however, in the below example, we eventually get an empty block group while we're trying to get more space for other types (metadata/system), - Before, block group "A": size=2G, used=1.2G block group "B": size=2G, used=512M - After "btrfs balance start -dusage=50 mount_point", block group "A": size=2G, used=(1.2+0.5)G block group "C": size=2G, used=0 Since there is no data in block group C, it won't be deleted automatically and we have to get the unused 2G until the next mount. Balance itself just moves data and doesn't remove data, so it's safe to not create such a empty block group if we already have data allocated in other block groups. Signed-off-by: Liu Bo Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 8dbf3ff15f8a72a3c32928f8129aa07344404612 Author: Luke Dashjr Date: Thu Oct 29 08:22:21 2015 +0000 btrfs: bugfix: handle FS_IOC32_{GETFLAGS,SETFLAGS,GETVERSION} in btrfs_ioctl commit 4c63c2454eff996c5e27991221106eb511f7db38 upstream. 32-bit ioctl uses these rather than the regular FS_IOC_* versions. They can be handled in btrfs using the same code. Without this, 32-bit {ch,ls}attr fail. Signed-off-by: Luke Dashjr Reviewed-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit edd7cd7a90e277d0f5cd3940ddd692e72043ce71 Author: Dave Chinner Date: Wed May 18 13:54:23 2016 +1000 xfs: skip stale inodes in xfs_iflush_cluster commit 7d3aa7fe970791f1a674b14572a411accf2f4d4e upstream. We don't write back stale inodes so we should skip them in xfs_iflush_cluster, too. Signed-off-by: Dave Chinner Reviewed-by: Brian Foster Reviewed-by: Christoph Hellwig Signed-off-by: Dave Chinner Signed-off-by: Greg Kroah-Hartman commit a7fd43317c7c7906108e57a4b1a5acb84df56693 Author: Dave Chinner Date: Wed May 18 13:54:22 2016 +1000 xfs: fix inode validity check in xfs_iflush_cluster commit 51b07f30a71c27405259a0248206ed4e22adbee2 upstream. Some careless idiot(*) wrote crap code in commit 1a3e8f3 ("xfs: convert inode cache lookups to use RCU locking") back in late 2010, and so xfs_iflush_cluster checks the wrong inode for whether it is still valid under RCU protection. Fix it to lock and check the correct inode. (*) Careless-idiot: Dave Chinner Discovered-by: Brain Foster Signed-off-by: Dave Chinner Reviewed-by: Christoph Hellwig Signed-off-by: Dave Chinner Signed-off-by: Greg Kroah-Hartman commit 431ea8f5a458e7968eb0cd879920c1e5bc1d8859 Author: Dave Chinner Date: Wed May 18 13:53:42 2016 +1000 xfs: xfs_iflush_cluster fails to abort on error commit b1438f477934f5a4d5a44df26f3079a7575d5946 upstream. When a failure due to an inode buffer occurs, the error handling fails to abort the inode writeback correctly. This can result in the inode being reclaimed whilst still in the AIL, leading to use-after-free situations as well as filesystems that cannot be unmounted as the inode log items left in the AIL never get removed. Fix this by ensuring fatal errors from xfs_imap_to_bp() result in the inode flush being aborted correctly. Reported-by: Shyam Kaushik Diagnosed-by: Shyam Kaushik Tested-by: Shyam Kaushik Signed-off-by: Dave Chinner Reviewed-by: Christoph Hellwig Signed-off-by: Dave Chinner Signed-off-by: Greg Kroah-Hartman commit df89f87aea3045754d1317d1c77a018b477f348e Author: Dave Chinner Date: Wed Apr 6 07:06:20 2016 +1000 xfs: Don't wrap growfs AGFL indexes commit ad747e3b299671e1a53db74963cc6c5f6cdb9f6d upstream. Commit 96f859d ("libxfs: pack the agfl header structure so XFS_AGFL_SIZE is correct") allowed the freelist to use the empty slot at the end of the freelist on 64 bit systems that was not being used due to sizeof() rounding up the structure size. This has caused versions of xfs_repair prior to 4.5.0 (which also has the fix) to report this as a corruption once the filesystem has been grown. Older kernels can also have problems (seen from a whacky container/vm management environment) mounting filesystems grown on a system with a newer kernel than the vm/container it is deployed on. To avoid this problem, change the initial free list indexes not to wrap across the end of the AGFL, hence avoiding the initialisation of agf_fllast to the last index in the AGFL. Signed-off-by: Dave Chinner Reviewed-by: Carlos Maiolino Signed-off-by: Dave Chinner Signed-off-by: Greg Kroah-Hartman commit 80d8d896b434bfeeb48592a19c74c90ef61d2f0a Author: Eric Sandeen Date: Wed Apr 6 07:05:41 2016 +1000 xfs: disallow rw remount on fs with unknown ro-compat features commit d0a58e833931234c44e515b5b8bede32bd4e6eed upstream. Today, a kernel which refuses to mount a filesystem read-write due to unknown ro-compat features can still transition to read-write via the remount path. The old kernel is most likely none the wiser, because it's unaware of the new feature, and isn't using it. However, writing to the filesystem may well corrupt metadata related to that new feature, and moving to a newer kernel which understand the feature will have problems. Right now the only ro-compat feature we have is the free inode btree, which showed up in v3.16. It would be good to push this back to all the active stable kernels, I think, so that if anyone is using newer mkfs (which enables the finobt feature) with older kernel releases, they'll be protected. Signed-off-by: Eric Sandeen Reviewed-by: Bill O'Donnell Reviewed-by: Dave Chinner Signed-off-by: Dave Chinner Signed-off-by: Greg Kroah-Hartman commit 4565487242b6cec2a747a8d82473d611b7fef733 Author: Arnd Bergmann Date: Mon Apr 25 17:35:30 2016 +0200 gcov: disable tree-loop-im to reduce stack usage commit c87bf431448b404a6ef5fbabd74c0e3e42157a7f upstream. Enabling CONFIG_GCOV_PROFILE_ALL produces us a lot of warnings like lib/lz4/lz4hc_compress.c: In function 'lz4_compresshcctx': lib/lz4/lz4hc_compress.c:514:1: warning: the frame size of 1504 bytes is larger than 1024 bytes [-Wframe-larger-than=] After some investigation, I found that this behavior started with gcc-4.9, and opened https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69702. A suggested workaround for it is to use the -fno-tree-loop-im flag that turns off one of the optimization stages in gcc, so the code runs a little slower but does not use excessive amounts of stack. We could make this conditional on the gcc version, but I could not find an easy way to do this in Kbuild and the benefit would be fairly small, given that most of the gcc version in production are affected now. I'm marking this for 'stable' backports because it addresses a bug with code generation in gcc that exists in all kernel versions with the affected gcc releases. Signed-off-by: Arnd Bergmann Acked-by: Peter Oberparleiter Signed-off-by: Michal Marek Signed-off-by: Greg Kroah-Hartman commit 45a9709c3ebe400f3548e4c144d2ee8218366706 Author: Kirill A. Shutemov Date: Fri May 27 14:27:38 2016 -0700 mm: thp: avoid false positive VM_BUG_ON_PAGE in page_move_anon_rmap() commit 0798d3c022dc63eb0ec02b511e1f76ca8411ef8e upstream. If page_move_anon_rmap() is refiling a pmd-splitted THP mapped in a tail page from a pte, the "address" must be THP aligned in order for the page->index bugcheck to pass in the CONFIG_DEBUG_VM=y builds. Link: http://lkml.kernel.org/r/1464253620-106404-1-git-send-email-kirill.shutemov@linux.intel.com Fixes: 6d0a07edd17c ("mm: thp: calculate the mapcount correctly for THP pages during WP faults") Signed-off-by: Kirill A. Shutemov Reported-by: Mika Westerberg Tested-by: Mika Westerberg Reviewed-by: Andrea Arcangeli Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 5ba525bea19cd375c48d9c27ec3de384722496b2 Author: Srinivas Pandruvada Date: Sat May 14 20:09:52 2016 -0700 scripts/package/Makefile: rpmbuild add support of RPMOPTS commit 65a9f31c5042e5bb50d30ed8ae374044be561054 upstream. After commit 21a59991ce0c ("scripts/package/Makefile: rpmbuild is needed for rpm targets"), it is no longer possible to specify RPMOPTS. For example, we can no longer able to control _topdir using the following make command. make RPMOPTS="--define '_topdir /home/xyz/workspace/'" binrpm-pkg Fixes: 21a59991ce0c ("scripts/package/Makefile: rpmbuild is needed for rpm targets") Signed-off-by: Srinivas Pandruvada Signed-off-by: Michal Marek Signed-off-by: Greg Kroah-Hartman commit e799b0ec06796a861c6b0075d25b908bcd4158e9 Author: Ville Syrjälä Date: Thu May 26 15:16:25 2016 -0700 dma-debug: avoid spinlock recursion when disabling dma-debug commit 3017cd63f26fc655d56875aaf497153ba60e9edf upstream. With netconsole (at least) the pr_err("... disablingn") call can recurse back into the dma-debug code, where it'll try to grab free_entries_lock again. Avoid the problem by doing the printk after dropping the lock. Link: http://lkml.kernel.org/r/1463678421-18683-1-git-send-email-ville.syrjala@linux.intel.com Signed-off-by: Ville Syrjälä Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 0c42f6c9199233f3947d531df81fc44574ace18e Author: Rafael J. Wysocki Date: Fri May 20 23:09:49 2016 +0200 PM / sleep: Handle failures in device_suspend_late() consistently commit 3a17fb329da68cb00558721aff876a80bba2fdb9 upstream. Grygorii Strashko reports: The PM runtime will be left disabled for the device if its .suspend_late() callback fails and async suspend is not allowed for this device. In this case device will not be added in dpm_late_early_list and dpm_resume_early() will ignore this device, as result PM runtime will be disabled for it forever (side effect: after 8 subsequent failures for the same device the PM runtime will be reenabled due to disable_depth overflow). To fix this problem, add devices to dpm_late_early_list regardless of whether or not device_suspend_late() returns errors for them. That will ensure failures in there to be handled consistently for all devices regardless of their async suspend/resume status. Reported-by: Grygorii Strashko Tested-by: Grygorii Strashko Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 3ae21caffa7a5bf482382fdcd05477084e62a7c6 Author: Weston Andros Adamson Date: Wed May 25 10:07:23 2016 -0400 nfs: avoid race that crashes nfs_init_commit commit ade8febde0271513360bac44883dbebad44276c3 upstream. Since the patch "NFS: Allow multiple commit requests in flight per file" we can run multiple simultaneous commits on the same inode. This introduced a race over collecting pages to commit that made it possible to call nfs_init_commit() with an empty list - which causes crashes like the one below. The fix is to catch this race and avoid calling nfs_init_commit and initiate_commit when there is no work to do. Here is the crash: [600522.076832] BUG: unable to handle kernel NULL pointer dereference at 0000000000000040 [600522.078475] IP: [] nfs_init_commit+0x22/0x130 [nfs] [600522.078745] PGD 4272b1067 PUD 4272cb067 PMD 0 [600522.078972] Oops: 0000 [#1] SMP [600522.079204] Modules linked in: nfsv3 nfs_layout_flexfiles rpcsec_gss_krb5 nfsv4 dns_resolver nfs fscache dcdbas ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw vmw_vsock_vmci_transport vsock bonding ipmi_devintf ipmi_msghandler coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel ppdev vmw_balloon parport_pc parport acpi_cpufreq vmw_vmci i2c_piix4 shpchp nfsd auth_rpcgss nfs_acl lockd grace sunrpc xfs libcrc32c vmwgfx drm_kms_helper ttm drm crc32c_intel serio_raw vmxnet3 [600522.081380] vmw_pvscsi ata_generic pata_acpi [600522.081809] CPU: 3 PID: 15667 Comm: /usr/bin/python Not tainted 4.1.9-100.pd.88.el7.x86_64 #1 [600522.082281] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 09/30/2014 [600522.082814] task: ffff8800bbbfa780 ti: ffff88042ae84000 task.ti: ffff88042ae84000 [600522.083378] RIP: 0010:[] [] nfs_init_commit+0x22/0x130 [nfs] [600522.083973] RSP: 0018:ffff88042ae87438 EFLAGS: 00010246 [600522.084571] RAX: 0000000000000000 RBX: ffff880003485e40 RCX: ffff88042ae87588 [600522.085188] RDX: 0000000000000000 RSI: ffff88042ae874b0 RDI: ffff880003485e40 [600522.085756] RBP: ffff88042ae87448 R08: ffff880003486010 R09: ffff88042ae874b0 [600522.086332] R10: 0000000000000000 R11: 0000000000000005 R12: ffff88042ae872d0 [600522.086905] R13: ffff88042ae874b0 R14: ffff880003485e40 R15: ffff88042704c840 [600522.087484] FS: 00007f4728ff2740(0000) GS:ffff88043fd80000(0000) knlGS:0000000000000000 [600522.088070] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [600522.088663] CR2: 0000000000000040 CR3: 000000042b6aa000 CR4: 00000000001406e0 [600522.089327] Stack: [600522.089926] 0000000000000001 ffff88042ae87588 ffff88042ae874f8 ffffffffa04f09fa [600522.090549] 0000000000017840 0000000000017840 ffff88042ae87588 ffff8803258d9930 [600522.091169] ffff88042ae87578 ffffffffa0563d80 0000000000000000 ffff88042704c840 [600522.091789] Call Trace: [600522.092420] [] pnfs_generic_commit_pagelist+0x1da/0x320 [nfsv4] [600522.093052] [] ? ff_layout_commit_prepare_v3+0x30/0x30 [nfs_layout_flexfiles] [600522.093696] [] ff_layout_commit_pagelist+0x15/0x20 [nfs_layout_flexfiles] [600522.094359] [] nfs_generic_commit_list+0xe8/0x120 [nfs] [600522.095032] [] nfs_commit_inode+0xba/0x110 [nfs] [600522.095719] [] nfs_release_page+0x44/0xd0 [nfs] [600522.096410] [] try_to_release_page+0x32/0x50 [600522.097109] [] shrink_page_list+0x961/0xb30 [600522.097812] [] shrink_inactive_list+0x1cd/0x550 [600522.098530] [] shrink_lruvec+0x635/0x840 [600522.099250] [] shrink_zone+0xf0/0x2f0 [600522.099974] [] do_try_to_free_pages+0x192/0x470 [600522.100709] [] try_to_free_pages+0xda/0x170 [600522.101464] [] __alloc_pages_nodemask+0x588/0x970 [600522.102235] [] alloc_pages_vma+0xb5/0x230 [600522.103000] [] ? cpumask_any_but+0x39/0x50 [600522.103774] [] wp_page_copy.isra.55+0x95/0x490 [600522.104558] [] ? __wake_up+0x48/0x60 [600522.105357] [] do_wp_page+0xab/0x4f0 [600522.106137] [] ? release_task+0x36b/0x470 [600522.106902] [] ? eventfd_ctx_read+0x67/0x1c0 [600522.107659] [] handle_mm_fault+0xc78/0x1900 [600522.108431] [] __do_page_fault+0x181/0x420 [600522.109173] [] ? __audit_syscall_exit+0x1e6/0x280 [600522.109893] [] do_page_fault+0x30/0x80 [600522.110594] [] ? syscall_trace_leave+0xc6/0x120 [600522.111288] [] page_fault+0x28/0x30 [600522.111947] Code: 5d c3 0f 1f 80 00 00 00 00 0f 1f 44 00 00 55 4c 8d 87 d0 01 00 00 48 89 e5 53 48 89 fb 48 83 ec 08 4c 8b 0e 49 8b 41 18 4c 39 ce <48> 8b 40 40 4c 8b 50 30 74 24 48 8b 87 d0 01 00 00 48 8b 7e 08 [600522.113343] RIP [] nfs_init_commit+0x22/0x130 [nfs] [600522.114003] RSP [600522.114636] CR2: 0000000000000040 Fixes: af7cf057 (NFS: Allow multiple commit requests in flight per file) Signed-off-by: Weston Andros Adamson Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit fec0f96129b51a2199c92d6a0021156e7e8de02f Author: Nicolai Stange Date: Thu May 5 19:46:19 2016 -0400 ext4: silence UBSAN in ext4_mb_init() commit 935244cd54b86ca46e69bc6604d2adfb1aec2d42 upstream. Currently, in ext4_mb_init(), there's a loop like the following: do { ... offset += 1 << (sb->s_blocksize_bits - i); i++; } while (i <= sb->s_blocksize_bits + 1); Note that the updated offset is used in the loop's next iteration only. However, at the last iteration, that is at i == sb->s_blocksize_bits + 1, the shift count becomes equal to (unsigned)-1 > 31 (c.f. C99 6.5.7(3)) and UBSAN reports UBSAN: Undefined behaviour in fs/ext4/mballoc.c:2621:15 shift exponent 4294967295 is too large for 32-bit type 'int' [...] Call Trace: [] dump_stack+0xbc/0x117 [] ? _atomic_dec_and_lock+0x169/0x169 [] ubsan_epilogue+0xd/0x4e [] __ubsan_handle_shift_out_of_bounds+0x1fb/0x254 [] ? __ubsan_handle_load_invalid_value+0x158/0x158 [] ? kmem_cache_alloc+0x101/0x390 [] ? ext4_mb_init+0x13b/0xfd0 [] ? create_cache+0x57/0x1f0 [] ? create_cache+0x11a/0x1f0 [] ? mutex_lock+0x38/0x60 [] ? mutex_unlock+0x1b/0x50 [] ? put_online_mems+0x5b/0xc0 [] ? kmem_cache_create+0x117/0x2c0 [] ext4_mb_init+0xc49/0xfd0 [...] Observe that the mentioned shift exponent, 4294967295, equals (unsigned)-1. Unless compilers start to do some fancy transformations (which at least GCC 6.0.0 doesn't currently do), the issue is of cosmetic nature only: the such calculated value of offset is never used again. Silence UBSAN by introducing another variable, offset_incr, holding the next increment to apply to offset and adjust that one by right shifting it by one position per loop iteration. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=114701 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=112161 Signed-off-by: Nicolai Stange Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 560f70981f6e70ffcb92a65892c2f67f686a31eb Author: Nicolai Stange Date: Thu May 5 17:38:03 2016 -0400 ext4: address UBSAN warning in mb_find_order_for_block() commit b5cb316cdf3a3f5f6125412b0f6065185240cfdc upstream. Currently, in mb_find_order_for_block(), there's a loop like the following: while (order <= e4b->bd_blkbits + 1) { ... bb += 1 << (e4b->bd_blkbits - order); } Note that the updated bb is used in the loop's next iteration only. However, at the last iteration, that is at order == e4b->bd_blkbits + 1, the shift count becomes negative (c.f. C99 6.5.7(3)) and UBSAN reports UBSAN: Undefined behaviour in fs/ext4/mballoc.c:1281:11 shift exponent -1 is negative [...] Call Trace: [] dump_stack+0xbc/0x117 [] ? _atomic_dec_and_lock+0x169/0x169 [] ubsan_epilogue+0xd/0x4e [] __ubsan_handle_shift_out_of_bounds+0x1fb/0x254 [] ? __ubsan_handle_load_invalid_value+0x158/0x158 [] ? ext4_mb_generate_from_pa+0x590/0x590 [] ? ext4_read_block_bitmap_nowait+0x598/0xe80 [] mb_find_order_for_block+0x1ce/0x240 [...] Unless compilers start to do some fancy transformations (which at least GCC 6.0.0 doesn't currently do), the issue is of cosmetic nature only: the such calculated value of bb is never used again. Silence UBSAN by introducing another variable, bb_incr, holding the next increment to apply to bb and adjust that one by right shifting it by one position per loop iteration. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=114701 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=112161 Signed-off-by: Nicolai Stange Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 6ce15a9a9f6a3e9a1ea1eabeb6e0df471b92a687 Author: Jan Kara Date: Thu May 5 11:10:15 2016 -0400 ext4: fix oops on corrupted filesystem commit 74177f55b70e2f2be770dd28684dd6d17106a4ba upstream. When filesystem is corrupted in the right way, it can happen ext4_mark_iloc_dirty() in ext4_orphan_add() returns error and we subsequently remove inode from the in-memory orphan list. However this deletion is done with list_del(&EXT4_I(inode)->i_orphan) and thus we leave i_orphan list_head with a stale content. Later we can look at this content causing list corruption, oops, or other issues. The reported trace looked like: WARNING: CPU: 0 PID: 46 at lib/list_debug.c:53 __list_del_entry+0x6b/0x100() list_del corruption, 0000000061c1d6e0->next is LIST_POISON1 0000000000100100) CPU: 0 PID: 46 Comm: ext4.exe Not tainted 4.1.0-rc4+ #250 Stack: 60462947 62219960 602ede24 62219960 602ede24 603ca293 622198f0 602f02eb 62219950 6002c12c 62219900 601b4d6b Call Trace: [<6005769c>] ? vprintk_emit+0x2dc/0x5c0 [<602ede24>] ? printk+0x0/0x94 [<600190bc>] show_stack+0xdc/0x1a0 [<602ede24>] ? printk+0x0/0x94 [<602ede24>] ? printk+0x0/0x94 [<602f02eb>] dump_stack+0x2a/0x2c [<6002c12c>] warn_slowpath_common+0x9c/0xf0 [<601b4d6b>] ? __list_del_entry+0x6b/0x100 [<6002c254>] warn_slowpath_fmt+0x94/0xa0 [<602f4d09>] ? __mutex_lock_slowpath+0x239/0x3a0 [<6002c1c0>] ? warn_slowpath_fmt+0x0/0xa0 [<60023ebf>] ? set_signals+0x3f/0x50 [<600a205a>] ? kmem_cache_free+0x10a/0x180 [<602f4e88>] ? mutex_lock+0x18/0x30 [<601b4d6b>] __list_del_entry+0x6b/0x100 [<601177ec>] ext4_orphan_del+0x22c/0x2f0 [<6012f27c>] ? __ext4_journal_start_sb+0x2c/0xa0 [<6010b973>] ? ext4_truncate+0x383/0x390 [<6010bc8b>] ext4_write_begin+0x30b/0x4b0 [<6001bb50>] ? copy_from_user+0x0/0xb0 [<601aa840>] ? iov_iter_fault_in_readable+0xa0/0xc0 [<60072c4f>] generic_perform_write+0xaf/0x1e0 [<600c4166>] ? file_update_time+0x46/0x110 [<60072f0f>] __generic_file_write_iter+0x18f/0x1b0 [<6010030f>] ext4_file_write_iter+0x15f/0x470 [<60094e10>] ? unlink_file_vma+0x0/0x70 [<6009b180>] ? unlink_anon_vmas+0x0/0x260 [<6008f169>] ? free_pgtables+0xb9/0x100 [<600a6030>] __vfs_write+0xb0/0x130 [<600a61d5>] vfs_write+0xa5/0x170 [<600a63d6>] SyS_write+0x56/0xe0 [<6029fcb0>] ? __libc_waitpid+0x0/0xa0 [<6001b698>] handle_syscall+0x68/0x90 [<6002633d>] userspace+0x4fd/0x600 [<6002274f>] ? save_registers+0x1f/0x40 [<60028bd7>] ? arch_prctl+0x177/0x1b0 [<60017bd5>] fork_handler+0x85/0x90 Fix the problem by using list_del_init() as we always should with i_orphan list. Reported-by: Vegard Nossum Signed-off-by: Jan Kara Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 2d337f81f01db9f7c9ea385f76ac536e9074cb87 Author: Seth Forshee Date: Thu May 5 10:52:38 2016 -0400 ext4: fix check of dqget() return value in ext4_ioctl_setproject() commit ff0bc08454917964291f72ee5b8eca66de4bc250 upstream. A failed call to dqget() returns an ERR_PTR() and not null. Fix the check in ext4_ioctl_setproject() to handle this correctly. Fixes: 9b7365fc1c82 ("ext4: add FS_IOC_FSSETXATTR/FS_IOC_FSGETXATTR interface support") Signed-off-by: Seth Forshee Signed-off-by: Theodore Ts'o Reviewed-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit fdfcb7deb2c4a0cfcaa5a9b9bffd95faa0f43b49 Author: Theodore Ts'o Date: Sat Apr 30 00:49:54 2016 -0400 ext4: clean up error handling when orphan list is corrupted commit 7827a7f6ebfcb7f388dc47fddd48567a314701ba upstream. Instead of just printing warning messages, if the orphan list is corrupted, declare the file system is corrupted. If there are any reserved inodes in the orphaned inode list, declare the file system corrupted and stop right away to avoid doing more potential damage to the file system. Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit b0bd19d30cf1719065be860ccc8485ec71321f12 Author: Theodore Ts'o Date: Sat Apr 30 00:48:54 2016 -0400 ext4: fix hang when processing corrupted orphaned inode list commit c9eb13a9105e2e418f72e46a2b6da3f49e696902 upstream. If the orphaned inode list contains inode #5, ext4_iget() returns a bad inode (since the bootloader inode should never be referenced directly). Because of the bad inode, we end up processing the inode repeatedly and this hangs the machine. This can be reproduced via: mke2fs -t ext4 /tmp/foo.img 100 debugfs -w -R "ssv last_orphan 5" /tmp/foo.img mount -o loop /tmp/foo.img /mnt (But don't do this if you are using an unpatched kernel if you care about the system staying functional. :-) This bug was found by the port of American Fuzzy Lop into the kernel to find file system problems[1]. (Since it *only* happens if inode #5 shows up on the orphan list --- 3, 7, 8, etc. won't do it, it's not surprising that AFL needed two hours before it found it.) [1] http://events.linuxfoundation.org/sites/events/files/slides/AFL%20filesystem%20fuzzing%2C%20Vault%202016_0.pdf Reported by: Vegard Nossum Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 8bf626545f9482e1b2f7539806a2d7e6749bd301 Author: Philipp Zabel Date: Thu May 12 15:00:44 2016 +0200 drm/imx: Match imx-ipuv3-crtc components using device node in platform data commit 310944d148e3600dcff8b346bee7fa01d34903b1 upstream. The component master driver imx-drm-core matches component devices using their of_node. Since commit 950b410dd1ab ("gpu: ipu-v3: Fix imx-ipuv3-crtc module autoloading"), the imx-ipuv3-crtc dev->of_node is not set during probing. Before that, of_node was set and caused an of: modalias to be used instead of the platform: modalias, which broke module autoloading. On the other hand, if dev->of_node is not set yet when the imx-ipuv3-crtc probe function calls component_add, component matching in imx-drm-core fails. While dev->of_node will be set once the next component tries to bring up the component master, imx-drm-core component binding will never succeed if one of the crtc devices is probed last. Add of_node to the component platform data and match against the pdata->of_node instead of dev->of_node in imx-drm-core to work around this problem. Fixes: 950b410dd1ab ("gpu: ipu-v3: Fix imx-ipuv3-crtc module autoloading") Signed-off-by: Philipp Zabel Tested-by: Fabio Estevam Tested-by: Lothar Waßmann Tested-by: Heiko Schocher Tested-by: Chris Ruehl Signed-off-by: Greg Kroah-Hartman commit dc87a7fa7eeb796f333f97d9e2c5d55b2801585e Author: Ville Syrjälä Date: Wed Mar 9 19:07:25 2016 +0200 drm/i915: Fix watermarks for VLV/CHV commit caed361d83b204b7766924b80463bf7502ee7986 upstream. commit 92826fcdfc14 ("drm/i915: Calculate watermark related members in the crtc_state, v4.") broke thigns by removing the pre vs. post wm update distinction. We also lost the pre plane wm update entirely for VLV/CHV from the crtc enable path. This caused underruns on modeset and plane enable/disable on CHV, and often those can lead to a dead pipe. So let's bring back the pre vs. post thing, and let's toss in an explicit wm update to valleyview_crtc_enable() to avoid having to put it into the common code. This is more or less a partial revert of the offending commit. Cc: Maarten Lankhorst Cc: drm-intel-fixes@lists.freedesktop.org Fixes: 92826fcdfc14 ("drm/i915: Calculate watermark related members in the crtc_state, v4.") Signed-off-by: Ville Syrjälä Link: http://patchwork.freedesktop.org/patch/msgid/1457543247-13987-4-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst Signed-off-by: Greg Kroah-Hartman commit fd20c05a48cb03fd0eb36c9ec9494db1baeaefe9 Author: Ville Syrjälä Date: Fri May 13 17:55:17 2016 +0300 drm/i915: Don't leave old junk in ilk active watermarks on readout commit 7045c3689f148a0c95f42bae8ef3eb2829ac7de9 upstream. When we read out the watermark state from the hardware we're supposed to transfer that into the active watermarks, but currently we fail to any part of the active watermarks that isn't explicitly written. Let's clear it all upfront. Looks like this has been like this since the beginning, when I added the readout. No idea why I didn't clear it up. Cc: Matt Roper Fixes: 243e6a44b9ca ("drm/i915: Init HSW watermark tracking in intel_modeset_setup_hw_state()") Signed-off-by: Ville Syrjälä Reviewed-by: Matt Roper Signed-off-by: Matt Roper Link: http://patchwork.freedesktop.org/patch/msgid/1463151318-14719-2-git-send-email-ville.syrjala@linux.intel.com (cherry picked from commit 15606534bf0a65d8a74a90fd57b8712d147dbca6) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 9d8d99a18f6db20523e461c4a42bced0661dff8a Author: Daniel Vetter Date: Wed May 18 18:47:11 2016 +0200 drm/i915/psr: Try to program link training times correctly commit 03b7b5f983091bca17e9c163832fcde56971d7d1 upstream. The default of 0 is 500us of link training, but that's not enough for some platforms. Decoding this correctly means we're using 2.5ms of link training on these platforms, which fixes flickering issues associated with enabling PSR. v2: Unbotch the math a bit. v3: Drop debug hunk. v4: Improve commit message. Tested-by: Lyude Cc: Lyude Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95176 Cc: Rodrigo Vivi Cc: Sonika Jindal Cc: Durgadoss R Cc: "Pandiyan, Dhinakaran" Tested-by: Ville Syrjälä Reviewed-by: Ville Syrjälä Tested-by: fritsch@kodi.tv Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1463590036-17824-2-git-send-email-daniel.vetter@ffwll.ch (cherry picked from commit 50db139018f9c94376d5f4db94a3bae65fdfac14) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit aa3f5dcc7e6eba318010d1397f80077a69d73d60 Author: Glenn Ruben Bakke Date: Fri Apr 22 18:06:11 2016 +0200 Bluetooth: 6lowpan: Fix memory corruption of ipv6 destination address commit 55441070ca1cbd47ce1ad2959bbf4b47aed9b83b upstream. The memcpy of ipv6 header destination address to the skb control block (sbk->cb) in header_create() results in currupted memory when bt_xmit() is issued. The skb->cb is "released" in the return of header_create() making room for lower layer to minipulate the skb->cb. The value retrieved in bt_xmit is not persistent across header creation and sending, and the lower layer will overwrite portions of skb->cb, making the copied destination address wrong. The memory corruption will lead to non-working multicast as the first 4 bytes of the copied destination address is replaced by a value that resolves into a non-multicast prefix. This fix removes the dependency on the skb control block between header creation and send, by moving the destination address memcpy to the send function path (setup_create, which is called from bt_xmit). Signed-off-by: Glenn Ruben Bakke Acked-by: Jukka Rissanen Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman commit 5f5dd28b3159de16b1995e4c0e93a6af7d3d18ea Author: Lyude Date: Tue May 31 12:49:07 2016 -0400 drm/atomic: Verify connector->funcs != NULL when clearing states Unfortunately since we don't have Dave's connector refcounting patch here yet, it's very possible that drm_atomic_state_default_clear() could get called by intel_display_resume() when intel_dp_mst_destroy_connector() isn't completely finished destroying an mst connector, but has already finished setting connector->funcs to NULL. As such, we need to treat the connector like it's already been destroyed and just skip it, otherwise we'll end up dereferencing a NULL pointer. This fix is only required for 4.6 and below. David Airlie's patchseries for 4.7 to add connector reference counting provides a more proper fix for this. Changes since v1: - Fix leftover whitespace Upstream fix: 0552f7651bc2 ("drm/i915/mst: use reference counted connectors. (v3)") Reviewed-by: Daniel Vetter Signed-off-by: Lyude commit e9585660aa9a700b469cb758819675e8c855a28f Author: Lyude Date: Thu May 12 10:56:59 2016 -0400 drm/fb_helper: Fix references to dev->mode_config.num_connector commit 255f0e7c418ad95a4baeda017ae6182ba9b3c423 upstream. During boot, MST hotplugs are generally expected (even if no physical hotplugging occurs) and result in DRM's connector topology changing. This means that using num_connector from the current mode configuration can lead to the number of connectors changing under us. This can lead to some nasty scenarios in fbcon: - We allocate an array to the size of dev->mode_config.num_connectors. - MST hotplug occurs, dev->mode_config.num_connectors gets incremented. - We try to loop through each element in the array using the new value of dev->mode_config.num_connectors, and end up going out of bounds since dev->mode_config.num_connectors is now larger then the array we allocated. fb_helper->connector_count however, will always remain consistent while we do a modeset in fb_helper. Note: This is just polish for 4.7, Dave Airlie's drm_connector refcounting fixed these bugs for real. But it's good enough duct-tape for stable kernel backporting, since backporting the refcounting changes is way too invasive. Signed-off-by: Lyude [danvet: Clarify why we need this. Also remove the now unused "dev" local variable to appease gcc.] Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1463065021-18280-3-git-send-email-cpaul@redhat.com Signed-off-by: Greg Kroah-Hartman commit 0bc0f333e496f4d61fdab7906ed4ce0de3141c93 Author: Lyude Date: Thu May 12 10:56:58 2016 -0400 drm/i915/fbdev: Fix num_connector references in intel_fb_initial_config() commit 14a3842a1d5945067d1dd0788f314e14d5b18e5b upstream. During boot time, MST devices usually send a ton of hotplug events irregardless of whether or not any physical hotplugs actually occurred. Hotplugs mean connectors being created/destroyed, and the number of DRM connectors changing under us. This isn't a problem if we use fb_helper->connector_count since we only set it once in the code, however if we use num_connector from struct drm_mode_config we risk it's value changing under us. On top of that, there's even a chance that dev->mode_config.num_connector != fb_helper->connector_count. If the number of connectors happens to increase under us, we'll end up using the wrong array size for memcpy and start writing beyond the actual length of the array, occasionally resulting in kernel panics. Note: This is just polish for 4.7, Dave Airlie's drm_connector refcounting fixed these bugs for real. But it's good enough duct-tape for stable kernel backporting, since backporting the refcounting changes is way too invasive. Signed-off-by: Lyude [danvet: Clarify why we need this.] Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1463065021-18280-2-git-send-email-cpaul@redhat.com Signed-off-by: Greg Kroah-Hartman commit f72eee26b4d11821169f4f80712cf533111c8a1b Author: Mario Kleiner Date: Tue May 24 18:12:43 2016 +0200 drm/amdgpu: Fix hdmi deep color support. commit 9d746ab68163d642dae13756b2b3145b2e38cb65 upstream. When porting the hdmi deep color detection code from radeon-kms to amdgpu-kms apparently some kind of copy and paste error happened, attaching an else branch to the wrong if statement. The result is that hdmi deep color mode is always disabled, regardless of gpu and display capabilities and user wishes, as the code mistakenly thinks that the display doesn't provide the required max_tmds_clock limit and falls back to 8 bpc. This patch fixes deep color support, as tested on a R9 380 Tonga Pro + suitable display, and should be backported to all kernels with amdgpu-kms support. Signed-off-by: Mario Kleiner Cc: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 3b687448b7e14bfd9b62e8519fc60a6565f9dc84 Author: Alex Deucher Date: Mon May 2 10:24:41 2016 -0400 drm/amdgpu: use drm_mode_vrefresh() rather than mode->vrefresh commit 6b8812eb004ee2b24aac8b1a711a0e8e797df3ce upstream. This is a port of radeon commit: 3d2d98ee1af0cf6eebfbd6bff4c17d3601ac1284 drm/radeon: use drm_mode_vrefresh() rather than mode->vrefresh to amdgpu. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 0238907f5506a7c2dab3c9bc6b875034017c4fad Author: Sinclair Yeh Date: Thu Apr 21 11:29:31 2016 -0700 drm/vmwgfx: Fix order of operation commit 7851496a32319237456919575e5f4ba62f74cc7d upstream. mode->hdisplay * (var->bits_per_pixel + 7) gets evaluated before the division, potentially making the pitch larger than it should be. Since the original intention is to do a div-round-up, just use the macro instead. Signed-off-by: Sinclair Yeh Reviewed-by: Thomas Hellstrom Signed-off-by: Greg Kroah-Hartman commit 21da473b6f906b5faa0043872f121b74f3602523 Author: Charmaine Lee Date: Tue Apr 12 08:19:08 2016 -0700 drm/vmwgfx: use vmw_cmd_dx_cid_check for query commands. commit e02e58843153ce80a9fe7588def89b2638d40e64 upstream. Instead of calling vmw_cmd_ok, call vmw_cmd_dx_cid_check to validate the context id for query commands. Signed-off-by: Charmaine Lee Reviewed-by: Sinclair Yeh Signed-off-by: Greg Kroah-Hartman commit 59a84240e805a927707121ce7d49e1f8a5eca656 Author: Charmaine Lee Date: Tue Apr 12 08:14:23 2016 -0700 drm/vmwgfx: Enable SVGA_3D_CMD_DX_SET_PREDICATION commit 1883598d4201361a6d2ce785095695f58071ee11 upstream. Fixes piglit tests nv_conditional_render-* crashes. Signed-off-by: Charmaine Lee Reviewed-by: Brian Paul Reviewed-by: Sinclair Yeh Signed-off-by: Greg Kroah-Hartman commit bacc6d7b638b100464752334197add0e3d5ea726 Author: Itai Handler Date: Tue Nov 3 00:20:56 2015 +0200 drm/gma500: Fix possible out of bounds read commit 7ccca1d5bf69fdd1d3c5fcf84faf1659a6e0ad11 upstream. Fix possible out of bounds read, by adding missing comma. The code may read pass the end of the dsi_errors array when the most significant bit (bit #31) in the intr_stat register is set. This bug has been detected using CppCheck (static analysis tool). Signed-off-by: Itai Handler Signed-off-by: Patrik Jakobsson Signed-off-by: Greg Kroah-Hartman commit 2b777480ae68dbd348d67a7a4ad5cab6c7967f60 Author: Tomáš Trnka Date: Fri May 20 16:41:10 2016 +0200 sunrpc: fix stripping of padded MIC tokens commit c0cb8bf3a8e4bd82e640862cdd8891400405cb89 upstream. The length of the GSS MIC token need not be a multiple of four bytes. It is then padded by XDR to a multiple of 4 B, but unwrap_integ_data() would previously only trim mic.len + 4 B. The remaining up to three bytes would then trigger a check in nfs4svc_decode_compoundargs(), leading to a "garbage args" error and mount failure: nfs4svc_decode_compoundargs: compound not properly padded! nfsd: failed to decode arguments! This would prevent older clients using the pre-RFC 4121 MIC format (37-byte MIC including a 9-byte OID) from mounting exports from v3.9+ servers using krb5i. The trimming was introduced by commit 4c190e2f913f ("sunrpc: trim off trailing checksum before returning decrypted or integrity authenticated buffer"). Fixes: 4c190e2f913f "unrpc: trim off trailing checksum..." Signed-off-by: Tomáš Trnka Acked-by: Jeff Layton Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 22b37b9b71a92bb88a9865a29d671b41a586a100 Author: Juergen Gross Date: Wed May 18 16:44:54 2016 +0200 xen: use same main loop for counting and remapping pages commit dd14be92fbf5bc1ef7343f34968440e44e21b46a upstream. Instead of having two functions for cycling through the E820 map in order to count to be remapped pages and remap them later, just use one function with a caller supplied sub-function called for each region to be processed. This eliminates the possibility of a mismatch between both loops which showed up in certain configurations. Suggested-by: Ed Swierk Signed-off-by: Juergen Gross Signed-off-by: David Vrabel Signed-off-by: Greg Kroah-Hartman commit 5e90fb436e8831140267abc2d946f10161261791 Author: Ross Lagerwall Date: Tue May 10 16:11:00 2016 +0100 xen/events: Don't move disabled irqs commit f0f393877c71ad227d36705d61d1e4062bc29cf5 upstream. Commit ff1e22e7a638 ("xen/events: Mask a moving irq") open-coded irq_move_irq() but left out checking if the IRQ is disabled. This broke resuming from suspend since it tries to move a (disabled) irq without holding the IRQ's desc->lock. Fix it by adding in a check for disabled IRQs. The resulting stacktrace was: kernel BUG at /build/linux-UbQGH5/linux-4.4.0/kernel/irq/migration.c:31! invalid opcode: 0000 [#1] SMP Modules linked in: xenfs xen_privcmd ... CPU: 0 PID: 9 Comm: migration/0 Not tainted 4.4.0-22-generic #39-Ubuntu Hardware name: Xen HVM domU, BIOS 4.6.1-xs125180 05/04/2016 task: ffff88003d75ee00 ti: ffff88003d7bc000 task.ti: ffff88003d7bc000 RIP: 0010:[] [] irq_move_masked_irq+0xd2/0xe0 RSP: 0018:ffff88003d7bfc50 EFLAGS: 00010046 RAX: 0000000000000000 RBX: ffff88003d40ba00 RCX: 0000000000000001 RDX: 0000000000000001 RSI: 0000000000000100 RDI: ffff88003d40bad8 RBP: ffff88003d7bfc68 R08: 0000000000000000 R09: ffff88003d000000 R10: 0000000000000000 R11: 000000000000023c R12: ffff88003d40bad0 R13: ffffffff81f3a4a0 R14: 0000000000000010 R15: 00000000ffffffff FS: 0000000000000000(0000) GS:ffff88003da00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd4264de624 CR3: 0000000037922000 CR4: 00000000003406f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Stack: ffff88003d40ba38 0000000000000024 0000000000000000 ffff88003d7bfca0 ffffffff814c8d92 00000010813ef89d 00000000805ea732 0000000000000009 0000000000000024 ffff88003cc39b80 ffff88003d7bfce0 ffffffff814c8f66 Call Trace: [] eoi_pirq+0xb2/0xf0 [] __startup_pirq+0xe6/0x150 [] xen_irq_resume+0x319/0x360 [