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 [] xen_suspend+0xb5/0x180 [] multi_cpu_stop+0xb5/0xe0 [] ? cpu_stop_queue_work+0x80/0x80 [] cpu_stopper_thread+0xb0/0x140 [] ? finish_task_switch+0x76/0x220 [] ? __raw_callee_save___pv_queued_spin_unlock+0x11/0x20 [] smpboot_thread_fn+0x105/0x160 [] ? sort_range+0x30/0x30 [] kthread+0xd8/0xf0 [] ? kthread_create_on_node+0x1e0/0x1e0 [] ret_from_fork+0x3f/0x70 [] ? kthread_create_on_node+0x1e0/0x1e0 Signed-off-by: Ross Lagerwall Reviewed-by: Boris Ostrovsky Signed-off-by: David Vrabel Signed-off-by: Greg Kroah-Hartman commit aefbdd5d9a6253f7e88b9b6176b4972b0211535d Author: Gavin Shan Date: Wed Apr 27 11:14:51 2016 +1000 powerpc/eeh: Restore initial state in eeh_pe_reset_and_recover() commit 5a0cdbfd17b90a89c64a71d8aec9773ecdb20d0d upstream. The function eeh_pe_reset_and_recover() is used to recover EEH error when the passthrou device are transferred to guest and backwards. The content in the device's config space will be lost on PE reset issued in the middle of the recovery. The function saves/restores it before/after the reset. However, config access to some adapters like Broadcom BCM5719 at this point will causes fenced PHB. The config space is always blocked and we save 0xFF's that are restored at late point. The memory BARs are totally corrupted, causing another EEH error upon access to one of the memory BARs. This restores the config space on those adapters like BCM5719 from the content saved to the EEH device when it's populated, to resolve above issue. Fixes: 5cfb20b9 ("powerpc/eeh: Emulate EEH recovery for VFIO devices") Signed-off-by: Gavin Shan Reviewed-by: Russell Currey Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit cf3ebe674935738597e19abfad69f589ebb9b49c Author: Guilherme G. Piccoli Date: Mon Apr 11 16:17:22 2016 -0300 Revert "powerpc/eeh: Fix crash in eeh_add_device_early() on Cell" commit c2078d9ef600bdbe568c89e5ddc2c6f15b7982c8 upstream. This reverts commit 89a51df5ab1d38b257300b8ac940bbac3bb0eb9b. The function eeh_add_device_early() is used to perform EEH initialization in devices added later on the system, like in hotplug/DLPAR scenarios. Since the commit 89a51df5ab1d ("powerpc/eeh: Fix crash in eeh_add_device_early() on Cell") a new check was introduced in this function - Cell has no EEH capabilities which led to kernel oops if hotplug was performed, so checking for eeh_enabled() was introduced to avoid the issue. However, in architectures that EEH is present like pSeries or PowerNV, we might reach a case in which no PCI devices are present on boot time and so EEH is not initialized. Then, if a device is added via DLPAR for example, eeh_add_device_early() fails because eeh_enabled() is false, and EEH end up not being enabled at all. This reverts the aforementioned patch since a new verification was introduced by the commit d91dafc02f42 ("powerpc/eeh: Delay probing EEH device during hotplug") and so the original Cell issue does not happen anymore. Reviewed-by: Gavin Shan Signed-off-by: Guilherme G. Piccoli Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit df508c17ffd1d4c5e67a56f11a78f9896b55a23c Author: Gavin Shan Date: Wed Apr 27 11:14:50 2016 +1000 powerpc/eeh: Don't report error in eeh_pe_reset_and_recover() commit affeb0f2d3a9af419ad7ef4ac782e1540b2f7b28 upstream. The function eeh_pe_reset_and_recover() is used to recover EEH error when the passthrough device are transferred to guest and backwards, meaning the device's driver is vfio-pci or none. When the driver is vfio-pci that provides error_detected() error handler only, the handler simply stops the guest and it's not expected behaviour. On the other hand, no error handlers will be called if we don't have a bound driver. This ignores the error handler in eeh_pe_reset_and_recover() that reports the error to device driver to avoid the exceptional behaviour. Fixes: 5cfb20b9 ("powerpc/eeh: Emulate EEH recovery for VFIO devices") Signed-off-by: Gavin Shan Reviewed-by: Russell Currey Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit b84c42fe6e0282397000be779e18377f835bc405 Author: Hari Bathini Date: Fri Apr 15 22:48:02 2016 +1000 powerpc/book3s64: Fix branching to OOL handlers in relocatable kernel commit 8ed8ab40047a570fdd8043a40c104a57248dd3fd upstream. Some of the interrupt vectors on 64-bit POWER server processors are only 32 bytes long (8 instructions), which is not enough for the full first-level interrupt handler. For these we need to branch to an out-of-line (OOL) handler. But when we are running a relocatable kernel, interrupt vectors till __end_interrupts marker are copied down to real address 0x100. So, branching to labels (ie. OOL handlers) outside this section must be handled differently (see LOAD_HANDLER()), considering relocatable kernel, which would need at least 4 instructions. However, branching from interrupt vector means that we corrupt the CFAR (come-from address register) on POWER7 and later processors as mentioned in commit 1707dd16. So, EXCEPTION_PROLOG_0 (6 instructions) that contains the part up to the point where the CFAR is saved in the PACA should be part of the short interrupt vectors before we branch out to OOL handlers. But as mentioned already, there are interrupt vectors on 64-bit POWER server processors that are only 32 bytes long (like vectors 0x4f00, 0x4f20, etc.), which cannot accomodate the above two cases at the same time owing to space constraint. Currently, in these interrupt vectors, we simply branch out to OOL handlers, without using LOAD_HANDLER(), which leaves us vulnerable when running a relocatable kernel (eg. kdump case). While this has been the case for sometime now and kdump is used widely, we were fortunate not to see any problems so far, for three reasons: 1. In almost all cases, production kernel (relocatable) is used for kdump as well, which would mean that crashed kernel's OOL handler would be at the same place where we end up branching to, from short interrupt vector of kdump kernel. 2. Also, OOL handler was unlikely the reason for crash in almost all the kdump scenarios, which meant we had a sane OOL handler from crashed kernel that we branched to. 3. On most 64-bit POWER server processors, page size is large enough that marking interrupt vector code as executable (see commit 429d2e83) leads to marking OOL handler code from crashed kernel, that sits right below interrupt vector code from kdump kernel, as executable as well. Let us fix this by moving the __end_interrupts marker down past OOL handlers to make sure that we also copy OOL handlers to real address 0x100 when running a relocatable kernel. This fix has been tested successfully in kdump scenario, on an LPAR with 4K page size by using different default/production kernel and kdump kernel. Also tested by manually corrupting the OOL handlers in the first kernel and then kdump'ing, and then causing the OOL handlers to fire - mpe. Fixes: c1fb6816fb1b ("powerpc: Add relocation on exception vector handlers") Signed-off-by: Hari Bathini Signed-off-by: Mahesh Salgaonkar Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 82d5cbbb85368aa9679e82fc701be23d68cd187c Author: Zhao Qiang Date: Wed Mar 9 09:48:11 2016 +0800 QE-UART: add "fsl,t1040-ucc-uart" to of_device_id commit 11ca2b7ab432eb90906168c327733575e68d388f upstream. New bindings use "fsl,t1040-ucc-uart" as the compatible for qe-uart. So add it. Signed-off-by: Zhao Qiang Signed-off-by: Greg Kroah-Hartman commit 6ead64f51f849718a5a07cb2c2822f18b7852037 Author: Oleg Nesterov Date: Mon May 23 16:23:50 2016 -0700 wait/ptrace: assume __WALL if the child is traced commit bf959931ddb88c4e4366e96dd22e68fa0db9527c upstream. The following program (simplified version of generated by syzkaller) #include #include #include #include #include void *thread_func(void *arg) { ptrace(PTRACE_TRACEME, 0,0,0); return 0; } int main(void) { pthread_t thread; if (fork()) return 0; while (getppid() != 1) ; pthread_create(&thread, NULL, thread_func, NULL); pthread_join(thread, NULL); return 0; } creates an unreapable zombie if /sbin/init doesn't use __WALL. This is not a kernel bug, at least in a sense that everything works as expected: debugger should reap a traced sub-thread before it can reap the leader, but without __WALL/__WCLONE do_wait() ignores sub-threads. Unfortunately, it seems that /sbin/init in most (all?) distributions doesn't use it and we have to change the kernel to avoid the problem. Note also that most init's use sys_waitid() which doesn't allow __WALL, so the necessary user-space fix is not that trivial. This patch just adds the "ptrace" check into eligible_child(). To some degree this matches the "tsk->ptrace" in exit_notify(), ->exit_signal is mostly ignored when the tracee reports to debugger. Or WSTOPPED, the tracer doesn't need to set this flag to wait for the stopped tracee. This obviously means the user-visible change: __WCLONE and __WALL no longer have any meaning for debugger. And I can only hope that this won't break something, but at least strace/gdb won't suffer. We could make a more conservative change. Say, we can take __WCLONE into account, or !thread_group_leader(). But it would be nice to not complicate these historical/confusing checks. Signed-off-by: Oleg Nesterov Reported-by: Dmitry Vyukov Cc: Denys Vlasenko Cc: Jan Kratochvil Cc: "Michael Kerrisk (man-pages)" Cc: Pedro Alves Cc: Roland McGrath Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit cc086397fcbfbfd4b65a49c86ae03864f28a666d Author: Stefan Bader Date: Fri May 20 16:58:38 2016 -0700 mm: use phys_addr_t for reserve_bootmem_region() arguments commit 4b50bcc7eda4d3cc9e3f2a0aa60e590fedf728c5 upstream. Since commit 92923ca3aace ("mm: meminit: only set page reserved in the memblock region") the reserved bit is set on reserved memblock regions. However start and end address are passed as unsigned long. This is only 32bit on i386, so it can end up marking the wrong pages reserved for ranges at 4GB and above. This was observed on a 32bit Xen dom0 which was booted with initial memory set to a value below 4G but allowing to balloon in memory (dom0_mem=1024M for example). This would define a reserved bootmem region for the additional memory (for example on a 8GB system there was a reverved region covering the 4GB-8GB range). But since the addresses were passed on as unsigned long, this was actually marking all pages from 0 to 4GB as reserved. Fixes: 92923ca3aacef63 ("mm: meminit: only set page reserved in the memblock region") Link: http://lkml.kernel.org/r/1463491221-10573-1-git-send-email-stefan.bader@canonical.com Signed-off-by: Stefan Bader Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 084043be4eda8ba06b7497bf4aa41b0d1feef490 Author: Tiffany Lin Date: Mon Mar 14 08:16:14 2016 -0300 media: v4l2-compat-ioctl32: fix missing reserved field copy in put_v4l2_create32 commit baf43c6eace43868e490f18560287fa3481b2159 upstream. In v4l2-compliance utility, test VIDIOC_CREATE_BUFS will check whether reserved filed of v4l2_create_buffers filled with zero Reserved field is filled with zero in v4l_create_bufs. This patch copy reserved field of v4l2_create_buffer from kernel space to user space Signed-off-by: Tiffany Lin Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 7bb265913bb3f3459ab5fc4efc812dd97b288840 Author: Prarit Bhargava Date: Wed May 11 12:27:16 2016 -0400 PCI: Disable all BAR sizing for devices with non-compliant BARs commit ad67b437f187ea818b2860524d10f878fadfdd99 upstream. b84106b4e229 ("PCI: Disable IO/MEM decoding for devices with non-compliant BARs") disabled BAR sizing for BARs 0-5 of devices that don't comply with the PCI spec. But it didn't do anything for expansion ROM BARs, so we still try to size them, resulting in warnings like this on Broadwell-EP: pci 0000:ff:12.0: BAR 6: failed to assign [mem size 0x00000001 pref] Move the non-compliant BAR check from __pci_read_base() up to pci_read_bases() so it applies to the expansion ROM BAR as well as to BARs 0-5. Note that direct callers of __pci_read_base(), like sriov_init(), will now bypass this check. We haven't had reports of devices with broken SR-IOV BARs yet. [bhelgaas: changelog] Fixes: b84106b4e229 ("PCI: Disable IO/MEM decoding for devices with non-compliant BARs") Signed-off-by: Prarit Bhargava Signed-off-by: Bjorn Helgaas CC: Thomas Gleixner CC: Ingo Molnar CC: "H. Peter Anvin" CC: Andi Kleen Signed-off-by: Greg Kroah-Hartman commit dc4847dcea1dc2fdfeed098b88cda7f2d9f23273 Author: Andrew Jeffery Date: Wed Apr 20 11:24:17 2016 +0930 pinctrl: exynos5440: Use off-stack memory for pinctrl_gpio_range commit 71324fdc72ef0163e57631aa814a9a81e9e4770b upstream. The range is registered into a linked list which can be referenced throughout the lifetime of the driver. Ensure the range's memory is useful for the same lifetime by adding it to the driver's private data structure. The bug was introduced in the driver's initial commit, which was present in v3.10. Fixes: f0b9a7e521fa ("pinctrl: exynos5440: add pinctrl driver for Samsung EXYNOS5440 SoC") Signed-off-by: Andrew Jeffery Acked-by: Tomasz Figa Reviewed-by: Krzysztof Kozlowski Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 3d6661b2043581b9ce1e2e359033098d87140bae Author: Martin Sperl Date: Mon Feb 29 11:39:21 2016 +0000 clk: bcm2835: correctly enable fractional clock support commit 959ca92a3235fc4b17c1e18483fc390b3d612254 upstream. The current driver calculates the clock divider with fractional support enabled. But it does not enable fractional support in the control register itself resulting in an integer only divider, but in clk_set_rate responds back the fractionally divided clock frequency. This patch enables fractional support in the control register whenever there is a fractional bit set in the requested clock divider. Mash clock limits are are also handled for the PWM clock applying the correct divider limits (2 and max_int) applicable to basic fractional divider support (mash order of 1). It also adds locking to protect the read/modify/write cycle of the register modification. Fixes: 41691b8862e2 ("clk: bcm2835: Add support for programming the audio domain clocks") Signed-off-by: Martin Sperl Signed-off-by: Eric Anholt Reviewed-by: Eric Anholt Signed-off-by: Greg Kroah-Hartman commit d43f1f993c8d0af8b2aac740b068c316d874c299 Author: Martin Sperl Date: Mon Feb 29 11:39:20 2016 +0000 clk: bcm2835: divider value has to be 1 or more commit 997f16bd5d2e9b3456027f96fcadfe1e2bf12f4e upstream. Current clamping of a normal divider allows a value < 1 to be valid. A divider of < 1 would actually only be possible if we had a PLL... So this patch clamps the divider to 1. Fixes: 41691b8862e2 ("clk: bcm2835: Add support for programming the audio domain clocks") Signed-off-by: Martin Sperl Signed-off-by: Eric Anholt Reviewed-by: Eric Anholt Signed-off-by: Greg Kroah-Hartman commit 609909668f24377eff05cf9a52e9a6ed0a855bbe Author: Martin Sperl Date: Mon Feb 29 11:39:17 2016 +0000 clk: bcm2835: pll_off should only update CM_PLL_ANARST commit 6727f086cfe4ddcc651eb2bf4301abfcf619be06 upstream. bcm2835_pll_off is currently assigning CM_PLL_ANARST to the control register, which may lose the other bits that are currently set by the clock dividers. It also now locks during the read/modify/write cycle of both registers. Fixes: 41691b8862e2 ("clk: bcm2835: Add support for programming the audio domain clocks") Signed-off-by: Martin Sperl Signed-off-by: Eric Anholt Reviewed-by: Eric Anholt Signed-off-by: Greg Kroah-Hartman commit 0f519544d9da48c5b64f708ee86dea161ee43885 Author: Vladimir Zapolskiy Date: Tue Mar 8 01:41:29 2016 +0200 clk: at91: fix check of clk_register() returned value commit cb0ceaf77d93964a0d00477c79f4499123f6159c upstream. The clk_register() function returns a valid pointer to struct clk or ERR_PTR() error code, this makes a check for returned NULL value useless and may lead to oops on error path. Signed-off-by: Vladimir Zapolskiy Acked-by: Alexandre Belloni Acked-by: Boris Brezillon Fixes: bcc5fd49a0fd ("clk: at91: add a driver for the h32mx clock") Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit 319e5751f330825a7b1e593a9ada36e6e8450448 Author: Eric Anholt Date: Wed Apr 13 13:05:03 2016 -0700 clk: bcm2835: Fix PLL poweron commit e708b383f4b94feca2e0d5d06e1cfc13cdfea100 upstream. In poweroff, we set the reset bit and the power down bit, but only managed to unset the reset bit for poweron. This meant that if HDMI did -EPROBE_DEFER after it had grabbed its clocks, we'd power down the PLLH (that had been on at boot time) and never recover. Signed-off-by: Eric Anholt Fixes: 41691b8862e2 ("clk: bcm2835: Add support for programming the audio domain clocks") Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit f49e30c2edc6808f188a3f00d1ac4b97e2002d69 Author: Daniel Lezcano Date: Tue May 17 16:54:00 2016 +0200 cpuidle: Fix cpuidle_state_is_coupled() argument in cpuidle_enter() commit e7387da52028b072489c45efeb7a916c0205ebd2 upstream. Commit 0b89e9aa2856 (cpuidle: delay enabling interrupts until all coupled CPUs leave idle) rightfully fixed a regression by letting the coupled idle state framework to handle local interrupt enabling when the CPU is exiting an idle state. The current code checks if the idle state is coupled and, if so, it will let the coupled code to enable interrupts. This way, it can decrement the ready-count before handling the interrupt. This mechanism prevents the other CPUs from waiting for a CPU which is handling interrupts. But the check is done against the state index returned by the back end driver's ->enter functions which could be different from the initial index passed as parameter to the cpuidle_enter_state() function. entered_state = target_state->enter(dev, drv, index); [ ... ] if (!cpuidle_state_is_coupled(drv, entered_state)) local_irq_enable(); [ ... ] If the 'index' is referring to a coupled idle state but the 'entered_state' is *not* coupled, then the interrupts are enabled again. All CPUs blocked on the sync barrier may busy loop longer if the CPU has interrupts to handle before decrementing the ready-count. That's consuming more energy than saving. Fixes: 0b89e9aa2856 (cpuidle: delay enabling interrupts until all coupled CPUs leave idle) Signed-off-by: Daniel Lezcano [ rjw: Subject & changelog ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 7b8c57be40de1d4709a01854a7f50a1cff535b34 Author: Dave Gerlach Date: Tue Apr 5 14:05:38 2016 -0500 cpuidle: Indicate when a device has been unregistered commit c998c07836f985b24361629dc98506ec7893e7a0 upstream. Currently the 'registered' member of the cpuidle_device struct is set to 1 during cpuidle_register_device. In this same function there are checks to see if the device is already registered to prevent duplicate calls to register the device, but this value is never set to 0 even on unregister of the device. Because of this, any attempt to call cpuidle_register_device after a call to cpuidle_unregister_device will fail which shouldn't be the case. To prevent this, set registered to 0 when the device is unregistered. Fixes: c878a52d3c7c (cpuidle: Check if device is already registered) Signed-off-by: Dave Gerlach Acked-by: Daniel Lezcano Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 90af331d8f16f9749664760b836fb1b9317eb408 Author: Ulf Hansson Date: Fri Apr 8 13:10:23 2016 +0200 PM / Runtime: Fix error path in pm_runtime_force_resume() commit 0ae3aeefabbeef26294e7a349b51f1c761d46c9f upstream. As pm_runtime_set_active() may fail because the device's parent isn't active, we can end up executing the ->runtime_resume() callback for the device when it isn't allowed. Fix this by invoking pm_runtime_set_active() before running the callback and let's also deal with the error code. Fixes: 37f204164dfb (PM: Add pm_runtime_suspend|resume_force functions) Signed-off-by: Ulf Hansson Reviewed-by: Linus Walleij Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 095a59cfcf22dd91aa28e1d77e6e33b99c2d0a92 Author: Ville Syrjälä Date: Fri Apr 22 22:38:55 2016 +0300 mfd: intel_soc_pmic_core: Terminate panel control GPIO lookup table correctly commit 36e6d081cfb2cb64e6d8e5121cffb1e62f894d36 upstream. GPIO lookup tables are supposed to be zero terminated. Let's do that and avoid accidentally walking off the end. Fixes: 61dd2ca2d44e ("mfd: intel_soc_pmic_core: Add lookup table for Panel Control as GPIO signal") Signed-off-by: Ville Syrjälä Acked-by: Linus Walleij Acked-by: Daniel Vetter Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit 3bec9182274d5c8b6dd20949b14ffe584ad412b6 Author: Heikki Krogerus Date: Mon Apr 18 15:14:56 2016 +0300 mfd: intel-lpss: Save register context on suspend commit 41a3da2b8e1639d983192e3650670df4ecc94cf7 upstream. All configurations are lost and the registers will have default values when the hardware is suspended and resumed, so saving the private register space context on suspend, and restoring it on resume. Fixes: 4b45efe85263 (mfd: Add support for Intel Sunrisepoint LPSS devices) Signed-off-by: Heikki Krogerus Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit 6bff15be8869b45e3bd6f4b8d4d60ebd08a1365a Author: Akshay Bhat Date: Mon Apr 18 15:47:53 2016 -0400 hwmon: (ads7828) Enable internal reference commit 7a18afe8097731b8ffb6cb5b2b3b418ded77c105 upstream. On ads7828 the internal reference defaults to off upon power up. When using internal reference, it needs to be turned on and the voltage needs to settle before normal conversion cycle can be started. Hence perform a dummy read in the probe to enable the internal reference allowing the voltage to settle before performing a normal read. Without this fix, the first read from the ADC when using internal reference always returns incorrect data. Signed-off-by: Akshay Bhat Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit adf82e8ee519df413deec3334021de502c82f17a Author: Raghava Aditya Renukunta Date: Mon Apr 25 23:32:37 2016 -0700 aacraid: Fix for KDUMP driver hang commit 78cbccd3bd683c295a44af8050797dc4a41376ff upstream. When KDUMP is triggered the driver first talks to the firmware in INTX mode, but the adapter firmware is still in MSIX mode. Therefore the first driver command hangs since the driver is waiting for an INTX response and firmware gives a MSIX response. If when the OS is installed on a RAID drive created by the adapter KDUMP will hang since the driver does not receive a response in sync mode. Fixed by: Change the firmware to INTX mode if it is in MSIX mode before sending the first sync command. Signed-off-by: Raghava Aditya Renukunta Reviewed-by: Johannes Thumshirn Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 7f778cfa7148ca300a92a2f237f1da0deafb27ff Author: Raghava Aditya Renukunta Date: Mon Apr 25 23:31:57 2016 -0700 aacraid: Fix for aac_command_thread hang commit fc4bf75ea300a5e62a2419f89dd0e22189dd7ab7 upstream. Typically under error conditions, it is possible for aac_command_thread() to miss the wakeup from kthread_stop() and go back to sleep, causing it to hang aac_shutdown. In the observed scenario, the adapter is not functioning correctly and so aac_fib_send() never completes (or time-outs depending on how it was called). Shortly after aac_command_thread() starts it performs aac_fib_send(SendHostTime) which hangs. When aac_probe_one /aac_get_adapter_info send time outs, kthread_stop is called which breaks the command thread out of it's hang. The code will still go back to sleep in schedule_timeout() without checking kthread_should_stop() so it causes aac_probe_one to hang until the schedule_timeout() which is 30 minutes. Fixed by: Adding another kthread_should_stop() before schedule_timeout() Signed-off-by: Raghava Aditya Renukunta Reviewed-by: Johannes Thumshirn Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 82aee68d6622cfe5b1927239a157731d1fc7ac9c Author: Raghava Aditya Renukunta Date: Mon Apr 25 23:31:26 2016 -0700 aacraid: Relinquish CPU during timeout wait commit 07beca2be24cc710461c0b131832524c9ee08910 upstream. aac_fib_send has a special function case for initial commands during driver initialization using wait < 0(pseudo sync mode). In this case, the command does not sleep but rather spins checking for timeout.This loop is calls cpu_relax() in an attempt to allow other processes/threads to use the CPU, but this function does not relinquish the CPU and so the command will hog the processor. This was observed in a KDUMP "crashkernel" and that prevented the "command thread" (which is responsible for completing the command from being timed out) from starting because it could not get the CPU. Fixed by replacing "cpu_relax()" call with "schedule()" Signed-off-by: Raghava Aditya Renukunta Reviewed-by: Johannes Thumshirn Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 3c70550d8a10e600bf02c7bdb5c46ba782548288 Author: Martin K. Petersen Date: Mon May 9 21:39:43 2016 -0400 Revert "lpfc: Delete unnecessary checks before the function call mempool_destroy" commit d65c8fff867a6450c58ce31572e883148a445ddf upstream. This reverts commit 9be321819c43417432a8376428b90fe3fe3a3510 which caused a regression on hardware using the SLI3 interface. Reported-by: Dick Kennedy Signed-off-by: Martin K. Petersen Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 85e29271c3a3942f6e7e453c8dae22c6210b8f03 Author: wang yanqing Date: Sat May 7 00:33:53 2016 +0800 rtlwifi: pci: use dev_kfree_skb_irq instead of kfree_skb in rtl_pci_reset_trx_ring commit cf968937d27751296920e6b82ffa89735e3a0023 upstream. We can't use kfree_skb in irq disable context, because spin_lock_irqsave make sure we are always in irq disable context, use dev_kfree_skb_irq instead of kfree_skb is better than dev_kfree_skb_any. This patch fix below kernel warning: [ 7612.095528] ------------[ cut here ]------------ [ 7612.095546] WARNING: CPU: 3 PID: 4460 at kernel/softirq.c:150 __local_bh_enable_ip+0x58/0x80() [ 7612.095550] Modules linked in: rtl8723be x86_pkg_temp_thermal btcoexist rtl_pci rtlwifi rtl8723_common [ 7612.095567] CPU: 3 PID: 4460 Comm: ifconfig Tainted: G W 4.4.0+ #4 [ 7612.095570] Hardware name: LENOVO 20DFA04FCD/20DFA04FCD, BIOS J5ET48WW (1.19 ) 08/27/2015 [ 7612.095574] 00000000 00000000 da37fc70 c12ce7c5 00000000 da37fca0 c104cc59 c19d4454 [ 7612.095584] 00000003 0000116c c19d4784 00000096 c10508a8 c10508a8 00000200 c1b42400 [ 7612.095594] f29be780 da37fcb0 c104ccad 00000009 00000000 da37fcbc c10508a8 f21f08b8 [ 7612.095604] Call Trace: [ 7612.095614] [] dump_stack+0x41/0x5c [ 7612.095620] [] warn_slowpath_common+0x89/0xc0 [ 7612.095628] [] ? __local_bh_enable_ip+0x58/0x80 [ 7612.095634] [] ? __local_bh_enable_ip+0x58/0x80 [ 7612.095640] [] warn_slowpath_null+0x1d/0x20 [ 7612.095646] [] __local_bh_enable_ip+0x58/0x80 [ 7612.095653] [] destroy_conntrack+0x64/0xa0 [ 7612.095660] [] nf_conntrack_destroy+0xf/0x20 [ 7612.095665] [] skb_release_head_state+0x55/0xa0 [ 7612.095670] [] skb_release_all+0xb/0x20 [ 7612.095674] [] __kfree_skb+0xb/0x60 [ 7612.095679] [] kfree_skb+0x30/0x70 [ 7612.095686] [] ? rtl_pci_reset_trx_ring+0x22d/0x370 [rtl_pci] [ 7612.095692] [] rtl_pci_reset_trx_ring+0x22d/0x370 [rtl_pci] [ 7612.095698] [] rtl_pci_start+0x19/0x190 [rtl_pci] [ 7612.095705] [] rtl_op_start+0x56/0x90 [rtlwifi] [ 7612.095712] [] drv_start+0x36/0xc0 [ 7612.095717] [] ieee80211_do_open+0x2d3/0x890 [ 7612.095725] [] ? call_netdevice_notifiers_info+0x2e/0x60 [ 7612.095730] [] ieee80211_open+0x4d/0x50 [ 7612.095736] [] __dev_open+0xa3/0x130 [ 7612.095742] [] ? _raw_spin_unlock_bh+0x13/0x20 [ 7612.095748] [] __dev_change_flags+0x89/0x140 [ 7612.095753] [] ? selinux_capable+0xd/0x10 [ 7612.095759] [] dev_change_flags+0x29/0x60 [ 7612.095765] [] devinet_ioctl+0x553/0x670 [ 7612.095772] [] ? _copy_to_user+0x28/0x40 [ 7612.095777] [] inet_ioctl+0x85/0xb0 [ 7612.095783] [] sock_ioctl+0x67/0x260 [ 7612.095788] [] ? sock_fasync+0x80/0x80 [ 7612.095795] [] do_vfs_ioctl+0x6b/0x550 [ 7612.095800] [] ? selinux_file_ioctl+0x102/0x1e0 [ 7612.095807] [] ? timekeeping_suspend+0x294/0x320 [ 7612.095813] [] ? __hrtimer_run_queues+0x14a/0x210 [ 7612.095820] [] ? security_file_ioctl+0x34/0x50 [ 7612.095827] [] SyS_ioctl+0x70/0x80 [ 7612.095832] [] do_fast_syscall_32+0x84/0x120 [ 7612.095839] [] sysenter_past_esp+0x36/0x55 [ 7612.095844] ---[ end trace 97e9c637a20e8348 ]--- Signed-off-by: Wang YanQing Acked-by: Larry Finger Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit b8b2eca206506905782d89c0ee775cf0b8920cb9 Author: wang yanqing Date: Tue May 3 00:38:36 2016 +0800 rtlwifi: Fix logic error in enter/exit power-save mode commit 873ffe154ae074c46ed2d72dbd9a2a99f06f55b4 upstream. In commit a269913c52ad ("rtlwifi: Rework rtl_lps_leave() and rtl_lps_enter() to use work queue"), the tests for enter/exit power-save mode were inverted. With this change applied, the wifi connection becomes much more stable. Fixes: a269913c52ad ("rtlwifi: Rework rtl_lps_leave() and rtl_lps_enter() to use work queue") Signed-off-by: Wang YanQing Acked-by: Larry Finger Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit da3d5ee58fd2eeddba38c0e7c6cd76a8180fb647 Author: Larry Finger Date: Wed Mar 16 13:33:35 2016 -0500 rtlwifi: btcoexist: Implement antenna selection commit baa1702290953295e421f0f433e2b1ff4815827c upstream. The previous patch added an option to rtl8723be to manually select the antenna for those cases when only a single antenna is present, and the on-board EEPROM is incorrectly programmed. This patch implements the necessary changes in the Bluetooth coexistence driver. Signed-off-by: Larry Finger Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit d967268c46f138c7e550e1d0ecd58cd79473d4a3 Author: Larry Finger Date: Wed Mar 16 13:33:34 2016 -0500 rtlwifi: rtl8723be: Add antenna select module parameter commit c18d8f5095715c56bb3cd9cba64242542632054b upstream. A number of new laptops have been delivered with only a single antenna. In principle, this is OK; however, a problem arises when the on-board EEPROM is programmed to use the other antenna connection. The option of opening the computer and moving the connector is not always possible as it will void the warranty in some cases. In addition, this solution breaks the Windows driver when the box dual boots Linux and Windows. A fix involving a new module parameter has been developed. This commit adds the new parameter and implements the changes needed for the driver. Signed-off-by: Larry Finger Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit aad56aa19257c76294a506f524328ad2cc2d455f Author: Krzysztof Kozlowski Date: Mon Mar 14 09:07:13 2016 +0900 hwrng: exynos - Fix unbalanced PM runtime put on timeout error path commit f1925d78d7b710a1179828d53e918295f5f5d222 upstream. In case of timeout during read operation, the exit path lacked PM runtime put. This could lead to unbalanced runtime PM usage counter thus leaving the device in an active state. Fixes: d7fd6075a205 ("hwrng: exynos - Add timeout for waiting on init done") Signed-off-by: Krzysztof Kozlowski Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit fe5cfed0523eb4b3d540712f70173872c91335d2 Author: Joseph Salisbury Date: Mon Mar 14 14:51:48 2016 -0400 ath5k: Change led pin configuration for compaq c700 laptop commit 7b9bc799a445aea95f64f15e0083cb19b5789abe upstream. BugLink: http://bugs.launchpad.net/bugs/972604 Commit 09c9bae26b0d3c9472cb6ae45010460a2cee8b8d ("ath5k: add led pin configuration for compaq c700 laptop") added a pin configuration for the Compaq c700 laptop. However, the polarity of the led pin is reversed. It should be red for wifi off and blue for wifi on, but it is the opposite. This bug was reported in the following bug report: http://pad.lv/972604 Fixes: 09c9bae26b0d3c9472cb6ae45010460a2cee8b8d ("ath5k: add led pin configuration for compaq c700 laptop") Signed-off-by: Joseph Salisbury Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit fcffcfc60058deb26bd465452103128b95356d06 Author: Anilkumar Kolli Date: Tue Apr 26 21:35:48 2016 +0530 ath10k: fix kernel panic, move arvifs list head init before htt init commit 4ad24a9d83bd4bf0a85e95bf144e18d3fda4fbf1 upstream. It is observed that while loading and unloading ath10k modules in an infinite loop, before ath10k_core_start() completion HTT rx frames are received, while processing these frames, dereferencing the arvifs list code is getting hit before initilizing the arvifs list, causing a kernel panic. This patch initilizes the arvifs list before initilizing htt. Fixes the below issue: [] (ath10k_htt_rx_pktlog_completion_handler+0x278/0xd08 [ath10k_core]) [] (ath10k_htt_rx_pktlog_completion_handler [ath10k_core]) [] (ath10k_htt_txrx_compl_task+0x5f4/0xeb0 [ath10k_core]) [] (ath10k_htt_txrx_compl_task [ath10k_core]) [] (tasklet_action+0x8c/0xec) [] (tasklet_action) [] (__do_softirq+0xf8/0x228) [] (__do_softirq) [] (run_ksoftirqd+0x30/0x90) Code: e5954ad8 e2899008 e1540009 0a00000d (e5943008) ---[ end trace 71de5c2e011dbf56 ]--- Kernel panic - not syncing: Fatal exception in interrupt Fixes: 500ff9f9389d ("ath10k: implement chanctx API") Signed-off-by: Anilkumar Kolli Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit ffebbb1e6efc11a6ba838001f6156227f9971ea8 Author: Rajkumar Manoharan Date: Thu Apr 7 12:11:54 2016 +0530 ath10k: fix rx_channel during hw reconfigure commit 1ce8c1484e80010a6e4b9611c65668ff77556f45 upstream. Upon firmware assert, restart work will be triggered so that mac80211 will reconfigure the driver. An issue is reported that after restart work, survey dump data do not contain in-use (SURVEY_INFO_IN_USE) info for operating channel. During reconfigure, since mac80211 already has valid channel context for given radio, channel context iteration return num_chanctx > 0. Hence rx_channel is always NULL. Fix this by assigning channel context to rx_channel when driver restart is in progress. Signed-off-by: Rajkumar Manoharan Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit 92d392efa0466dc6f7b2e6fb85c78e4c53f28e91 Author: Rajkumar Manoharan Date: Wed Mar 2 20:13:52 2016 +0530 ath10k: fix firmware assert in monitor mode commit 8a75fc54745fd3ce9062ab1cc6429a9da9ac2a68 upstream. commit 166de3f1895d ("ath10k: remove supported chain mask") had revealed an issue on monitor mode. Configuring NSS upon monitor interface creation is causing target assert in all qca9888x and qca6174 firmware. Firmware assert issue can be reproduced by below sequence even after reverting commit 166de3f1895d ("ath10k: remove supported chain mask"). ip link set wlan0 down iw wlan0 set type monitor iw phy0 set antenna 7 ip link set wlan0 up This issue is originally reported on qca9888 with 10.1 firmware. Fixes: 5572a95b4b ("ath10k: apply chainmask settings to vdev on creation") Reported-by: Janusz Dziedzic Signed-off-by: Rajkumar Manoharan Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit c645036c2d049d3c87b83dfeef1fedf378faf742 Author: Anilkumar Kolli Date: Fri Mar 11 11:46:39 2016 +0530 ath10k: fix debugfs pktlog_filter write commit 9ddc486aa09a3413a6c492fcf160ce61bfccb7b1 upstream. It is observed that, we are disabling the packet log if we write same value to the pktlog_filter for the second time. Always enable pktlogs on non zero filter. Fixes: 90174455ae05 ("ath10k: add support to configure pktlog filter") Signed-off-by: Anilkumar Kolli Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit 13ada841daef975e07a5a288f52b1bdd0d25f8ff Author: Vittorio Gambaletta (VittGam) Date: Mon Apr 11 04:48:55 2016 +0200 ath9k: Fix LED polarity for some Mini PCI AR9220 MB92 cards. commit 0f9edcdd88a993914fa1d1dc369b35dc503979db upstream. The Wistron DNMA-92 and Compex WLM200NX have inverted LED polarity (active high instead of active low). The same PCI Subsystem ID is used by both cards, which are based on the same Atheros MB92 design. Cc: Cc: Cc: Signed-off-by: Vittorio Gambaletta Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit 2684bb0a7b1922fa476981864d9e2235688b8d0e Author: Vittorio Gambaletta (VittGam) Date: Mon Apr 11 04:48:54 2016 +0200 ath9k: Add a module parameter to invert LED polarity. commit cd84042ce9040ad038e958bc67a46fcfc015c736 upstream. The LED can be active high instead of active low on some hardware. Add the led_active_high module parameter. It defaults to -1 to obey platform data as before. Setting the parameter to 1 or 0 will force the LED respectively active high or active low. Cc: Cc: Cc: Signed-off-by: Vittorio Gambaletta Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit 11db63d081f37e24ff5725f72c580a1b9ffce9e7 Author: Alexander Kurz Date: Thu Apr 14 23:30:49 2016 +0200 ARM: dts: imx35: restore existing used clock enumeration commit 3397c2c45b1b6f54834dfeae30a73046f33ca943 upstream. A new element got inserted into enum mx35_clks with commit 3713e3f5e927 ("clk: imx35: define two clocks for rtc"). This insertion shifted most nummerical clock assignments to a new nummerical value which in turn rendered most hardcoded nummeric values in imx35.dtsi incorrect. Restore the existing order by moving the newly introduced clock to the end of the enum. Update the dts documentation accordingly. Signed-off-by: Alexander Kurz Fixes: 3713e3f5e927 ("clk: imx35: define two clocks for rtc") Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit 9ac1cd64aad6139631b7e07f6de1057e85301dd4 Author: Marek Szyprowski Date: Fri May 6 09:27:16 2016 +0200 ARM: dts: exynos: Add interrupt line to MAX8997 PMIC on exynos4210-trats commit 330d12764e15f6e3e94ff34cda29db96d2589c24 upstream. MAX8997 PMIC requires interrupt and fails probing without it. Signed-off-by: Marek Szyprowski Fixes: d105f0b1215d ("ARM: dts: Add basic dts file for Samsung Trats board") [k.kozlowski: Write commit message, add CC-stable] Signed-off-by: Krzysztof Kozlowski Signed-off-by: Greg Kroah-Hartman commit a198b6586b0fcc260250e75ac8dfac935fb7619d Author: Florian Vallee Date: Tue Apr 19 17:50:05 2016 +0200 ARM: dts: at91: fix typo in sama5d2 PIN_PD24 description commit b1f3a3b03eb5f61b4051e2da9aa15653e705e111 upstream. Fix a typo on PIN_PD24 for UTXD2 and FLEXCOM4_IO3 which were wrongly linked to PIN_PD23). Signed-off-by: Florian Vallee Fixes: 7f16cb676c00 ("ARM: at91/dt: add sama5d2 pinmux") [nicolas.ferre@atmel.com: add commit message, changed subject] Signed-off-by: Nicolas Ferre Signed-off-by: Greg Kroah-Hartman commit 4fef66c6e38ac5aae1e53bfe7d7f607be13b6d73 Author: Imre Kaloz Date: Fri Jul 31 20:42:00 2015 +0200 ARM: mvebu: fix GPIO config on the Linksys boards commit 9800917cf92f5b5fe5cae706cb70db8d014f663c upstream. Some of the GPIO configs were wrong in the submitted DTS files, this patch fixes all affected boards. Signed-off-by: Imre Kaloz Signed-off-by: Greg Kroah-Hartman Signed-off-by: Gregory CLEMENT commit 72269e999aceccdadc6794c8f7b34bb3110fd904 Author: Priit Laes Date: Thu Mar 24 21:52:17 2016 +0200 ARM: sun7i: dt: Enable dram gate 5 (tve0 clock) for simplefb TV output commit 4b8ccef22fb547007ac38c4e5a28a773adee1e6e upstream. Seems like dram_gate 5 was forgotten when DRAM gating driver was added. Add it. Fixes: 0b4bf5a5200b (ARM: dts: sun7i: Add DRAM gates) Signed-off-by: Priit Laes Signed-off-by: Maxime Ripard Signed-off-by: Greg Kroah-Hartman commit c59ef0b284e2f104fc863d01b8b3409a1a8f560c Author: Priit Laes Date: Thu Mar 24 21:52:16 2016 +0200 ARM: sun4i: dt: Enable dram gate 5 (tve0 clock) for simplefb TV output commit bec38aaafd9ec1463dd3857f02bc029707e4213d upstream. Seems like dram_gate 5 was forgotten when DRAM gate driver was added. Enable it. Fixes: 82f8582feef4 (ARM: dts: sun4i: Add DRAM gates) Signed-off-by: Priit Laes Signed-off-by: Maxime Ripard Signed-off-by: Greg Kroah-Hartman commit 16abb8433908df9b0ae504a20e9d5515df1a5e41 Author: Cameron Gutman Date: Fri May 27 16:23:50 2016 -0700 Input: xpad - prevent spurious input from wired Xbox 360 controllers commit 1ff5fa3c6732f08e01ae12f12286d4728c9e4d86 upstream. After initially connecting a wired Xbox 360 controller or sending it a command to change LEDs, a status/response packet is interpreted as controller input. This causes the state of buttons represented in byte 2 of the controller data packet to be incorrect until the next valid input packet. Wireless Xbox 360 controllers are not affected. Writing a new value to the LED device while holding the Start button and running jstest is sufficient to reproduce this bug. An event will come through with the Start button released. Xboxdrv also won't attempt to read controller input from a packet where byte 0 is non-zero. It also checks that byte 1 is 0x14, but that value differs between wired and wireless controllers and this code is shared by both. I think just checking byte 0 is enough to eliminate unwanted packets. The following are some examples of 3-byte status packets I saw: 01 03 02 02 03 00 03 03 03 08 03 00 Signed-off-by: Cameron Gutman Signed-off-by: Pavel Rojtberg Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit ec0b397bdb5c89a58082f7f748051f7fbcff8113 Author: Pavel Rojtberg Date: Fri May 27 16:22:25 2016 -0700 Input: xpad - move pending clear to the correct location commit 4efc6939a83c54fb3417541be48991afd0290ba3 upstream. otherwise we lose ff commands: https://github.com/paroj/xpad/issues/27 Signed-off-by: Pavel Rojtberg Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit eaf6a64aa39ffa2b33f9894b7544df1e11e386c1 Author: Ricky Liang Date: Fri May 20 10:58:59 2016 -0700 Input: uinput - handle compat ioctl for UI_SET_PHYS commit affa80bd97f7ca282d1faa91667b3ee9e4c590e6 upstream. When running a 32-bit userspace on a 64-bit kernel, the UI_SET_PHYS ioctl needs to be treated with special care, as it has the pointer size encoded in the command. Signed-off-by: Ricky Liang Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 72f67f5546ea86c557e24fcde454a71d8b1d0042 Author: Mark Brown Date: Wed May 18 18:30:39 2016 +0100 ASoC: ak4642: Enable cache usage to fix crashes on resume commit d3030d11961a8c103cf07aed59905276ddfc06c2 upstream. The ak4642 driver is using a regmap cache sync to restore the configuration of the chip on resume but (as Peter observed) does not actually define a register cache which means that the resume is never going to work and we trigger asserts in regmap. Fix this by enabling caching. Reported-by: Geert Uytterhoeven Reported-by: Peter Ujfalusi Tested-by: Geert Uytterhoeven Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 866e26f1283d71f416def70a831cb136d24ec54e Author: Mikulas Patocka Date: Tue May 24 22:48:33 2016 +0200 affs: fix remount failure when there are no options changed commit 01d6e08711bf90bc4d7ead14a93a0cbd73b1896a upstream. Commit c8f33d0bec99 ("affs: kstrdup() memory handling") checks if the kstrdup function returns NULL due to out-of-memory condition. However, if we are remounting a filesystem with no change to filesystem-specific options, the parameter data is NULL. In this case, kstrdup returns NULL (because it was passed NULL parameter), although no out of memory condition exists. The mount syscall then fails with ENOMEM. This patch fixes the bug. We fail with ENOMEM only if data is non-NULL. The patch also changes the call to replace_mount_options - if we didn't pass any filesystem-specific options, we don't call replace_mount_options (thus we don't erase existing reported options). Fixes: c8f33d0bec99 ("affs: kstrdup() memory handling") Signed-off-by: Mikulas Patocka Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit e43cafb338c7820e5771f32dc4fc4e043cdfd9a0 Author: Maciej W. Rozycki Date: Thu May 26 12:55:45 2016 +0100 MIPS: VDSO: Build with `-fno-strict-aliasing' commit 94cc36b84acc29f543b48bc5ed786011b112a666 upstream. Avoid an aliasing issue causing a build error in VDSO: In file included from include/linux/srcu.h:34:0, from include/linux/notifier.h:15, from ./arch/mips/include/asm/uprobes.h:9, from include/linux/uprobes.h:61, from include/linux/mm_types.h:13, from ./arch/mips/include/asm/vdso.h:14, from arch/mips/vdso/vdso.h:27, from arch/mips/vdso/gettimeofday.c:11: include/linux/workqueue.h: In function 'work_static': include/linux/workqueue.h:186:2: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing] return *work_data_bits(work) & WORK_STRUCT_STATIC; ^ cc1: all warnings being treated as errors make[2]: *** [arch/mips/vdso/gettimeofday.o] Error 1 with a CONFIG_DEBUG_OBJECTS_WORK configuration and GCC 5.2.0. Include `-fno-strict-aliasing' along with compiler options used, as required for kernel code, fixing a problem present since the introduction of VDSO with commit ebb5e78cc634 ("MIPS: Initial implementation of a VDSO"). Thanks to Tejun for diagnosing this properly! Signed-off-by: Maciej W. Rozycki Reviewed-by: James Hogan Fixes: ebb5e78cc634 ("MIPS: Initial implementation of a VDSO") Cc: Tejun Heo Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/13357/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 895daf6989bc552954253319a625c1c2c20df0c1 Author: Harvey Hunt Date: Wed May 25 11:06:35 2016 +0100 MIPS: lib: Mark intrinsics notrace commit aedcfbe06558a9f53002e82d5be64c6c94687726 upstream. On certain MIPS32 devices, the ftrace tracer "function_graph" uses __lshrdi3() during the capturing of trace data. ftrace then attempts to trace __lshrdi3() which leads to infinite recursion and a stack overflow. Fix this by marking __lshrdi3() as notrace. Mark the other compiler intrinsics as notrace in case the compiler decides to use them in the ftrace path. Signed-off-by: Harvey Hunt Cc: Cc: Patchwork: https://patchwork.linux-mips.org/patch/13354/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit cf12a51b3e9eeb56ba3fa3f7df9ebb2f18693d33 Author: James Hogan Date: Tue May 24 09:35:11 2016 +0100 MIPS: Build microMIPS VDSO for microMIPS kernels commit bb93078e655be1e24d68f28f2756676e62c037ce upstream. MicroMIPS kernels may be expected to run on microMIPS only cores which don't support the normal MIPS instruction set, so be sure to pass the -mmicromips flag through to the VDSO cflags. Fixes: ebb5e78cc634 ("MIPS: Initial implementation of a VDSO") Signed-off-by: James Hogan Cc: Paul Burton Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/13349/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 01fba0e9846771d41d82c67b9920d8ecbcd73db1 Author: James Hogan Date: Tue May 24 09:35:10 2016 +0100 MIPS: Fix sigreturn via VDSO on microMIPS kernel commit 13eb192d10bcc9ac518d57356179071d603bcb4e upstream. In microMIPS kernels, handle_signal() sets the isa16 mode bit in the vdso address so that the sigreturn trampolines (which are offset from the VDSO) get executed as microMIPS. However commit ebb5e78cc634 ("MIPS: Initial implementation of a VDSO") changed the offsets to come from the VDSO image, which already have the isa16 mode bit set correctly since they're extracted from the VDSO shared library symbol table. Drop the isa16 mode bit handling from handle_signal() to fix sigreturn for cores which support both microMIPS and normal MIPS. This doesn't fix microMIPS only cores, since the VDSO is still built for normal MIPS, but thats a separate problem. Fixes: ebb5e78cc634 ("MIPS: Initial implementation of a VDSO") Signed-off-by: James Hogan Cc: Paul Burton Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/13348/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 9f6097aa7f0c27e711c4c70d3d9a94f871695e83 Author: Maciej W. Rozycki Date: Thu May 12 10:19:08 2016 +0100 MIPS: ptrace: Prevent writes to read-only FCSR bits commit abf378be49f38c4d3e23581d3df3fa9f1b1b11d2 upstream. Correct the cases missed with commit 9b26616c8d9d ("MIPS: Respect the ISA level in FCSR handling") and prevent writes to read-only FCSR bits there. This in particular applies to FP context initialisation where any IEEE 754-2008 bits preset by `mips_set_personality_nan' are cleared before the relevant ptrace(2) call takes effect and the PTRACE_POKEUSR request addressing FPC_CSR where no masking of read-only FCSR bits is done. Remove the FCSR clearing from FP context initialisation then and unify PTRACE_POKEUSR/FPC_CSR and PTRACE_SETFPREGS handling, by factoring out code from `ptrace_setfpregs' and calling it from both places. This mostly matters to soft float configurations where the emulator can be switched this way to a mode which should not be accessible and cannot be set with the CTC1 instruction. With hard float configurations any effect is transient anyway as read-only bits will retain their values at the time the FP context is restored. Signed-off-by: Maciej W. Rozycki Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/13239/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 4f4e1ecd1053f7b6314b5e9ddcf4e79e0f9c4f7c Author: Maciej W. Rozycki Date: Thu May 12 10:18:27 2016 +0100 MIPS: ptrace: Fix FP context restoration FCSR regression commit 4249548454f7ba4581aeee26bd83f42b48a14d15 upstream. Fix a floating-point context restoration regression introduced with commit 9b26616c8d9d ("MIPS: Respect the ISA level in FCSR handling") that causes a Floating Point exception and consequently a kernel oops with hard float configurations when one or more FCSR Enable and their corresponding Cause bits are set both at a time via a ptrace(2) call. To do so reinstate Cause bit masking originally introduced with commit b1442d39fac2 ("MIPS: Prevent user from setting FCSR cause bits") to address this exact problem and then inadvertently removed from the PTRACE_SETFPREGS request with the commit referred above. Signed-off-by: Maciej W. Rozycki Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/13238/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit f06c3317c5d73eac632c9576d49228dd45c391ac Author: Paul Burton Date: Thu Apr 21 12:43:57 2016 +0100 MIPS: Disable preemption during prctl(PR_SET_FP_MODE, ...) commit bd239f1e1429e7781096bf3884bdb1b2b1bb4f28 upstream. Whilst a PR_SET_FP_MODE prctl is performed there are decisions made based upon whether the task is executing on the current CPU. This may change if we're preempted, so disable preemption to avoid such changes for the lifetime of the mode switch. Signed-off-by: Paul Burton Fixes: 9791554b45a2 ("MIPS,prctl: add PR_[GS]ET_FP_MODE prctl options for MIPS") Reviewed-by: Maciej W. Rozycki Tested-by: Aurelien Jarno Cc: Adam Buchbinder Cc: James Hogan Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/13144/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 62f517ad2dd547d1889d1e3d9cc41ee4987c223f Author: Paul Burton Date: Thu Apr 21 18:04:53 2016 +0100 MIPS: Prevent "restoration" of MSA context in non-MSA kernels commit 6533af4d4831c421cd9aa4dce7cfc19a3514cc09 upstream. If a kernel doesn't support MSA context (ie. CONFIG_CPU_HAS_MSA=n) then it will only keep 64 bits per FP register in thread context, and the calls to set_fpr64 in restore_msa_extcontext will overrun the end of the FP register context into the FCSR & MSACSR values. GCC 6.x has become smart enough to detect this & complain like so: arch/mips/kernel/signal.c: In function 'protected_restore_fp_context': ./arch/mips/include/asm/processor.h:114:17: error: array subscript is above array bounds [-Werror=array-bounds] fpr->val##width[FPR_IDX(width, idx)] = val; \ ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~ ./arch/mips/include/asm/processor.h:118:1: note: in expansion of macro 'BUILD_FPR_ACCESS' BUILD_FPR_ACCESS(64) The only way to trigger this code to run would be for a program to set up an artificial extended MSA context structure following a sigframe & execute sigreturn. Whilst this doesn't allow a program to write to any state that it couldn't already, it makes little sense to allow this "restoration" of MSA context in a system that doesn't support MSA. Fix this by killing a program with SIGSYS if it tries something as crazy as "restoring" fake MSA context in this way, also fixing the build error & allowing for most of restore_msa_extcontext to be optimised out of kernels without support for MSA. Signed-off-by: Paul Burton Reported-by: Michal Toman Fixes: bf82cb30c7e5 ("MIPS: Save MSA extended context around signals") Tested-by: Aaro Koskinen Cc: James Hogan Cc: Michal Toman Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/13164/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 5111f7713d97ff1dcd82680eed42c4f193dbd970 Author: James Hogan Date: Fri Apr 15 10:07:24 2016 +0100 MIPS: Fix MSA ld_*/st_* asm macros to use PTR_ADDU commit ea1688573426adc2587ed52d086b51c7c62eaca3 upstream. The MSA ld_*/st_* assembler macros for when the toolchain doesn't support MSA use addu to offset the base address. However it is a virtual memory pointer so fix it to use PTR_ADDU which expands to daddu for 64-bit kernels. Signed-off-by: James Hogan Cc: Paul Burton Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/13062/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 4646bac1628e6c231d83d749be36ea02659a8b32 Author: Paul Burton Date: Fri Apr 15 10:07:23 2016 +0100 MIPS: Use copy_s.fmt rather than copy_u.fmt commit 8a3c8b48aca8771bff3536e40aa26ffb311699d1 upstream. In revision 1.12 of the MSA specification, the copy_u.w instruction has been removed for MIPS32 & the copy_u.d instruction has been removed for MIPS64. Newer toolchains (eg. Codescape SDK essentials 2015.10) will complain about this like so: arch/mips/kernel/r4k_fpu.S:290: Error: opcode not supported on this processor: mips32r2 (mips32r2) `copy_u.w $1,$w26[3]' Since we always copy to the width of a GPR, simply use copy_s instead of copy_u to fix this. Signed-off-by: Paul Burton Signed-off-by: James Hogan Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/13061/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 89953062689161dd901c9b42b0b1ec5398a9d7f8 Author: Huacai Chen Date: Thu Mar 17 20:41:05 2016 +0800 MIPS: Loongson-3: Reserve 32MB for RS780E integrated GPU commit 3484de7bcbed20ecbf2b8d80671619e7059e2dd7 upstream. Due to datasheet, reserving 0xff800000~0xffffffff (8MB below 4GB) is not enough for RS780E integrated GPU's TOM (top of memory) registers and MSI/MSI-x memory region, so we reserve 0xfe000000~0xffffffff (32MB below 4GB). Signed-off-by: Huacai Chen Cc: Aurelien Jarno Cc: Steven J . Hill Cc: Fuxin Zhang Cc: Zhangjin Wu Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/12889/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit f6a93d695e33decee983a840bd1ab40968ac0096 Author: Huacai Chen Date: Thu Mar 17 20:37:10 2016 +0800 MIPS: Reserve nosave data for hibernation commit a95d069204e178f18476f5499abab0d0d9cbc32c upstream. After commit 92923ca3aacef63c92d ("mm: meminit: only set page reserved in the memblock region"), the MIPS hibernation is broken. Because pages in nosave data section should be "reserved", but currently they aren't set to "reserved" at initialization. This patch makes hibernation work again. Signed-off-by: Huacai Chen Cc: Aurelien Jarno Cc: Steven J . Hill Cc: Fuxin Zhang Cc: Zhangjin Wu Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/12888/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit f2c44e7f0344179746ac0517b05cc2f6ef9c0294 Author: Matthias Schiffer Date: Thu Mar 24 16:02:52 2016 +0100 MIPS: ath79: make bootconsole wait for both THRE and TEMT commit f5b556c94c8490d42fea79d7b4ae0ecbc291e69d upstream. This makes the ath79 bootconsole behave the same way as the generic 8250 bootconsole. Also waiting for TEMT (transmit buffer is empty) instead of just THRE (transmit buffer is not full) ensures that all characters have been transmitted before the real serial driver starts reconfiguring the serial controller (which would sometimes result in garbage being transmitted.) This change does not cause a visible performance loss. In addition, this seems to fix a hang observed in certain configurations on many AR7xxx/AR9xxx SoCs during autoconfig of the real serial driver. A more complete follow-up patch will disable 8250 autoconfig for ath79 altogether (the serial controller is detected as a 16550A, which is not fully compatible with the ath79 serial, and the autoconfig may lead to undefined behavior on ath79.) Signed-off-by: Matthias Schiffer Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 98ab3ff0938a7495f61e8db436983d8795af679f Author: Huacai Chen Date: Thu Mar 17 20:41:06 2016 +0800 MIPS: Loongson-3: Fix build error after ld-version.sh modification commit 820880cdba0137baff6cc0e828c3c418c363ae44 upstream. Commit d5ece1cb074b2c ("Fix ld-version.sh to handle large 3rd version part") modifies the ld version description. This causes a build error on Loongson-3, so fix it. Signed-off-by: Huacai Chen Cc: Aurelien Jarno Cc: Steven J . Hill Cc: Fuxin Zhang Cc: Zhangjin Wu Cc: Huacai Chen Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/12890/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit da403cc968c9a1e382aa9a7aa7d7b31a126f0974 Author: Paul Burton Date: Tue Mar 1 02:37:59 2016 +0000 MIPS: Sync icache & dcache in set_pte_at commit 37d22a0d798b5c938b277d32cfd86dc231381342 upstream. It's possible for pages to become visible prior to update_mmu_cache running if a thread within the same address space preempts the current thread or runs simultaneously on another CPU. That is, the following scenario is possible: CPU0 CPU1 write to page flush_dcache_page flush_icache_page set_pte_at map page update_mmu_cache If CPU1 maps the page in between CPU0's set_pte_at, which marks it valid & visible, and update_mmu_cache where the dcache flush occurs then CPU1s icache will fill from stale data (unless it fills from the dcache, in which case all is good, but most MIPS CPUs don't have this property). Commit 4d46a67a3eb8 ("MIPS: Fix race condition in lazy cache flushing.") attempted to fix that by performing the dcache flush in flush_icache_page such that it occurs before the set_pte_at call makes the page visible. However it has the problem that not all code that writes to pages exposed to userland call flush_icache_page. There are many callers of set_pte_at under mm/ and only 2 of them do call flush_icache_page. Thus the race window between a page becoming visible & being coherent between the icache & dcache remains open in some cases. To illustrate some of the cases, a WARN was added to __update_cache with this patch applied that triggered in cases where a page about to be flushed from the dcache was not the last page provided to flush_icache_page. That is, backtraces were obtained for cases in which the race window is left open without this patch. The 2 standout examples follow. When forking a process: [ 15.271842] [<80417630>] __update_cache+0xcc/0x188 [ 15.277274] [<80530394>] copy_page_range+0x56c/0x6ac [ 15.282861] [<8042936c>] copy_process.part.54+0xd40/0x17ac [ 15.289028] [<80429f80>] do_fork+0xe4/0x420 [ 15.293747] [<80413808>] handle_sys+0x128/0x14c When exec'ing an ELF binary: [ 14.445964] [<80417630>] __update_cache+0xcc/0x188 [ 14.451369] [<80538d88>] move_page_tables+0x414/0x498 [ 14.457075] [<8055d848>] setup_arg_pages+0x220/0x318 [ 14.462685] [<805b0f38>] load_elf_binary+0x530/0x12a0 [ 14.468374] [<8055ec3c>] search_binary_handler+0xbc/0x214 [ 14.474444] [<8055f6c0>] do_execveat_common+0x43c/0x67c [ 14.480324] [<8055f938>] do_execve+0x38/0x44 [ 14.485137] [<80413808>] handle_sys+0x128/0x14c These code paths write into a page, call flush_dcache_page then call set_pte_at without flush_icache_page inbetween. The end result is that the icache can become corrupted & userland processes may execute unexpected or invalid code, typically resulting in a reserved instruction exception, a trap or a segfault. Fix this race condition fully by performing any cache maintenance required to keep the icache & dcache in sync in set_pte_at, before the page is made valid. This has the added bonus of ensuring the cache maintenance always happens in one location, rather than being duplicated in flush_icache_page & update_mmu_cache. It also matches the way other architectures solve the same problem (see arm, ia64 & powerpc). Signed-off-by: Paul Burton Reported-by: Ionela Voinescu Cc: Lars Persson Fixes: 4d46a67a3eb8 ("MIPS: Fix race condition in lazy cache flushing.") Cc: Steven J. Hill Cc: David Daney Cc: Huacai Chen Cc: Aneesh Kumar K.V Cc: Andrew Morton Cc: Jerome Marchand Cc: Kirill A. Shutemov Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/12722/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit f8d3e12ae760ff9e6e68b7ad588f86b362c8890d Author: Paul Burton Date: Tue Mar 1 02:37:58 2016 +0000 MIPS: Handle highmem pages in __update_cache commit f4281bba818105c7c91799abe40bc05c0dbdaa25 upstream. The following patch will expose __update_cache to highmem pages. Handle them by mapping them in for the duration of the cache maintenance, just like in __flush_dcache_page. The code for that isn't shared because we need the page address in __update_cache so sharing became messy. Given that the entirity is an extra 5 lines, just duplicate it. Signed-off-by: Paul Burton Cc: Lars Persson Cc: Andrew Morton Cc: Jerome Marchand Cc: Kirill A. Shutemov Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/12721/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 32808b8d9581e639bb1774f89091a54a34ea012d Author: Paul Burton Date: Tue Mar 1 02:37:57 2016 +0000 MIPS: Flush highmem pages in __flush_dcache_page commit 234859e49a15323cf1b2331bdde7f658c4cb45fb upstream. When flush_dcache_page is called on an executable page, that page is about to be provided to userland & we can presume that the icache contains no valid entries for its address range. However if the icache does not fill from the dcache then we cannot presume that the pages content has been written back as far as the memories that the dcache will fill from (ie. L2 or further out). This was being done for lowmem pages, but not for highmem which can lead to icache corruption. Fix this by mapping highmem pages & flushing their content from the dcache in __flush_dcache_page before providing the page to userland, just as is done for lowmem pages. Signed-off-by: Paul Burton Cc: Lars Persson Cc: Andrew Morton Cc: Kirill A. Shutemov Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/12720/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 0696548022f6734d02b4b0551593a9aa0ad6ce91 Author: James Hogan Date: Tue Mar 1 22:19:36 2016 +0000 MIPS: Fix watchpoint restoration commit a7e89326b415b5d81c4b1016fd4a40db861eb58d upstream. Commit f51246efee2b ("MIPS: Get rid of finish_arch_switch().") moved the __restore_watch() call from finish_arch_switch() (i.e. after resume() returns) to before the resume() call in switch_to(). This results in watchpoints only being restored when a task is descheduled, preventing the watchpoints from being effective most of the time, except due to chance before the watchpoints are lazily removed. Fix the call sequence from switch_to() through to mips_install_watch_registers() to pass the task_struct pointer of the next task, instead of using current. This allows the watchpoints for the next (non-current) task to be restored without reintroducing finish_arch_switch(). Fixes: f51246efee2b ("MIPS: Get rid of finish_arch_switch().") Signed-off-by: James Hogan Cc: Paul Burton Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/12726/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit d8d515290ae3a5fc15a6d17dbd3ec28b33994ec5 Author: James Hogan Date: Mon Feb 8 18:43:51 2016 +0000 MIPS: Fix uapi include in exported asm/siginfo.h commit 987e5b834467c9251ca584febda65ef8f66351a9 upstream. Since commit 8cb48fe169dd ("MIPS: Provide correct siginfo_t.si_stime"), MIPS' uapi/asm/siginfo.h has included uapi/asm-generic/siginfo.h directly before defining MIPS' struct siginfo, in order to get the necessary definitions needed for the siginfo struct without the generic copy_siginfo() hitting compiler errors due to struct siginfo not yet being defined. Now that the generic copy_siginfo() is moved out to linux/signal.h we can safely include asm-generic/siginfo.h before defining the MIPS specific struct siginfo, which avoids the uapi/ include as well as breakage due to generic copy_siginfo() being defined before struct siginfo. Reported-by: Christopher Ferris Fixes: 8cb48fe169dd ("MIPS: Provide correct siginfo_t.si_stime") Signed-off-by: James Hogan Cc: Petr Malat Cc: linux-mips@linux-mips.org Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 5b7dc1c078a1e8fc601f5dc45347cfdeffc1f168 Author: James Hogan Date: Mon Feb 8 18:43:49 2016 +0000 MIPS: Fix siginfo.h to use strict posix types commit 5daebc477da4dfeb31ae193d83084def58fd2697 upstream. Commit 85efde6f4e0d ("make exported headers use strict posix types") changed the asm-generic siginfo.h to use the __kernel_* types, and commit 3a471cbc081b ("remove __KERNEL_STRICT_NAMES") make the internal types accessible only to the kernel, but the MIPS implementation hasn't been updated to match. Switch to proper types now so that the exported asm/siginfo.h won't produce quite so many compiler errors when included alone by a user program. Signed-off-by: James Hogan Cc: Christopher Ferris Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/12477/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit fb3a1a14326b6ea1e962006250ba2484c864c2af Author: James Hogan Date: Fri Dec 4 22:25:02 2015 +0000 MIPS: Avoid using unwind_stack() with usermode commit 81a76d7119f63c359750e4adeff922a31ad1135f upstream. When showing backtraces in response to traps, for example crashes and address errors (usually unaligned accesses) when they are set in debugfs to be reported, unwind_stack will be used if the PC was in the kernel text address range. However since EVA it is possible for user and kernel address ranges to overlap, and even without EVA userland can still trigger an address error by jumping to a KSeg0 address. Adjust the check to also ensure that it was running in kernel mode. I don't believe any harm can come of this problem, since unwind_stack() is sufficiently defensive, however it is only meant for unwinding kernel code, so to be correct it should use the raw backtracing instead. Signed-off-by: James Hogan Reviewed-by: Leonid Yegoshin Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/11701/ Signed-off-by: Ralf Baechle (cherry picked from commit d2941a975ac745c607dfb590e92bb30bc352dad9) Signed-off-by: Greg Kroah-Hartman commit 75050bb1b75f82bd7cd92ddf1222703d29512304 Author: James Hogan Date: Fri Dec 4 22:25:01 2015 +0000 MIPS: Don't unwind to user mode with EVA commit a816b306c62195b7c43c92cb13330821a96bdc27 upstream. When unwinding through IRQs and exceptions, the unwinding only continues if the PC is a kernel text address, however since EVA it is possible for user and kernel address ranges to overlap, potentially allowing unwinding to continue to user mode if the user PC happens to be in the kernel text address range. Adjust the check to also ensure that the register state from before the exception is actually running in kernel mode, i.e. !user_mode(regs). I don't believe any harm can come of this problem, since the PC is only output, the stack pointer is checked to ensure it resides within the task's stack page before it is dereferenced in search of the return address, and the return address register is similarly only output (if the PC is in a leaf function or the beginning of a non-leaf function). However unwind_stack() is only meant for unwinding kernel code, so to be correct the unwind should stop there. Signed-off-by: James Hogan Reviewed-by: Leonid Yegoshin Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/11700/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 65a0186ec096277482716be7c4329c514f2925c1 Author: Maciej W. Rozycki Date: Tue May 17 06:12:27 2016 +0100 MIPS: MSA: Fix a link error on `_init_msa_upper' with older GCC commit e49d38488515057dba8f0c2ba4cfde5be4a7281f upstream. Fix a build regression from commit c9017757c532 ("MIPS: init upper 64b of vector registers when MSA is first used"): arch/mips/built-in.o: In function `enable_restore_fp_context': traps.c:(.text+0xbb90): undefined reference to `_init_msa_upper' traps.c:(.text+0xbb90): relocation truncated to fit: R_MIPS_26 against `_init_msa_upper' traps.c:(.text+0xbef0): undefined reference to `_init_msa_upper' traps.c:(.text+0xbef0): relocation truncated to fit: R_MIPS_26 against `_init_msa_upper' to !CONFIG_CPU_HAS_MSA configurations with older GCC versions, which are unable to figure out that calls to `_init_msa_upper' are indeed dead. Of the many ways to tackle this failure choose the approach we have already taken in `thread_msa_context_live'. [ralf@linux-mips.org: Drop patch segment to junk file.] Signed-off-by: Maciej W. Rozycki Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/13271/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 555e302e907fe98a2600d25031a9a05b3b5907d3 Author: Paul Burton Date: Thu Apr 21 14:04:55 2016 +0100 MIPS: math-emu: Fix jalr emulation when rd == $0 commit ab4a92e66741b35ca12f8497896bafbe579c28a1 upstream. When emulating a jalr instruction with rd == $0, the code in isBranchInstr was incorrectly writing to GPR $0 which should actually always remain zeroed. This would lead to any further instructions emulated which use $0 operating on a bogus value until the task is next context switched, at which point the value of $0 in the task context would be restored to the correct zero by a store in SAVE_SOME. Fix this by not writing to rd if it is $0. Fixes: 102cedc32a6e ("MIPS: microMIPS: Floating point support.") Signed-off-by: Paul Burton Cc: Maciej W. Rozycki Cc: James Hogan Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/13160/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 3cef3b3d25da5e828e25ba5ea9638a0d775cbe63 Author: Leonid Yegoshin Date: Tue Apr 28 12:53:35 2015 -0700 MIPS64: R6: R2 emulation bugfix commit 41fa29e4d8cf4150568a0fe9bb4d62229f9caed5 upstream. Error recovery pointers for fixups was improperly set as ".word" which is unsuitable for MIPS64. Replaced by STR(PTR) [ralf@linux-mips.org: Apply changes as requested in the review process.] Signed-off-by: Leonid Yegoshin Reviewed-by: James Hogan Reviewed-by: Markos Chandras Fixes: b0a668fb2038 ("MIPS: kernel: mips-r2-to-r6-emul: Add R2 emulator for MIPS R6") Cc: macro@linux-mips.org Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/9911/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman