commit ba760d4302e4fce130007b8bdbce7fcafc9bd9a9 Author: Greg Kroah-Hartman Date: Tue Jun 7 18:14:51 2016 -0700 Linux 4.4.13 commit 55f6ddfceef32eb9d7174ad5a74e473ef76cfe3b Author: Dave Chinner Date: Tue Jan 12 07:04:01 2016 +1100 xfs: handle dquot buffer readahead in log recovery correctly commit 7d6a13f023567d573ac362502bb702eda716e654 upstream. When we do dquot readahead in log recovery, we do not use a verifier as the underlying buffer may not have dquots in it. e.g. the allocation operation hasn't yet been replayed. Hence we do not want to fail recovery because we detect an operation to be replayed has not been run yet. This problem was addressed for inodes in commit d891400 ("xfs: inode buffers may not be valid during recovery readahead") but the problem was not recognised to exist for dquots and their buffers as the dquot readahead did not have a verifier. The result of not using a verifier is that when the buffer is then next read to replay a dquot modification, the dquot buffer verifier will only be attached to the buffer if *readahead is not complete*. Hence we can read the buffer, replay the dquot changes and then add it to the delwri submission list without it having a verifier attached to it. This then generates warnings in xfs_buf_ioapply(), which catches and warns about this case. Fix this and make it handle the same readahead verifier error cases as for inode buffers by adding a new readahead verifier that has a write operation as well as a read operation that marks the buffer as not done if any corruption is detected. Also make sure we don't run readahead if the dquot buffer has been marked as cancelled by recovery. This will result in readahead either succeeding and the buffer having a valid write verifier, or readahead failing and the buffer state requiring the subsequent read to resubmit the IO with the new verifier. In either case, this will result in the buffer always ending up with a valid write verifier on it. Note: we also need to fix the inode buffer readahead error handling to mark the buffer with EIO. Brian noticed the code I copied from there wrong during review, so fix it at the same time. Add comments linking the two functions that handle readahead verifier errors together so we don't forget this behavioural link in future. Signed-off-by: Dave Chinner Reviewed-by: Brian Foster Signed-off-by: Dave Chinner Signed-off-by: Greg Kroah-Hartman commit 063b0dc8b46e56efa480bc2640fe01024f709482 Author: Eric Sandeen Date: Mon Jan 4 16:10:19 2016 +1100 xfs: print name of verifier if it fails commit 233135b763db7c64d07b728a9c66745fb0376275 upstream. This adds a name to each buf_ops structure, so that if a verifier fails we can print the type of verifier that failed it. Should be a slight debugging aid, I hope. Signed-off-by: Eric Sandeen Reviewed-by: Brian Foster Signed-off-by: Dave Chinner Cc: Holger Hoffstätte Signed-off-by: Greg Kroah-Hartman commit 21cfd6cc64f531fa2d96eaa7b816af4ed7428227 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 baa7a74d6df5e67d62045ad6d7dbe1942bbbbefe 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 7dc8f21bd5afbabb086891b3a9d0930883bed793 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 d7d92ca7dd363153407b19c749ce9a9ea1f46fcb 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 ec86bfec23e3e5d92ac5e6242f074c92f127d6ef 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 8edc7f04694d0fd243425e65299ee6ec10259b4f 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 4b2fb17654ef0ffd08b92293a09c5ead0499e2ef 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 7d0b494532b703da654f96389804f491a6594bbb 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 98c28450538d0a191d031cce8852e568b62a1127 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 8b8de1c9295cafcc9a9b85b3287acac7d948fb63 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 12aa7d95f4882d21cd337d4f6fd40859cac67688 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 b2601bb015a7681fb44bd7a2f15760b2396d0de7 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 b2044c3f8310ccac10122f2fa64f8ae574b4bfef 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 c5ce389844f2686564e1217c94c4c3e92fab413d 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 137bd12493e76f610aa56cee1e63e70b3707f6d8 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 d7d5e9bed91c75e765f9219a58199ce9bf5e3db3 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 8453324b7f4968ad2ebd90c9831c05f9801d92c3 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 c5b424e7fd4204a16a0884c2e544ff14083cd5bd 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 c0217001bc050076131309291ec81310a0146e30 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 4630a1d74d0a3cc76573fc43fb7c7009265c035a 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 bf9be90437e6f2a6079b9a00619ba58906997f56 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 55d851a914b51e79b33e52dabef18fe22ea80a46 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 c170833402b26fcbaa783bb044b11398724bd388 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 267706b9c5bacb58aacf631b8cc5b7ec0e8cab22 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 50dd02e72b9792a22d39bf73b6d2490451f14f9b 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 6c1e441c3b16d417dc29397c5b88d978d4e7c414 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 aa1cc4d4753f56f85c3df65a574d8fdb5823c243 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 6232876e14a5a7fc0b0449a740bda8ffe2ed59ed 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 0118086d556d96f85ecc5455016ed1f447267bda 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 af64f74e5f72903de2ce891bde1386a6d3be712c 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 d140d14201f8a0e5a0d3b690ebb346f380e60386 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 5d3bb5e616bc03dfb963ddff665023564fbcc8e8 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 fa6d0ba12a8eb6a2e9a1646c5816da307c1f93a7 Author: Willy Tarreau Date: Mon Jan 18 16:36:09 2016 +0100 pipe: limit the per-user amount of pages allocated in pipes commit 759c01142a5d0f364a462346168a56de28a80f52 upstream. On no-so-small systems, it is possible for a single process to cause an OOM condition by filling large pipes with data that are never read. A typical process filling 4000 pipes with 1 MB of data will use 4 GB of memory. On small systems it may be tricky to set the pipe max size to prevent this from happening. This patch makes it possible to enforce a per-user soft limit above which new pipes will be limited to a single page, effectively limiting them to 4 kB each, as well as a hard limit above which no new pipes may be created for this user. This has the effect of protecting the system against memory abuse without hurting other users, and still allowing pipes to work correctly though with less data at once. The limit are controlled by two new sysctls : pipe-user-pages-soft, and pipe-user-pages-hard. Both may be disabled by setting them to zero. The default soft limit allows the default number of FDs per process (1024) to create pipes of the default size (64kB), thus reaching a limit of 64MB before starting to create only smaller pipes. With 256 processes limited to 1024 FDs each, this results in 1024*64kB + (256*1024 - 1024) * 4kB = 1084 MB of memory allocated for a user. The hard limit is disabled by default to avoid breaking existing applications that make intensive use of pipes (eg: for splicing). Reported-by: socketpair@gmail.com Reported-by: Tetsuo Handa Mitigates: CVE-2013-4312 (Linux 2.0+) Suggested-by: Linus Torvalds Signed-off-by: Willy Tarreau Signed-off-by: Al Viro Cc: Moritz Muehlenhoff Signed-off-by: Greg Kroah-Hartman commit 5015641d2152f0fdb328d45d517db95be5485edc 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 0eea2e24fc600fa20d357e022ef29029140bb714 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 18875bf7728d25dec9bce7966c2fe4fefd5d00bc 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 08c6a55e79c3e83a69b7e59f55f2307708eb706e 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 a87f69dceff5c93a7d8f70f2cb255e1fcbda83bb 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 f4b0dd357f31c3f794ebb171a4ed903c0eee4565 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 b2cfbf421062a4f27801d6771dfd83c1cd894342 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 3232e7c4db4fd966b30ceec24ed9f37277a81c61 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 4ee87930e4e26a1f873086ab24d53b946787c63f 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 d5298429006ed65ad676f3b7ade0b52fd712dea7 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 dd1917666c6d13f1bdb34ef4647205e732df06d1 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 3b2321716df07e7a61fdc8a7e54d2a85c878d758 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 a1e15f5ae6d69e834b751b719d007b380f4a42fb 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 4072a4bcd24f2b07eb1b6dfc2a2e7fac4c501114 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 d306f756f8c63ea820af01ecf27e089f3118a00a 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 b8562066d4819ee23d3f8da2fa5e9160bf854835 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 9a11bd2d14ad54e92170cdc9c2e2f278305929c1 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 0f0a9a1866754cc025030789bb4928d8b50cc5e5 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 9a5ca989b54975b40915bc6fa5c909cf11f90c62 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 04a6bcca2f76f7aa5b8749644e3a2947a3cf040d 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 d896d805dbf5ebf6814c4e84d5321a8169304b19 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 ad4d53046e1d131de921176d49cf805744089a0c 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 5618e882939a08f5733743ec5c296fa5254dc110 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 c56cebbe83dde1c93599eb29d85d5c889d7a00cf 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 ab1619f4f94b908bfa33ef7eb505c50955741eb4 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 dcd9fc92f1453d1f61279f2352d093bd8ce324cd 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 117d1b454bf5b8e66bc4ebfc50437977a52b0ce5 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 86834a9133bb79a5dc078539385984a5afae014f 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 b89721d70e1cce49e4f503ad9df765a02fb60cd8 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 354c6bccfc258851f7a6c9287f4e98a832feef22 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 cc2e71f0b16f309b11b0fcdfd934ea2e4d0db13b 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 670664734da1f96f7d8525a91cd71a4c21db460f 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 59bc5bedbd712003945e6d6bbef0aba5bb4603dc 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 5d03c6ea151f5a4f5c0189bceddc10badf4cb54d 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 90756ca854623b5f2bbcd4447b420ba46ee9cda1 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 854d1c275baea33efabec4daf97f7d662cad6505 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 8f1b5ede037a9c704283e3ac31f161523885dacc 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 91bb3cf4785d545074689f481ff1a0bd5322d45b 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 71f5e9b77853dc80ed1b1d5b8428f0e10b3ae1d3 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 7b74228bb0815412ed2735b379113ee386179766 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 bfcc040a885bc182ad950cc45b00d0e1367a7284 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 1985bf8d711a562dd143be05f05707333fbf7c7b 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 13defedff19cae72e2b88a120c03792b3610bb06 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 e47a4d4f11421b5725cba669bfef200bdc49564d 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 57a94749251c3a5ce07b237a16723be8ea01b1ac 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 6dc9f27c09cf380f70505c08bcd805e4495ab4f8 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 612d5094624df41eb4cd83a8594836836e1041cd 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 73410f3b164cd436aaaf6a1944aab4892d7b92f2 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 1a01c8c418772bc87a182126e16eba8400eaf46a 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 f2c41222fc75e84b2f0337b673b31ae7e1bd6fd7 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 969f0f69e8d0c4b2706c9c31589c2ac39806dafd 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 6a0538541547a6513126f947b4417ff6ee8a9316 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 a8c09ec300b6bdfae69d03fd047848f8d34421e8 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 a3dc327c1f5ccbe64d998f5e44926c967afd8a30 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 68d64569ff9568752eee68ee2fceaf68725834e9 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 d59a1b85d6b7d16485f5362077e2ed9a5c9022cd 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 df27ff8678252b751e6bc2ea8835e58eb43b8e30 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 fdb691ea15b53da6854b8820df96926eb199ad2c 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 a8389fdf397f4c591372b13b9caa1eec4bb2b09c 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 5fc0cab84d045bc5c1a3174e546fb3c8e529150a 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 982db881156d3e1c97f2a247c17f15e25d2afeef 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 a08eb4c2f58a21135c28c55796a7bda426103ade 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