commit db2d0b7c1dde59b93045a6d011f392fb04b276af Author: Greg Kroah-Hartman Date: Mon Sep 16 08:22:25 2019 +0200 Linux 4.19.73 commit ba03ee62aed0b0ee2eadfeb4a2fecc7d7eb47871 Author: yongduan Date: Wed Sep 11 17:44:24 2019 +0800 vhost: make sure log_num < in_num commit 060423bfdee3f8bc6e2c1bac97de24d5415e2bc4 upstream. The code assumes log_num < in_num everywhere, and that is true as long as in_num is incremented by descriptor iov count, and log_num by 1. However this breaks if there's a zero sized descriptor. As a result, if a malicious guest creates a vring desc with desc.len = 0, it may cause the host kernel to crash by overflowing the log array. This bug can be triggered during the VM migration. There's no need to log when desc.len = 0, so just don't increment log_num in this case. Fixes: 3a4d5c94e959 ("vhost_net: a kernel-level virtio server") Cc: stable@vger.kernel.org Reviewed-by: Lidong Chen Signed-off-by: ruippan Signed-off-by: yongduan Acked-by: Michael S. Tsirkin Reviewed-by: Tyler Hicks Signed-off-by: Michael S. Tsirkin Signed-off-by: Greg Kroah-Hartman commit 569775bd536416ed9049aa580d9f89a0b4307d60 Author: Gustavo Romero Date: Wed Sep 4 00:55:28 2019 -0400 powerpc/tm: Fix restoring FP/VMX facility incorrectly on interrupts [ Upstream commit a8318c13e79badb92bc6640704a64cc022a6eb97 ] When in userspace and MSR FP=0 the hardware FP state is unrelated to the current process. This is extended for transactions where if tbegin is run with FP=0, the hardware checkpoint FP state will also be unrelated to the current process. Due to this, we need to ensure this hardware checkpoint is updated with the correct state before we enable FP for this process. Unfortunately we get this wrong when returning to a process from a hardware interrupt. A process that starts a transaction with FP=0 can take an interrupt. When the kernel returns back to that process, we change to FP=1 but with hardware checkpoint FP state not updated. If this transaction is then rolled back, the FP registers now contain the wrong state. The process looks like this: Userspace: Kernel Start userspace with MSR FP=0 TM=1 < ----- ... tbegin bne Hardware interrupt ---- > .... ret_from_except restore_math() /* sees FP=0 */ restore_fp() tm_active_with_fp() /* sees FP=1 (Incorrect) */ load_fp_state() FP = 0 -> 1 < ----- Return to userspace with MSR TM=1 FP=1 with junk in the FP TM checkpoint TM rollback reads FP junk When returning from the hardware exception, tm_active_with_fp() is incorrectly making restore_fp() call load_fp_state() which is setting FP=1. The fix is to remove tm_active_with_fp(). tm_active_with_fp() is attempting to handle the case where FP state has been changed inside a transaction. In this case the checkpointed and transactional FP state is different and hence we must restore the FP state (ie. we can't do lazy FP restore inside a transaction that's used FP). It's safe to remove tm_active_with_fp() as this case is handled by restore_tm_state(). restore_tm_state() detects if FP has been using inside a transaction and will set load_fp and call restore_math() to ensure the FP state (checkpoint and transaction) is restored. This is a data integrity problem for the current process as the FP registers are corrupted. It's also a security problem as the FP registers from one process may be leaked to another. Similarly for VMX. A simple testcase to replicate this will be posted to tools/testing/selftests/powerpc/tm/tm-poison.c This fixes CVE-2019-15031. Fixes: a7771176b439 ("powerpc: Don't enable FP/Altivec if not checkpointed") Cc: stable@vger.kernel.org # 4.15+ Signed-off-by: Gustavo Romero Signed-off-by: Michael Neuling Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20190904045529.23002-2-gromero@linux.vnet.ibm.com Signed-off-by: Sasha Levin commit 052bc385f97054973c0140c474e6d5de624130c8 Author: Breno Leitao Date: Thu Aug 16 14:21:07 2018 -0300 powerpc/tm: Remove msr_tm_active() [ Upstream commit 5c784c8414fba11b62e12439f11e109fb5751f38 ] Currently msr_tm_active() is a wrapper around MSR_TM_ACTIVE() if CONFIG_PPC_TRANSACTIONAL_MEM is set, or it is just a function that returns false if CONFIG_PPC_TRANSACTIONAL_MEM is not set. This function is not necessary, since MSR_TM_ACTIVE() just do the same and could be used, removing the dualism and simplifying the code. This patchset remove every instance of msr_tm_active() and replaced it by MSR_TM_ACTIVE(). Signed-off-by: Breno Leitao Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit f193e02265aacc1a9f49b1ab27dbd63974266cee Author: Lyude Paul Date: Thu Aug 1 18:01:17 2019 -0400 PCI: Reset both NVIDIA GPU and HDA in ThinkPad P50 workaround [ Upstream commit ad54567ad5d8e938ee6cf02e4f3867f18835ae6e ] quirk_reset_lenovo_thinkpad_50_nvgpu() resets NVIDIA GPUs to work around an apparent BIOS defect. It previously used pci_reset_function(), and the available method was a bus reset, which was fine because there was only one function on the bus. After b516ea586d71 ("PCI: Enable NVIDIA HDA controllers"), there are now two functions (the HDA controller and the GPU itself) on the bus, so the reset fails. Use pci_reset_bus() explicitly instead of pci_reset_function() since it's OK to reset both devices. [bhelgaas: commit log, add e0547c81bfcf] Fixes: b516ea586d71 ("PCI: Enable NVIDIA HDA controllers") Fixes: e0547c81bfcf ("PCI: Reset Lenovo ThinkPad P50 nvgpu at boot if necessary") Link: https://lore.kernel.org/r/20190801220117.14952-1-lyude@redhat.com Signed-off-by: Lyude Paul Signed-off-by: Bjorn Helgaas Acked-by: Ben Skeggs Cc: Lukas Wunner Cc: Daniel Drake Cc: Aaron Plattner Cc: Peter Wu Cc: Ilia Mirkin Cc: Karol Herbst Cc: Maik Freudenberg Signed-off-by: Sasha Levin commit ff69322509bb3f48c4e08cc3bef7c414519a7862 Author: Colin Ian King Date: Fri May 10 22:06:38 2019 -0400 ext4: unsigned int compared against zero [ Upstream commit fbbbbd2f28aec991f3fbc248df211550fbdfd58c ] There are two cases where u32 variables n and err are being checked for less than zero error values, the checks is always false because the variables are not signed. Fix this by making the variables ints. Addresses-Coverity: ("Unsigned compared against 0") Fixes: 345c0dbf3a30 ("ext4: protect journal inode's blocks using block_validity") Signed-off-by: Colin Ian King Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 292666d2d868f30a55f6d5f15c5a1a16a38a99c5 Author: Theodore Ts'o Date: Wed May 15 00:51:19 2019 -0400 ext4: fix block validity checks for journal inodes using indirect blocks [ Upstream commit 170417c8c7bb2cbbdd949bf5c443c0c8f24a203b ] Commit 345c0dbf3a30 ("ext4: protect journal inode's blocks using block_validity") failed to add an exception for the journal inode in ext4_check_blockref(), which is the function used by ext4_get_branch() for indirect blocks. This caused attempts to read from the ext3-style journals to fail with: [ 848.968550] EXT4-fs error (device sdb7): ext4_get_branch:171: inode #8: block 30343695: comm jbd2/sdb7-8: invalid block Fix this by adding the missing exception check. Fixes: 345c0dbf3a30 ("ext4: protect journal inode's blocks using block_validity") Reported-by: Arthur Marsh Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 97fbf573460e56ddf172614f70cdfa2af03b20ea Author: Theodore Ts'o Date: Wed May 22 10:27:01 2019 -0400 ext4: don't perform block validity checks on the journal inode [ Upstream commit 0a944e8a6c66ca04c7afbaa17e22bf208a8b37f0 ] Since the journal inode is already checked when we added it to the block validity's system zone, if we check it again, we'll just trigger a failure. This was causing failures like this: [ 53.897001] EXT4-fs error (device sda): ext4_find_extent:909: inode #8: comm jbd2/sda-8: pblk 121667583 bad header/extent: invalid extent entries - magic f30a, entries 8, max 340(340), depth 0(0) [ 53.931430] jbd2_journal_bmap: journal block not found at offset 49 on sda-8 [ 53.938480] Aborting journal on device sda-8. ... but only if the system was under enough memory pressure that logical->physical mapping for the journal inode gets pushed out of the extent cache. (This is why it wasn't noticed earlier.) Fixes: 345c0dbf3a30 ("ext4: protect journal inode's blocks using block_validity") Reported-by: Dan Rue Signed-off-by: Theodore Ts'o Tested-by: Naresh Kamboju Signed-off-by: Sasha Levin commit 1e88a1f874ca5c5c449dd1580c02aaeda60b6485 Author: Lyude Paul Date: Tue Oct 9 16:44:24 2018 -0400 drm/atomic_helper: Allow DPMS On<->Off changes for unregistered connectors [ Upstream commit 34ca26a98ad67edd6e4870fe2d4aa047d41a51dd ] It appears when testing my previous fix for some of the legacy modesetting issues with MST, I misattributed some kernel splats that started appearing on my machine after a rebase as being from upstream. But it appears they actually came from my patch series: [ 2.980512] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] Updating routing for [CONNECTOR:65:eDP-1] [ 2.980516] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] [CONNECTOR:65:eDP-1] is not registered [ 2.980516] ------------[ cut here ]------------ [ 2.980519] Could not determine valid watermarks for inherited state [ 2.980553] WARNING: CPU: 3 PID: 551 at drivers/gpu/drm/i915/intel_display.c:14983 intel_modeset_init+0x14d7/0x19f0 [i915] [ 2.980556] Modules linked in: i915(O+) i2c_algo_bit drm_kms_helper(O) syscopyarea sysfillrect sysimgblt fb_sys_fops drm(O) intel_rapl x86_pkg_temp_thermal iTCO_wdt wmi_bmof coretemp crc32_pclmul psmouse i2c_i801 mei_me mei i2c_core lpc_ich mfd_core tpm_tis tpm_tis_core wmi tpm thinkpad_acpi pcc_cpufreq video ehci_pci crc32c_intel serio_raw ehci_hcd xhci_pci xhci_hcd [ 2.980577] CPU: 3 PID: 551 Comm: systemd-udevd Tainted: G O 4.19.0-rc7Lyude-Test+ #1 [ 2.980579] Hardware name: LENOVO 20BWS1KY00/20BWS1KY00, BIOS JBET63WW (1.27 ) 11/10/2016 [ 2.980605] RIP: 0010:intel_modeset_init+0x14d7/0x19f0 [i915] [ 2.980607] Code: 89 df e8 ec 27 02 00 e9 24 f2 ff ff be 03 00 00 00 48 89 df e8 da 27 02 00 e9 26 f2 ff ff 48 c7 c7 c8 d1 34 a0 e8 23 cf dc e0 <0f> 0b e9 7c fd ff ff f6 c4 04 0f 85 37 f7 ff ff 48 8b 83 60 08 00 [ 2.980611] RSP: 0018:ffffc90000287988 EFLAGS: 00010282 [ 2.980614] RAX: 0000000000000000 RBX: ffff88031b488000 RCX: 0000000000000006 [ 2.980617] RDX: 0000000000000007 RSI: 0000000000000086 RDI: ffff880321ad54d0 [ 2.980620] RBP: ffffc90000287a10 R08: 000000000000040a R09: 0000000000000065 [ 2.980623] R10: ffff88030ebb8f00 R11: ffffffff81416590 R12: ffff88031b488000 [ 2.980626] R13: ffff88031b4883a0 R14: ffffc900002879a8 R15: ffff880319099800 [ 2.980630] FS: 00007f475620d180(0000) GS:ffff880321ac0000(0000) knlGS:0000000000000000 [ 2.980633] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 2.980636] CR2: 00007f9ef28018a0 CR3: 000000031b72c001 CR4: 00000000003606e0 [ 2.980639] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 2.980642] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 2.980645] Call Trace: [ 2.980675] i915_driver_load+0xb0e/0xdc0 [i915] [ 2.980681] ? kernfs_add_one+0xe7/0x130 [ 2.980709] i915_pci_probe+0x46/0x60 [i915] [ 2.980715] pci_device_probe+0xd4/0x150 [ 2.980719] really_probe+0x243/0x3b0 [ 2.980722] driver_probe_device+0xba/0x100 [ 2.980726] __driver_attach+0xe4/0x110 [ 2.980729] ? driver_probe_device+0x100/0x100 [ 2.980733] bus_for_each_dev+0x74/0xb0 [ 2.980736] driver_attach+0x1e/0x20 [ 2.980739] bus_add_driver+0x159/0x230 [ 2.980743] ? 0xffffffffa0393000 [ 2.980746] driver_register+0x70/0xc0 [ 2.980749] ? 0xffffffffa0393000 [ 2.980753] __pci_register_driver+0x57/0x60 [ 2.980780] i915_init+0x55/0x58 [i915] [ 2.980785] do_one_initcall+0x4a/0x1c4 [ 2.980789] ? do_init_module+0x27/0x210 [ 2.980793] ? kmem_cache_alloc_trace+0x131/0x190 [ 2.980797] do_init_module+0x60/0x210 [ 2.980800] load_module+0x2063/0x22e0 [ 2.980804] ? vfs_read+0x116/0x140 [ 2.980807] ? vfs_read+0x116/0x140 [ 2.980811] __do_sys_finit_module+0xbd/0x120 [ 2.980814] ? __do_sys_finit_module+0xbd/0x120 [ 2.980818] __x64_sys_finit_module+0x1a/0x20 [ 2.980821] do_syscall_64+0x5a/0x110 [ 2.980824] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 2.980826] RIP: 0033:0x7f4754e32879 [ 2.980828] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d f7 45 2c 00 f7 d8 64 89 01 48 [ 2.980831] RSP: 002b:00007fff43fd97d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [ 2.980834] RAX: ffffffffffffffda RBX: 0000559a44ca64f0 RCX: 00007f4754e32879 [ 2.980836] RDX: 0000000000000000 RSI: 00007f475599f4cd RDI: 0000000000000018 [ 2.980838] RBP: 00007f475599f4cd R08: 0000000000000000 R09: 0000000000000000 [ 2.980839] R10: 0000000000000018 R11: 0000000000000246 R12: 0000000000000000 [ 2.980841] R13: 0000559a44c92fd0 R14: 0000000000020000 R15: 0000000000000000 [ 2.980881] WARNING: CPU: 3 PID: 551 at drivers/gpu/drm/i915/intel_display.c:14983 intel_modeset_init+0x14d7/0x19f0 [i915] [ 2.980884] ---[ end trace 5eb47a76277d4731 ]--- The cause of this appears to be due to the fact that if there's pre-existing display state that was set by the BIOS when i915 loads, it will attempt to perform a modeset before the driver is registered with userspace. Since this happens before the driver's registered with userspace, it's connectors are also unregistered and thus-states which would turn on DPMS on a connector end up getting rejected since the connector isn't registered. These bugs managed to get past Intel's CI partially due to the fact it never ran a full test on my patches for some reason, but also because all of the tests unload the GPU once before running. Since this bug is only really triggered when the drivers tries to perform a modeset before it's been fully registered with userspace when coming from whatever display configuration the firmware left us with, it likely would never have been picked up by CI in the first place. After some discussion with vsyrjala, we decided the best course of action would be to just move the unregistered connector checks out of update_connector_routing() and into drm_atomic_set_crtc_for_connector(). The reason for this being that legacy modesetting isn't going to be expecting failures anywhere (at least this is the case with X), so ideally we want to ensure that any DPMS changes will still work even on unregistered connectors. Instead, we now only reject new modesets which would change the current CRTC assigned to an unregistered connector unless no new CRTC is being assigned to replace the connector's previous one. Signed-off-by: Lyude Paul Reported-by: Ville Syrjälä Fixes: 4d80273976bf ("drm/atomic_helper: Disallow new modesets on unregistered connectors") Cc: Daniel Vetter Cc: Ville Syrjälä Cc: stable@vger.kernel.org Reviewed-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20181009204424.21462-1-lyude@redhat.com (cherry picked from commit b5d29843d8ef86d4cde4742e095b81b7fd41e688) Fixes: e96550956fbc ("drm/atomic_helper: Disallow new modesets on unregistered connectors") Signed-off-by: Joonas Lahtinen Signed-off-by: Sasha Levin commit b1dd1d06b31da3cb8a535f9eeb3909e83f9ba3f5 Author: Halil Pasic Date: Tue Jul 23 17:11:01 2019 +0200 virtio/s390: fix race on airq_areas[] [ Upstream commit 4f419eb14272e0698e8c55bb5f3f266cc2a21c81 ] The access to airq_areas was racy ever since the adapter interrupts got introduced to virtio-ccw, but since commit 39c7dcb15892 ("virtio/s390: make airq summary indicators DMA") this became an issue in practice as well. Namely before that commit the airq_info that got overwritten was still functional. After that commit however the two infos share a summary_indicator, which aggravates the situation. Which means auto-online mechanism occasionally hangs the boot with virtio_blk. Signed-off-by: Halil Pasic Reported-by: Marc Hartmayer Reviewed-by: Cornelia Huck Cc: stable@vger.kernel.org Fixes: 96b14536d935 ("virtio-ccw: virtio-ccw adapter interrupt support.") Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin commit 057cdb6f0f47c643905df5557fdf9d56f46d2931 Author: Ville Syrjälä Date: Wed Jul 17 14:45:36 2019 +0300 drm/i915: Make sure cdclk is high enough for DP audio on VLV/CHV [ Upstream commit a8f196a0fa6391a436f63f360a1fb57031fdf26c ] On VLV/CHV there is some kind of linkage between the cdclk frequency and the DP link frequency. The spec says: "For DP audio configuration, cdclk frequency shall be set to meet the following requirements: DP Link Frequency(MHz) | Cdclk frequency(MHz) 270 | 320 or higher 162 | 200 or higher" I suspect that would more accurately be expressed as "cdclk >= DP link clock", and in any case we can express it like that in the code because of the limited set of cdclk (200, 266, 320, 400 MHz) and link frequencies (162 and 270 MHz) we support. Without this we can end up in a situation where the cdclk is too low and enabling DP audio will kill the pipe. Happens eg. with 2560x1440 modes where the 266MHz cdclk is sufficient to pump the pixels (241.5 MHz dotclock) but is too low for the DP audio due to the link frequency being 270 MHz. v2: Spell out the cdclk and link frequencies we actually support Cc: stable@vger.kernel.org Tested-by: Stefan Gottwald Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111149 Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20190717114536.22937-1-ville.syrjala@linux.intel.com Acked-by: Chris Wilson (cherry picked from commit bffb31f73b29a60ef693842d8744950c2819851d) Signed-off-by: Jani Nikula Signed-off-by: Sasha Levin commit b113f98432aed624fd9b80af818bd87e4db83537 Author: Coly Li Date: Fri Jun 28 19:59:58 2019 +0800 bcache: fix race in btree_flush_write() [ Upstream commit 50a260e859964002dab162513a10f91ae9d3bcd3 ] There is a race between mca_reap(), btree_node_free() and journal code btree_flush_write(), which results very rare and strange deadlock or panic and are very hard to reproduce. Let me explain how the race happens. In btree_flush_write() one btree node with oldest journal pin is selected, then it is flushed to cache device, the select-and-flush is a two steps operation. Between these two steps, there are something may happen inside the race window, - The selected btree node was reaped by mca_reap() and allocated to other requesters for other btree node. - The slected btree node was selected, flushed and released by mca shrink callback bch_mca_scan(). When btree_flush_write() tries to flush the selected btree node, firstly b->write_lock is held by mutex_lock(). If the race happens and the memory of selected btree node is allocated to other btree node, if that btree node's write_lock is held already, a deadlock very probably happens here. A worse case is the memory of the selected btree node is released, then all references to this btree node (e.g. b->write_lock) will trigger NULL pointer deference panic. This race was introduced in commit cafe56359144 ("bcache: A block layer cache"), and enlarged by commit c4dc2497d50d ("bcache: fix high CPU occupancy during journal"), which selected 128 btree nodes and flushed them one-by-one in a quite long time period. Such race is not easy to reproduce before. On a Lenovo SR650 server with 48 Xeon cores, and configure 1 NVMe SSD as cache device, a MD raid0 device assembled by 3 NVMe SSDs as backing device, this race can be observed around every 10,000 times btree_flush_write() gets called. Both deadlock and kernel panic all happened as aftermath of the race. The idea of the fix is to add a btree flag BTREE_NODE_journal_flush. It is set when selecting btree nodes, and cleared after btree nodes flushed. Then when mca_reap() selects a btree node with this bit set, this btree node will be skipped. Since mca_reap() only reaps btree node without BTREE_NODE_journal_flush flag, such race is avoided. Once corner case should be noticed, that is btree_node_free(). It might be called in some error handling code path. For example the following code piece from btree_split(), 2149 err_free2: 2150 bkey_put(b->c, &n2->key); 2151 btree_node_free(n2); 2152 rw_unlock(true, n2); 2153 err_free1: 2154 bkey_put(b->c, &n1->key); 2155 btree_node_free(n1); 2156 rw_unlock(true, n1); At line 2151 and 2155, the btree node n2 and n1 are released without mac_reap(), so BTREE_NODE_journal_flush also needs to be checked here. If btree_node_free() is called directly in such error handling path, and the selected btree node has BTREE_NODE_journal_flush bit set, just delay for 1 us and retry again. In this case this btree node won't be skipped, just retry until the BTREE_NODE_journal_flush bit cleared, and free the btree node memory. Fixes: cafe56359144 ("bcache: A block layer cache") Signed-off-by: Coly Li Reported-and-tested-by: kbuild test robot Cc: stable@vger.kernel.org Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit f73c35d9297698cb9ce03dc84eaae19e2e1cd7a7 Author: Coly Li Date: Fri Jun 28 19:59:56 2019 +0800 bcache: add comments for mutex_lock(&b->write_lock) [ Upstream commit 41508bb7d46b74dba631017e5a702a86caf1db8c ] When accessing or modifying BTREE_NODE_dirty bit, it is not always necessary to acquire b->write_lock. In bch_btree_cache_free() and mca_reap() acquiring b->write_lock is necessary, and this patch adds comments to explain why mutex_lock(&b->write_lock) is necessary for checking or clearing BTREE_NODE_dirty bit there. Signed-off-by: Coly Li Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 7989a5026fd12c7208448b66c51402a65a8a7f16 Author: Coly Li Date: Fri Jun 28 19:59:55 2019 +0800 bcache: only clear BTREE_NODE_dirty bit when it is set [ Upstream commit e5ec5f4765ada9c75fb3eee93a6e72f0e50599d5 ] In bch_btree_cache_free() and btree_node_free(), BTREE_NODE_dirty is always set no matter btree node is dirty or not. The code looks like this, if (btree_node_dirty(b)) btree_complete_write(b, btree_current_write(b)); clear_bit(BTREE_NODE_dirty, &b->flags); Indeed if btree_node_dirty(b) returns false, it means BTREE_NODE_dirty bit is cleared, then it is unnecessary to clear the bit again. This patch only clears BTREE_NODE_dirty when btree_node_dirty(b) is true (the bit is set), to save a few CPU cycles. Signed-off-by: Coly Li Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 652993a5aae5ffa1d59188058c07e8f0e5d2461f Author: Trond Myklebust Date: Fri Jul 19 14:08:37 2019 -0400 NFSv4: Fix delegation state recovery [ Upstream commit 5eb8d18ca0e001c6055da2b7f30d8f6dca23a44f ] Once we clear the NFS_DELEGATED_STATE flag, we're telling nfs_delegation_claim_opens() that we're done recovering all open state for that stateid, so we really need to ensure that we test for all open modes that are currently cached and recover them before exiting nfs4_open_delegation_recall(). Fixes: 24311f884189d ("NFSv4: Recovery of recalled read delegations...") Signed-off-by: Trond Myklebust Cc: stable@vger.kernel.org # v4.3+ Signed-off-by: Sasha Levin commit 5026932adb1a5e862787676a0337aa58fbf91251 Author: Arnd Bergmann Date: Thu Jul 18 15:57:49 2019 +0200 iio: adc: gyroadc: fix uninitialized return code [ Upstream commit 90c6260c1905a68fb596844087f2223bd4657fee ] gcc-9 complains about a blatant uninitialized variable use that all earlier compiler versions missed: drivers/iio/adc/rcar-gyroadc.c:510:5: warning: 'ret' may be used uninitialized in this function [-Wmaybe-uninitialized] Return -EINVAL instead here and a few lines above it where we accidentally return 0 on failure. Cc: stable@vger.kernel.org Fixes: 059c53b32329 ("iio: adc: Add Renesas GyroADC driver") Signed-off-by: Arnd Bergmann Reviewed-by: Wolfram Sang Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 2e7e7c8f9423faa5f957c640a2c5ef531b6c3967 Author: Ralph Campbell Date: Fri Aug 2 21:49:08 2019 -0700 mm/migrate.c: initialize pud_entry in migrate_vma() [ Upstream commit 7b358c6f12dc82364f6d317f8c8f1d794adbc3f5 ] When CONFIG_MIGRATE_VMA_HELPER is enabled, migrate_vma() calls migrate_vma_collect() which initializes a struct mm_walk but didn't initialize mm_walk.pud_entry. (Found by code inspection) Use a C structure initialization to make sure it is set to NULL. Link: http://lkml.kernel.org/r/20190719233225.12243-1-rcampbell@nvidia.com Fixes: 8763cb45ab967 ("mm/migrate: new memory migration helper for use with device memory") Signed-off-by: Ralph Campbell Reviewed-by: John Hubbard Reviewed-by: Andrew Morton Cc: "Jérôme Glisse" Cc: Mel Gorman Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit b8ad18a10f703ae39791046d47d7ea9153ad1ed5 Author: Michał Mirosław Date: Mon Jul 22 21:05:56 2019 +0200 i2c: at91: fix clk_offset for sama5d2 [ Upstream commit b1ac6704493fa14b5dc19eb6b69a73932361a131 ] In SAMA5D2 datasheet, TWIHS_CWGR register rescription mentions clock offset of 3 cycles (compared to 4 in eg. SAMA5D3). Cc: stable@vger.kernel.org # 5.2.x [needs applying to i2c-at91.c instead for earlier kernels] Fixes: 0ef6f3213dac ("i2c: at91: add support for new alternative command mode") Signed-off-by: Michał Mirosław Acked-by: Ludovic Desroches Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 4c9170b55f3a73873e6c7ee8fb339b7016d5b0cf Author: Michał Mirosław Date: Mon Jul 22 20:55:27 2019 +0200 i2c: at91: disable TXRDY interrupt after sending data [ Upstream commit d12e3aae160fb26b534c4496b211d6e60a5179ed ] Driver was not disabling TXRDY interrupt after last TX byte. This caused interrupt storm until transfer timeouts for slow or broken device on the bus. The patch fixes the interrupt storm on my SAMA5D2-based board. Cc: stable@vger.kernel.org # 5.2.x [v5.2 introduced file split; the patch should apply to i2c-at91.c before the split] Fixes: fac368a04048 ("i2c: at91: add new driver") Signed-off-by: Michał Mirosław Acked-by: Ludovic Desroches Tested-by: Raag Jadav Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit c9c90711ee88429766dc3c7a942c8d1905bb0113 Author: Bartosz Golaszewski Date: Mon Jul 8 10:23:43 2019 +0200 gpio: don't WARN() on NULL descs if gpiolib is disabled [ Upstream commit ffe0bbabb0cffceceae07484fde1ec2a63b1537c ] If gpiolib is disabled, we use the inline stubs from gpio/consumer.h instead of regular definitions of GPIO API. The stubs for 'optional' variants of gpiod_get routines return NULL in this case as if the relevant GPIO wasn't found. This is correct so far. Calling other (non-gpio_get) stubs from this header triggers a warning because the GPIO descriptor couldn't have been requested. The warning however is unconditional (WARN_ON(1)) and is emitted even if the passed descriptor pointer is NULL. We don't want to force the users of 'optional' gpio_get to check the returned pointer before calling e.g. gpiod_set_value() so let's only WARN on non-NULL descriptors. Cc: stable@vger.kernel.org Reported-by: Claus H. Stovgaard Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit a532a120a5cd1d9c6bfe761d5aa546274d5d2819 Author: Chris Wilson Date: Sat Jul 20 19:08:48 2019 +0100 iommu/iova: Remove stale cached32_node [ Upstream commit 9eed17d37c77171cf5ffb95c4257f87df3cd4c8f ] Since the cached32_node is allowed to be advanced above dma_32bit_pfn (to provide a shortcut into the limited range), we need to be careful to remove the to be freed node if it is the cached32_node. [ 48.477773] BUG: KASAN: use-after-free in __cached_rbnode_delete_update+0x68/0x110 [ 48.477812] Read of size 8 at addr ffff88870fc19020 by task kworker/u8:1/37 [ 48.477843] [ 48.477879] CPU: 1 PID: 37 Comm: kworker/u8:1 Tainted: G U 5.2.0+ #735 [ 48.477915] Hardware name: Intel Corporation NUC7i5BNK/NUC7i5BNB, BIOS BNKBL357.86A.0052.2017.0918.1346 09/18/2017 [ 48.478047] Workqueue: i915 __i915_gem_free_work [i915] [ 48.478075] Call Trace: [ 48.478111] dump_stack+0x5b/0x90 [ 48.478137] print_address_description+0x67/0x237 [ 48.478178] ? __cached_rbnode_delete_update+0x68/0x110 [ 48.478212] __kasan_report.cold.3+0x1c/0x38 [ 48.478240] ? __cached_rbnode_delete_update+0x68/0x110 [ 48.478280] ? __cached_rbnode_delete_update+0x68/0x110 [ 48.478308] __cached_rbnode_delete_update+0x68/0x110 [ 48.478344] private_free_iova+0x2b/0x60 [ 48.478378] iova_magazine_free_pfns+0x46/0xa0 [ 48.478403] free_iova_fast+0x277/0x340 [ 48.478443] fq_ring_free+0x15a/0x1a0 [ 48.478473] queue_iova+0x19c/0x1f0 [ 48.478597] cleanup_page_dma.isra.64+0x62/0xb0 [i915] [ 48.478712] __gen8_ppgtt_cleanup+0x63/0x80 [i915] [ 48.478826] __gen8_ppgtt_cleanup+0x42/0x80 [i915] [ 48.478940] __gen8_ppgtt_clear+0x433/0x4b0 [i915] [ 48.479053] __gen8_ppgtt_clear+0x462/0x4b0 [i915] [ 48.479081] ? __sg_free_table+0x9e/0xf0 [ 48.479116] ? kfree+0x7f/0x150 [ 48.479234] i915_vma_unbind+0x1e2/0x240 [i915] [ 48.479352] i915_vma_destroy+0x3a/0x280 [i915] [ 48.479465] __i915_gem_free_objects+0xf0/0x2d0 [i915] [ 48.479579] __i915_gem_free_work+0x41/0xa0 [i915] [ 48.479607] process_one_work+0x495/0x710 [ 48.479642] worker_thread+0x4c7/0x6f0 [ 48.479687] ? process_one_work+0x710/0x710 [ 48.479724] kthread+0x1b2/0x1d0 [ 48.479774] ? kthread_create_worker_on_cpu+0xa0/0xa0 [ 48.479820] ret_from_fork+0x1f/0x30 [ 48.479864] [ 48.479907] Allocated by task 631: [ 48.479944] save_stack+0x19/0x80 [ 48.479994] __kasan_kmalloc.constprop.6+0xc1/0xd0 [ 48.480038] kmem_cache_alloc+0x91/0xf0 [ 48.480082] alloc_iova+0x2b/0x1e0 [ 48.480125] alloc_iova_fast+0x58/0x376 [ 48.480166] intel_alloc_iova+0x90/0xc0 [ 48.480214] intel_map_sg+0xde/0x1f0 [ 48.480343] i915_gem_gtt_prepare_pages+0xb8/0x170 [i915] [ 48.480465] huge_get_pages+0x232/0x2b0 [i915] [ 48.480590] ____i915_gem_object_get_pages+0x40/0xb0 [i915] [ 48.480712] __i915_gem_object_get_pages+0x90/0xa0 [i915] [ 48.480834] i915_gem_object_prepare_write+0x2d6/0x330 [i915] [ 48.480955] create_test_object.isra.54+0x1a9/0x3e0 [i915] [ 48.481075] igt_shared_ctx_exec+0x365/0x3c0 [i915] [ 48.481210] __i915_subtests.cold.4+0x30/0x92 [i915] [ 48.481341] __run_selftests.cold.3+0xa9/0x119 [i915] [ 48.481466] i915_live_selftests+0x3c/0x70 [i915] [ 48.481583] i915_pci_probe+0xe7/0x220 [i915] [ 48.481620] pci_device_probe+0xe0/0x180 [ 48.481665] really_probe+0x163/0x4e0 [ 48.481710] device_driver_attach+0x85/0x90 [ 48.481750] __driver_attach+0xa5/0x180 [ 48.481796] bus_for_each_dev+0xda/0x130 [ 48.481831] bus_add_driver+0x205/0x2e0 [ 48.481882] driver_register+0xca/0x140 [ 48.481927] do_one_initcall+0x6c/0x1af [ 48.481970] do_init_module+0x106/0x350 [ 48.482010] load_module+0x3d2c/0x3ea0 [ 48.482058] __do_sys_finit_module+0x110/0x180 [ 48.482102] do_syscall_64+0x62/0x1f0 [ 48.482147] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 48.482190] [ 48.482224] Freed by task 37: [ 48.482273] save_stack+0x19/0x80 [ 48.482318] __kasan_slab_free+0x12e/0x180 [ 48.482363] kmem_cache_free+0x70/0x140 [ 48.482406] __free_iova+0x1d/0x30 [ 48.482445] fq_ring_free+0x15a/0x1a0 [ 48.482490] queue_iova+0x19c/0x1f0 [ 48.482624] cleanup_page_dma.isra.64+0x62/0xb0 [i915] [ 48.482749] __gen8_ppgtt_cleanup+0x63/0x80 [i915] [ 48.482873] __gen8_ppgtt_cleanup+0x42/0x80 [i915] [ 48.482999] __gen8_ppgtt_clear+0x433/0x4b0 [i915] [ 48.483123] __gen8_ppgtt_clear+0x462/0x4b0 [i915] [ 48.483250] i915_vma_unbind+0x1e2/0x240 [i915] [ 48.483378] i915_vma_destroy+0x3a/0x280 [i915] [ 48.483500] __i915_gem_free_objects+0xf0/0x2d0 [i915] [ 48.483622] __i915_gem_free_work+0x41/0xa0 [i915] [ 48.483659] process_one_work+0x495/0x710 [ 48.483704] worker_thread+0x4c7/0x6f0 [ 48.483748] kthread+0x1b2/0x1d0 [ 48.483787] ret_from_fork+0x1f/0x30 [ 48.483831] [ 48.483868] The buggy address belongs to the object at ffff88870fc19000 [ 48.483868] which belongs to the cache iommu_iova of size 40 [ 48.483920] The buggy address is located 32 bytes inside of [ 48.483920] 40-byte region [ffff88870fc19000, ffff88870fc19028) [ 48.483964] The buggy address belongs to the page: [ 48.484006] page:ffffea001c3f0600 refcount:1 mapcount:0 mapping:ffff8888181a91c0 index:0x0 compound_mapcount: 0 [ 48.484045] flags: 0x8000000000010200(slab|head) [ 48.484096] raw: 8000000000010200 ffffea001c421a08 ffffea001c447e88 ffff8888181a91c0 [ 48.484141] raw: 0000000000000000 0000000000120012 00000001ffffffff 0000000000000000 [ 48.484188] page dumped because: kasan: bad access detected [ 48.484230] [ 48.484265] Memory state around the buggy address: [ 48.484314] ffff88870fc18f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 48.484361] ffff88870fc18f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 48.484406] >ffff88870fc19000: fb fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc [ 48.484451] ^ [ 48.484494] ffff88870fc19080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 48.484530] ffff88870fc19100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108602 Fixes: e60aa7b53845 ("iommu/iova: Extend rbtree node caching") Signed-off-by: Chris Wilson Cc: Robin Murphy Cc: Joerg Roedel Cc: Joerg Roedel Cc: # v4.15+ Reviewed-by: Robin Murphy Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit c4fc7cb93e0a9f428389f3a70ea4ac2de8769a44 Author: Suraj Jitindar Singh Date: Wed Jul 10 15:20:18 2019 +1000 powerpc/mm: Limit rma_size to 1TB when running without HV mode [ Upstream commit da0ef93310e67ae6902efded60b6724dab27a5d1 ] The virtual real mode addressing (VRMA) mechanism is used when a partition is using HPT (Hash Page Table) translation and performs real mode accesses (MSR[IR|DR] = 0) in non-hypervisor mode. In this mode effective address bits 0:23 are treated as zero (i.e. the access is aliased to 0) and the access is performed using an implicit 1TB SLB entry. The size of the RMA (Real Memory Area) is communicated to the guest as the size of the first memory region in the device tree. And because of the mechanism described above can be expected to not exceed 1TB. In the event that the host erroneously represents the RMA as being larger than 1TB, guest accesses in real mode to memory addresses above 1TB will be aliased down to below 1TB. This means that a memory access performed in real mode may differ to one performed in virtual mode for the same memory address, which would likely have unintended consequences. To avoid this outcome have the guest explicitly limit the size of the RMA to the current maximum, which is 1TB. This means that even if the first memory block is larger than 1TB, only the first 1TB should be accessed in real mode. Fixes: c610d65c0ad0 ("powerpc/pseries: lift RTAS limit for hash") Cc: stable@vger.kernel.org # v4.16+ Signed-off-by: Suraj Jitindar Singh Tested-by: Satheesh Rajendran Reviewed-by: David Gibson Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20190710052018.14628-1-sjitindarsingh@gmail.com Signed-off-by: Sasha Levin commit 5b9a6ba975c0e6932e27624d700f42b55318687e Author: Takashi Iwai Date: Fri Jul 19 10:27:54 2019 +0200 ALSA: hda - Fix intermittent CORB/RIRB stall on Intel chips [ Upstream commit 2756d9143aa517b97961e85412882b8ce31371a6 ] It turned out that the recent Intel HD-audio controller chips show a significant stall during the system PM resume intermittently. It doesn't happen so often and usually it may read back successfully after one or more seconds, but in some rare worst cases the driver went into fallback mode. After trial-and-error, we found out that the communication stall seems covered by issuing the sync after each verb write, as already done for AMD and other chipsets. So this patch enables the write-sync flag for the recent Intel chips, Skylake and onward, as a workaround. Also, since Broxton and co have the very same driver flags as Skylake, refer to the Skylake driver flags instead of defining the same contents again for simplification. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=201901 Reported-and-tested-by: Todd Brandt Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 87c3692172daf1c3a666bd2d634c0d0163ffe5c1 Author: Sébastien Szymanski Date: Tue May 7 17:27:12 2019 +0200 drm/panel: Add support for Armadeus ST0700 Adapt [ Upstream commit c479450f61c7f1f248c9a54aedacd2a6ca521ff8 ] This patch adds support for the Armadeus ST0700 Adapt. It comes with a Santek ST0700I5Y-RBSLW 7.0" WVGA (800x480) TFT and an adapter board so that it can be connected on the TFT header of Armadeus Dev boards. Cc: stable@vger.kernel.org # v4.19 Reviewed-by: Rob Herring Signed-off-by: Sébastien Szymanski Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20190507152713.27494-1-sebastien.szymanski@armadeus.com Signed-off-by: Sasha Levin commit ecf99cdea02dcc792c27a52d1cf3e1c532551479 Author: Mike Snitzer Date: Tue Jul 2 15:50:08 2019 -0400 dm thin metadata: check if in fail_io mode when setting needs_check [ Upstream commit 54fa16ee532705985e6c946da455856f18f63ee1 ] Check if in fail_io mode at start of dm_pool_metadata_set_needs_check(). Otherwise dm_pool_metadata_set_needs_check()'s superblock_lock() can crash in dm_bm_write_lock() while accessing the block manager object that was previously destroyed as part of a failed dm_pool_abort_metadata() that ultimately set fail_io to begin with. Also, update DMERR() message to more accurately describe superblock_lock() failure. Cc: stable@vger.kernel.org Reported-by: Zdenek Kabelac Signed-off-by: Mike Snitzer Signed-off-by: Sasha Levin commit 5e9a2ce6d3b4a50a0abf754505e5a5ca32bccde5 Author: Norbert Manthey Date: Fri Jul 5 15:06:00 2019 +0200 pstore: Fix double-free in pstore_mkfile() failure path [ Upstream commit 4c6d80e1144bdf48cae6b602ae30d41f3e5c76a9 ] The pstore_mkfile() function is passed a pointer to a struct pstore_record. On success it consumes this 'record' pointer and references it from the created inode. On failure, however, it may or may not free the record. There are even two different code paths which return -ENOMEM -- one of which does and the other doesn't free the record. Make the behaviour deterministic by never consuming and freeing the record when returning failure, allowing the caller to do the cleanup consistently. Signed-off-by: Norbert Manthey Link: https://lore.kernel.org/r/1562331960-26198-1-git-send-email-nmanthey@amazon.de Fixes: 83f70f0769ddd ("pstore: Do not duplicate record metadata") Fixes: 1dfff7dd67d1a ("pstore: Pass record contents instead of copying") Cc: stable@vger.kernel.org [kees: also move "private" allocation location, rename inode cleanup label] Signed-off-by: Kees Cook Signed-off-by: Sasha Levin commit 192b9af8caf04f9a61c0506dccf5b90817195c48 Author: Nadav Amit Date: Thu Jul 18 15:57:31 2019 -0700 resource: fix locking in find_next_iomem_res() [ Upstream commit 49f17c26c123b60fd1c74629eef077740d16ffc2 ] Since resources can be removed, locking should ensure that the resource is not removed while accessing it. However, find_next_iomem_res() does not hold the lock while copying the data of the resource. Keep holding the lock while the data is copied. While at it, change the return value to a more informative value. It is disregarded by the callers. [akpm@linux-foundation.org: fix find_next_iomem_res() documentation] Link: http://lkml.kernel.org/r/20190613045903.4922-2-namit@vmware.com Fixes: ff3cc952d3f00 ("resource: Add remove_resource interface") Signed-off-by: Nadav Amit Reviewed-by: Andrew Morton Reviewed-by: Dan Williams Cc: Borislav Petkov Cc: Toshi Kani Cc: Peter Zijlstra Cc: Dave Hansen Cc: Bjorn Helgaas Cc: Ingo Molnar Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 485bcc29a2005a0817b7a5f041962e1ffe66e0c8 Author: Bjorn Helgaas Date: Thu Sep 27 09:22:09 2018 -0500 resource: Fix find_next_iomem_res() iteration issue [ Upstream commit 010a93bf97c72f43aac664d0a685942f83d1a103 ] Previously find_next_iomem_res() used "*res" as both an input parameter for the range to search and the type of resource to search for, and an output parameter for the resource we found, which makes the interface confusing. The current callers use find_next_iomem_res() incorrectly because they allocate a single struct resource and use it for repeated calls to find_next_iomem_res(). When find_next_iomem_res() returns a resource, it overwrites the start, end, flags, and desc members of the struct. If we call find_next_iomem_res() again, we must update or restore these fields. The previous code restored res.start and res.end, but not res.flags or res.desc. Since the callers did not restore res.flags, if they searched for flags IORESOURCE_MEM | IORESOURCE_BUSY and found a resource with flags IORESOURCE_MEM | IORESOURCE_BUSY | IORESOURCE_SYSRAM, the next search would incorrectly skip resources unless they were also marked as IORESOURCE_SYSRAM. Fix this by restructuring the interface so it takes explicit "start, end, flags" parameters and uses "*res" only as an output parameter. Based on a patch by Lianbo Jiang . [ bp: While at it: - make comments kernel-doc style. - Originally-by: http://lore.kernel.org/lkml/20180921073211.20097-2-lijiang@redhat.com Signed-off-by: Bjorn Helgaas Signed-off-by: Borislav Petkov CC: Andrew Morton CC: Brijesh Singh CC: Dan Williams CC: H. Peter Anvin CC: Lianbo Jiang CC: Takashi Iwai CC: Thomas Gleixner CC: Tom Lendacky CC: Vivek Goyal CC: Yaowei Bai CC: bhe@redhat.com CC: dan.j.williams@intel.com CC: dyoung@redhat.com CC: kexec@lists.infradead.org CC: mingo@redhat.com CC: x86-ml Link: http://lkml.kernel.org/r/153805812916.1157.177580438135143788.stgit@bhelgaas-glaptop.roam.corp.google.com Signed-off-by: Sasha Levin commit 9a80dfccade1dac74a5dfa39ceb85101804b5313 Author: Bjorn Helgaas Date: Thu Sep 27 09:22:02 2018 -0500 resource: Include resource end in walk_*() interfaces [ Upstream commit a98959fdbda1849a01b2150bb635ed559ec06700 ] find_next_iomem_res() finds an iomem resource that covers part of a range described by "start, end". All callers expect that range to be inclusive, i.e., both start and end are included, but find_next_iomem_res() doesn't handle the end address correctly. If it finds an iomem resource that contains exactly the end address, it skips it, e.g., if "start, end" is [0x0-0x10000] and there happens to be an iomem resource [mem 0x10000-0x10000] (the single byte at 0x10000), we skip it: find_next_iomem_res(...) { start = 0x0; end = 0x10000; for (p = next_resource(...)) { # p->start = 0x10000; # p->end = 0x10000; # we *should* return this resource, but this condition is false: if ((p->end >= start) && (p->start < end)) break; Adjust find_next_iomem_res() so it allows a resource that includes the single byte at the end of the range. This is a corner case that we probably don't see in practice. Fixes: 58c1b5b07907 ("[PATCH] memory hotadd fixes: find_next_system_ram catch range fix") Signed-off-by: Bjorn Helgaas Signed-off-by: Borislav Petkov CC: Andrew Morton CC: Brijesh Singh CC: Dan Williams CC: H. Peter Anvin CC: Lianbo Jiang CC: Takashi Iwai CC: Thomas Gleixner CC: Tom Lendacky CC: Vivek Goyal CC: Yaowei Bai CC: bhe@redhat.com CC: dan.j.williams@intel.com CC: dyoung@redhat.com CC: kexec@lists.infradead.org CC: mingo@redhat.com CC: x86-ml Link: http://lkml.kernel.org/r/153805812254.1157.16736368485811773752.stgit@bhelgaas-glaptop.roam.corp.google.com Signed-off-by: Sasha Levin commit 1c13c9c40e3176d501bfa3498c78a607fad6ceb3 Author: Johannes Thumshirn Date: Thu Jun 6 12:07:15 2019 +0200 btrfs: correctly validate compression type [ Upstream commit aa53e3bfac7205fb3a8815ac1c937fd6ed01b41e ] Nikolay reported the following KASAN splat when running btrfs/048: [ 1843.470920] ================================================================== [ 1843.471971] BUG: KASAN: slab-out-of-bounds in strncmp+0x66/0xb0 [ 1843.472775] Read of size 1 at addr ffff888111e369e2 by task btrfs/3979 [ 1843.473904] CPU: 3 PID: 3979 Comm: btrfs Not tainted 5.2.0-rc3-default #536 [ 1843.475009] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 [ 1843.476322] Call Trace: [ 1843.476674] dump_stack+0x7c/0xbb [ 1843.477132] ? strncmp+0x66/0xb0 [ 1843.477587] print_address_description+0x114/0x320 [ 1843.478256] ? strncmp+0x66/0xb0 [ 1843.478740] ? strncmp+0x66/0xb0 [ 1843.479185] __kasan_report+0x14e/0x192 [ 1843.479759] ? strncmp+0x66/0xb0 [ 1843.480209] kasan_report+0xe/0x20 [ 1843.480679] strncmp+0x66/0xb0 [ 1843.481105] prop_compression_validate+0x24/0x70 [ 1843.481798] btrfs_xattr_handler_set_prop+0x65/0x160 [ 1843.482509] __vfs_setxattr+0x71/0x90 [ 1843.483012] __vfs_setxattr_noperm+0x84/0x130 [ 1843.483606] vfs_setxattr+0xac/0xb0 [ 1843.484085] setxattr+0x18c/0x230 [ 1843.484546] ? vfs_setxattr+0xb0/0xb0 [ 1843.485048] ? __mod_node_page_state+0x1f/0xa0 [ 1843.485672] ? _raw_spin_unlock+0x24/0x40 [ 1843.486233] ? __handle_mm_fault+0x988/0x1290 [ 1843.486823] ? lock_acquire+0xb4/0x1e0 [ 1843.487330] ? lock_acquire+0xb4/0x1e0 [ 1843.487842] ? mnt_want_write_file+0x3c/0x80 [ 1843.488442] ? debug_lockdep_rcu_enabled+0x22/0x40 [ 1843.489089] ? rcu_sync_lockdep_assert+0xe/0x70 [ 1843.489707] ? __sb_start_write+0x158/0x200 [ 1843.490278] ? mnt_want_write_file+0x3c/0x80 [ 1843.490855] ? __mnt_want_write+0x98/0xe0 [ 1843.491397] __x64_sys_fsetxattr+0xba/0xe0 [ 1843.492201] ? trace_hardirqs_off_thunk+0x1a/0x1c [ 1843.493201] do_syscall_64+0x6c/0x230 [ 1843.493988] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 1843.495041] RIP: 0033:0x7fa7a8a7707a [ 1843.495819] Code: 48 8b 0d 21 de 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 be 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d ee dd 2b 00 f7 d8 64 89 01 48 [ 1843.499203] RSP: 002b:00007ffcb73bca38 EFLAGS: 00000202 ORIG_RAX: 00000000000000be [ 1843.500210] RAX: ffffffffffffffda RBX: 00007ffcb73bda9d RCX: 00007fa7a8a7707a [ 1843.501170] RDX: 00007ffcb73bda9d RSI: 00000000006dc050 RDI: 0000000000000003 [ 1843.502152] RBP: 00000000006dc050 R08: 0000000000000000 R09: 0000000000000000 [ 1843.503109] R10: 0000000000000002 R11: 0000000000000202 R12: 00007ffcb73bda91 [ 1843.504055] R13: 0000000000000003 R14: 00007ffcb73bda82 R15: ffffffffffffffff [ 1843.505268] Allocated by task 3979: [ 1843.505771] save_stack+0x19/0x80 [ 1843.506211] __kasan_kmalloc.constprop.5+0xa0/0xd0 [ 1843.506836] setxattr+0xeb/0x230 [ 1843.507264] __x64_sys_fsetxattr+0xba/0xe0 [ 1843.507886] do_syscall_64+0x6c/0x230 [ 1843.508429] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 1843.509558] Freed by task 0: [ 1843.510188] (stack is not available) [ 1843.511309] The buggy address belongs to the object at ffff888111e369e0 which belongs to the cache kmalloc-8 of size 8 [ 1843.514095] The buggy address is located 2 bytes inside of 8-byte region [ffff888111e369e0, ffff888111e369e8) [ 1843.516524] The buggy address belongs to the page: [ 1843.517561] page:ffff88813f478d80 refcount:1 mapcount:0 mapping:ffff88811940c300 index:0xffff888111e373b8 compound_mapcount: 0 [ 1843.519993] flags: 0x4404000010200(slab|head) [ 1843.520951] raw: 0004404000010200 ffff88813f48b008 ffff888119403d50 ffff88811940c300 [ 1843.522616] raw: ffff888111e373b8 000000000016000f 00000001ffffffff 0000000000000000 [ 1843.524281] page dumped because: kasan: bad access detected [ 1843.525936] Memory state around the buggy address: [ 1843.526975] ffff888111e36880: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 1843.528479] ffff888111e36900: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 1843.530138] >ffff888111e36980: fc fc fc fc fc fc fc fc fc fc fc fc 02 fc fc fc [ 1843.531877] ^ [ 1843.533287] ffff888111e36a00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 1843.534874] ffff888111e36a80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 1843.536468] ================================================================== This is caused by supplying a too short compression value ('lz') in the test-case and comparing it to 'lzo' with strncmp() and a length of 3. strncmp() read past the 'lz' when looking for the 'o' and thus caused an out-of-bounds read. Introduce a new check 'btrfs_compress_is_valid_type()' which not only checks the user-supplied value against known compression types, but also employs checks for too short values. Reported-by: Nikolay Borisov Fixes: 272e5326c783 ("btrfs: prop: fix vanished compression property after failed set") CC: stable@vger.kernel.org # 5.1+ Reviewed-by: Nikolay Borisov Signed-off-by: Johannes Thumshirn Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 0ca2688bd7cdddb7878151959ddcef8a4deab1e3 Author: Bart Van Assche Date: Wed May 29 09:38:31 2019 -0700 RDMA/srp: Accept again source addresses that do not have a port number [ Upstream commit bcef5b7215681250c4bf8961dfe15e9e4fef97d0 ] The function srp_parse_in() is used both for parsing source address specifications and for target address specifications. Target addresses must have a port number. Having to specify a port number for source addresses is inconvenient. Make sure that srp_parse_in() supports again parsing addresses with no port number. Cc: Fixes: c62adb7def71 ("IB/srp: Fix IPv6 address parsing") Signed-off-by: Bart Van Assche Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 9541604735b26947a1a25c73610e801f80baaf5c Author: Bart Van Assche Date: Mon Dec 17 13:20:34 2018 -0800 RDMA/srp: Document srp_parse_in() arguments [ Upstream commit e37df2d5b569390e3b80ebed9a73fd5b9dcda010 ] This patch avoids that a warning is reported when building with W=1. Cc: Sergey Gorenko Cc: Max Gurtovoy Cc: Laurence Oberman Signed-off-by: Bart Van Assche Signed-off-by: Doug Ledford Signed-off-by: Sasha Levin commit bab0ff2d87db2b2c46c4158f28d37699e396c3c4 Author: Linus Walleij Date: Mon Jul 15 22:21:01 2019 +0200 ARM: dts: gemini: Set DIR-685 SPI CS as active low [ Upstream commit f90b8fda3a9d72a9422ea80ae95843697f94ea4a ] The SPI to the display on the DIR-685 is active low, we were just saved by the SPI library enforcing active low on everything before, so set it as active low to avoid ambiguity. Link: https://lore.kernel.org/r/20190715202101.16060-1-linus.walleij@linaro.org Cc: stable@vger.kernel.org Signed-off-by: Linus Walleij Signed-off-by: Olof Johansson Signed-off-by: Sasha Levin commit 3a1b79ade460080cc7dd45e08ddac7312b91129d Author: Michael Neuling Date: Thu Jun 20 16:00:40 2019 +1000 KVM: PPC: Book3S HV: Fix CR0 setting in TM emulation [ Upstream commit 3fefd1cd95df04da67c83c1cb93b663f04b3324f ] When emulating tsr, treclaim and trechkpt, we incorrectly set CR0. The code currently sets: CR0 <- 00 || MSR[TS] but according to the ISA it should be: CR0 <- 0 || MSR[TS] || 0 This fixes the bit shift to put the bits in the correct location. This is a data integrity issue as CR0 is corrupted. Fixes: 4bb3c7a0208f ("KVM: PPC: Book3S HV: Work around transactional memory bugs in POWER9") Cc: stable@vger.kernel.org # v4.17+ Tested-by: Suraj Jitindar Singh Signed-off-by: Michael Neuling Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 3ac718069f7c542cbf4b133c1026db93dc2bc09a Author: Paul Mackerras Date: Mon Oct 8 16:30:58 2018 +1100 KVM: PPC: Use ccr field in pt_regs struct embedded in vcpu struct [ Upstream commit fd0944baad806dfb4c777124ec712c55b714ff51 ] When the 'regs' field was added to struct kvm_vcpu_arch, the code was changed to use several of the fields inside regs (e.g., gpr, lr, etc.) but not the ccr field, because the ccr field in struct pt_regs is 64 bits on 64-bit platforms, but the cr field in kvm_vcpu_arch is only 32 bits. This changes the code to use the regs.ccr field instead of cr, and changes the assembly code on 64-bit platforms to use 64-bit loads and stores instead of 32-bit ones. Reviewed-by: David Gibson Signed-off-by: Paul Mackerras Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit beeeead95b2fd2b2c1662357d7f02de437fd421b Author: Wanpeng Li Date: Mon Sep 2 15:43:32 2019 -0400 KVM: VMX: check CPUID before allowing read/write of IA32_XSS [ Upstream commit 4d763b168e9c5c366b05812c7bba7662e5ea3669 ] Raise #GP when guest read/write IA32_XSS, but the CPUID bits say that it shouldn't exist. Fixes: 203000993de5 (kvm: vmx: add MSR logic for XSAVES) Reported-by: Xiaoyao Li Reported-by: Tao Xu Cc: Paolo Bonzini Cc: Radim Krčmář Cc: stable@vger.kernel.org Signed-off-by: Wanpeng Li Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 891011ca564ddc66976345a6d8b84775a92d244e Author: Sean Christopherson Date: Mon Sep 2 15:38:20 2019 -0400 KVM: VMX: Fix handling of #MC that occurs during VM-Entry [ Upstream commit beb8d93b3e423043e079ef3dda19dad7b28467a8 ] A previous fix to prevent KVM from consuming stale VMCS state after a failed VM-Entry inadvertantly blocked KVM's handling of machine checks that occur during VM-Entry. Per Intel's SDM, a #MC during VM-Entry is handled in one of three ways, depending on when the #MC is recognoized. As it pertains to this bug fix, the third case explicitly states EXIT_REASON_MCE_DURING_VMENTRY is handled like any other VM-Exit during VM-Entry, i.e. sets bit 31 to indicate the VM-Entry failed. If a machine-check event occurs during a VM entry, one of the following occurs: - The machine-check event is handled as if it occurred before the VM entry: ... - The machine-check event is handled after VM entry completes: ... - A VM-entry failure occurs as described in Section 26.7. The basic exit reason is 41, for "VM-entry failure due to machine-check event". Explicitly handle EXIT_REASON_MCE_DURING_VMENTRY as a one-off case in vmx_vcpu_run() instead of binning it into vmx_complete_atomic_exit(). Doing so allows vmx_vcpu_run() to handle VMX_EXIT_REASONS_FAILED_VMENTRY in a sane fashion and also simplifies vmx_complete_atomic_exit() since VMCS.VM_EXIT_INTR_INFO is guaranteed to be fresh. Fixes: b060ca3b2e9e7 ("kvm: vmx: Handle VMLAUNCH/VMRESUME failure properly") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Reviewed-by: Jim Mattson Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 74ce13331db90a855f61d65daa56908c8733c128 Author: Sean Christopherson Date: Tue May 7 09:06:27 2019 -0700 KVM: VMX: Always signal #GP on WRMSR to MSR_IA32_CR_PAT with bad value [ Upstream commit d28f4290b53a157191ed9991ad05dffe9e8c0c89 ] The behavior of WRMSR is in no way dependent on whether or not KVM consumes the value. Fixes: 4566654bb9be9 ("KVM: vmx: Inject #GP on invalid PAT CR") Cc: stable@vger.kernel.org Cc: Nadav Amit Signed-off-by: Sean Christopherson Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 74fd8aae19d996c62df9f7919aadfa4744f5c5ad Author: Paolo Bonzini Date: Wed Apr 10 11:41:40 2019 +0200 KVM: x86: optimize check for valid PAT value [ Upstream commit 674ea351cdeb01d2740edce31db7f2d79ce6095d ] This check will soon be done on every nested vmentry and vmexit, "parallelize" it using bitwise operations. Reviewed-by: Sean Christopherson Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 812810399999a673d30f9d04d38659030a28051a Author: Yan, Zheng Date: Sun Jun 2 09:45:38 2019 +0800 ceph: use ceph_evict_inode to cleanup inode's resource [ Upstream commit 87bc5b895d94a0f40fe170d4cf5771c8e8f85d15 ] remove_session_caps() relies on __wait_on_freeing_inode(), to wait for freeing inode to remove its caps. But VFS wakes freeing inode waiters before calling destroy_inode(). Cc: stable@vger.kernel.org Link: https://tracker.ceph.com/issues/40102 Signed-off-by: "Yan, Zheng" Reviewed-by: Jeff Layton Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 42fa0e35d6e0972780c0ca195402cfad4067fe8d Author: Takashi Iwai Date: Tue Jul 16 08:56:51 2019 +0200 ALSA: hda - Don't resume forcibly i915 HDMI/DP codec [ Upstream commit 4914da2fb0c89205790503f20dfdde854f3afdd8 ] We apply the codec resume forcibly at system resume callback for updating and syncing the jack detection state that may have changed during sleeping. This is, however, superfluous for the codec like Intel HDMI/DP, where the jack detection is managed via the audio component notification; i.e. the jack state change shall be reported sooner or later from the graphics side at mode change. This patch changes the codec resume callback to avoid the forcible resume conditionally with a new flag, codec->relaxed_resume, for reducing the resume time. The flag is set in the codec probe. Although this doesn't fix the entire bug mentioned in the bugzilla entry below, it's still a good optimization and some improvements are seen. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=201901 Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 987564c28e8aec5cf161bf90fc4e616ae8839f33 Author: Paulo Alcantara (SUSE) Date: Tue Jun 18 16:16:02 2019 -0300 cifs: Properly handle auto disabling of serverino option [ Upstream commit 29fbeb7a908a60a5ae8c50fbe171cb8fdcef1980 ] Fix mount options comparison when serverino option is turned off later in cifs_autodisable_serverino() and thus avoiding mismatch of new cifs mounts. Cc: stable@vger.kernel.org Signed-off-by: Paulo Alcantara (SUSE) Signed-off-by: Steve French Reviewed-by: Pavel Shilovsky Signed-off-by: Sasha Levin commit d85e830d8534d3696c9c55e0d15089e9e91cb9ff Author: Benjamin Block Date: Tue Jul 2 23:02:01 2019 +0200 scsi: zfcp: fix request object use-after-free in send path causing wrong traces [ Upstream commit 106d45f350c7cac876844dc685845cba4ffdb70b ] When tracing instances where we open and close WKA ports, we also pass the request-ID of the respective FSF command. But after successfully sending the FSF command we must not use the request-object anymore, as this might result in an use-after-free (see "zfcp: fix request object use-after-free in send path causing seqno errors" ). To fix this add a new variable that caches the request-ID before sending the request. This won't change during the hand-off to the FCP channel, and so it's safe to trace this cached request-ID later, instead of using the request object. Signed-off-by: Benjamin Block Fixes: d27a7cb91960 ("zfcp: trace on request for open and close of WKA port") Cc: #2.6.38+ Reviewed-by: Steffen Maier Reviewed-by: Jens Remus Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit ba8701d2226c848a21285153ec79c46f992a668b Author: Ajay Singh Date: Wed Jun 26 12:40:48 2019 +0000 staging: wilc1000: fix error path cleanup in wilc_wlan_initialize() [ Upstream commit 6419f818ababebc1116fb2d0e220bd4fe835d0e3 ] For the error path in wilc_wlan_initialize(), the resources are not cleanup in the correct order. Reverted the previous changes and use the correct order to free during error condition. Fixes: b46d68825c2d ("staging: wilc1000: remove COMPLEMENT_BOOT") Cc: Signed-off-by: Ajay Singh Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 60b856dc174431561372d664c2c317dc4aa73fc8 Author: Roman Bolshakov Date: Tue Jul 2 22:16:38 2019 +0300 scsi: target/iblock: Fix overrun in WRITE SAME emulation [ Upstream commit 5676234f20fef02f6ca9bd66c63a8860fce62645 ] WRITE SAME corrupts data on the block device behind iblock if the command is emulated. The emulation code issues (M - 1) * N times more bios than requested, where M is the number of 512 blocks per real block size and N is the NUMBER OF LOGICAL BLOCKS specified in WRITE SAME command. So, for a device with 4k blocks, 7 * N more LBAs gets written after the requested range. The issue happens because the number of 512 byte sectors to be written is decreased one by one while the real bios are typically from 1 to 8 512 byte sectors per bio. Fixes: c66ac9db8d4a ("[SCSI] target: Add LIO target core v4.0.0-rc6") Cc: Signed-off-by: Roman Bolshakov Reviewed-by: Bart Van Assche Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit ba52842de1adfc46ee78d6e2fc6440b97508abc5 Author: Bart Van Assche Date: Mon Oct 15 08:51:37 2018 -0700 scsi: target/core: Use the SECTOR_SHIFT constant [ Upstream commit 80b045b385cfef10939c913fbfeb19ce5491c1f2 ] Instead of duplicating the SECTOR_SHIFT definition from , use it. This patch does not change any functionality. Reviewed-by: Christoph Hellwig Cc: Nicholas Bellinger Cc: Mike Christie Cc: Hannes Reinecke Signed-off-by: Bart Van Assche Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 17111037fdf07b2468598506229872b8a135f834 Author: Mike Salvatore Date: Wed Jun 12 14:55:14 2019 -0700 apparmor: reset pos on failure to unpack for various functions [ Upstream commit 156e42996bd84eccb6acf319f19ce0cb140d00e3 ] Each function that manipulates the aa_ext struct should reset it's "pos" member on failure. This ensures that, on failure, no changes are made to the state of the aa_ext struct. There are paths were elements are optional and the error path is used to indicate the optional element is not present. This means instead of just aborting on error the unpack stream can become unsynchronized on optional elements, if using one of the affected functions. Cc: stable@vger.kernel.org Fixes: 736ec752d95e ("AppArmor: policy routines for loading and unpacking policy") Signed-off-by: Mike Salvatore Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 90ca4912e55d99de7fea970ec2b2d19e52e6ef54 Author: Mike Marciniszyn Date: Fri Jun 14 12:32:26 2019 -0400 IB/hfi1: Avoid hardlockup with flushlist_lock [ Upstream commit cf131a81967583ae737df6383a0893b9fee75b4e ] Heavy contention of the sde flushlist_lock can cause hard lockups at extreme scale when the flushing logic is under stress. Mitigate by replacing the item at a time copy to the local list with an O(1) list_splice_init() and using the high priority work queue to do the flushes. Fixes: 7724105686e7 ("IB/hfi1: add driver files") Cc: Reviewed-by: Dennis Dalessandro Signed-off-by: Mike Marciniszyn Signed-off-by: Dennis Dalessandro Signed-off-by: Doug Ledford Signed-off-by: Sasha Levin commit fa717fc442ff8098205b7bd86a5a26265fa8c9b9 Author: Jon Hunter Date: Wed Jun 5 15:01:39 2019 +0100 clk: tegra210: Fix default rates for HDA clocks [ Upstream commit 9caec6620f25b6d15646bbdb93062c872ba3b56f ] Currently the default clock rates for the HDA and HDA2CODEC_2X clocks are both 19.2MHz. However, the default rates for these clocks should actually be 51MHz and 48MHz, respectively. The current clock settings results in a distorted output during audio playback. Correct the default clock rates for these clocks by specifying them in the clock init table for Tegra210. Cc: stable@vger.kernel.org Signed-off-by: Jon Hunter Acked-by: Thierry Reding Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 350503c8982b7e518a136a816f292467deae7afe Author: Jon Hunter Date: Mon Dec 3 10:28:40 2018 +0000 clk: tegra: Fix maximum audio sync clock for Tegra124/210 [ Upstream commit 845d782d91448e0fbca686bca2cc9f9c2a9ba3e7 ] The maximum frequency supported for I2S on Tegra124 and Tegra210 is 24.576MHz (as stated in the Tegra TK1 data sheet for Tegra124 and the Jetson TX1 module data sheet for Tegra210). However, the maximum I2S frequency is limited to 24MHz because that is the maximum frequency of the audio sync clock. Increase the maximum audio sync clock frequency to 24.576MHz for Tegra124 and Tegra210 in order to support 24.576MHz for I2S. Update the tegra_clk_register_sync_source() function so that it does not set the initial rate for the sync clocks and use the clock init tables to set the initial rate instead. Signed-off-by: Jon Hunter Acked-by: Thierry Reding Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit acc07941e2240af16a922dc38149bae1628aee93 Author: Ronnie Sahlberg Date: Wed Jun 5 10:38:38 2019 +1000 cifs: add spinlock for the openFileList to cifsInodeInfo [ Upstream commit 487317c99477d00f22370625d53be3239febabbe ] We can not depend on the tcon->open_file_lock here since in multiuser mode we may have the same file/inode open via multiple different tcons. The current code is race prone and will crash if one user deletes a file at the same time a different user opens/create the file. To avoid this we need to have a spinlock attached to the inode and not the tcon. RHBZ: 1580165 CC: Stable Signed-off-by: Ronnie Sahlberg Signed-off-by: Steve French Reviewed-by: Pavel Shilovsky Signed-off-by: Sasha Levin commit 1d0648767ccf02dc3f6f8aa49d6084f661097f38 Author: Filipe Manana Date: Wed Jun 12 11:05:42 2019 +0100 Btrfs: fix race between block group removal and block group allocation [ Upstream commit 8eaf40c0e24e98899a0f3ac9d25a33aafe13822a ] If a task is removing the block group that currently has the highest start offset amongst all existing block groups, there is a short time window where it races with a concurrent block group allocation, resulting in a transaction abort with an error code of EEXIST. The following diagram explains the race in detail: Task A Task B btrfs_remove_block_group(bg offset X) remove_extent_mapping(em offset X) -> removes extent map X from the tree of extent maps (fs_info->mapping_tree), so the next call to find_next_chunk() will return offset X btrfs_alloc_chunk() find_next_chunk() --> returns offset X __btrfs_alloc_chunk(offset X) btrfs_make_block_group() btrfs_create_block_group_cache() --> creates btrfs_block_group_cache object with a key corresponding to the block group item in the extent, the key is: (offset X, BTRFS_BLOCK_GROUP_ITEM_KEY, 1G) --> adds the btrfs_block_group_cache object to the list new_bgs of the transaction handle btrfs_end_transaction(trans handle) __btrfs_end_transaction() btrfs_create_pending_block_groups() --> sees the new btrfs_block_group_cache in the new_bgs list of the transaction handle --> its call to btrfs_insert_item() fails with -EEXIST when attempting to insert the block group item key (offset X, BTRFS_BLOCK_GROUP_ITEM_KEY, 1G) because task A has not removed that key yet --> aborts the running transaction with error -EEXIST btrfs_del_item() -> removes the block group's key from the extent tree, key is (offset X, BTRFS_BLOCK_GROUP_ITEM_KEY, 1G) A sample transaction abort trace: [78912.403537] ------------[ cut here ]------------ [78912.403811] BTRFS: Transaction aborted (error -17) [78912.404082] WARNING: CPU: 2 PID: 20465 at fs/btrfs/extent-tree.c:10551 btrfs_create_pending_block_groups+0x196/0x250 [btrfs] (...) [78912.405642] CPU: 2 PID: 20465 Comm: btrfs Tainted: G W 5.0.0-btrfs-next-46 #1 [78912.405941] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.2-0-gf9626ccb91-prebuilt.qemu-project.org 04/01/2014 [78912.406586] RIP: 0010:btrfs_create_pending_block_groups+0x196/0x250 [btrfs] (...) [78912.407636] RSP: 0018:ffff9d3d4b7e3b08 EFLAGS: 00010282 [78912.407997] RAX: 0000000000000000 RBX: ffff90959a3796f0 RCX: 0000000000000006 [78912.408369] RDX: 0000000000000007 RSI: 0000000000000001 RDI: ffff909636b16860 [78912.408746] RBP: ffff909626758a58 R08: 0000000000000000 R09: 0000000000000000 [78912.409144] R10: ffff9095ff462400 R11: 0000000000000000 R12: ffff90959a379588 [78912.409521] R13: ffff909626758ab0 R14: ffff9095036c0000 R15: ffff9095299e1158 [78912.409899] FS: 00007f387f16f700(0000) GS:ffff909636b00000(0000) knlGS:0000000000000000 [78912.410285] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [78912.410673] CR2: 00007f429fc87cbc CR3: 000000014440a004 CR4: 00000000003606e0 [78912.411095] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [78912.411496] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [78912.411898] Call Trace: [78912.412318] __btrfs_end_transaction+0x5b/0x1c0 [btrfs] [78912.412746] btrfs_inc_block_group_ro+0xcf/0x160 [btrfs] [78912.413179] scrub_enumerate_chunks+0x188/0x5b0 [btrfs] [78912.413622] ? __mutex_unlock_slowpath+0x100/0x2a0 [78912.414078] btrfs_scrub_dev+0x2ef/0x720 [btrfs] [78912.414535] ? __sb_start_write+0xd4/0x1c0 [78912.414963] ? mnt_want_write_file+0x24/0x50 [78912.415403] btrfs_ioctl+0x17fb/0x3120 [btrfs] [78912.415832] ? lock_acquire+0xa6/0x190 [78912.416256] ? do_vfs_ioctl+0xa2/0x6f0 [78912.416685] ? btrfs_ioctl_get_supported_features+0x30/0x30 [btrfs] [78912.417116] do_vfs_ioctl+0xa2/0x6f0 [78912.417534] ? __fget+0x113/0x200 [78912.417954] ksys_ioctl+0x70/0x80 [78912.418369] __x64_sys_ioctl+0x16/0x20 [78912.418812] do_syscall_64+0x60/0x1b0 [78912.419231] entry_SYSCALL_64_after_hwframe+0x49/0xbe [78912.419644] RIP: 0033:0x7f3880252dd7 (...) [78912.420957] RSP: 002b:00007f387f16ed68 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [78912.421426] RAX: ffffffffffffffda RBX: 000055f5becc1df0 RCX: 00007f3880252dd7 [78912.421889] RDX: 000055f5becc1df0 RSI: 00000000c400941b RDI: 0000000000000003 [78912.422354] RBP: 0000000000000000 R08: 00007f387f16f700 R09: 0000000000000000 [78912.422790] R10: 00007f387f16f700 R11: 0000000000000246 R12: 0000000000000000 [78912.423202] R13: 00007ffda49c266f R14: 0000000000000000 R15: 00007f388145e040 [78912.425505] ---[ end trace eb9bfe7c426fc4d3 ]--- Fix this by calling remove_extent_mapping(), at btrfs_remove_block_group(), only at the very end, after removing the block group item key from the extent tree (and removing the free space tree entry if we are using the free space tree feature). Fixes: 04216820fe83d5 ("Btrfs: fix race between fs trimming and block group remove/allocation") CC: stable@vger.kernel.org # 4.4+ Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit f276beb324cc1c60dc3495dc03a927a70c1aa5c7 Author: Shirish S Date: Tue Jun 4 21:25:03 2019 +0530 drm/amdgpu/{uvd,vcn}: fetch ring's read_ptr after alloc [ Upstream commit 517b91f4cde3043d77b2178548473e8545ef07cb ] [What] readptr read always returns zero, since most likely these blocks are either power or clock gated. [How] fetch rptr after amdgpu_ring_alloc() which informs the power management code that the block is about to be used and hence the gating is turned off. Signed-off-by: Louis Li Signed-off-by: Shirish S Reviewed-by: Christian König Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 7abeffff7bc33f86da68ca3bfc0fee881b3ab7de Author: Louis Li Date: Sat May 25 06:39:47 2019 +0800 drm/amdgpu: fix ring test failure issue during s3 in vce 3.0 (V2) [ Upstream commit ce0e22f5d886d1b56c7ab4347c45b9ac5fcc058d ] [What] vce ring test fails consistently during resume in s3 cycle, due to mismatch read & write pointers. On debug/analysis its found that rptr to be compared is not being correctly updated/read, which leads to this failure. Below is the failure signature: [drm:amdgpu_vce_ring_test_ring] *ERROR* amdgpu: ring 12 test failed [drm:amdgpu_device_ip_resume_phase2] *ERROR* resume of IP block failed -110 [drm:amdgpu_device_resume] *ERROR* amdgpu_device_ip_resume failed (-110). [How] fetch rptr appropriately, meaning move its read location further down in the code flow. With this patch applied the s3 failure is no more seen for >5k s3 cycles, which otherwise is pretty consistent. V2: remove reduntant fetch of rptr Signed-off-by: Louis Li Reviewed-by: Christian König Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit d5f6539381c765291f96b744549b2dfb688a3f4a Author: Peter Xu Date: Sun May 5 16:56:42 2019 +0800 kvm: Check irqchip mode before assign irqfd [ Upstream commit 654f1f13ea56b92bacade8ce2725aea0457f91c0 ] When assigning kvm irqfd we didn't check the irqchip mode but we allow KVM_IRQFD to succeed with all the irqchip modes. However it does not make much sense to create irqfd even without the kernel chips. Let's provide a arch-dependent helper to check whether a specific irqfd is allowed by the arch. At least for x86, it should make sense to check: - when irqchip mode is NONE, all irqfds should be disallowed, and, - when irqchip mode is SPLIT, irqfds that are with resamplefd should be disallowed. For either of the case, previously we'll silently ignore the irq or the irq ack event if the irqchip mode is incorrect. However that can cause misterious guest behaviors and it can be hard to triage. Let's fail KVM_IRQFD even earlier to detect these incorrect configurations. CC: Paolo Bonzini CC: Radim Krčmář CC: Alex Williamson CC: Eduardo Habkost Signed-off-by: Peter Xu Cc: stable@vger.kernel.org Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 90772cf588380e6253b8d820ed6c3a7933950181 Author: Kent Russell Date: Mon May 13 09:00:05 2019 -0400 drm/amdkfd: Add missing Polaris10 ID [ Upstream commit 0a5a9c276c335870a1cecc4f02b76d6d6f663c8b ] This was added to amdgpu but was missed in amdkfd Signed-off-by: Kent Russell Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Cc: stable@vger.kernel.rg Signed-off-by: Sasha Levin commit cacbc85376b628c1d7d596de04783291c7372e1a Author: Eugeniy Paltsev Date: Mon May 13 20:28:00 2019 +0300 ARC: mm: SIGSEGV userspace trying to access kernel virtual memory [ Upstream commit a8c715b4dd73c26a81a9cc8dc792aa715d8b4bb2 ] As of today if userspace process tries to access a kernel virtual addres (0x7000_0000 to 0x7ffff_ffff) such that a legit kernel mapping already exists, that process hangs instead of being killed with SIGSEGV Fix that by ensuring that do_page_fault() handles kenrel vaddr only if in kernel mode. And given this, we can also simplify the code a bit. Now a vmalloc fault implies kernel mode so its failure (for some reason) can reuse the @no_context label and we can remove @bad_area_nosemaphore. Reproduce user test for original problem: ------------------------>8----------------- #include #include int main(int argc, char *argv[]) { volatile uint32_t temp; temp = *(uint32_t *)(0x70000000); } ------------------------>8----------------- Cc: Signed-off-by: Eugeniy Paltsev Signed-off-by: Vineet Gupta Signed-off-by: Sasha Levin commit 7edfa9c99d215db6ef5df1038de5b36bcfa1bb63 Author: Eugeniy Paltsev Date: Wed Nov 7 15:12:49 2018 +0300 ARC: mm: fix uninitialised signal code in do_page_fault [ Upstream commit 121e38e5acdc8e1e4cdb750fcdcc72f94e420968 ] Commit 15773ae938d8 ("signal/arc: Use force_sig_fault where appropriate") introduced undefined behaviour by leaving si_code unitiailized and leaking random kernel values to user space. Fixes: 15773ae938d8 ("signal/arc: Use force_sig_fault where appropriate") Signed-off-by: Eugeniy Paltsev Signed-off-by: Vineet Gupta Signed-off-by: Sasha Levin commit 0828438e523e084420d381805c60d3dccba1f7a7 Author: Eric W. Biederman Date: Tue Aug 1 13:41:34 2017 -0500 signal/arc: Use force_sig_fault where appropriate [ Upstream commit 15773ae938d8d93d982461990bebad6e1d7a1830 ] Acked-by: Vineet Gupta Signed-off-by: "Eric W. Biederman" Signed-off-by: Sasha Levin commit fcb2f1e2ea687b3507b11c8e74c30dd3d967f1b0 Author: Milan Broz Date: Wed May 15 16:23:43 2019 +0200 dm crypt: move detailed message into debug level [ Upstream commit 7a1cd7238fde6ab367384a4a2998cba48330c398 ] The information about tag size should not be printed without debug info set. Also print device major:minor in the error message to identify the device instance. Also use rate limiting and debug level for info about used crypto API implementaton. This is important because during online reencryption the existing message saturates syslog (because we are moving hotzone across the whole device). Cc: stable@vger.kernel.org Signed-off-by: Milan Broz Signed-off-by: Mike Snitzer Signed-off-by: Sasha Levin commit 96b44c20e6f0694b41c690da4ecfe9a1297879d2 Author: Long Li Date: Mon Apr 15 14:49:17 2019 -0700 cifs: smbd: take an array of reqeusts when sending upper layer data [ Upstream commit 4739f2328661d070f93f9bcc8afb2a82706c826d ] To support compounding, __smb_send_rqst() now sends an array of requests to the transport layer. Change smbd_send() to take an array of requests, and send them in as few packets as possible. Signed-off-by: Long Li Signed-off-by: Steve French CC: Stable Signed-off-by: Sasha Levin commit 3f27a14b03d8bd8eb589b9eaa0046c7840cff813 Author: Jisheng Zhang Date: Fri Mar 29 11:58:53 2019 +0000 PCI: dwc: Use devm_pci_alloc_host_bridge() to simplify code [ Upstream commit e6fdd3bf5aecd8615f31a5128775b9abcf3e0d86 ] Use devm_pci_alloc_host_bridge() to simplify the error code path. This also fixes a leak in the dw_pcie_host_init() error path. Signed-off-by: Jisheng Zhang Signed-off-by: Lorenzo Pieralisi Signed-off-by: Bjorn Helgaas Acked-by: Gustavo Pimentel CC: stable@vger.kernel.org # v4.13+ Signed-off-by: Sasha Levin commit 842da8fac1821f3a63130f5e87c9356ed51d046c Author: Adrian Hunter Date: Mon Apr 8 11:32:11 2019 +0300 mmc: sdhci-pci: Add support for Intel CML [ Upstream commit 765c59675ab571caf7ada456bbfd23a73136b535 ] Add PCI Ids for Intel CML. Signed-off-by: Adrian Hunter Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit e238e6dc222b8ae83014b1940670dc3ae06c20a6 Author: Ming Lei Date: Tue Apr 30 09:52:25 2019 +0800 blk-mq: free hw queue's resource in hctx's release handler [ Upstream commit c7e2d94b3d1634988a95ac4d77a72dc7487ece06 ] Once blk_cleanup_queue() returns, tags shouldn't be used any more, because blk_mq_free_tag_set() may be called. Commit 45a9c9d909b2 ("blk-mq: Fix a use-after-free") fixes this issue exactly. However, that commit introduces another issue. Before 45a9c9d909b2, we are allowed to run queue during cleaning up queue if the queue's kobj refcount is held. After that commit, queue can't be run during queue cleaning up, otherwise oops can be triggered easily because some fields of hctx are freed by blk_mq_free_queue() in blk_cleanup_queue(). We have invented ways for addressing this kind of issue before, such as: 8dc765d438f1 ("SCSI: fix queue cleanup race before queue initialization is done") c2856ae2f315 ("blk-mq: quiesce queue before freeing queue") But still can't cover all cases, recently James reports another such kind of issue: https://marc.info/?l=linux-scsi&m=155389088124782&w=2 This issue can be quite hard to address by previous way, given scsi_run_queue() may run requeues for other LUNs. Fixes the above issue by freeing hctx's resources in its release handler, and this way is safe becasue tags isn't needed for freeing such hctx resource. This approach follows typical design pattern wrt. kobject's release handler. Cc: Dongli Zhang Cc: James Smart Cc: Bart Van Assche Cc: linux-scsi@vger.kernel.org, Cc: Martin K . Petersen , Cc: Christoph Hellwig , Cc: James E . J . Bottomley , Reported-by: James Smart Fixes: 45a9c9d909b2 ("blk-mq: Fix a use-after-free") Cc: stable@vger.kernel.org Reviewed-by: Hannes Reinecke Reviewed-by: Christoph Hellwig Tested-by: James Smart Signed-off-by: Ming Lei Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 69409854ba08d3aeb28a3989703381857842e2ab Author: Yufen Yu Date: Wed Apr 24 23:19:05 2019 +0800 dm mpath: fix missing call of path selector type->end_io [ Upstream commit 5de719e3d01b4abe0de0d7b857148a880ff2a90b ] After commit 396eaf21ee17 ("blk-mq: improve DM's blk-mq IO merging via blk_insert_cloned_request feedback"), map_request() will requeue the tio when issued clone request return BLK_STS_RESOURCE or BLK_STS_DEV_RESOURCE. Thus, if device driver status is error, a tio may be requeued multiple times until the return value is not DM_MAPIO_REQUEUE. That means type->start_io may be called multiple times, while type->end_io is only called when IO complete. In fact, even without commit 396eaf21ee17, setup_clone() failure can also cause tio requeue and associated missed call to type->end_io. The service-time path selector selects path based on in_flight_size, which is increased by st_start_io() and decreased by st_end_io(). Missed calls to st_end_io() can lead to in_flight_size count error and will cause the selector to make the wrong choice. In addition, queue-length path selector will also be affected. To fix the problem, call type->end_io in ->release_clone_rq before tio requeue. map_info is passed to ->release_clone_rq() for map_request() error path that result in requeue. Fixes: 396eaf21ee17 ("blk-mq: improve DM's blk-mq IO merging via blk_insert_cloned_request feedback") Cc: stable@vger.kernl.org Signed-off-by: Yufen Yu Signed-off-by: Mike Snitzer Signed-off-by: Sasha Levin commit 0fe097012b6ca7d5103eb6905ff6a2b640c78f67 Author: Lyude Paul Date: Tue Feb 12 17:02:30 2019 -0500 PCI: Reset Lenovo ThinkPad P50 nvgpu at boot if necessary [ Upstream commit e0547c81bfcfad01cbbfa93a5e66bb98ab932f80 ] On ThinkPad P50 SKUs with an Nvidia Quadro M1000M instead of the M2000M variant, the BIOS does not always reset the secondary Nvidia GPU during reboot if the laptop is configured in Hybrid Graphics mode. The reason is unknown, but the following steps and possibly a good bit of patience will reproduce the issue: 1. Boot up the laptop normally in Hybrid Graphics mode 2. Make sure nouveau is loaded and that the GPU is awake 3. Allow the Nvidia GPU to runtime suspend itself after being idle 4. Reboot the machine, the more sudden the better (e.g. sysrq-b may help) 5. If nouveau loads up properly, reboot the machine again and go back to step 2 until you reproduce the issue This results in some very strange behavior: the GPU will be left in exactly the same state it was in when the previously booted kernel started the reboot. This has all sorts of bad side effects: for starters, this completely breaks nouveau starting with a mysterious EVO channel failure that happens well before we've actually used the EVO channel for anything: nouveau 0000:01:00.0: disp: chid 0 mthd 0000 data 00000400 00001000 00000002 This causes a timeout trying to bring up the GR ctx: nouveau 0000:01:00.0: timeout WARNING: CPU: 0 PID: 12 at drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.c:1547 gf100_grctx_generate+0x7b2/0x850 [nouveau] Hardware name: LENOVO 20EQS64N0B/20EQS64N0B, BIOS N1EET82W (1.55 ) 12/18/2018 Workqueue: events_long drm_dp_mst_link_probe_work [drm_kms_helper] ... nouveau 0000:01:00.0: gr: wait for idle timeout (en: 1, ctxsw: 0, busy: 1) nouveau 0000:01:00.0: gr: wait for idle timeout (en: 1, ctxsw: 0, busy: 1) nouveau 0000:01:00.0: fifo: fault 01 [WRITE] at 0000000000008000 engine 00 [GR] client 15 [HUB/SCC_NB] reason c4 [] on channel -1 [0000000000 unknown] The GPU never manages to recover. Booting without loading nouveau causes issues as well, since the GPU starts sending spurious interrupts that cause other device's IRQs to get disabled by the kernel: irq 16: nobody cared (try booting with the "irqpoll" option) ... handlers: [<000000007faa9e99>] i801_isr [i2c_i801] Disabling IRQ #16 ... serio: RMI4 PS/2 pass-through port at rmi4-00.fn03 i801_smbus 0000:00:1f.4: Timeout waiting for interrupt! i801_smbus 0000:00:1f.4: Transaction timeout rmi4_f03 rmi4-00.fn03: rmi_f03_pt_write: Failed to write to F03 TX register (-110). i801_smbus 0000:00:1f.4: Timeout waiting for interrupt! i801_smbus 0000:00:1f.4: Transaction timeout rmi4_physical rmi4-00: rmi_driver_set_irq_bits: Failed to change enabled interrupts! This causes the touchpad and sometimes other things to get disabled. Since this happens without nouveau, we can't fix this problem from nouveau itself. Add a PCI quirk for the specific P50 variant of this GPU. Make sure the GPU is advertising NoReset- so we don't reset the GPU when the machine is in Dedicated graphics mode (where the GPU being initialized by the BIOS is normal and expected). Map the GPU MMIO space and read the magic 0x2240c register, which will have bit 1 set if the device was POSTed during a previous boot. Once we've confirmed all of this, reset the GPU and re-disable it - bringing it back to a healthy state. Link: https://bugzilla.kernel.org/show_bug.cgi?id=203003 Link: https://lore.kernel.org/lkml/20190212220230.1568-1-lyude@redhat.com Signed-off-by: Lyude Paul Signed-off-by: Bjorn Helgaas Cc: nouveau@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Cc: Karol Herbst Cc: Ben Skeggs Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 5659dfca74d0f033cb039ed73c4e2c42d787d047 Author: Logan Gunthorpe Date: Wed Oct 10 15:55:05 2018 -0500 PCI: Add macro for Switchtec quirk declarations [ Upstream commit 01d5d7fa8376c6b5acda86e16fcad22de6bba486 ] Add SWITCHTEC_QUIRK() to reduce redundancy in declaring devices that use quirk_switchtec_ntb_dma_alias(). By itself, this is no functional change, but a subsequent patch updates SWITCHTEC_QUIRK() to fix ad281ecf1c7d ("PCI: Add DMA alias quirk for Microsemi Switchtec NTB"). Fixes: ad281ecf1c7d ("PCI: Add DMA alias quirk for Microsemi Switchtec NTB") Signed-off-by: Logan Gunthorpe [bhelgaas: split to separate patch] Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit e4ba157877db4a441dc50cce8028ad25c78bdecd Author: Christoph Muellner Date: Fri Mar 22 12:38:04 2019 +0100 dt-bindings: mmc: Add disable-cqe-dcmd property. [ Upstream commit 28f22fb755ecf9f933f045bc0afdb8140641b01c ] Add disable-cqe-dcmd as optional property for MMC hosts. This property allows to disable or not enable the direct command features of the command queue engine. Signed-off-by: Christoph Muellner Signed-off-by: Philipp Tomsich Fixes: 84362d79f436 ("mmc: sdhci-of-arasan: Add CQHCI support for arasan,sdhci-5.1") Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit eb83f9fa10f72d5e749aec38b2f2667a94db816e Author: Sowjanya Komatineni Date: Wed Jan 23 11:30:51 2019 -0800 dt-bindings: mmc: Add supports-cqe property [ Upstream commit c7fddbd5db5cffd10ed4d18efa20e36803d1899f ] Add supports-cqe optional property for MMC hosts. This property is used to identify the specific host controller supporting command queue. Signed-off-by: Sowjanya Komatineni Reviewed-by: Thierry Reding Reviewed-by: Rob Herring Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 0a0176f93ea966f6b2bc71b00164b4d7e3b36af8 Author: Christian Lamparter Date: Tue Feb 26 01:12:01 2019 +0100 ARM: dts: qcom: ipq4019: enlarge PCIe BAR range [ Upstream commit f3e35357cd460a8aeb48b8113dc4b761a7d5c828 ] David Bauer reported that the VDSL modem (attached via PCIe) on his AVM Fritz!Box 7530 was complaining about not having enough space in the BAR. A closer inspection of the old qcom-ipq40xx.dtsi pulled from the GL-iNet repository listed: | qcom,pcie@80000 { | compatible = "qcom,msm_pcie"; | reg = <0x80000 0x2000>, | <0x99000 0x800>, | <0x40000000 0xf1d>, | <0x40000f20 0xa8>, | <0x40100000 0x1000>, | <0x40200000 0x100000>, | <0x40300000 0xd00000>; | reg-names = "parf", "phy", "dm_core", "elbi", | "conf", "io", "bars"; Matching the reg-names with the listed reg leads to <0xd00000> as the size for the "bars". Cc: stable@vger.kernel.org BugLink: https://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg45212.html Reported-by: David Bauer Signed-off-by: Christian Lamparter Signed-off-by: Andy Gross Signed-off-by: Sasha Levin commit 445a78ea3f906518cb85163b71dad3502a91b779 Author: Niklas Cassel Date: Thu Jan 24 14:00:47 2019 +0100 ARM: dts: qcom: ipq4019: Fix MSI IRQ type [ Upstream commit 97131f85c08e024df49480ed499aae8fb754067f ] The databook clearly states that the MSI IRQ (msi_ctrl_int) is a level triggered interrupt. The msi_ctrl_int will be high for as long as any MSI status bit is set, thus the IRQ type should be set to IRQ_TYPE_LEVEL_HIGH, causing the IRQ handler to keep getting called, as long as any MSI status bit is set. A git grep shows that ipq4019 is the only SoC using snps,dw-pcie that has configured this IRQ incorrectly. Not having the correct IRQ type defined will cause us to lose interrupts, which in turn causes timeouts in the PCIe endpoint drivers. Signed-off-by: Niklas Cassel Reviewed-by: Bjorn Andersson Signed-off-by: Andy Gross Signed-off-by: Sasha Levin commit df1216d8bc866336e393240466c875a0bac4049f Author: Mathias Kresin Date: Wed Jul 25 10:37:48 2018 +0200 ARM: dts: qcom: ipq4019: fix PCI range [ Upstream commit da89f500cb55fb3f19c4b399b46d8add0abbd4d6 ] The PCI range is invalid and PCI attached devices doen't work. Signed-off-by: Mathias Kresin Signed-off-by: John Crispin Signed-off-by: Andy Gross Signed-off-by: Sasha Levin commit 2fd4629de51974002f4e9cf1a35a1926dd6c9d99 Author: Theodore Ts'o Date: Tue Apr 9 23:37:08 2019 -0400 ext4: protect journal inode's blocks using block_validity [ Upstream commit 345c0dbf3a30872d9b204db96b5857cd00808cae ] Add the blocks which belong to the journal inode to block_validity's system zone so attempts to deallocate or overwrite the journal due a corrupted file system where the journal blocks are also claimed by another inode. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202879 Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Sasha Levin commit f10a92309b8392637e388948e313d00c5d34bf1b Author: Koen Vandeputte Date: Mon Mar 18 12:40:05 2019 -0400 media: i2c: tda1997x: select V4L2_FWNODE [ Upstream commit 5f2efda71c09b12012053f457fac7692f268b72c ] Building tda1997x fails now unless V4L2_FWNODE is selected: drivers/media/i2c/tda1997x.o: in function `tda1997x_parse_dt' undefined reference to `v4l2_fwnode_endpoint_parse' While at it, also sort the selections alphabetically Fixes: 9ac0038db9a7 ("media: i2c: Add TDA1997x HDMI receiver driver") Signed-off-by: Koen Vandeputte Cc: stable@vger.kernel.org # v4.17+ Acked-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 4061e662c8e9f5fb796b05fd2ab58fed8cd16d59 Author: ZhangXiaoxu Date: Sat Apr 6 15:30:38 2019 +0800 cifs: Fix lease buffer length error [ Upstream commit b57a55e2200ede754e4dc9cce4ba9402544b9365 ] There is a KASAN slab-out-of-bounds: BUG: KASAN: slab-out-of-bounds in _copy_from_iter_full+0x783/0xaa0 Read of size 80 at addr ffff88810c35e180 by task mount.cifs/539 CPU: 1 PID: 539 Comm: mount.cifs Not tainted 4.19 #10 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack+0xdd/0x12a print_address_description+0xa7/0x540 kasan_report+0x1ff/0x550 check_memory_region+0x2f1/0x310 memcpy+0x2f/0x80 _copy_from_iter_full+0x783/0xaa0 tcp_sendmsg_locked+0x1840/0x4140 tcp_sendmsg+0x37/0x60 inet_sendmsg+0x18c/0x490 sock_sendmsg+0xae/0x130 smb_send_kvec+0x29c/0x520 __smb_send_rqst+0x3ef/0xc60 smb_send_rqst+0x25a/0x2e0 compound_send_recv+0x9e8/0x2af0 cifs_send_recv+0x24/0x30 SMB2_open+0x35e/0x1620 open_shroot+0x27b/0x490 smb2_open_op_close+0x4e1/0x590 smb2_query_path_info+0x2ac/0x650 cifs_get_inode_info+0x1058/0x28f0 cifs_root_iget+0x3bb/0xf80 cifs_smb3_do_mount+0xe00/0x14c0 cifs_do_mount+0x15/0x20 mount_fs+0x5e/0x290 vfs_kern_mount+0x88/0x460 do_mount+0x398/0x31e0 ksys_mount+0xc6/0x150 __x64_sys_mount+0xea/0x190 do_syscall_64+0x122/0x590 entry_SYSCALL_64_after_hwframe+0x44/0xa9 It can be reproduced by the following step: 1. samba configured with: server max protocol = SMB2_10 2. mount -o vers=default When parse the mount version parameter, the 'ops' and 'vals' was setted to smb30, if negotiate result is smb21, just update the 'ops' to smb21, but the 'vals' is still smb30. When add lease context, the iov_base is allocated with smb21 ops, but the iov_len is initiallited with the smb30. Because the iov_len is longer than iov_base, when send the message, copy array out of bounds. we need to keep the 'ops' and 'vals' consistent. Fixes: 9764c02fcbad ("SMB3: Add support for multidialect negotiate (SMB2.1 and later)") Fixes: d5c7076b772a ("smb3: add smb3.1.1 to default dialect list") Signed-off-by: ZhangXiaoxu Signed-off-by: Steve French CC: Stable Reviewed-by: Pavel Shilovsky Signed-off-by: Sasha Levin commit df5d4ea2d8beae6a4e1e6a8967bed11d6a9f4050 Author: Sean Christopherson Date: Tue Apr 2 08:10:48 2019 -0700 KVM: x86: Always use 32-bit SMRAM save state for 32-bit kernels [ Upstream commit b68f3cc7d978943fcf85148165b00594c38db776 ] Invoking the 64-bit variation on a 32-bit kenrel will crash the guest, trigger a WARN, and/or lead to a buffer overrun in the host, e.g. rsm_load_state_64() writes r8-r15 unconditionally, but enum kvm_reg and thus x86_emulate_ctxt._regs only define r8-r15 for CONFIG_X86_64. KVM allows userspace to report long mode support via CPUID, even though the guest is all but guaranteed to crash if it actually tries to enable long mode. But, a pure 32-bit guest that is ignorant of long mode will happily plod along. SMM complicates things as 64-bit CPUs use a different SMRAM save state area. KVM handles this correctly for 64-bit kernels, e.g. uses the legacy save state map if userspace has hid long mode from the guest, but doesn't fare well when userspace reports long mode support on a 32-bit host kernel (32-bit KVM doesn't support 64-bit guests). Since the alternative is to crash the guest, e.g. by not loading state or explicitly requesting shutdown, unconditionally use the legacy SMRAM save state map for 32-bit KVM. If a guest has managed to get far enough to handle SMIs when running under a weird/buggy userspace hypervisor, then don't deliberately crash the guest since there are no downsides (from KVM's perspective) to allow it to continue running. Fixes: 660a5d517aaab ("KVM: x86: save/load state on SMM switch") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 7a74d806bdaa4718b96577068fe86fcdb91436e1 Author: WANG Chao Date: Fri Apr 12 15:55:39 2019 +0800 x86/kvm: move kvm_load/put_guest_xcr0 into atomic context [ Upstream commit 1811d979c71621aafc7b879477202d286f7e863b ] guest xcr0 could leak into host when MCE happens in guest mode. Because do_machine_check() could schedule out at a few places. For example: kvm_load_guest_xcr0 ... kvm_x86_ops->run(vcpu) { vmx_vcpu_run vmx_complete_atomic_exit kvm_machine_check do_machine_check do_memory_failure memory_failure lock_page In this case, host_xcr0 is 0x2ff, guest vcpu xcr0 is 0xff. After schedule out, host cpu has guest xcr0 loaded (0xff). In __switch_to { switch_fpu_finish copy_kernel_to_fpregs XRSTORS If any bit i in XSTATE_BV[i] == 1 and xcr0[i] == 0, XRSTORS will generate #GP (In this case, bit 9). Then ex_handler_fprestore kicks in and tries to reinitialize fpu by restoring init fpu state. Same story as last #GP, except we get DOUBLE FAULT this time. Cc: stable@vger.kernel.org Signed-off-by: WANG Chao Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 163b24b1a68c9d6cad8ffc04482c99267b508361 Author: Ben Gardon Date: Mon Apr 8 11:07:30 2019 -0700 kvm: mmu: Fix overflow on kvm mmu page limit calculation [ Upstream commit bc8a3d8925a8fa09fa550e0da115d95851ce33c6 ] KVM bases its memory usage limits on the total number of guest pages across all memslots. However, those limits, and the calculations to produce them, use 32 bit unsigned integers. This can result in overflow if a VM has more guest pages that can be represented by a u32. As a result of this overflow, KVM can use a low limit on the number of MMU pages it will allocate. This makes KVM unable to map all of guest memory at once, prompting spurious faults. Tested: Ran all kvm-unit-tests on an Intel Haswell machine. This patch introduced no new failures. Signed-off-by: Ben Gardon Cc: stable@vger.kernel.org Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit feced628c0684b0cfd8f5c42bd82f05651b31303 Author: Moni Shoua Date: Mon Sep 2 10:16:07 2019 -0400 IB/mlx5: Reset access mask when looping inside page fault handler [ Upstream commit 1abe186ed8a6593069bc122da55fc684383fdc1c ] If page-fault handler spans multiple MRs then the access mask needs to be reset before each MR handling or otherwise write access will be granted to mapped pages instead of read-only. Cc: # 3.19 Fixes: 7bdf65d411c1 ("IB/mlx5: Handle page faults") Reported-by: Jerome Glisse Signed-off-by: Moni Shoua Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 37222eaf7eb7f4f88ac70a36df492c94da517886 Author: Dinh Nguyen Date: Wed Mar 13 17:28:37 2019 -0500 arm64: dts: stratix10: add the sysmgr-syscon property from the gmac's [ Upstream commit 8efd6365417a044db03009724ecc1a9521524913 ] The gmac ethernet driver uses the "altr,sysmgr-syscon" property to configure phy settings for the gmac controller. Add the "altr,sysmgr-syscon" property to all gmac nodes. This patch fixes: [ 0.917530] socfpga-dwmac ff800000.ethernet: No sysmgr-syscon node found [ 0.924209] socfpga-dwmac ff800000.ethernet: Unable to parse OF data Cc: stable@vger.kernel.org Reported-by: Ley Foon Tan Signed-off-by: Dinh Nguyen Signed-off-by: Sasha Levin commit 3cfce8b77aad06fbd2e43b3ae847ad8bd78334b0 Author: Hans de Goede Date: Sat Mar 16 16:57:12 2019 +0100 usb: typec: tcpm: Try PD-2.0 if sink does not respond to 3.0 source-caps [ Upstream commit 976daf9d1199932df80e7b04546d1a1bd4ed5ece ] PD 2.0 sinks are supposed to accept src-capabilities with a 3.0 header and simply ignore any src PDOs which the sink does not understand such as PPS but some 2.0 sinks instead ignore the entire PD_DATA_SOURCE_CAP message, causing contract negotiation to fail. This commit fixes such sinks not working by re-trying the contract negotiation with PD-2.0 source-caps messages if we don't have a contract after PD_N_HARD_RESET_COUNT hard-reset attempts. The problem fixed by this commit was noticed with a Type-C to VGA dongle. Signed-off-by: Hans de Goede Reviewed-by: Guenter Roeck Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit fba4f7c118e4a8c0eb23e8eccaca1f1a30892506 Author: Chris Wilson Date: Thu Mar 14 07:58:29 2019 +0000 drm/i915: Sanity check mmap length against object size [ Upstream commit 000c4f90e3f0194eef218ff2c6a8fd8ca1de4313 ] We assumed that vm_mmap() would reject an attempt to mmap past the end of the filp (our object), but we were wrong. Applications that tried to use the mmap beyond the end of the object would be greeted by a SIGBUS. After this patch, those applications will be told about the error on creating the mmap, rather than at a random moment on later access. Reported-by: Antonio Argenziano Testcase: igt/gem_mmap/bad-size Signed-off-by: Chris Wilson Cc: Antonio Argenziano Cc: Joonas Lahtinen Cc: Tvrtko Ursulin Cc: stable@vger.kernel.org Reviewed-by: Tvrtko Ursulin Reviewed-by: Joonas Lahtinen Link: https://patchwork.freedesktop.org/patch/msgid/20190314075829.16838-1-chris@chris-wilson.co.uk (cherry picked from commit 794a11cb67201ad1bb61af510bb8460280feb3f3) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit 6423a2ad57097eb29758afa87f9c8b5b4fd06c1b Author: Joonas Lahtinen Date: Thu Feb 7 10:54:54 2019 +0200 drm/i915: Handle vm_mmap error during I915_GEM_MMAP ioctl with WC set [ Upstream commit ebfb6977801da521d8d5d752d373a187e2a2b9b3 ] Add err goto label and use it when VMA can't be established or changes underneath. v2: - Dropping Fixes: as it's indeed impossible to race an object to the error address. (Chris) v3: - Use IS_ERR_VALUE (Chris) Reported-by: Adam Zabrocki Signed-off-by: Joonas Lahtinen Cc: Chris Wilson Cc: Tvrtko Ursulin Cc: Adam Zabrocki Reviewed-by: Tvrtko Ursulin #v2 Reviewed-by: Chris Wilson Link: https://patchwork.freedesktop.org/patch/msgid/20190207085454.10598-2-joonas.lahtinen@linux.intel.com Signed-off-by: Sasha Levin commit 778d626c6af3c6f98166ae3da6f2f11991f15160 Author: Pavel Shilovsky Date: Tue Jan 29 16:40:28 2019 -0800 CIFS: Fix leaking locked VFS cache pages in writeback retry [ Upstream commit 165df9a080b6863ae286fa01780c13d87cd81076 ] If we don't find a writable file handle when retrying writepages we break of the loop and do not unlock and put pages neither from wdata2 nor from the original wdata. Fix this by walking through all the remaining pages and cleanup them properly. Cc: Signed-off-by: Pavel Shilovsky Signed-off-by: Steve French Signed-off-by: Sasha Levin commit fb2dabeabb175afcebc37561c8992732278fa8c0 Author: Pavel Shilovsky Date: Tue Jan 8 11:15:28 2019 -0800 CIFS: Fix error paths in writeback code [ Upstream commit 9a66396f1857cc1de06f4f4771797315e1a4ea56 ] This patch aims to address writeback code problems related to error paths. In particular it respects EINTR and related error codes and stores and returns the first error occurred during writeback. Signed-off-by: Pavel Shilovsky Acked-by: Jeff Layton Signed-off-by: Steve French Signed-off-by: Sasha Levin commit e407b58c357604c1d973a0f99ec5ec573fb7b11d Author: Ben Dooks Date: Fri Mar 1 12:00:46 2019 +0000 drm: add __user attribute to ptr_to_compat() [ Upstream commit e552f0851070fe4975d610a99910be4e9bf5d7bd ] The ptr_to_compat() call takes a "void __user *", so cast the compat drm calls that use it to avoid the following warnings from sparse: drivers/gpu/drm/drm_ioc32.c:188:39: warning: incorrect type in argument 1 (different address spaces) drivers/gpu/drm/drm_ioc32.c:188:39: expected void [noderef] *uptr drivers/gpu/drm/drm_ioc32.c:188:39: got void *[addressable] [assigned] handle drivers/gpu/drm/drm_ioc32.c:529:41: warning: incorrect type in argument 1 (different address spaces) drivers/gpu/drm/drm_ioc32.c:529:41: expected void [noderef] *uptr drivers/gpu/drm/drm_ioc32.c:529:41: got void *[addressable] [assigned] handle Cc: stable@vger.kernel.org Signed-off-by: Ben Dooks Signed-off-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/20190301120046.26961-1-ben.dooks@codethink.co.uk Signed-off-by: Sasha Levin commit e1a12c3b6f87f5099a1f531501c6abb3ac5ddce4 Author: Bjorn Andersson Date: Fri Jan 25 15:26:16 2019 -0800 PCI: qcom: Don't deassert reset GPIO during probe [ Upstream commit 02b485e31d98265189b91f3e69c43df2ed50610c ] Acquiring the reset GPIO low means that reset is being deasserted, this is followed almost immediately with qcom_pcie_host_init() asserting it, initializing it and then finally deasserting it again, for the link to come up. Some PCIe devices requires a minimum time between the initial deassert and subsequent reset cycles. In a platform that boots with the reset GPIO asserted this requirement is being violated by this deassert/assert pulse. Acquire the reset GPIO high to prevent this situation by matching the state to the subsequent asserted state. Fixes: 82a823833f4e ("PCI: qcom: Add Qualcomm PCIe controller driver") Signed-off-by: Bjorn Andersson [lorenzo.pieralisi@arm.com: updated commit log] Signed-off-by: Lorenzo Pieralisi Acked-by: Stanimir Varbanov Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit be905d0f2330a6bfd5e5acdd849c769f989594d5 Author: Bjorn Andersson Date: Fri Aug 31 15:55:10 2018 -0700 PCI: qcom: Fix error handling in runtime PM support [ Upstream commit 6e5da6f7d82474e94c2d4a38cf9ca4edbb3e03a0 ] The driver does not cope with the fact that probe can fail in a number of cases after enabling runtime PM on the device; this results in warnings about "Unbalanced pm_runtime_enable". Furthermore if probe fails after invoking qcom_pcie_host_init() the power-domain will be left referenced. As it is not possible for the error handling in qcom_pcie_host_init() to handle errors happening after returning from that function the pm_runtime_get_sync() is moved to qcom_pcie_probe() as well. Fixes: 854b69efbdd2 ("PCI: qcom: add runtime pm support to pcie_port") Signed-off-by: Bjorn Andersson [lorenzo.pieralisi@arm.com: updated commit log] Signed-off-by: Lorenzo Pieralisi Acked-by: Stanimir Varbanov Signed-off-by: Sasha Levin commit 476ecc14cfdb42cf27f12effef69e4028e81b90e Author: Dan Robertson Date: Tue Feb 19 02:56:43 2019 +0000 btrfs: init csum_list before possible free [ Upstream commit e49be14b8d80e23bb7c53d78c21717a474ade76b ] The scrub_ctx csum_list member must be initialized before scrub_free_ctx is called. If the csum_list is not initialized beforehand, the list_empty call in scrub_free_csums will result in a null deref if the allocation fails in the for loop. Fixes: a2de733c78fa ("btrfs: scrub") CC: stable@vger.kernel.org # 3.0+ Reviewed-by: Nikolay Borisov Signed-off-by: Dan Robertson Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 936690bdd8e61c76b199073c1a73594fbba178c2 Author: Anand Jain Date: Wed Jan 30 14:45:00 2019 +0800 btrfs: scrub: fix circular locking dependency warning [ Upstream commit 1cec3f27168d7835ff3d23ab371cd548440131bb ] This fixes a longstanding lockdep warning triggered by fstests/btrfs/011. Circular locking dependency check reports warning[1], that's because the btrfs_scrub_dev() calls the stack #0 below with, the fs_info::scrub_lock held. The test case leading to this warning: $ mkfs.btrfs -f /dev/sdb $ mount /dev/sdb /btrfs $ btrfs scrub start -B /btrfs In fact we have fs_info::scrub_workers_refcnt to track if the init and destroy of the scrub workers are needed. So once we have incremented and decremented the fs_info::scrub_workers_refcnt value in the thread, its ok to drop the scrub_lock, and then actually do the btrfs_destroy_workqueue() part. So this patch drops the scrub_lock before calling btrfs_destroy_workqueue(). [359.258534] ====================================================== [359.260305] WARNING: possible circular locking dependency detected [359.261938] 5.0.0-rc6-default #461 Not tainted [359.263135] ------------------------------------------------------ [359.264672] btrfs/20975 is trying to acquire lock: [359.265927] 00000000d4d32bea ((wq_completion)"%s-%s""btrfs", name){+.+.}, at: flush_workqueue+0x87/0x540 [359.268416] [359.268416] but task is already holding lock: [359.270061] 0000000053ea26a6 (&fs_info->scrub_lock){+.+.}, at: btrfs_scrub_dev+0x322/0x590 [btrfs] [359.272418] [359.272418] which lock already depends on the new lock. [359.272418] [359.274692] [359.274692] the existing dependency chain (in reverse order) is: [359.276671] [359.276671] -> #3 (&fs_info->scrub_lock){+.+.}: [359.278187] __mutex_lock+0x86/0x9c0 [359.279086] btrfs_scrub_pause+0x31/0x100 [btrfs] [359.280421] btrfs_commit_transaction+0x1e4/0x9e0 [btrfs] [359.281931] close_ctree+0x30b/0x350 [btrfs] [359.283208] generic_shutdown_super+0x64/0x100 [359.284516] kill_anon_super+0x14/0x30 [359.285658] btrfs_kill_super+0x12/0xa0 [btrfs] [359.286964] deactivate_locked_super+0x29/0x60 [359.288242] cleanup_mnt+0x3b/0x70 [359.289310] task_work_run+0x98/0xc0 [359.290428] exit_to_usermode_loop+0x83/0x90 [359.291445] do_syscall_64+0x15b/0x180 [359.292598] entry_SYSCALL_64_after_hwframe+0x49/0xbe [359.294011] [359.294011] -> #2 (sb_internal#2){.+.+}: [359.295432] __sb_start_write+0x113/0x1d0 [359.296394] start_transaction+0x369/0x500 [btrfs] [359.297471] btrfs_finish_ordered_io+0x2aa/0x7c0 [btrfs] [359.298629] normal_work_helper+0xcd/0x530 [btrfs] [359.299698] process_one_work+0x246/0x610 [359.300898] worker_thread+0x3c/0x390 [359.302020] kthread+0x116/0x130 [359.303053] ret_from_fork+0x24/0x30 [359.304152] [359.304152] -> #1 ((work_completion)(&work->normal_work)){+.+.}: [359.306100] process_one_work+0x21f/0x610 [359.307302] worker_thread+0x3c/0x390 [359.308465] kthread+0x116/0x130 [359.309357] ret_from_fork+0x24/0x30 [359.310229] [359.310229] -> #0 ((wq_completion)"%s-%s""btrfs", name){+.+.}: [359.311812] lock_acquire+0x90/0x180 [359.312929] flush_workqueue+0xaa/0x540 [359.313845] drain_workqueue+0xa1/0x180 [359.314761] destroy_workqueue+0x17/0x240 [359.315754] btrfs_destroy_workqueue+0x57/0x200 [btrfs] [359.317245] scrub_workers_put+0x2c/0x60 [btrfs] [359.318585] btrfs_scrub_dev+0x336/0x590 [btrfs] [359.319944] btrfs_dev_replace_by_ioctl.cold.19+0x179/0x1bb [btrfs] [359.321622] btrfs_ioctl+0x28a4/0x2e40 [btrfs] [359.322908] do_vfs_ioctl+0xa2/0x6d0 [359.324021] ksys_ioctl+0x3a/0x70 [359.325066] __x64_sys_ioctl+0x16/0x20 [359.326236] do_syscall_64+0x54/0x180 [359.327379] entry_SYSCALL_64_after_hwframe+0x49/0xbe [359.328772] [359.328772] other info that might help us debug this: [359.328772] [359.330990] Chain exists of: [359.330990] (wq_completion)"%s-%s""btrfs", name --> sb_internal#2 --> &fs_info->scrub_lock [359.330990] [359.334376] Possible unsafe locking scenario: [359.334376] [359.336020] CPU0 CPU1 [359.337070] ---- ---- [359.337821] lock(&fs_info->scrub_lock); [359.338506] lock(sb_internal#2); [359.339506] lock(&fs_info->scrub_lock); [359.341461] lock((wq_completion)"%s-%s""btrfs", name); [359.342437] [359.342437] *** DEADLOCK *** [359.342437] [359.343745] 1 lock held by btrfs/20975: [359.344788] #0: 0000000053ea26a6 (&fs_info->scrub_lock){+.+.}, at: btrfs_scrub_dev+0x322/0x590 [btrfs] [359.346778] [359.346778] stack backtrace: [359.347897] CPU: 0 PID: 20975 Comm: btrfs Not tainted 5.0.0-rc6-default #461 [359.348983] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.2-0-gf9626cc-prebuilt.qemu-project.org 04/01/2014 [359.350501] Call Trace: [359.350931] dump_stack+0x67/0x90 [359.351676] print_circular_bug.isra.37.cold.56+0x15c/0x195 [359.353569] check_prev_add.constprop.44+0x4f9/0x750 [359.354849] ? check_prev_add.constprop.44+0x286/0x750 [359.356505] __lock_acquire+0xb84/0xf10 [359.357505] lock_acquire+0x90/0x180 [359.358271] ? flush_workqueue+0x87/0x540 [359.359098] flush_workqueue+0xaa/0x540 [359.359912] ? flush_workqueue+0x87/0x540 [359.360740] ? drain_workqueue+0x1e/0x180 [359.361565] ? drain_workqueue+0xa1/0x180 [359.362391] drain_workqueue+0xa1/0x180 [359.363193] destroy_workqueue+0x17/0x240 [359.364539] btrfs_destroy_workqueue+0x57/0x200 [btrfs] [359.365673] scrub_workers_put+0x2c/0x60 [btrfs] [359.366618] btrfs_scrub_dev+0x336/0x590 [btrfs] [359.367594] ? start_transaction+0xa1/0x500 [btrfs] [359.368679] btrfs_dev_replace_by_ioctl.cold.19+0x179/0x1bb [btrfs] [359.369545] btrfs_ioctl+0x28a4/0x2e40 [btrfs] [359.370186] ? __lock_acquire+0x263/0xf10 [359.370777] ? kvm_clock_read+0x14/0x30 [359.371392] ? kvm_sched_clock_read+0x5/0x10 [359.372248] ? sched_clock+0x5/0x10 [359.372786] ? sched_clock_cpu+0xc/0xc0 [359.373662] ? do_vfs_ioctl+0xa2/0x6d0 [359.374552] do_vfs_ioctl+0xa2/0x6d0 [359.375378] ? do_sigaction+0xff/0x250 [359.376233] ksys_ioctl+0x3a/0x70 [359.376954] __x64_sys_ioctl+0x16/0x20 [359.377772] do_syscall_64+0x54/0x180 [359.378841] entry_SYSCALL_64_after_hwframe+0x49/0xbe [359.380422] RIP: 0033:0x7f5429296a97 Backporting to older kernels: scrub_nocow_workers must be freed the same way as the others. CC: stable@vger.kernel.org # 4.4+ Signed-off-by: Anand Jain [ update changelog ] Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit ff55333f5c525dc7ee7e9f41db1e289bc8cbf04f Author: David Sterba Date: Tue Dec 4 16:11:56 2018 +0100 btrfs: scrub: move scrub_setup_ctx allocation out of device_list_mutex [ Upstream commit 0e94c4f45d14cf89d1f40c91b0a8517e791672a7 ] The scrub context is allocated with GFP_KERNEL and called from btrfs_scrub_dev under the fs_info::device_list_mutex. This is not safe regarding reclaim that could try to flush filesystem data in order to get the memory. And the device_list_mutex is held during superblock commit, so this would cause a lockup. Move the alocation and initialization before any changes that require the mutex. Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 8ba3169dceac319cb12917c66094be4810af4fd9 Author: David Sterba Date: Tue Dec 4 16:11:55 2018 +0100 btrfs: scrub: pass fs_info to scrub_setup_ctx [ Upstream commit 92f7ba434f51e8e9317f1d166105889aa230abd2 ] We can pass fs_info directly as this is the only member of btrfs_device that's bing used inside scrub_setup_ctx. Reviewed-by: Nikolay Borisov Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit df7329207870bfe8b36ec48b882d75c8d456ae66 Author: Takeshi Saito Date: Tue Jan 29 06:40:39 2019 +0100 mmc: renesas_sdhi: Fix card initialization failure in high speed mode [ Upstream commit d30ae056adb81e1d2b8b953efa74735a020b8e3b ] This fixes card initialization failure in high speed mode. If U-Boot uses SDR or HS200/400 mode before starting Linux and Linux DT does not enable SDR/HS200/HS400 mode, card initialization fails in high speed mode. It is necessary to initialize SCC registers during card initialization phase. HW reset function is registered only for a port with either of SDR/HS200/HS400 properties in device tree. If SDR/HS200/HS400 properties are not present in device tree, SCC registers will not be reset. In SoC that support SCC registers, HW reset function should be registered regardless of the configuration of device tree. Reproduction procedure: - Use U-Boot that support MMC HS200/400 mode. - Delete HS200/HS400 properties in device tree. (Delete mmc-hs200-1_8v and mmc-hs400-1_8v) - MMC port works high speed mode and all commands fail. Signed-off-by: Takeshi Saito Signed-off-by: Marek Vasut Cc: Niklas Söderlund Cc: Simon Horman Reviewed-by: Wolfram Sang Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 915c9d0a1d683c74d725c0d149afb8106f1b5303 Author: Michael Ellerman Date: Fri Feb 22 13:22:08 2019 +1100 powerpc/kvm: Save and restore host AMR/IAMR/UAMOR [ Upstream commit c3c7470c75566a077c8dc71dcf8f1948b8ddfab4 ] When the hash MMU is active the AMR, IAMR and UAMOR are used for pkeys. The AMR is directly writable by user space, and the UAMOR masks those writes, meaning both registers are effectively user register state. The IAMR is used to create an execute only key. Also we must maintain the value of at least the AMR when running in process context, so that any memory accesses done by the kernel on behalf of the process are correctly controlled by the AMR. Although we are correctly switching all registers when going into a guest, on returning to the host we just write 0 into all regs, except on Power9 where we restore the IAMR correctly. This could be observed by a user process if it writes the AMR, then runs a guest and we then return immediately to it without rescheduling. Because we have written 0 to the AMR that would have the effect of granting read/write permission to pages that the process was trying to protect. In addition, when using the Radix MMU, the AMR can prevent inadvertent kernel access to userspace data, writing 0 to the AMR disables that protection. So save and restore AMR, IAMR and UAMOR. Fixes: cf43d3b26452 ("powerpc: Enable pkey subsystem") Cc: stable@vger.kernel.org # v4.16+ Signed-off-by: Russell Currey Signed-off-by: Michael Ellerman Acked-by: Paul Mackerras Signed-off-by: Sasha Levin commit b3f864b88256118a1566922c6ce079305d46662c Author: Russell King Date: Thu Feb 21 15:59:58 2019 +0000 spi: spi-gpio: fix SPI_CS_HIGH capability [ Upstream commit b89fefda7d4e3a649129584d855be233c7465264 ] spi-gpio is capable of dealing with active-high chip-selects. Unfortunately, commit 4b859db2c606 ("spi: spi-gpio: add SPI_3WIRE support") broke this by setting master->mode_bits, which overrides the setting in the spi-bitbang code. Fix this. [Fixed a trivial conflict with SPI_3WIRE_HIZ support -- broonie] Fixes: 4b859db2c606 ("spi: spi-gpio: add SPI_3WIRE support") Signed-off-by: Russell King Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 1d60902a5448b2bd55806c5883965a03c7e1e309 Author: Pavel Tatashin Date: Sat Jan 26 12:49:56 2019 -0500 x86/kvmclock: set offset for kvm unstable clock [ Upstream commit b5179ec4187251a751832193693d6e474d3445ac ] VMs may show incorrect uptime and dmesg printk offsets on hypervisors with unstable clock. The problem is produced when VM is rebooted without exiting from qemu. The fix is to calculate clock offset not only for stable clock but for unstable clock as well, and use kvm_sched_clock_read() which substracts the offset for both clocks. This is safe, because pvclock_clocksource_read() does the right thing and makes sure that clock always goes forward, so once offset is calculated with unstable clock, we won't get new reads that are smaller than offset, and thus won't get negative results. Thank you Jon DeVree for helping to reproduce this issue. Fixes: 857baa87b642 ("sched/clock: Enable sched clock early") Cc: stable@vger.kernel.org Reported-by: Dominique Martinet Signed-off-by: Pavel Tatashin Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 716b0cfa88a5e8f1acb59d254ace64491265b431 Author: Ihab Zhaika Date: Mon Feb 4 10:16:03 2019 +0200 iwlwifi: add new card for 9260 series [ Upstream commit 3941310cf665b8a7965424d2a185c80782faa030 ] Add one PCI ID for 9260 series. CC: # 4.14+ Signed-off-by: Ihab Zhaika Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin commit 213566a9b0de6b786cdd3d9f60704e002284b02d Author: Luca Coelho Date: Wed Aug 15 22:07:25 2018 +0300 iwlwifi: fix devices with PCI Device ID 0x34F0 and 11ac RF modules [ Upstream commit ab27926d9e4ae23df4f4d98e31f067c8b486bb4f ] The devices with PCI device ID 0x34F0 are part of the SoC and can be combined with some different external RF modules. The configuration for these devices should reflect that, but are currently mixed up. To avoid confusion with discrete devices, add part of the firmware to be used and the official name of the device to the cfg structs. This is least reorganization possible (without messing things even more) that could be done as a bugfix for this SoC. Further reorganization of this code will be done separately. Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin commit 2b76fcb6ba6239f8247591af2db491ec8c2bdc5f Author: Lyude Paul Date: Mon Jan 28 16:03:50 2019 -0500 drm/nouveau: Don't WARN_ON VCPI allocation failures [ Upstream commit b513a18cf1d705bd04efd91c417e79e4938be093 ] This is much louder then we want. VCPI allocation failures are quite normal, since they will happen if any part of the modesetting process is interrupted by removing the DP MST topology in question. So just print a debugging message on VCPI failures instead. Signed-off-by: Lyude Paul Fixes: f479c0ba4a17 ("drm/nouveau/kms/nv50: initial support for DP 1.2 multi-stream") Cc: Ben Skeggs Cc: dri-devel@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org Cc: # v4.10+ Signed-off-by: Ben Skeggs Signed-off-by: Sasha Levin commit 173b6557fcbc0eb5e045834d244dd07ec87db8b3 Author: Felix Fietkau Date: Mon Sep 2 08:55:14 2019 -0400 mt76: fix corrupted software generated tx CCMP PN [ Upstream commit 906d2d3f874a54183df5a609fda180adf0462428 ] Since ccmp_pn is u8 *, the second half needs to start at array index 4 instead of 0. Fixes a connection stall after a certain amount of traffic Fixes: 23405236460b9 ("mt76: fix transmission of encrypted management frames") Cc: stable@vger.kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 0d7f329e2431c1a211d53f52a26f021cb2be97d5 Author: Krzysztof Kozlowski Date: Tue Feb 12 18:45:49 2019 +0100 iio: adc: exynos-adc: Use proper number of channels for Exynos4x12 [ Upstream commit 103cda6a3b8d2c10d5f8cd7abad118e9db8f4776 ] Exynos4212 and Exynos4412 have only four ADC channels so using "samsung,exynos-adc-v1" compatible (for eight channels ADCv1) on them is wrong. Add a new compatible for Exynos4x12. Signed-off-by: Krzysztof Kozlowski Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 4e516b721a509a781a9d586790c80592ac5b11a4 Author: Jonathan Bakker Date: Fri Dec 7 20:11:36 2018 +0100 dt-bindings: iio: adc: exynos-adc: Add S5PV210 variant [ Upstream commit a9b0a2a7c19316588421b94946c8e2e5a84ac14e ] Add information about new compatible for S5PV210 Signed-off-by: Jonathan Bakker Signed-off-by: Paweł Chmiel Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 7f588a7262b3e4878e3dce5e60b27b7bbc59e2b2 Author: Jonathan Bakker Date: Fri Dec 7 20:11:34 2018 +0100 iio: adc: exynos-adc: Add S5PV210 variant [ Upstream commit 882bf52fdeab47dbe991cc0e564b0b51c571d0a3 ] S5PV210's ADC variant is almost the same as v1 except that it has 10 channels and doesn't require the pmu register Signed-off-by: Jonathan Bakker Signed-off-by: Paweł Chmiel Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit cd490d44150da6e7600fcee57d2480c6e2b9609c Author: Sean Christopherson Date: Mon Sep 2 08:33:15 2019 -0400 KVM: VMX: Compare only a single byte for VMCS' "launched" in vCPU-run [ Upstream commit 61c08aa9606d4e48a8a50639c956448a720174c3 ] The vCPU-run asm blob does a manual comparison of a VMCS' launched status to execute the correct VM-Enter instruction, i.e. VMLAUNCH vs. VMRESUME. The launched flag is a bool, which is a typedef of _Bool. C99 does not define an exact size for _Bool, stating only that is must be large enough to hold '0' and '1'. Most, if not all, compilers use a single byte for _Bool, including gcc[1]. Originally, 'launched' was of type 'int' and so the asm blob used 'cmpl' to check the launch status. When 'launched' was moved to be stored on a per-VMCS basis, struct vcpu_vmx's "temporary" __launched flag was added in order to avoid having to pass the current VMCS into the asm blob. The new '__launched' was defined as a 'bool' and not an 'int', but the 'cmp' instruction was not updated. This has not caused any known problems, likely due to compilers aligning variables to 4-byte or 8-byte boundaries and KVM zeroing out struct vcpu_vmx during allocation. I.e. vCPU-run accesses "junk" data, it just happens to always be zero and so doesn't affect the result. [1] https://gcc.gnu.org/ml/gcc-patches/2000-10/msg01127.html Fixes: d462b8192368 ("KVM: VMX: Keep list of loaded VMCSs, instead of vcpus") Cc: Reviewed-by: Jim Mattson Reviewed-by: Konrad Rzeszutek Wilk Signed-off-by: Sean Christopherson Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 687e470e9123a72a25ba56e9dec5929619edf4b1 Author: Tang Junhui Date: Sat Feb 9 12:52:58 2019 +0800 bcache: treat stale && dirty keys as bad keys [ Upstream commit 58ac323084ebf44f8470eeb8b82660f9d0ee3689 ] Stale && dirty keys can be produced in the follow way: After writeback in write_dirty_finish(), dirty keys k1 will replace by clean keys k2 ==>ret = bch_btree_insert(dc->disk.c, &keys, NULL, &w->key); ==>btree_insert_fn(struct btree_op *b_op, struct btree *b) ==>static int bch_btree_insert_node(struct btree *b, struct btree_op *op, struct keylist *insert_keys, atomic_t *journal_ref, Then two steps: A) update k1 to k2 in btree node memory; bch_btree_insert_keys(b, op, insert_keys, replace_key) B) Write the bset(contains k2) to cache disk by a 30s delay work bch_btree_leaf_dirty(b, journal_ref). But before the 30s delay work write the bset to cache device, these things happened: A) GC works, and reclaim the bucket k2 point to; B) Allocator works, and invalidate the bucket k2 point to, and increase the gen of the bucket, and place it into free_inc fifo; C) Until now, the 30s delay work still does not finish work, so in the disk, the key still is k1, it is dirty and stale (its gen is smaller than the gen of the bucket). and then the machine power off suddenly happens; D) When the machine power on again, after the btree reconstruction, the stale dirty key appear. In bch_extent_bad(), when expensive_debug_checks is off, it would treat the dirty key as good even it is stale keys, and it would cause bellow probelms: A) In read_dirty() it would cause machine crash: BUG_ON(ptr_stale(dc->disk.c, &w->key, 0)); B) It could be worse when reads hits stale dirty keys, it would read old incorrect data. This patch tolerate the existence of these stale && dirty keys, and treat them as bad key in bch_extent_bad(). (Coly Li: fix indent which was modified by sender's email client) Signed-off-by: Tang Junhui Cc: stable@vger.kernel.org Signed-off-by: Coly Li Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit d1cec665de2c30e4fcad23b871173ad51c2946b7 Author: Coly Li Date: Mon Oct 8 20:41:18 2018 +0800 bcache: replace hard coded number with BUCKET_GC_GEN_MAX [ Upstream commit 149d0efada7777ad5a5242b095692af142f533d8 ] In extents.c:bch_extent_bad(), number 96 is used as parameter to call btree_bug_on(). The purpose is to check whether stale gen value exceeds BUCKET_GC_GEN_MAX, so it is better to use macro BUCKET_GC_GEN_MAX to make the code more understandable. Signed-off-by: Coly Li Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit ee30121fbd78a1097d838fc7abd7b9161edc5e2d Author: Jarkko Sakkinen Date: Tue Feb 5 11:14:00 2019 +0200 tpm: Fix some name collisions with drivers/char/tpm.h [ Upstream commit 8ab547a2dcfac6ec184a5e036e1093eb3f7a215c ] * Rename TPM_BUFSIZE defined in drivers/char/tpm/st33zp24/st33zp24.h to ST33ZP24_BUFSIZE. * Rename TPM_BUFSIZE defined in drivers/char/tpm/tpm_i2c_infineon.c to TPM_I2C_INFINEON_BUFSIZE. * Rename TPM_RETRY in tpm_i2c_nuvoton to TPM_I2C_RETRIES. * Remove TPM_HEADER_SIZE from tpm_i2c_nuvoton. Cc: stable@vger.kernel.org Fixes: bf38b8710892 ("tpm/tpm_i2c_stm_st33: Split tpm_i2c_tpm_st33 in 2 layers (core + phy)") Fixes: aad628c1d91a ("char/tpm: Add new driver for Infineon I2C TIS TPM") Fixes: 32d33b29ba07 ("TPM: Retry SaveState command in suspend path") Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin commit c207ac66848e82c5d1fa953a5e573469f50b8d3b Author: Jarkko Nikula Date: Mon Jan 21 16:11:28 2019 +0200 mfd: Kconfig: Fix I2C_DESIGNWARE_PLATFORM dependencies [ Upstream commit 09fdc98577120d4f47601c3127efde726a2300c6 ] INTEL_SOC_PMIC, INTEL_SOC_PMIC_CHTWC and MFD_TPS68470 select the I2C_DESIGNWARE_PLATFORM without its dependencies making it possible to see warning and build error like below: WARNING: unmet direct dependencies detected for I2C_DESIGNWARE_PLATFORM Depends on [n]: I2C [=y] && HAS_IOMEM [=y] && (ACPI [=y] && COMMON_CLK [=n] || !ACPI [=y]) Selected by [y]: - MFD_TPS68470 [=y] && HAS_IOMEM [=y] && ACPI [=y] && I2C [=y]=y /usr/bin/ld: drivers/i2c/busses/i2c-designware-platdrv.o: in function `dw_i2c_plat_resume': i2c-designware-platdrv.c:(.text+0x62): undefined reference to `i2c_dw_prepare_clk' /usr/bin/ld: drivers/i2c/busses/i2c-designware-platdrv.o: in function `dw_i2c_plat_suspend': i2c-designware-platdrv.c:(.text+0x9a): undefined reference to `i2c_dw_prepare_clk' /usr/bin/ld: drivers/i2c/busses/i2c-designware-platdrv.o: in function `dw_i2c_plat_probe': i2c-designware-platdrv.c:(.text+0x41c): undefined reference to `i2c_dw_prepare_clk' /usr/bin/ld: i2c-designware-platdrv.c:(.text+0x438): undefined reference to `i2c_dw_read_comp_param' /usr/bin/ld: i2c-designware-platdrv.c:(.text+0x545): undefined reference to `i2c_dw_probe' /usr/bin/ld: i2c-designware-platdrv.c:(.text+0x727): undefined reference to `i2c_dw_probe_slave' Fix this by making above options to depend on I2C_DESIGNWARE_PLATFORM being built-in. I2C_DESIGNWARE_PLATFORM is a visible symbol with dependencies so in general the select should be avoided. Fixes: acebcff9eda8 ("mfd: intel_soc_pmic: Select designware i2c-bus driver") Fixes: de85d79f4aab ("mfd: Add Cherry Trail Whiskey Cove PMIC driver") Fixes: 9bbf6a15ce19 ("mfd: Add support for TPS68470 device") Cc: Stable # v4.14+ Reported-by: Randy Dunlap Signed-off-by: Jarkko Nikula Acked-by: Randy Dunlap # build-tested Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 6fd5e50add364b878331c04bcbd2e2e793f71b05 Author: José Roberto de Souza Date: Mon Nov 19 15:01:01 2018 -0800 drm/i915/ilk: Fix warning when reading emon_status with no output [ Upstream commit cab870b7fdf3c4be747d88de5248b28db7d4055e ] When there is no output no one will hold a runtime_pm reference causing a warning when trying to read emom_status in debugfs. [22.756480] ------------[ cut here ]------------ [22.756489] RPM wakelock ref not held during HW access [22.756578] WARNING: CPU: 0 PID: 1058 at drivers/gpu/drm/i915/intel_drv.h:2104 gen5_read32+0x16b/0x1a0 [i915] [22.756580] Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic i915 coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core e1000e snd_pcm mei_me prime_numbers mei lpc_ich [22.756595] CPU: 0 PID: 1058 Comm: debugfs_test Not tainted 4.20.0-rc1-CI-Trybot_3219+ #1 [22.756597] Hardware name: Hewlett-Packard HP Compaq 8100 Elite SFF PC/304Ah, BIOS 786H1 v01.13 07/14/2011 [22.756634] RIP: 0010:gen5_read32+0x16b/0x1a0 [i915] [22.756637] Code: a4 ea e0 0f 0b e9 d2 fe ff ff 80 3d a5 71 19 00 00 0f 85 d3 fe ff ff 48 c7 c7 48 d0 2d a0 c6 05 91 71 19 00 01 e8 35 a4 ea e0 <0f> 0b e9 b9 fe ff ff e8 69 c6 f2 e0 85 c0 75 92 48 c7 c2 78 d0 2d [22.756639] RSP: 0018:ffffc90000f1fd38 EFLAGS: 00010282 [22.756642] RAX: 0000000000000000 RBX: ffff8801f7ab0000 RCX: 0000000000000006 [22.756643] RDX: 0000000000000006 RSI: ffffffff8212886a RDI: ffffffff820d6d57 [22.756645] RBP: 0000000000011020 R08: 0000000043e3d1a8 R09: 0000000000000000 [22.756647] R10: ffffc90000f1fd80 R11: 0000000000000000 R12: 0000000000000001 [22.756649] R13: ffff8801f7ab0068 R14: 0000000000000001 R15: ffff88020d53d188 [22.756651] FS: 00007f2878849980(0000) GS:ffff880213a00000(0000) knlGS:0000000000000000 [22.756653] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [22.756655] CR2: 00005638deedf028 CR3: 0000000203292001 CR4: 00000000000206f0 [22.756657] Call Trace: [22.756689] i915_mch_val+0x1b/0x60 [i915] [22.756721] i915_emon_status+0x45/0xd0 [i915] [22.756730] seq_read+0xdb/0x3c0 [22.756736] ? lockdep_hardirqs_off+0x94/0xd0 [22.756740] ? __slab_free+0x24e/0x510 [22.756746] full_proxy_read+0x52/0x90 [22.756752] __vfs_read+0x31/0x170 [22.756759] ? do_sys_open+0x13b/0x240 [22.756763] ? rcu_read_lock_sched_held+0x6f/0x80 [22.756766] vfs_read+0x9e/0x140 [22.756770] ksys_read+0x50/0xc0 [22.756775] do_syscall_64+0x55/0x190 [22.756781] entry_SYSCALL_64_after_hwframe+0x49/0xbe [22.756783] RIP: 0033:0x7f28781dc34e [22.756786] Code: 00 00 00 00 48 8b 15 71 8c 20 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff c3 0f 1f 40 00 8b 05 ba d0 20 00 85 c0 75 16 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 5a f3 c3 0f 1f 84 00 00 00 00 00 41 54 55 49 [22.756787] RSP: 002b:00007ffd33fa0d08 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 [22.756790] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f28781dc34e [22.756792] RDX: 0000000000000200 RSI: 00007ffd33fa0d50 RDI: 0000000000000008 [22.756794] RBP: 00007ffd33fa0f60 R08: 0000000000000000 R09: 0000000000000020 [22.756796] R10: 0000000000000000 R11: 0000000000000246 R12: 00005638de45c2c0 [22.756797] R13: 00007ffd33fa14b0 R14: 0000000000000000 R15: 0000000000000000 [22.756806] irq event stamp: 47950 [22.756811] hardirqs last enabled at (47949): [] vprintk_emit+0x124/0x320 [22.756813] hardirqs last disabled at (47950): [] trace_hardirqs_off_thunk+0x1a/0x1c [22.756816] softirqs last enabled at (47518): [] __do_softirq+0x33a/0x4b9 [22.756820] softirqs last disabled at (47479): [] irq_exit+0xa9/0xc0 [22.756858] WARNING: CPU: 0 PID: 1058 at drivers/gpu/drm/i915/intel_drv.h:2104 gen5_read32+0x16b/0x1a0 [i915] [22.756860] ---[ end trace bf56fa7d6a3cbf7a ] Signed-off-by: José Roberto de Souza Reviewed-by: Rodrigo Vivi Link: https://patchwork.freedesktop.org/patch/msgid/20181119230101.32460-1-jose.souza@intel.com Signed-off-by: Sasha Levin commit 2b4f567912ad5f6653c557e424ee1bf85d8b6266 Author: Ville Syrjälä Date: Tue Nov 27 20:20:04 2018 +0200 drm/vblank: Allow dynamic per-crtc max_vblank_count [ Upstream commit ed20151a7699bb2c77eba3610199789a126940c4 ] On i965gm we need to adjust max_vblank_count dynamically depending on whether the TV encoder is used or not. To that end add a per-crtc max_vblank_count that takes precedence over its device wide counterpart. The driver can now call drm_crtc_set_max_vblank_count() to configure the per-crtc value before calling drm_vblank_on(). Also looks like there was some discussion about exynos needing similar treatment. v2: Drop the extra max_vblank_count!=0 check for the WARN(last!=current), will take care of it in i915 code (Daniel) WARN_ON(!inmodeset) (Daniel) WARN_ON(dev->max_vblank_count) Pimp up the docs (Daniel) Cc: stable@vger.kernel.org Cc: Inki Dae Cc: Daniel Vetter Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20181127182004.28885-1-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter Signed-off-by: Sasha Levin commit 71f71910546204a57c220eaecbfeec4303a3383b Author: Gilad Ben-Yossef Date: Mon Feb 11 16:27:58 2019 +0200 crypto: ccree - add missing inline qualifier [ Upstream commit f1071c3e2473ae19a7f5d892a187c4cab1a61f2e ] Commit 1358c13a48c4 ("crypto: ccree - fix resume race condition on init") was missing a "inline" qualifier for stub function used when CONFIG_PM is not set causing a build warning. Fixes: 1358c13a48c4 ("crypto: ccree - fix resume race condition on init") Cc: stable@kernel.org # v4.20 Signed-off-by: Gilad Ben-Yossef Acked-by: Geert Uytterhoeven Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 72eec6b303f47b05b79dddb00f58c8dc4e7a042b Author: Gilad Ben-Yossef Date: Thu Feb 7 15:36:11 2019 +0200 crypto: ccree - fix resume race condition on init [ Upstream commit 1358c13a48c43f5e4de0c1835291837a27b9720c ] We were enabling autosuspend, which is using data set by the hash module, prior to the hash module being inited, casuing a crash on resume as part of the startup sequence if the race was lost. This was never a real problem because the PM infra was using low res timers so we were always winning the race, until commit 8234f6734c5d ("PM-runtime: Switch autosuspend over to using hrtimers") changed that :-) Fix this by seperating the PM setup and enablement and doing the latter only at the end of the init sequence. Signed-off-by: Gilad Ben-Yossef Cc: Vincent Guittot Cc: stable@kernel.org # v4.20 Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit f0e286550af8844abe440b6ad4b34d0a0240f765 Author: Yishai Hadas Date: Thu Jan 24 14:33:12 2019 +0200 IB/uverbs: Fix OOPs upon device disassociation [ Upstream commit 425784aa5b029eeb80498c73a68f62c3ad1d3b3f ] The async_file might be freed before the disassociation has been ended, causing qp shutdown to use after free on it. Since uverbs_destroy_ufile_hw is not a fence, it returns if a disassociation is ongoing in another thread. It has to be written this way to avoid deadlock. However this means that the ufile FD close cannot destroy anything that may still be used by an active kref, such as the the async_file. To fix that move the kref_put() to be in ib_uverbs_release_file(). BUG: unable to handle kernel paging request at ffffffffba682787 PGD bc80e067 P4D bc80e067 PUD bc80f063 PMD 1313df163 PTE 80000000bc682061 Oops: 0003 [#1] SMP PTI CPU: 1 PID: 32410 Comm: bash Tainted: G OE 4.20.0-rc6+ #3 Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 RIP: 0010:__pv_queued_spin_lock_slowpath+0x1b3/0x2a0 Code: 98 83 e2 60 49 89 df 48 8b 04 c5 80 18 72 ba 48 8d ba 80 32 02 00 ba 00 80 00 00 4c 8d 65 14 41 bd 01 00 00 00 48 01 c7 85 d2 <48> 89 2f 48 89 fb 74 14 8b 45 08 85 c0 75 42 84 d2 74 6b f3 90 83 RSP: 0018:ffffc1bbc064fb58 EFLAGS: 00010006 RAX: ffffffffba65f4e7 RBX: ffff9f209c656c00 RCX: 0000000000000001 RDX: 0000000000008000 RSI: 0000000000000000 RDI: ffffffffba682787 RBP: ffff9f217bb23280 R08: 0000000000000001 R09: 0000000000000000 R10: ffff9f209d2c7800 R11: ffffffffffffffe8 R12: ffff9f217bb23294 R13: 0000000000000001 R14: 0000000000000000 R15: ffff9f209c656c00 FS: 00007fac55aad740(0000) GS:ffff9f217bb00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffba682787 CR3: 000000012f8e0000 CR4: 00000000000006e0 Call Trace: _raw_spin_lock_irq+0x27/0x30 ib_uverbs_release_uevent+0x1e/0xa0 [ib_uverbs] uverbs_free_qp+0x7e/0x90 [ib_uverbs] destroy_hw_idr_uobject+0x1c/0x50 [ib_uverbs] uverbs_destroy_uobject+0x2e/0x180 [ib_uverbs] __uverbs_cleanup_ufile+0x73/0x90 [ib_uverbs] uverbs_destroy_ufile_hw+0x5d/0x120 [ib_uverbs] ib_uverbs_remove_one+0xea/0x240 [ib_uverbs] ib_unregister_device+0xfb/0x200 [ib_core] mlx5_ib_remove+0x51/0xe0 [mlx5_ib] mlx5_remove_device+0xc1/0xd0 [mlx5_core] mlx5_unregister_device+0x3d/0xb0 [mlx5_core] remove_one+0x2a/0x90 [mlx5_core] pci_device_remove+0x3b/0xc0 device_release_driver_internal+0x16d/0x240 unbind_store+0xb2/0x100 kernfs_fop_write+0x102/0x180 __vfs_write+0x36/0x1a0 ? __alloc_fd+0xa9/0x170 ? set_close_on_exec+0x49/0x70 vfs_write+0xad/0x1a0 ksys_write+0x52/0xc0 do_syscall_64+0x5b/0x180 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7fac551aac60 Cc: # 4.2 Fixes: 036b10635739 ("IB/uverbs: Enable device removal when there are active user space applications") Signed-off-by: Yishai Hadas Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 8c6fb55abf2c8272cae2464b0d3f0537792e79c3 Author: Vineet Gupta Date: Mon Dec 10 16:56:45 2018 -0800 ARC: mm: do_page_fault fixes #1: relinquish mmap_sem if signal arrives while handle_mm_fault [ Upstream commit 4d447455e73b47c43dd35fcc38ed823d3182a474 ] do_page_fault() forgot to relinquish mmap_sem if a signal came while handling handle_mm_fault() - due to say a ctl+c or oom etc. This would later cause a deadlock by acquiring it twice. This came to light when running libc testsuite tst-tls3-malloc test but is likely also the cause for prior seen LTP failures. Using lockdep clearly showed what the issue was. | # while true; do ./tst-tls3-malloc ; done | Didn't expect signal from child: got `Segmentation fault' | ^C | ============================================ | WARNING: possible recursive locking detected | 4.17.0+ #25 Not tainted | -------------------------------------------- | tst-tls3-malloc/510 is trying to acquire lock: | 606c7728 (&mm->mmap_sem){++++}, at: __might_fault+0x28/0x5c | |but task is already holding lock: |606c7728 (&mm->mmap_sem){++++}, at: do_page_fault+0x9c/0x2a0 | | other info that might help us debug this: | Possible unsafe locking scenario: | | CPU0 | ---- | lock(&mm->mmap_sem); | lock(&mm->mmap_sem); | | *** DEADLOCK *** | ------------------------------------------------------------ What the change does is not obvious (note to myself) prior code was | do_page_fault | | down_read() <-- lock taken | handle_mm_fault <-- signal pending as this runs | if fatal_signal_pending | if VM_FAULT_ERROR | up_read | if user_mode | return <-- lock still held, this was the BUG New code | do_page_fault | | down_read() <-- lock taken | handle_mm_fault <-- signal pending as this runs | if fatal_signal_pending | if VM_FAULT_RETRY | return <-- not same case as above, but still OK since | core mm already relinq lock for FAULT_RETRY | ... | | < Now falls through for bug case above > | | up_read() <-- lock relinquished Cc: stable@vger.kernel.org Signed-off-by: Vineet Gupta Signed-off-by: Sasha Levin commit 96af7d92d8d27d97edc65ce53d8dd8c4d0f4fa58 Author: Vineet Gupta Date: Tue Dec 18 10:39:58 2018 -0800 ARC: show_regs: lockdep: re-enable preemption [ Upstream commit f731a8e89f8c78985707c626680f3e24c7a60772 ] signal handling core calls show_regs() with preemption disabled which on ARC takes mmap_sem for mm/vma access, causing lockdep splat. | [ARCLinux]# ./segv-null-ptr | potentially unexpected fatal signal 11. | BUG: sleeping function called from invalid context at kernel/fork.c:1011 | in_atomic(): 1, irqs_disabled(): 0, pid: 70, name: segv-null-ptr | no locks held by segv-null-ptr/70. | CPU: 0 PID: 70 Comm: segv-null-ptr Not tainted 4.18.0+ #69 | | Stack Trace: | arc_unwind_core+0xcc/0x100 | ___might_sleep+0x17a/0x190 | mmput+0x16/0xb8 | show_regs+0x52/0x310 | get_signal+0x5ee/0x610 | do_signal+0x2c/0x218 | resume_user_mode_begin+0x90/0xd8 Workaround by re-enabling preemption temporarily. Note that the preemption disabling in core code around show_regs() was introduced by commit 3a9f84d354ce ("signals, debug: fix BUG: using smp_processor_id() in preemptible code in print_fatal_signal()") to silence a differnt lockdep seen on x86 bakc in 2009. Cc: Signed-off-by: Vineet Gupta Signed-off-by: Sasha Levin commit 424b75b79994c57a87e34ff1a0fd462dd3dbcb24 Author: Hans Verkuil Date: Fri Jan 11 07:07:25 2019 -0500 media: vim2m: only cancel work if it is for right context [ Upstream commit 240809ef6630a4ce57c273c2d79ffb657cd361eb ] cancel_delayed_work_sync() was called for any queue, but it should only be called for the queue that is associated with the currently running job. Otherwise, if two filehandles are streaming at the same time, then closing the first will cancel the work which might still be running for a job from the second filehandle. As a result the second filehandle will never be able to finish the job and an attempt to stop streaming on that second filehandle will stall. Fixes: 52117be68b82 ("media: vim2m: use cancel_delayed_work_sync instead of flush_schedule_work") Signed-off-by: Hans Verkuil Cc: # for v4.20 and up Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit be77686f0369dff64d7cce4b56dcce4559421ad6 Author: Qu Wenruo Date: Tue Jan 8 14:08:18 2019 +0800 btrfs: Use real device structure to verify dev extent [ Upstream commit 1b3922a8bc74231f9a767d1be6d9a061a4d4eeab ] [BUG] Linux v5.0-rc1 will fail fstests/btrfs/163 with the following kernel message: BTRFS error (device dm-6): dev extent devid 1 physical offset 13631488 len 8388608 is beyond device boundary 0 BTRFS error (device dm-6): failed to verify dev extents against chunks: -117 BTRFS error (device dm-6): open_ctree failed [CAUSE] Commit cf90d884b347 ("btrfs: Introduce mount time chunk <-> dev extent mapping check") introduced strict check on dev extents. We use btrfs_find_device() with dev uuid and fs uuid set to NULL, and only dependent on @devid to find the real device. For seed devices, we call clone_fs_devices() in open_seed_devices() to allow us search seed devices directly. However clone_fs_devices() just populates devices with devid and dev uuid, without populating other essential members, like disk_total_bytes. This makes any device returned by btrfs_find_device(fs_info, devid, NULL, NULL) is just a dummy, with 0 disk_total_bytes, and any dev extents on the seed device will not pass the device boundary check. [FIX] This patch will try to verify the device returned by btrfs_find_device() and if it's a dummy then re-search in seed devices. Fixes: cf90d884b347 ("btrfs: Introduce mount time chunk <-> dev extent mapping check") CC: stable@vger.kernel.org # 4.19+ Reported-by: Filipe Manana Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit a2790b9939aebb9a22cf7ce2eea1a3a1953a686c Author: Qu Wenruo Date: Fri Oct 5 17:45:55 2018 +0800 btrfs: volumes: Make sure no dev extent is beyond device boundary [ Upstream commit 05a37c48604c19b50873fd9663f9140c150469d1 ] Add extra dev extent end check against device boundary. Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit cfbf227e05911bffd07a958254e1c41972e64338 Author: Ram Pai Date: Thu Dec 20 12:03:30 2018 -0800 powerpc/pkeys: Fix handling of pkey state across fork() [ Upstream commit 2cd4bd192ee94848695c1c052d87913260e10f36 ] Protection key tracking information is not copied over to the mm_struct of the child during fork(). This can cause the child to erroneously allocate keys that were already allocated. Any allocated execute-only key is lost aswell. Add code; called by dup_mmap(), to copy the pkey state from parent to child explicitly. This problem was originally found by Dave Hansen on x86, which turns out to be a problem on powerpc aswell. Fixes: cf43d3b26452 ("powerpc: Enable pkey subsystem") Cc: stable@vger.kernel.org # v4.16+ Reviewed-by: Thiago Jung Bauermann Signed-off-by: Ram Pai Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 2ad95be1899576135f1a26bc6d2ed010fbd0c248 Author: Shivasharan S Date: Tue Dec 18 05:59:54 2018 -0800 scsi: megaraid_sas: Use 63-bit DMA addressing [ Upstream commit 894169db12463cea08d0e2a9e35f42b291340e5a ] Although MegaRAID controllers support 64-bit DMA addressing, as per hardware design, DMA address with all 64-bits set (0xFFFFFFFF-FFFFFFFF) results in a firmware fault. Driver will set 63-bit DMA mask to ensure the above address will not be used. Cc: stable@vger.kernel.org Signed-off-by: Shivasharan S Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 3263f78640ccc130dfdde8b20d78f78c97ee129f Author: Shivasharan S Date: Tue Oct 16 23:37:42 2018 -0700 scsi: megaraid_sas: Add check for reset adapter bit [ Upstream commit de93b40d98ead27ee2f7f7df93fdd4914a6c8d8d ] For SAS3 and later controllers, FW sets the reset adapter bit indicating the driver to perform a controller reset. Driver needs to check if this bit is set before doing a reset. This reduces the driver probe failure time to 180seconds in case there is a faulty controller connected. Signed-off-by: Sumit Saxena Signed-off-by: Shivasharan S Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit dc4e3ec9d226e9528ea221483d30fba7b4d24622 Author: Shivasharan S Date: Tue Oct 16 23:37:46 2018 -0700 scsi: megaraid_sas: Fix combined reply queue mode detection [ Upstream commit e29c322133472628c6de85efb99ccd3b3df5571e ] For Invader series, if FW supports more than 8 MSI-x vectors, driver needs to enable combined reply queue mode. For Ventura series, driver enables combined reply queue mode in case of more than 16 MSI-x vectors. Signed-off-by: Sumit Saxena Signed-off-by: Shivasharan S Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit eb124aaa2e85e9dceac37be5b7166a04b9b26735 Author: Nikolay Borisov Date: Wed Nov 21 17:10:52 2018 +0200 btrfs: Fix error handling in btrfs_cleanup_ordered_extents [ Upstream commit d1051d6ebf8ef3517a5a3cf82bba8436d190f1c2 ] Running btrfs/124 in a loop hung up on me sporadically with the following call trace: btrfs D 0 5760 5324 0x00000000 Call Trace: ? __schedule+0x243/0x800 schedule+0x33/0x90 btrfs_start_ordered_extent+0x10c/0x1b0 [btrfs] ? wait_woken+0xa0/0xa0 btrfs_wait_ordered_range+0xbb/0x100 [btrfs] btrfs_relocate_block_group+0x1ff/0x230 [btrfs] btrfs_relocate_chunk+0x49/0x100 [btrfs] btrfs_balance+0xbeb/0x1740 [btrfs] btrfs_ioctl_balance+0x2ee/0x380 [btrfs] btrfs_ioctl+0x1691/0x3110 [btrfs] ? lockdep_hardirqs_on+0xed/0x180 ? __handle_mm_fault+0x8e7/0xfb0 ? _raw_spin_unlock+0x24/0x30 ? __handle_mm_fault+0x8e7/0xfb0 ? do_vfs_ioctl+0xa5/0x6e0 ? btrfs_ioctl_get_supported_features+0x30/0x30 [btrfs] do_vfs_ioctl+0xa5/0x6e0 ? entry_SYSCALL_64_after_hwframe+0x3e/0xbe ksys_ioctl+0x3a/0x70 __x64_sys_ioctl+0x16/0x20 do_syscall_64+0x60/0x1b0 entry_SYSCALL_64_after_hwframe+0x49/0xbe This happens because during page writeback it's valid for writepage_delalloc to instantiate a delalloc range which doesn't belong to the page currently being written back. The reason this case is valid is due to find_lock_delalloc_range returning any available range after the passed delalloc_start and ignoring whether the page under writeback is within that range. In turn ordered extents (OE) are always created for the returned range from find_lock_delalloc_range. If, however, a failure occurs while OE are being created then the clean up code in btrfs_cleanup_ordered_extents will be called. Unfortunately the code in btrfs_cleanup_ordered_extents doesn't consider the case of such 'foreign' range being processed and instead it always assumes that the range OE are created for belongs to the page. This leads to the first page of such foregin range to not be cleaned up since it's deliberately missed and skipped by the current cleaning up code. Fix this by correctly checking whether the current page belongs to the range being instantiated and if so adjsut the range parameters passed for cleaning up. If it doesn't, then just clean the whole OE range directly. Fixes: 524272607e88 ("btrfs: Handle delalloc error correctly to avoid ordered extent hang") CC: stable@vger.kernel.org # 4.14+ Reviewed-by: Josef Bacik Signed-off-by: Nikolay Borisov Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 1669d1d2e696bedebaedede086870d217a6512d0 Author: Nikolay Borisov Date: Thu Nov 1 14:09:46 2018 +0200 btrfs: Remove extent_io_ops::fill_delalloc [ Upstream commit 5eaad97af8aeff38debe7d3c69ec3a0d71f8350f ] This callback is called only from writepage_delalloc which in turn is guaranteed to be called from the data page writeout path. In the end there is no reason to have the call to this function to be indrected via the extent_io_ops structure. This patch removes the callback definition, exports the function and calls it directly. No functional changes. Reviewed-by: Josef Bacik Signed-off-by: Nikolay Borisov Reviewed-by: David Sterba [ rename to btrfs_run_delalloc_range ] Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 338a528b79225a16462d59b0a2b3faddd4f36d2a Author: Filipe Manana Date: Mon Nov 26 20:07:17 2018 +0000 Btrfs: fix deadlock with memory reclaim during scrub [ Upstream commit a5fb11429167ee6ddeeacc554efaf5776b36433a ] When a transaction commit starts, it attempts to pause scrub and it blocks until the scrub is paused. So while the transaction is blocked waiting for scrub to pause, we can not do memory allocation with GFP_KERNEL from scrub, otherwise we risk getting into a deadlock with reclaim. Checking for scrub pause requests is done early at the beginning of the while loop of scrub_stripe() and later in the loop, scrub_extent() and scrub_raid56_parity() are called, which in turn call scrub_pages() and scrub_pages_for_parity() respectively. These last two functions do memory allocations using GFP_KERNEL. Same problem could happen while scrubbing the super blocks, since it calls scrub_pages(). We also can not have any of the worker tasks, created by the scrub task, doing GFP_KERNEL allocations, because before pausing, the scrub task waits for all the worker tasks to complete (also done at scrub_stripe()). So make sure GFP_NOFS is used for the memory allocations because at any time a scrub pause request can happen from another task that started to commit a transaction. Fixes: 58c4e173847a ("btrfs: scrub: use GFP_KERNEL on the submission path") CC: stable@vger.kernel.org # 4.6+ Reviewed-by: Nikolay Borisov Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit fac803479f60a560915a7d51a0a3a7614be3381b Author: Omar Sandoval Date: Tue Aug 14 11:09:52 2018 -0700 Btrfs: clean up scrub is_dev_replace parameter [ Upstream commit 32934280967d00dc2b5c4d3b63b21a9c8638326e ] struct scrub_ctx has an ->is_dev_replace member, so there's no point in passing around is_dev_replace where sctx is available. Signed-off-by: Omar Sandoval Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit d3984e80d7f27c1283ea51e067ec8311619d9c3d Author: Paul Mackerras Date: Fri Nov 16 21:28:18 2018 +1100 KVM: PPC: Book3S HV: Fix race between kvm_unmap_hva_range and MMU mode switch [ Upstream commit 234ff0b729ad882d20f7996591a964965647addf ] Testing has revealed an occasional crash which appears to be caused by a race between kvmppc_switch_mmu_to_hpt and kvm_unmap_hva_range_hv. The symptom is a NULL pointer dereference in __find_linux_pte() called from kvm_unmap_radix() with kvm->arch.pgtable == NULL. Looking at kvmppc_switch_mmu_to_hpt(), it does indeed clear kvm->arch.pgtable (via kvmppc_free_radix()) before setting kvm->arch.radix to NULL, and there is nothing to prevent kvm_unmap_hva_range_hv() or the other MMU callback functions from being called concurrently with kvmppc_switch_mmu_to_hpt() or kvmppc_switch_mmu_to_radix(). This patch therefore adds calls to spin_lock/unlock on the kvm->mmu_lock around the assignments to kvm->arch.radix, and makes sure that the partition-scoped radix tree or HPT is only freed after changing kvm->arch.radix. This also takes the kvm->mmu_lock in kvmppc_rmap_reset() to make sure that the clearing of each rmap array (one per memslot) doesn't happen concurrently with use of the array in the kvm_unmap_hva_range_hv() or the other MMU callbacks. Fixes: 18c3640cefc7 ("KVM: PPC: Book3S HV: Add infrastructure for running HPT guests on radix host") Cc: stable@vger.kernel.org # v4.15+ Signed-off-by: Paul Mackerras Signed-off-by: Sasha Levin commit d88b01d04c6a16dee1fa172db5064af2768b33a7 Author: Chris Wilson Date: Sun Aug 12 23:36:29 2018 +0100 drm/i915: Cleanup gt powerstate from gem [ Upstream commit 30b710840e4b9c9699d3d4b33fb19ad8880d4614 ] Since the gt powerstate is allocated by i915_gem_init, clean it from i915_gem_fini for symmetry and to correct the imbalance on error. Signed-off-by: Chris Wilson Reviewed-by: Mika Kuoppala Link: https://patchwork.freedesktop.org/patch/msgid/20180812223642.24865-1-chris@chris-wilson.co.uk Signed-off-by: Sasha Levin commit b185bde520d5feb8fc750107d4cda32262fd92bf Author: Chris Wilson Date: Thu Jul 26 09:50:32 2018 +0100 drm/i915: Restore sane defaults for KMS on GEM error load [ Upstream commit 7ed43df720c007d60bee6d81da07bcdc7e4a55ae ] If we fail during GEM initialisation, we scrub the HW state by performing a device level GPU resuet. However, we want to leave the system in a usable state (with functioning KMS but no GEM) so after scrubbing the HW state, we need to restore some sane defaults and re-enable the low-level common parts of the GPU (such as the GMCH). v2: Restore GTT entries. Signed-off-by: Chris Wilson Link: https://patchwork.freedesktop.org/patch/msgid/20180726085033.4044-2-chris@chris-wilson.co.uk Reviewed-by: Michał Winiarski Signed-off-by: Sasha Levin commit f999485109d1bd2553535cfb0797827c2b3d9cb8 Author: Hans Verkuil Date: Wed Nov 7 09:04:54 2018 -0500 media: vim2m: use cancel_delayed_work_sync instead of flush_schedule_work [ Upstream commit 52117be68b82ee05c96da0a7beec319906ccf6cc ] The use of flush_schedule_work() made no sense and caused a syzkaller error. Replace with the correct cancel_delayed_work_sync(). Signed-off-by: Hans Verkuil Reported-by: syzbot+69780d144754b8071f4b@syzkaller.appspotmail.com Cc: # for v4.20 and up Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit a7b6f95f3ca616c0a9b03ba69f6c3e37849fc542 Author: Hans Verkuil Date: Mon May 21 04:54:56 2018 -0400 media: vim2m: use workqueue [ Upstream commit 144bd0ee304c7d0690eec285aee93019d3f30fc8 ] v4l2_ctrl uses mutexes, so we can't setup a ctrl_handler in interrupt context. Switch to a workqueue instead and drop the timer. Signed-off-by: Hans Verkuil Reviewed-by: Mauro Carvalho Chehab Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit e432a58d7a0de0a20b518fe947c39d0b43a070ab Author: Harald Freudenberger Date: Fri Nov 9 14:59:24 2018 +0100 s390/zcrypt: reinit ap queue state machine during device probe [ Upstream commit 104f708fd1241b22f808bdf066ab67dc5a051de5 ] Until the vfio-ap driver came into live there was a well known agreement about the way how ap devices are initialized and their states when the driver's probe function is called. However, the vfio device driver when receiving an ap queue device does additional resets thereby removing the registration for interrupts for the ap device done by the ap bus core code. So when later the vfio driver releases the device and one of the default zcrypt drivers takes care of the device the interrupt registration needs to get renewed. The current code does no renew and result is that requests send into such a queue will never see a reply processed - the application hangs. This patch adds a function which resets the aq queue state machine for the ap queue device and triggers the walk through the initial states (which are reset and registration for interrupts). This function is now called before the driver's probe function is invoked. When the association between driver and device is released, the driver's remove function is called. The current implementation calls a ap queue function ap_queue_remove(). This invokation has been moved to the ap bus function to make the probe / remove pair for ap bus and drivers more symmetric. Fixes: 7e0bdbe5c21c ("s390/zcrypt: AP bus support for alternate driver(s)") Cc: stable@vger.kernel.org # 4.19+ Signed-off-by: Harald Freudenberger Reviewd-by: Tony Krowiak Reviewd-by: Martin Schwidefsky Signed-off-by: Martin Schwidefsky Signed-off-by: Sasha Levin commit a4f404af3ca83859ed5fd09b2f60972337847724 Author: Bartosz Golaszewski Date: Wed Nov 21 10:35:16 2018 +0100 ARM: davinci: dm644x: define gpio interrupts as separate resources [ Upstream commit adcf60ce14c8250761af9de907eb6c7d096c26d3 ] Since commit eb3744a2dd01 ("gpio: davinci: Do not assume continuous IRQ numbering") the davinci GPIO driver fails to probe if we boot in legacy mode from any of the board files. Since the driver now expects every interrupt to be defined as a separate resource, split the definition of IRQ resources instead of having a single continuous interrupt range. Fixes: eb3744a2dd01 ("gpio: davinci: Do not assume continuous IRQ numbering") Cc: stable@vger.kernel.org Signed-off-by: Bartosz Golaszewski Signed-off-by: Sekhar Nori Signed-off-by: Sasha Levin commit 8d6b2b24ca8500e754cb004c671f967bcfa9a3cf Author: Bartosz Golaszewski Date: Wed Nov 21 10:35:15 2018 +0100 ARM: davinci: dm355: define gpio interrupts as separate resources [ Upstream commit 27db7baab640ea28d7994eda943fef170e347081 ] Since commit eb3744a2dd01 ("gpio: davinci: Do not assume continuous IRQ numbering") the davinci GPIO driver fails to probe if we boot in legacy mode from any of the board files. Since the driver now expects every interrupt to be defined as a separate resource, split the definition of IRQ resources instead of having a single continuous interrupt range. Fixes: eb3744a2dd01 ("gpio: davinci: Do not assume continuous IRQ numbering") Cc: stable@vger.kernel.org Signed-off-by: Bartosz Golaszewski Signed-off-by: Sekhar Nori Signed-off-by: Sasha Levin commit d31f2b61e7f91d0c746b056e1a735afce1080ba9 Author: Bartosz Golaszewski Date: Wed Nov 21 10:35:14 2018 +0100 ARM: davinci: dm646x: define gpio interrupts as separate resources [ Upstream commit 2c9c83491f30afbce25796e185cd4d5e36080e31 ] Since commit eb3744a2dd01 ("gpio: davinci: Do not assume continuous IRQ numbering") the davinci GPIO driver fails to probe if we boot in legacy mode from any of the board files. Since the driver now expects every interrupt to be defined as a separate resource, split the definition of IRQ resources instead of having a single continuous interrupt range. Fixes: eb3744a2dd01 ("gpio: davinci: Do not assume continuous IRQ numbering") Cc: stable@vger.kernel.org Signed-off-by: Bartosz Golaszewski Signed-off-by: Sekhar Nori Signed-off-by: Sasha Levin commit 4883e9e66f76da1134cb4edf297b79377ff1cbec Author: Bartosz Golaszewski Date: Wed Nov 21 10:35:13 2018 +0100 ARM: davinci: dm365: define gpio interrupts as separate resources [ Upstream commit 193c04374e281a56c7d4f96e66d329671945bebe ] Since commit eb3744a2dd01 ("gpio: davinci: Do not assume continuous IRQ numbering") the davinci GPIO driver fails to probe if we boot in legacy mode from any of the board files. Since the driver now expects every interrupt to be defined as a separate resource, split the definition of IRQ resources instead of having a single continuous interrupt range. Fixes: eb3744a2dd01 ("gpio: davinci: Do not assume continuous IRQ numbering") Cc: stable@vger.kernel.org Signed-off-by: Bartosz Golaszewski Signed-off-by: Sekhar Nori Signed-off-by: Sasha Levin commit 0a6c3bdae2c9a433d932f36a9ecd8f1ad511d0f8 Author: Bartosz Golaszewski Date: Wed Nov 21 10:35:12 2018 +0100 ARM: davinci: da8xx: define gpio interrupts as separate resources [ Upstream commit 58a0afbf4c99ac355df16773af835b919b9432ee ] Since commit eb3744a2dd01 ("gpio: davinci: Do not assume continuous IRQ numbering") the davinci GPIO driver fails to probe if we boot in legacy mode from any of the board files. Since the driver now expects every interrupt to be defined as a separate resource, split the definition of IRQ resources instead of having a single continuous interrupt range. Fixes: eb3744a2dd01 ("gpio: davinci: Do not assume continuous IRQ numbering") Cc: stable@vger.kernel.org Signed-off-by: Bartosz Golaszewski Signed-off-by: Sekhar Nori Signed-off-by: Sasha Levin commit 016218ef6bb057ac494ea59caeb928492c2fcb6e Author: Lyude Paul Date: Mon Nov 19 19:44:55 2018 +0000 drm/amd/dm: Understand why attaching path/tile properties are needed [ Upstream commit 04ac4b0ed412f65230b456fcd9aa07e13befff89 ] Path property is used for userspace to know what MST connector goes to what actual DRM DisplayPort connector, the tiling property is for tiling configurations. Not sure what else there is to figure out. Signed-off-by: Lyude Paul Reviewed-by: Jerry (Fangzhi) Zuo Cc: Stable Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 853dc0759586fb6a8cb3b2a659493d63796fe0f1 Author: Rex Zhu Date: Tue Nov 13 11:15:56 2018 +0800 drm/amd/pp: Fix truncated clock value when set watermark [ Upstream commit 4d454e9ffdb1ef5a51ebc147b5389c96048db683 ] the clk value should be tranferred to MHz first and then transfer to uint16. otherwise, the clock value will be truncated. Reviewed-by: Alex Deucher Reported-by: Hersen Wu Signed-off-by: Rex Zhu Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 5faabd22ed64df5c581f5224fcdbf822ab60a152 Author: David Francis Date: Thu Oct 18 11:21:15 2018 -0400 powerplay: Respect units on max dcfclk watermark [ Upstream commit f191415b24a3ad3fa22088af7cd7fc328a2f469f ] In a refactor, the watermark clock inputs to powerplay from DC were changed from units of 10kHz to kHz clocks. One division by 100 was not converted into a division by 1000. Signed-off-by: David Francis Reviewed-by: Harry Wentland Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 11bedb2e77a061b4ea3ca5fed5a06c5945168bb9 Author: Dexuan Cui Date: Thu Oct 18 05:09:30 2018 +0000 Drivers: hv: kvp: Fix the recent regression caused by incorrect clean-up [ Upstream commit e670de54c813b5bc3672dd1c67871dc60e9206f4 ] In kvp_send_key(), we do need call process_ib_ipinfo() if message->kvp_hdr.operation is KVP_OP_GET_IP_INFO, because it turns out the userland hv_kvp_daemon needs the info of operation, adapter_id and addr_family. With the incorrect fc62c3b1977d, the host can't get the VM's IP via KVP. And, fc62c3b1977d added a "break;", but actually forgot to initialize the key_size/value in the case of KVP_OP_SET, so the default key_size of 0 is passed to the kvp daemon, and the pool files /var/lib/hyperv/.kvp_pool_* can't be updated. This patch effectively rolls back the previous fc62c3b1977d, and correctly fixes the "this statement may fall through" warnings. This patch is tested on WS 2012 R2 and 2016. Fixes: fc62c3b1977d ("Drivers: hv: kvp: Fix two "this statement may fall through" warnings") Signed-off-by: Dexuan Cui Cc: K. Y. Srinivasan Cc: Stephen Hemminger Signed-off-by: Haiyang Zhang Cc: Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 74ff258346e488407adaacaee902260e97210ec8 Author: Dexuan Cui Date: Sun Sep 23 21:10:42 2018 +0000 Drivers: hv: kvp: Fix the indentation of some "break" statements [ Upstream commit d544c22d6951be3386ac59bb9a99c9bc566b3f09 ] No functional change. Signed-off-by: Dexuan Cui Cc: K. Y. Srinivasan Cc: Haiyang Zhang Cc: Stephen Hemminger Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e352d8eb9394af1897cfeaaafe8fd946269f6637 Author: Lyude Paul Date: Mon Oct 8 19:24:30 2018 -0400 drm/atomic_helper: Disallow new modesets on unregistered connectors [ Upstream commit 4d80273976bf880c4bed9359b8f2d45663140c86 ] With the exception of modesets which would switch the DPMS state of a connector from on to off, we want to make sure that we disallow all modesets which would result in enabling a new monitor or a new mode configuration on a monitor if the connector for the display in question is no longer registered. This allows us to stop userspace from trying to enable new displays on connectors for an MST topology that were just removed from the system, without preventing userspace from disabling DPMS on those connectors. Changes since v5: - Fix typo in comment, nothing else Signed-off-by: Lyude Paul Reviewed-by: Daniel Vetter Cc: stable@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20181008232437.5571-2-lyude@redhat.com Signed-off-by: Sasha Levin commit cff9e1e331519b107df742fc99b02fe018dd494d Author: Imre Deak Date: Tue Oct 16 19:00:11 2018 +0300 drm/i915/gen9+: Fix initial readout for Y tiled framebuffers [ Upstream commit 914a4fd8cd28016038ce749a818a836124a8d270 ] If BIOS configured a Y tiled FB we failed to set up the backing object tiling accordingly, leading to a lack of GT fence installed and a garbled console. The problem was bisected to commit 011f22eb545a ("drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers v2") but it just revealed a pre-existing issue. Kudos to Ville who suspected a missing fence looking at the corruption on the screen. Cc: Ville Syrjälä Cc: Mika Westerberg Cc: Hans de Goede Cc: Cc: Reported-by: Mika Westerberg Reported-by: Tested-by: Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108264 Fixes: bc8d7dffacb1 ("drm/i915/skl: Provide a Skylake version of get_plane_config()") Signed-off-by: Imre Deak Reviewed-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20181016160011.28347-1-imre.deak@intel.com Signed-off-by: Sasha Levin commit 8ccbb1d24c26ab7cf1bcd94d5cd75377bea95ec0 Author: Dhinakaran Pandiyan Date: Tue Aug 21 18:50:53 2018 -0700 drm/i915: Rename PLANE_CTL_DECOMPRESSION_ENABLE [ Upstream commit 53867b46fa8443713b3aee520d6ca558b222d829 ] Rename PLANE_CTL_DECOMPRESSION_ENABLE to resemble the bpsec name - PLANE_CTL_RENDER_DECOMPRESSION_ENABLE Suggested-by: Rodrigo Vivi Cc: Daniel Vetter Signed-off-by: Dhinakaran Pandiyan Reviewed-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20180822015053.1420-2-dhinakaran.pandiyan@intel.com Signed-off-by: Sasha Levin commit 4b2dfc0e2d44e7fdd8fd5d6b1d25eef0c10cf3f7 Author: Lyude Paul Date: Mon Oct 8 19:24:34 2018 -0400 drm/i915: Fix intel_dp_mst_best_encoder() [ Upstream commit a9f9ca33d1fe9325f414914be526c0fc4ba5281c ] Currently, i915 appears to rely on blocking modesets on no-longer-present MSTB ports by simply returning NULL for ->best_encoder(), which in turn causes any new atomic commits that don't disable the CRTC to fail. This is wrong however, since we still want to allow userspace to disable CRTCs on no-longer-present MSTB ports by changing the DPMS state to off and this still requires that we retrieve an encoder. So, fix this by always returning a valid encoder regardless of the state of the MST port. Changes since v1: - Remove mst atomic helper, since this got replaced with a much simpler solution Signed-off-by: Lyude Paul Reviewed-by: Daniel Vetter Cc: stable@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20181008232437.5571-6-lyude@redhat.com Signed-off-by: Sasha Levin commit 796469e361ed70d19d35b564a440befc5883a32b Author: Vitaly Kuznetsov Date: Tue Oct 16 18:50:06 2018 +0200 x86/kvm/lapic: preserve gfn_to_hva_cache len on cache reinit [ Upstream commit a7c42bb6da6b1b54b2e7bd567636d72d87b10a79 ] vcpu->arch.pv_eoi is accessible through both HV_X64_MSR_VP_ASSIST_PAGE and MSR_KVM_PV_EOI_EN so on migration userspace may try to restore them in any order. Values match, however, kvm_lapic_enable_pv_eoi() uses different length: for Hyper-V case it's the whole struct hv_vp_assist_page, for KVM native case it is 8. In case we restore KVM-native MSR last cache will be reinitialized with len=8 so trying to access VP assist page beyond 8 bytes with kvm_read_guest_cached() will fail. Check if we re-initializing cache for the same address and preserve length in case it was greater. Signed-off-by: Vitaly Kuznetsov Cc: stable@vger.kernel.org Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit cdad0f65050e1431bddf1896112f738fc76ad598 Author: Ladi Prosek Date: Tue Oct 16 18:49:59 2018 +0200 KVM: hyperv: define VP assist page helpers [ Upstream commit 72bbf9358c3676bd89dc4bd8fb0b1f2a11c288fc ] The state related to the VP assist page is still managed by the LAPIC code in the pv_eoi field. Signed-off-by: Ladi Prosek Signed-off-by: Vitaly Kuznetsov Reviewed-by: Liran Alon Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit b0d9043bdbe693319b4eaa2523003654bf6e200e Author: Vitaly Kuznetsov Date: Wed Sep 26 19:02:56 2018 +0200 KVM: x86: hyperv: keep track of mismatched VP indexes [ Upstream commit 87ee613d076351950b74383215437f841ebbeb75 ] In most common cases VP index of a vcpu matches its vcpu index. Userspace is, however, free to set any mapping it wishes and we need to account for that when we need to find a vCPU with a particular VP index. To keep search algorithms optimal in both cases introduce 'num_mismatched_vp_indexes' counter showing how many vCPUs with mismatching VP index we have. In case the counter is zero we can assume vp_index == vcpu_idx. Signed-off-by: Vitaly Kuznetsov Reviewed-by: Roman Kagan Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit f031fd03e22e2193f996c6050aacca675e33d2fc Author: Vitaly Kuznetsov Date: Wed Sep 26 19:02:55 2018 +0200 KVM: x86: hyperv: consistently use 'hv_vcpu' for 'struct kvm_vcpu_hv' variables [ Upstream commit 1779a39f786397760ae7a7cc03cf37697d8ae58d ] Rename 'hv' to 'hv_vcpu' in kvm_hv_set_msr/kvm_hv_get_msr(); 'hv' is 'reserved' for 'struct kvm_hv' variables across the file. Signed-off-by: Vitaly Kuznetsov Reviewed-by: Roman Kagan Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 0b535f7b95af9fa030a03243f62f29774eb5ff90 Author: Vitaly Kuznetsov Date: Wed Aug 22 12:18:28 2018 +0200 KVM: x86: hyperv: enforce vp_index < KVM_MAX_VCPUS [ Upstream commit 9170200ec0ebad70e5b9902bc93e2b1b11456a3b ] Hyper-V TLFS (5.0b) states: > Virtual processors are identified by using an index (VP index). The > maximum number of virtual processors per partition supported by the > current implementation of the hypervisor can be obtained through CPUID > leaf 0x40000005. A virtual processor index must be less than the > maximum number of virtual processors per partition. Forbid userspace to set VP_INDEX above KVM_MAX_VCPUS. get_vcpu_by_vpidx() can now be optimized to bail early when supplied vpidx is >= KVM_MAX_VCPUS. Signed-off-by: Vitaly Kuznetsov Reviewed-by: Roman Kagan Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 8e91cc7f7f916d5ce310026591d549aa5bf5952d Author: Feifei Xu Date: Tue Oct 16 14:54:46 2018 +0800 drm/amdgpu: Update gc_9_0 golden settings. [ Upstream commit c55045adf7210d246a016c961916f078ed31a951 ] Add mmDB_DEBUG3 settings. Signed-off-by: Feifei Xu Reviewed-by: Evan Quan Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit bcc3bd761ab5f2d4539f396a1fd7d0c7dbd955c9 Author: Feifei Xu Date: Thu Jul 26 12:31:34 2018 +0800 drm/amdgpu/gfx9: Update gfx9 golden settings. [ Upstream commit 54d682d9a5b357eb711994fa94ef1bc44d7ce9d9 ] Update the goldensettings for vega20. Signed-off-by: Feifei Xu Signed-off-by: Evan Quan Reviewed-by: Hawking Zhang Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 2c2cf2245ff60a1dedeeaf8c62df4aa1919ea4b7 Author: Brian Norris Date: Mon Oct 8 19:08:05 2018 -0700 remoteproc: qcom: q6v5-mss: add SCM probe dependency [ Upstream commit bbcda30271752bb7490f2e2aef5411dbcae69116 ] The memory ownership transfer request is performed using SCM, ensure that SCM is available before we probe the driver if memory protection is needed by the subsystem. Fixes: 6c5a9dc2481b ("remoteproc: qcom: Make secure world call for mem ownership switch") Cc: stable@vger.kernel.org Signed-off-by: Brian Norris [bjorn: Added condition for need_mem_protection, updated commit message] Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 4d9707586ec70f6bc78eef980c03bfe953a0eb52 Author: Zhimin Gu Date: Fri Sep 21 14:26:24 2018 +0800 x86, hibernate: Fix nosave_regions setup for hibernation [ Upstream commit cc55f7537db6af371e9c1c6a71161ee40f918824 ] On 32bit systems, nosave_regions(non RAM areas) located between max_low_pfn and max_pfn are not excluded from hibernation snapshot currently, which may result in a machine check exception when trying to access these unsafe regions during hibernation: [ 612.800453] Disabling lock debugging due to kernel taint [ 612.805786] mce: [Hardware Error]: CPU 0: Machine Check Exception: 5 Bank 6: fe00000000801136 [ 612.814344] mce: [Hardware Error]: RIP !INEXACT! 60:<00000000d90be566> {swsusp_save+0x436/0x560} [ 612.823167] mce: [Hardware Error]: TSC 1f5939fe276 ADDR dd000000 MISC 30e0000086 [ 612.830677] mce: [Hardware Error]: PROCESSOR 0:306c3 TIME 1529487426 SOCKET 0 APIC 0 microcode 24 [ 612.839581] mce: [Hardware Error]: Run the above through 'mcelog --ascii' [ 612.846394] mce: [Hardware Error]: Machine check: Processor context corrupt [ 612.853380] Kernel panic - not syncing: Fatal machine check [ 612.858978] Kernel Offset: 0x18000000 from 0xc1000000 (relocation range: 0xc0000000-0xf7ffdfff) This is because on 32bit systems, pages above max_low_pfn are regarded as high memeory, and accessing unsafe pages might cause expected MCE. On the problematic 32bit system, there are reserved memory above low memory, which triggered the MCE: e820 memory mapping: [ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009d7ff] usable [ 0.000000] BIOS-e820: [mem 0x000000000009d800-0x000000000009ffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved [ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000d160cfff] usable [ 0.000000] BIOS-e820: [mem 0x00000000d160d000-0x00000000d1613fff] ACPI NVS [ 0.000000] BIOS-e820: [mem 0x00000000d1614000-0x00000000d1a44fff] usable [ 0.000000] BIOS-e820: [mem 0x00000000d1a45000-0x00000000d1ecffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000d1ed0000-0x00000000d7eeafff] usable [ 0.000000] BIOS-e820: [mem 0x00000000d7eeb000-0x00000000d7ffffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000d8000000-0x00000000d875ffff] usable [ 0.000000] BIOS-e820: [mem 0x00000000d8760000-0x00000000d87fffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000d8800000-0x00000000d8fadfff] usable [ 0.000000] BIOS-e820: [mem 0x00000000d8fae000-0x00000000d8ffffff] ACPI data [ 0.000000] BIOS-e820: [mem 0x00000000d9000000-0x00000000da71bfff] usable [ 0.000000] BIOS-e820: [mem 0x00000000da71c000-0x00000000da7fffff] ACPI NVS [ 0.000000] BIOS-e820: [mem 0x00000000da800000-0x00000000dbb8bfff] usable [ 0.000000] BIOS-e820: [mem 0x00000000dbb8c000-0x00000000dbffffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000dd000000-0x00000000df1fffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000f8000000-0x00000000fbffffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000fec00000-0x00000000fec00fff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000fed00000-0x00000000fed03fff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000ff000000-0x00000000ffffffff] reserved [ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000041edfffff] usable Fix this problem by changing pfn limit from max_low_pfn to max_pfn. This fix does not impact 64bit system because on 64bit max_low_pfn is the same as max_pfn. Signed-off-by: Zhimin Gu Acked-by: Pavel Machek Signed-off-by: Chen Yu Acked-by: Thomas Gleixner Cc: All applicable Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 805e0e46eb54e9655bbfe1692b55e59a5b534dba Author: Dexuan Cui Date: Sun Sep 23 21:10:43 2018 +0000 Drivers: hv: kvp: Fix two "this statement may fall through" warnings [ Upstream commit fc62c3b1977d62e6374fd6e28d371bb42dfa5c9d ] We don't need to call process_ib_ipinfo() if message->kvp_hdr.operation is KVP_OP_GET_IP_INFO in kvp_send_key(), because here we just need to pass on the op code from the host to the userspace; when the userspace returns the info requested by the host, we pass the info on to the host in kvp_respond_to_host() -> process_ob_ipinfo(). BTW, the current buggy code actually doesn't cause any harm, because only message->kvp_hdr.operation is used by the userspace, in the case of KVP_OP_GET_IP_INFO. The patch also adds a missing "break;" in kvp_send_key(). BTW, the current buggy code actually doesn't cause any harm, because in the case of KVP_OP_SET, the unexpected fall-through corrupts message->body.kvp_set.data.key_size, but that is not really used: see the definition of struct hv_kvp_exchg_msg_value. Signed-off-by: Dexuan Cui Cc: K. Y. Srinivasan Cc: Haiyang Zhang Cc: Stephen Hemminger Cc: Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 3f3beae228422dbe7dd5497c7750a3ea8402c91e Author: David Howells Date: Fri Sep 28 00:51:20 2018 +0100 keys: Fix the use of the C++ keyword "private" in uapi/linux/keyctl.h [ Upstream commit 2ecefa0a15fd0ef88b9cd5d15ceb813008136431 ] The keyctl_dh_params struct in uapi/linux/keyctl.h contains the symbol "private" which means that the header file will cause compilation failure if #included in to a C++ program. Further, the patch that added the same struct to the keyutils package named the symbol "priv", not "private". The previous attempt to fix this (commit 8a2336e549d3) did so by simply renaming the kernel's copy of the field to dh_private, but this then breaks existing userspace and as such has been reverted (commit 8c0f9f5b309d). [And note, to those who think that wrapping the struct in extern "C" {} will work: it won't; that only changes how symbol names are presented to the assembler and linker.]. Instead, insert an anonymous union around the "private" member and add a second member in there with the name "priv" to match the one in the keyutils package. The "private" member is then wrapped in !__cplusplus cpp-conditionals to hide it from C++. Fixes: ddbb41148724 ("KEYS: Add KEYCTL_DH_COMPUTE command") Fixes: 8a2336e549d3 ("uapi/linux/keyctl.h: don't use C++ reserved keyword as a struct member name") Signed-off-by: David Howells cc: Randy Dunlap cc: Lubomir Rintel cc: James Morris cc: Mat Martineau cc: Stephan Mueller cc: Andrew Morton cc: Linus Torvalds cc: stable@vger.kernel.org Signed-off-by: James Morris Signed-off-by: Sasha Levin commit bac1c4edb5c487c5a755f8631e6bb0506b90cc8e Author: Giridhar Malavali Date: Wed Sep 26 22:05:18 2018 -0700 scsi: qla2xxx: Move log messages before issuing command to firmware [ Upstream commit 9fe278f44b4bc06cc61e33b2af65f87d507d13d0 ] There is a probability that the SRB structure might have been released by the time the debug log message dereferences it. This patch moved the log messages before the command is issued to the firmware to prevent unknown behavior and kernel crash Fixes: 726b85487067 ("qla2xxx: Add framework for async fabric discovery") Cc: Signed-off-by: Giridhar Malavali Reviewed-by: Ewan D. Milne Signed-off-by: Himanshu Madhani Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 6e087eae89df5f9904fe07e5bb31d33ae3140fb2 Author: Hans Verkuil Date: Thu Sep 13 08:00:39 2018 -0400 media: cec: remove cec-edid.c [ Upstream commit f94d463f1b7f83d465ed77521821583dbcdaa3c5 ] Move cec_get_edid_phys_addr() to cec-adap.c. It's not worth keeping a separate source for this. Signed-off-by: Hans Verkuil Cc: # for v4.17 and up Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 851308450a8f38f9f9b0b6591edd4ae286d4442f Author: Hans Verkuil Date: Thu Sep 13 03:40:56 2018 -0400 media: cec/v4l2: move V4L2 specific CEC functions to V4L2 [ Upstream commit 9cfd2753f8f3923f89cbb15f940f3aa0e7202d3e ] Several CEC functions are actually specific for use with receivers, i.e. they should be part of the V4L2 subsystem, not CEC. These functions deal with validating and modifying EDIDs for (HDMI) receivers, and they do not actually have anything to do with the CEC subsystem and whether or not CEC is enabled. The problem was that if the CEC_CORE config option was not set, then these functions would become stubs, but that's not right: they should always be valid. So replace the cec_ prefix by v4l2_ and move them to v4l2-dv-timings.c. Update all drivers that call these accordingly. Signed-off-by: Hans Verkuil Reported-by: Lars-Peter Clausen Cc: # for v4.17 and up Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit c09d675f294b64c607ed87c946698836db2b9530 Author: Jan-Marek Glogowski Date: Sat Aug 25 15:10:35 2018 -0400 drm/i915: Re-apply "Perform link quality check, unconditionally during long pulse" [ Upstream commit 3cf71bc9904d7ee4a25a822c5dcb54c7804ea388 ] This re-applies the workaround for "some DP sinks, [which] are a little nuts" from commit 1a36147bb939 ("drm/i915: Perform link quality check unconditionally during long pulse"). It makes the secondary AOC E2460P monitor connected via DP to an acer Veriton N4640G usable again. This hunk was dropped in commit c85d200e8321 ("drm/i915: Move SST DP link retraining into the ->post_hotplug() hook") Fixes: c85d200e8321 ("drm/i915: Move SST DP link retraining into the ->post_hotplug() hook") [Cleaned up commit message, added stable cc] Signed-off-by: Lyude Paul Signed-off-by: Jan-Marek Glogowski Cc: stable@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20180825191035.3945-1-lyude@redhat.com Signed-off-by: Sasha Levin commit 3015291b2fb5aaa01a2ff15706f6c6e4f6c8f91f Author: YueHaibing Date: Tue Jun 11 23:00:07 2019 +0800 kernel/module: Fix mem leak in module_add_modinfo_attrs [ Upstream commit bc6f2a757d525e001268c3658bd88822e768f8db ] In module_add_modinfo_attrs if sysfs_create_file fails, we forget to free allocated modinfo_attrs and roll back the sysfs files. Fixes: 03e88ae1b13d ("[PATCH] fix module sysfs files reference counting") Reviewed-by: Miroslav Benes Signed-off-by: YueHaibing Signed-off-by: Jessica Yu Signed-off-by: Sasha Levin commit 9c49f7811f823b45a4ddd825152de2e11ceaa73e Author: Jessica Yu Date: Tue Jul 23 15:26:28 2019 +0200 modules: always page-align module section allocations [ Upstream commit 38f054d549a869f22a02224cd276a27bf14b6171 ] Some arches (e.g., arm64, x86) have moved towards non-executable module_alloc() allocations for security hardening reasons. That means that the module loader will need to set the text section of a module to executable, regardless of whether or not CONFIG_STRICT_MODULE_RWX is set. When CONFIG_STRICT_MODULE_RWX=y, module section allocations are always page-aligned to handle memory rwx permissions. On some arches with CONFIG_STRICT_MODULE_RWX=n however, when setting the module text to executable, the BUG_ON() in frob_text() gets triggered since module section allocations are not page-aligned when CONFIG_STRICT_MODULE_RWX=n. Since the set_memory_* API works with pages, and since we need to call set_memory_x() regardless of whether CONFIG_STRICT_MODULE_RWX is set, we might as well page-align all module section allocations for ease of managing rwx permissions of module sections (text, rodata, etc). Fixes: 2eef1399a866 ("modules: fix BUG when load module with rodata=n") Reported-by: Martin Kaiser Reported-by: Bartosz Golaszewski Tested-by: David Lechner Tested-by: Martin Kaiser Tested-by: Bartosz Golaszewski Signed-off-by: Jessica Yu Signed-off-by: Sasha Levin commit 84ba9ae18fbbc1c2ef3c7fc5a726568b2fc4382d Author: Brian Norris Date: Tue Oct 9 15:25:27 2018 -0700 remoteproc: qcom: q6v5: shore up resource probe handling [ Upstream commit 1e2517d126171a41f801738ffd19687836cd178a ] Commit d5269c4553a6 ("remoteproc: qcom: q6v5: Propagate EPROBE_DEFER") fixed up our probe code to handle -EPROBE_DEFER, but it ignored one of our interrupts, and it also didn't really handle all the other error codes you might get (e.g., with a bad DT definition). Handle those all explicitly. Fixes: d5269c4553a6 ("remoteproc: qcom: q6v5: Propagate EPROBE_DEFER") Reviewed-by: Douglas Anderson Signed-off-by: Brian Norris Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 56944c0b9774ddc5bf6d974b924fca4fb6ad63ac Author: Nathan Chancellor Date: Thu Oct 18 12:13:40 2018 -0700 clk: s2mps11: Add used attribute to s2mps11_dt_match [ Upstream commit 9c940bbe2bb47e03ca5e937d30b6a50bf9c0e671 ] Clang warns after commit 8985167ecf57 ("clk: s2mps11: Fix matching when built as module and DT node contains compatible"): drivers/clk/clk-s2mps11.c:242:34: warning: variable 's2mps11_dt_match' is not needed and will not be emitted [-Wunneeded-internal-declaration] static const struct of_device_id s2mps11_dt_match[] = { ^ 1 warning generated. This warning happens when a variable is used in some construct that doesn't require a reference to that variable to be emitted in the symbol table; in this case, it's MODULE_DEVICE_TABLE, which only needs to hold the data of the variable, not the variable itself. $ nm -S drivers/clk/clk-s2mps11.o | rg s2mps11_dt_match 00000078 000003d4 R __mod_of__s2mps11_dt_match_device_table Normally, with device ID table variables, it means that the variable just needs to be tied to the device declaration at the bottom of the file, like s2mps11_clk_id: $ nm -S drivers/clk/clk-s2mps11.o | rg s2mps11_clk_id 00000000 00000078 R __mod_platform__s2mps11_clk_id_device_table 00000000 00000078 r s2mps11_clk_id However, because the comment above this deliberately doesn't want this variable added to .of_match_table, we need to mark s2mps11_dt_match as __used to silence this warning. This makes it clear to Clang that the variable is used for something, even if a reference to it isn't being emitted. Signed-off-by: Nathan Chancellor Fixes: 8985167ecf57 ("clk: s2mps11: Fix matching when built as module and DT node contains compatible") Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 480101a4aea26d908c920acb8c50656cbada5fec Author: Hannes Reinecke Date: Fri May 3 11:43:52 2019 +0200 nvme-fc: use separate work queue to avoid warning [ Upstream commit 8730c1ddb69bdeeb10c1f613a4e15e95862b1981 ] When tearing down a controller the following warning is issued: WARNING: CPU: 0 PID: 30681 at ../kernel/workqueue.c:2418 check_flush_dependency This happens as the err_work workqueue item is scheduled on the system workqueue (which has WQ_MEM_RECLAIM not set), but is flushed from a workqueue which has WQ_MEM_RECLAIM set. Fix this by providing an FC-NVMe specific workqueue. Fixes: 4cff280a5fcc ("nvme-fc: resolve io failures during connect") Signed-off-by: Hannes Reinecke Reviewed-by: James Smart Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 5f147150b75307c8c0220ec4a4bd4f9a82018a54 Author: David Abdurachmanov Date: Thu Dec 6 11:26:26 2018 +0100 riscv: remove unused variable in ftrace [ Upstream commit 397182e0db56b8894a43631ce72de14d90a29834 ] Noticed while building kernel-4.20.0-0.rc5.git2.1.fc30 for Fedora 30/RISCV. [..] BUILDSTDERR: arch/riscv/kernel/ftrace.c: In function 'prepare_ftrace_return': BUILDSTDERR: arch/riscv/kernel/ftrace.c:135:6: warning: unused variable 'err' [-Wunused-variable] BUILDSTDERR: int err; BUILDSTDERR: ^~~ [..] Signed-off-by: David Abdurachmanov Fixes: e949b6db51dc1 ("riscv/function_graph: Simplify with function_graph_enter()") Reviewed-by: Olof Johansson Acked-by: Steven Rostedt (VMware) Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit 8d23872c7539985433f38628d8216ef9320f46ac Author: Nicolas Boichat Date: Thu Jul 11 20:52:27 2019 -0700 scripts/decode_stacktrace: match basepath using shell prefix operator, not regex [ Upstream commit 31013836a71e07751a6827f9d2ad41ef502ddaff ] The basepath may contain special characters, which would confuse the regex matcher. ${var#prefix} does the right thing. Link: http://lkml.kernel.org/r/20190518055946.181563-1-drinkcat@chromium.org Fixes: 67a28de47faa8358 ("scripts/decode_stacktrace: only strip base path when a prefix of the path") Signed-off-by: Nicolas Boichat Reviewed-by: Stephen Boyd Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 6c550a5db18f29b7336ca295a904b5f1cc7fccbf Author: Dmitry Voytik Date: Tue Jan 22 23:38:48 2019 +0100 arm64: dts: rockchip: enable usb-host regulators at boot on rk3328-rock64 [ Upstream commit 26e2d7b03ea7ff254bf78305aa44dda62e70b78e ] After commit ef05bcb60c1a, boot from USB drives is broken. Fix this problem by enabling usb-host regulators during boot time. Fixes: ef05bcb60c1a ("arm64: dts: rockchip: fix vcc_host1_5v pin assign on rk3328-rock64") Cc: stable@vger.kernel.org Signed-off-by: Dmitry Voytik Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 573370113b24b79168289fe710c43a720676b9da Author: Fabien Dessenne Date: Fri May 31 05:18:15 2019 -0400 media: stm32-dcmi: fix irq = 0 case [ Upstream commit dbb9fcc8c2d8d4ea1104f51d4947a8a8199a2cb5 ] Manage the irq = 0 case, where we shall return an error. Fixes: b5b5a27bee58 ("media: stm32-dcmi: return appropriate error codes during probe") Signed-off-by: Fabien Dessenne Reported-by: Pavel Machek Acked-by: Pavel Machek Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 7f8b23600779b90c6b16c2558a9d751fd9b400df Author: Christophe Leroy Date: Fri May 10 06:31:28 2019 +0000 powerpc/64: mark start_here_multiplatform as __ref [ Upstream commit 9c4e4c90ec24652921e31e9551fcaedc26eec86d ] Otherwise, the following warning is encountered: WARNING: vmlinux.o(.text+0x3dc6): Section mismatch in reference from the variable start_here_multiplatform to the function .init.text:.early_setup() The function start_here_multiplatform() references the function __init .early_setup(). This is often because start_here_multiplatform lacks a __init annotation or the annotation of .early_setup is wrong. Fixes: 56c46bba9bbf ("powerpc/64: Fix booting large kernels with STRICT_KERNEL_RWX") Cc: Russell Currey Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 85a24825b2e63d5088f6c5088025bd2cf2504f45 Author: Steven Rostedt (VMware) Date: Mon Mar 4 16:35:22 2019 -0500 x86/ftrace: Fix warning and considate ftrace_jmp_replace() and ftrace_call_replace() [ Upstream commit 745cfeaac09ce359130a5451d90cb0bd4094c290 ] Arnd reported the following compiler warning: arch/x86/kernel/ftrace.c:669:23: error: 'ftrace_jmp_replace' defined but not used [-Werror=unused-function] The ftrace_jmp_replace() function now only has a single user and should be simply moved by that user. But looking at the code, it shows that ftrace_jmp_replace() is similar to ftrace_call_replace() except that instead of using the opcode of 0xe8 it uses 0xe9. It makes more sense to consolidate that function into one implementation that both ftrace_jmp_replace() and ftrace_call_replace() use by passing in the op code separate. The structure in ftrace_code_union is also modified to replace the "e8" field with the more appropriate name "op". Cc: stable@vger.kernel.org Reported-by: Arnd Bergmann Acked-by: Arnd Bergmann Link: http://lkml.kernel.org/r/20190304200748.1418790-1-arnd@arndb.de Fixes: d2a68c4effd8 ("x86/ftrace: Do not call function graph from dynamic trampolines") Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit b93aed78eb786a299590db1ff5b7076504e95ad4 Author: Hangbin Liu Date: Tue May 21 14:40:47 2019 +0800 selftests: fib_rule_tests: use pre-defined DEV_ADDR [ Upstream commit 34632975cafdd07ce80e85c2eda4e9c16b5f2faa ] DEV_ADDR is defined but not used. Use it in address setting. Do the same with IPv6 for consistency. Reported-by: David Ahern Fixes: fc82d93e57e3 ("selftests: fib_rule_tests: fix local IPv4 address typo") Signed-off-by: Hangbin Liu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 68829256e1f9ba375080e762f2c82b33a25f55e1 Author: Jason A. Donenfeld Date: Fri Jun 21 22:32:47 2019 +0200 timekeeping: Use proper ktime_add when adding nsecs in coarse offset [ Upstream commit 0354c1a3cdf31f44b035cfad14d32282e815a572 ] While this doesn't actually amount to a real difference, since the macro evaluates to the same thing, every place else operates on ktime_t using these functions, so let's not break the pattern. Fixes: e3ff9c3678b4 ("timekeeping: Repair ktime_get_coarse*() granularity") Signed-off-by: Jason A. Donenfeld Signed-off-by: Thomas Gleixner Reviewed-by: Arnd Bergmann Link: https://lkml.kernel.org/r/20190621203249.3909-1-Jason@zx2c4.com Signed-off-by: Sasha Levin commit 1aa38eceb6c006a8bb96f2922cab5d03131d9b41 Author: Manikanta Pubbisetty Date: Mon Jul 22 12:44:50 2019 +0530 {nl,mac}80211: fix interface combinations on crypto controlled devices [ Upstream commit e6f4051123fd33901e9655a675b22aefcdc5d277 ] Commit 33d915d9e8ce ("{nl,mac}80211: allow 4addr AP operation on crypto controlled devices") has introduced a change which allows 4addr operation on crypto controlled devices (ex: ath10k). This change has inadvertently impacted the interface combinations logic on such devices. General rule is that software interfaces like AP/VLAN should not be listed under supported interface combinations and should not be considered during validation of these combinations; because of the aforementioned change, AP/VLAN interfaces(if present) will be checked against interfaces supported by the device and blocks valid interface combinations. Consider a case where an AP and AP/VLAN are up and running; when a second AP device is brought up on the same physical device, this AP will be checked against the AP/VLAN interface (which will not be part of supported interface combinations of the device) and blocks second AP to come up. Add a new API cfg80211_iftype_allowed() to fix the problem, this API works for all devices with/without SW crypto control. Signed-off-by: Manikanta Pubbisetty Fixes: 33d915d9e8ce ("{nl,mac}80211: allow 4addr AP operation on crypto controlled devices") Link: https://lore.kernel.org/r/1563779690-9716-1-git-send-email-mpubbise@codeaurora.org Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 178d1337a5274e414127400f551af453aeefe312 Author: Dennis Zhou Date: Fri Jul 5 17:09:09 2019 -0400 blk-iolatency: fix STS_AGAIN handling [ Upstream commit c9b3007feca018d3f7061f5d5a14cb00766ffe9b ] The iolatency controller is based on rq_qos. It increments on rq_qos_throttle() and decrements on either rq_qos_cleanup() or rq_qos_done_bio(). a3fb01ba5af0 fixes the double accounting issue where blk_mq_make_request() may call both rq_qos_cleanup() and rq_qos_done_bio() on REQ_NO_WAIT. So checking STS_AGAIN prevents the double decrement. The above works upstream as the only way we can get STS_AGAIN is from blk_mq_get_request() failing. The STS_AGAIN handling isn't a real problem as bio_endio() skipping only happens on reserved tag allocation failures which can only be caused by driver bugs and already triggers WARN. However, the fix creates a not so great dependency on how STS_AGAIN can be propagated. Internally, we (Facebook) carry a patch that kills read ahead if a cgroup is io congested or a fatal signal is pending. This combined with chained bios progagate their bi_status to the parent is not already set can can cause the parent bio to not clean up properly even though it was successful. This consequently leaks the inflight counter and can hang all IOs under that blkg. To nip the adverse interaction early, this removes the rq_qos_cleanup() callback in iolatency in favor of cleaning up always on the rq_qos_done_bio() path. Fixes: a3fb01ba5af0 ("blk-iolatency: only account submitted bios") Debugged-by: Tejun Heo Debugged-by: Josef Bacik Signed-off-by: Dennis Zhou Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 5f33e81250a6b555d0011cdcecbdc4a83392fff8 Author: Liu Bo Date: Fri Jan 25 08:12:48 2019 +0800 Blk-iolatency: warn on negative inflight IO counter [ Upstream commit 391f552af213985d3d324c60004475759a7030c5 ] This is to catch any unexpected negative value of inflight IO counter. Signed-off-by: Liu Bo Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 91a71a61da8c7400274b2d5c82e8354ea1b19245 Author: Dexuan Cui Date: Wed Jul 31 01:25:45 2019 +0000 hv_sock: Fix hang when a connection is closed [ Upstream commit 685703b497bacea8765bb409d6b73455b73c540e ] There is a race condition for an established connection that is being closed by the guest: the refcnt is 4 at the end of hvs_release() (Note: here the 'remove_sock' is false): 1 for the initial value; 1 for the sk being in the bound list; 1 for the sk being in the connected list; 1 for the delayed close_work. After hvs_release() finishes, __vsock_release() -> sock_put(sk) *may* decrease the refcnt to 3. Concurrently, hvs_close_connection() runs in another thread: calls vsock_remove_sock() to decrease the refcnt by 2; call sock_put() to decrease the refcnt to 0, and free the sk; next, the "release_sock(sk)" may hang due to use-after-free. In the above, after hvs_release() finishes, if hvs_close_connection() runs faster than "__vsock_release() -> sock_put(sk)", then there is not any issue, because at the beginning of hvs_close_connection(), the refcnt is still 4. The issue can be resolved if an extra reference is taken when the connection is established. Fixes: a9eeb998c28d ("hv_sock: Add support for delayed close") Signed-off-by: Dexuan Cui Reviewed-by: Sunil Muthuswamy Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 86d5ae21d6b8cac3d6394093d414ffe2abf8877a Author: Sven Eckelmann Date: Thu Aug 22 08:55:36 2019 +0200 batman-adv: Only read OGM tvlv_len after buffer len check commit a15d56a60760aa9dbe26343b9a0ac5228f35d445 upstream. Multiple batadv_ogm_packet can be stored in an skbuff. The functions batadv_iv_ogm_send_to_if()/batadv_iv_ogm_receive() use batadv_iv_ogm_aggr_packet() to check if there is another additional batadv_ogm_packet in the skb or not before they continue processing the packet. The length for such an OGM is BATADV_OGM_HLEN + batadv_ogm_packet->tvlv_len. The check must first check that at least BATADV_OGM_HLEN bytes are available before it accesses tvlv_len (which is part of the header. Otherwise it might try read outside of the currently available skbuff to get the content of tvlv_len. Fixes: ef26157747d4 ("batman-adv: tvlv - basic infrastructure") Reported-by: syzbot+355cab184197dbbfa384@syzkaller.appspotmail.com Signed-off-by: Sven Eckelmann Acked-by: Antonio Quartulli Signed-off-by: Simon Wunderlich Signed-off-by: Greg Kroah-Hartman commit 4b5fee457723d983868a8cbc140c85bf13845a95 Author: Eric Dumazet Date: Mon Aug 12 04:57:27 2019 -0700 batman-adv: fix uninit-value in batadv_netlink_get_ifindex() commit 3ee1bb7aae97324ec9078da1f00cb2176919563f upstream. batadv_netlink_get_ifindex() needs to make sure user passed a correct u32 attribute. syzbot reported : BUG: KMSAN: uninit-value in batadv_netlink_dump_hardif+0x70d/0x880 net/batman-adv/netlink.c:968 CPU: 1 PID: 11705 Comm: syz-executor888 Not tainted 5.1.0+ #1 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x191/0x1f0 lib/dump_stack.c:113 kmsan_report+0x130/0x2a0 mm/kmsan/kmsan.c:622 __msan_warning+0x75/0xe0 mm/kmsan/kmsan_instr.c:310 batadv_netlink_dump_hardif+0x70d/0x880 net/batman-adv/netlink.c:968 genl_lock_dumpit+0xc6/0x130 net/netlink/genetlink.c:482 netlink_dump+0xa84/0x1ab0 net/netlink/af_netlink.c:2253 __netlink_dump_start+0xa3a/0xb30 net/netlink/af_netlink.c:2361 genl_family_rcv_msg net/netlink/genetlink.c:550 [inline] genl_rcv_msg+0xfc1/0x1a40 net/netlink/genetlink.c:627 netlink_rcv_skb+0x431/0x620 net/netlink/af_netlink.c:2486 genl_rcv+0x63/0x80 net/netlink/genetlink.c:638 netlink_unicast_kernel net/netlink/af_netlink.c:1311 [inline] netlink_unicast+0xf3e/0x1020 net/netlink/af_netlink.c:1337 netlink_sendmsg+0x127e/0x12f0 net/netlink/af_netlink.c:1926 sock_sendmsg_nosec net/socket.c:651 [inline] sock_sendmsg net/socket.c:661 [inline] ___sys_sendmsg+0xcc6/0x1200 net/socket.c:2260 __sys_sendmsg net/socket.c:2298 [inline] __do_sys_sendmsg net/socket.c:2307 [inline] __se_sys_sendmsg+0x305/0x460 net/socket.c:2305 __x64_sys_sendmsg+0x4a/0x70 net/socket.c:2305 do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291 entry_SYSCALL_64_after_hwframe+0x63/0xe7 RIP: 0033:0x440209 Fixes: b60620cf567b ("batman-adv: netlink: hardif query") Signed-off-by: Eric Dumazet Reported-by: syzbot Signed-off-by: Sven Eckelmann Signed-off-by: Simon Wunderlich Signed-off-by: Greg Kroah-Hartman commit 47a0f70d7d9ac3d6b1a96b312d07bc67af3834e9 Author: Gustavo Romero Date: Wed Sep 4 00:55:27 2019 -0400 powerpc/tm: Fix FP/VMX unavailable exceptions inside a transaction commit 8205d5d98ef7f155de211f5e2eb6ca03d95a5a60 upstream. When we take an FP unavailable exception in a transaction we have to account for the hardware FP TM checkpointed registers being incorrect. In this case for this process we know the current and checkpointed FP registers must be the same (since FP wasn't used inside the transaction) hence in the thread_struct we copy the current FP registers to the checkpointed ones. This copy is done in tm_reclaim_thread(). We use thread->ckpt_regs.msr to determine if FP was on when in userspace. thread->ckpt_regs.msr represents the state of the MSR when exiting userspace. This is setup by check_if_tm_restore_required(). Unfortunatley there is an optimisation in giveup_all() which returns early if tsk->thread.regs->msr (via local variable `usermsr`) has FP=VEC=VSX=SPE=0. This optimisation means that check_if_tm_restore_required() is not called and hence thread->ckpt_regs.msr is not updated and will contain an old value. This can happen if due to load_fp=255 we start a userspace process with MSR FP=1 and then we are context switched out. In this case thread->ckpt_regs.msr will contain FP=1. If that same process is then context switched in and load_fp overflows, MSR will have FP=0. If that process now enters a transaction and does an FP instruction, the FP unavailable will not update thread->ckpt_regs.msr (the bug) and MSR FP=1 will be retained in thread->ckpt_regs.msr. tm_reclaim_thread() will then not perform the required memcpy and the checkpointed FP regs in the thread struct will contain the wrong values. The code path for this happening is: Userspace: Kernel Start userspace with MSR FP/VEC/VSX/SPE=0 TM=1 < ----- ... tbegin bne fp instruction FP unavailable ---- > fp_unavailable_tm() tm_reclaim_current() tm_reclaim_thread() giveup_all() return early since FP/VMX/VSX=0 /* ckpt MSR not updated (Incorrect) */ tm_reclaim() /* thread_struct ckpt FP regs contain junk (OK) */ /* Sees ckpt MSR FP=1 (Incorrect) */ no memcpy() performed /* thread_struct ckpt FP regs not fixed (Incorrect) */ tm_recheckpoint() /* Put junk in hardware checkpoint FP regs */ .... < ----- Return to userspace with MSR TM=1 FP=1 with junk in the FP TM checkpoint TM rollback reads FP junk This is a data integrity problem for the current process as the FP registers are corrupted. It's also a security problem as the FP registers from one process may be leaked to another. This patch moves up check_if_tm_restore_required() in giveup_all() to ensure thread->ckpt_regs.msr is updated correctly. A simple testcase to replicate this will be posted to tools/testing/selftests/powerpc/tm/tm-poison.c Similarly for VMX. This fixes CVE-2019-15030. Fixes: f48e91e87e67 ("powerpc/tm: Fix FP and VMX register corruption") Cc: stable@vger.kernel.org # 4.12+ Signed-off-by: Gustavo Romero Signed-off-by: Michael Neuling Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20190904045529.23002-1-gromero@linux.vnet.ibm.com Signed-off-by: Greg Kroah-Hartman commit 6e7040d65a718cd1cb0d4c914f3ff1d7735eb844 Author: Tiwei Bie Date: Wed Aug 28 13:37:00 2019 +0800 vhost/test: fix build for vhost test - again commit 264b563b8675771834419057cbe076c1a41fb666 upstream. Since vhost_exceeds_weight() was introduced, callers need to specify the packet weight and byte weight in vhost_dev_init(). Note that, the packet weight isn't counted in this patch to keep the original behavior unchanged. Fixes: e82b9b0727ff ("vhost: introduce vhost_exceeds_weight()") Cc: stable@vger.kernel.org Signed-off-by: Tiwei Bie Signed-off-by: Michael S. Tsirkin Acked-by: Jason Wang Signed-off-by: Greg Kroah-Hartman commit 4f45483faadf13e7ad700b89453aee9ffb4ad69b Author: Tiwei Bie Date: Wed Aug 28 13:36:59 2019 +0800 vhost/test: fix build for vhost test commit 93d2c4de8d8129b97ee1e1a222aedb0719d2fcd9 upstream. Since below commit, callers need to specify the iov_limit in vhost_dev_init() explicitly. Fixes: b46a0bf78ad7 ("vhost: fix OOB in get_rx_bufs()") Cc: stable@vger.kernel.org Signed-off-by: Tiwei Bie Signed-off-by: Michael S. Tsirkin Acked-by: Jason Wang Signed-off-by: Greg Kroah-Hartman commit dcd22e14780a9ece05456488b3fc233f2fbaa5fc Author: Dan Carpenter Date: Thu Aug 15 11:30:50 2019 +0300 drm/vmwgfx: Fix double free in vmw_recv_msg() commit 08b0c891605acf727e43e3e03a25857d3e789b61 upstream. We recently added a kfree() after the end of the loop: if (retries == RETRIES) { kfree(reply); return -EINVAL; } There are two problems. First the test is wrong and because retries equals RETRIES if we succeed on the last iteration through the loop. Second if we fail on the last iteration through the loop then the kfree is a double free. When you're reading this code, please note the break statement at the end of the while loop. This patch changes the loop so that if it's not successful then "reply" is NULL and we can test for that afterward. Cc: Fixes: 6b7c3b86f0b6 ("drm/vmwgfx: fix memory leak when too many retries have occurred") Signed-off-by: Dan Carpenter Reviewed-by: Thomas Hellstrom Signed-off-by: Thomas Hellstrom Signed-off-by: Greg Kroah-Hartman commit 38d38d1e0cc57817a786a4fe954202d77c1210d5 Author: Liangyan Date: Mon Aug 26 20:16:33 2019 +0800 sched/fair: Don't assign runtime for throttled cfs_rq commit 5e2d2cc2588bd3307ce3937acbc2ed03c830a861 upstream. do_sched_cfs_period_timer() will refill cfs_b runtime and call distribute_cfs_runtime to unthrottle cfs_rq, sometimes cfs_b->runtime will allocate all quota to one cfs_rq incorrectly, then other cfs_rqs attached to this cfs_b can't get runtime and will be throttled. We find that one throttled cfs_rq has non-negative cfs_rq->runtime_remaining and cause an unexpetced cast from s64 to u64 in snippet: distribute_cfs_runtime() { runtime = -cfs_rq->runtime_remaining + 1; } The runtime here will change to a large number and consume all cfs_b->runtime in this cfs_b period. According to Ben Segall, the throttled cfs_rq can have account_cfs_rq_runtime called on it because it is throttled before idle_balance, and the idle_balance calls update_rq_clock to add time that is accounted to the task. This commit prevents cfs_rq to be assgined new runtime if it has been throttled until that distribute_cfs_runtime is called. Signed-off-by: Liangyan Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Valentin Schneider Reviewed-by: Ben Segall Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: shanpeic@linux.alibaba.com Cc: stable@vger.kernel.org Cc: xlpang@linux.alibaba.com Fixes: d3d9dc330236 ("sched: Throttle entities exceeding their allowed bandwidth") Link: https://lkml.kernel.org/r/20190826121633.6538-1-liangyan.peng@linux.alibaba.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 044ab4715585171cef24d7099af66a06a19af976 Author: Hui Wang Date: Wed Sep 4 13:53:27 2019 +0800 ALSA: hda/realtek - Fix the problem of two front mics on a ThinkCentre commit 2a36c16efab254dd6017efeb35ad88ecc96f2328 upstream. This ThinkCentre machine has a new realtek codec alc222, it is not in the support list, we add it in the realtek.c then this machine can apply FIXUPs for the realtek codec. And this machine has two front mics which can't be handled by PA so far, it uses the pin 0x18 and 0x19 as the front mics, as a result the existing FIXUP ALC294_FIXUP_LENOVO_MIC_LOCATION doesn't work on this machine. Fortunately another FIXUP ALC283_FIXUP_HEADSET_MIC also can change the location for one of the two mics on this machine. Link: https://lore.kernel.org/r/20190904055327.9883-1-hui.wang@canonical.com Signed-off-by: Hui Wang Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 849f85bfdf12628f876dedccd89a59b39138154d Author: Jian-Hong Pan Date: Mon Sep 2 18:00:56 2019 +0800 ALSA: hda/realtek - Enable internal speaker & headset mic of ASUS UX431FL commit 60083f9e94b2f28047d71ed778adf89357c1a8fb upstream. Original pin node values of ASUS UX431FL with ALC294: 0x12 0xb7a60140 0x13 0x40000000 0x14 0x90170110 0x15 0x411111f0 0x16 0x411111f0 0x17 0x90170111 0x18 0x411111f0 0x19 0x411111f0 0x1a 0x411111f0 0x1b 0x411111f0 0x1d 0x4066852d 0x1e 0x411111f0 0x1f 0x411111f0 0x21 0x04211020 1. Has duplicated internal speakers (0x14 & 0x17) which makes the output route become confused. So, the output volume cannot be changed by setting. 2. Misses the headset mic pin node. This patch disables the confusing speaker (NID 0x14) and enables the headset mic (NID 0x19). Link: https://lore.kernel.org/r/20190902100054.6941-1-jian-hong@endlessm.com Signed-off-by: Jian-Hong Pan Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit a956998ac1c287ffd16b77adc4a90bde6eec3c6c Author: Sam Bazley Date: Sun Sep 1 03:31:30 2019 +0100 ALSA: hda/realtek - Add quirk for HP Pavilion 15 commit d33cd42d86671bed870827aa399aeb9f1da74119 upstream. HP Pavilion 15 (AMD Ryzen-based model) with 103c:84e7 needs the same quirk like HP Envy/Spectre x360 for enabling the mute LED over Mic3 pin. [ rearranged in the SSID number order by tiwai ] Signed-off-by: Sam Bazley Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit d11ca2d79334b6c7d447c14c0f139eee5fa5e84f Author: Takashi Iwai Date: Fri Aug 30 12:03:38 2019 +0200 ALSA: hda/realtek - Fix overridden device-specific initialization commit 89781d0806c2c4f29072d3f00cb2dd4274aabc3d upstream. The recent change to shuffle the codec initialization procedure for Realtek via commit 607ca3bd220f ("ALSA: hda/realtek - EAPD turn on later") caused the silent output on some machines. This change was supposed to be safe, but it isn't actually; some devices have quirk setups to override the EAPD via COEF or BTL in the additional verb table, which is applied at the beginning of snd_hda_gen_init(). And this EAPD setup is again overridden in alc_auto_init_amp(). For recovering from the regression, tell snd_hda_gen_init() not to apply the verbs there by a new flag, then apply the verbs in alc_init(). BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204727 Fixes: 607ca3bd220f ("ALSA: hda/realtek - EAPD turn on later") Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 2c4d2ce8b7998b914401b66d12b1f7f316ff0db8 Author: Takashi Iwai Date: Thu Aug 29 09:52:02 2019 +0200 ALSA: hda - Fix potential endless loop at applying quirks commit 333f31436d3db19f4286f8862a00ea1d8d8420a1 upstream. Since the chained quirks via chained_before flag is applied before the depth check, it may lead to the endless recursive calls, when the chain were set up incorrectly. Fix it by moving the depth check at the beginning of the loop. Fixes: 1f57825077dc ("ALSA: hda - Add chained_before flag to the fixup entry") Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman