commit 5697a9d3d55fad99ffc3c1ba5654426ab64df333 Author: Greg Kroah-Hartman Date: Tue Aug 6 19:08:23 2019 +0200 Linux 5.2.7 commit 726d427e17b9185d9a35409a6c2a0a991615df6a Author: Josh Poimboeuf Date: Sat Aug 3 21:21:54 2019 +0200 Documentation: Add swapgs description to the Spectre v1 documentation commit 4c92057661a3412f547ede95715641d7ee16ddac upstream Add documentation to the Spectre document about the new swapgs variant of Spectre v1. Signed-off-by: Josh Poimboeuf Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 6ec6d45454123ca5281f2f4aea68235c6b0770fb Author: Thomas Gleixner Date: Wed Jul 17 21:18:59 2019 +0200 x86/speculation/swapgs: Exclude ATOMs from speculation through SWAPGS commit f36cf386e3fec258a341d446915862eded3e13d8 upstream Intel provided the following information: On all current Atom processors, instructions that use a segment register value (e.g. a load or store) will not speculatively execute before the last writer of that segment retires. Thus they will not use a speculatively written segment value. That means on ATOMs there is no speculation through SWAPGS, so the SWAPGS entry paths can be excluded from the extra LFENCE if PTI is disabled. Create a separate bug flag for the through SWAPGS speculation and mark all out-of-order ATOMs and AMD/HYGON CPUs as not affected. The in-order ATOMs are excluded from the whole mitigation mess anyway. Reported-by: Andrew Cooper Signed-off-by: Thomas Gleixner Reviewed-by: Tyler Hicks Reviewed-by: Josh Poimboeuf Signed-off-by: Greg Kroah-Hartman commit 061b8f7dfb9c4b8afcf20e9873f064438b0d8046 Author: Josh Poimboeuf Date: Mon Jul 15 11:51:39 2019 -0500 x86/entry/64: Use JMP instead of JMPQ commit 64dbc122b20f75183d8822618c24f85144a5a94d upstream Somehow the swapgs mitigation entry code patch ended up with a JMPQ instruction instead of JMP, where only the short jump is needed. Some assembler versions apparently fail to optimize JMPQ into a two-byte JMP when possible, instead always using a 7-byte JMP with relocation. For some reason that makes the entry code explode with a #GP during boot. Change it back to "JMP" as originally intended. Fixes: 18ec54fdd6d1 ("x86/speculation: Prepare entry code for Spectre v1 swapgs mitigations") Signed-off-by: Josh Poimboeuf Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 405d06fba6937bf272917ec36bd1cf4ad7f7f286 Author: Josh Poimboeuf Date: Mon Jul 8 11:52:26 2019 -0500 x86/speculation: Enable Spectre v1 swapgs mitigations commit a2059825986a1c8143fd6698774fa9d83733bb11 upstream The previous commit added macro calls in the entry code which mitigate the Spectre v1 swapgs issue if the X86_FEATURE_FENCE_SWAPGS_* features are enabled. Enable those features where applicable. The mitigations may be disabled with "nospectre_v1" or "mitigations=off". There are different features which can affect the risk of attack: - When FSGSBASE is enabled, unprivileged users are able to place any value in GS, using the wrgsbase instruction. This means they can write a GS value which points to any value in kernel space, which can be useful with the following gadget in an interrupt/exception/NMI handler: if (coming from user space) swapgs mov %gs:, %reg1 // dependent load or store based on the value of %reg // for example: mov %(reg1), %reg2 If an interrupt is coming from user space, and the entry code speculatively skips the swapgs (due to user branch mistraining), it may speculatively execute the GS-based load and a subsequent dependent load or store, exposing the kernel data to an L1 side channel leak. Note that, on Intel, a similar attack exists in the above gadget when coming from kernel space, if the swapgs gets speculatively executed to switch back to the user GS. On AMD, this variant isn't possible because swapgs is serializing with respect to future GS-based accesses. NOTE: The FSGSBASE patch set hasn't been merged yet, so the above case doesn't exist quite yet. - When FSGSBASE is disabled, the issue is mitigated somewhat because unprivileged users must use prctl(ARCH_SET_GS) to set GS, which restricts GS values to user space addresses only. That means the gadget would need an additional step, since the target kernel address needs to be read from user space first. Something like: if (coming from user space) swapgs mov %gs:, %reg1 mov (%reg1), %reg2 // dependent load or store based on the value of %reg2 // for example: mov %(reg2), %reg3 It's difficult to audit for this gadget in all the handlers, so while there are no known instances of it, it's entirely possible that it exists somewhere (or could be introduced in the future). Without tooling to analyze all such code paths, consider it vulnerable. Effects of SMAP on the !FSGSBASE case: - If SMAP is enabled, and the CPU reports RDCL_NO (i.e., not susceptible to Meltdown), the kernel is prevented from speculatively reading user space memory, even L1 cached values. This effectively disables the !FSGSBASE attack vector. - If SMAP is enabled, but the CPU *is* susceptible to Meltdown, SMAP still prevents the kernel from speculatively reading user space memory. But it does *not* prevent the kernel from reading the user value from L1, if it has already been cached. This is probably only a small hurdle for an attacker to overcome. Thanks to Dave Hansen for contributing the speculative_smap() function. Thanks to Andrew Cooper for providing the inside scoop on whether swapgs is serializing on AMD. [ tglx: Fixed the USER fence decision and polished the comment as suggested by Dave Hansen ] Signed-off-by: Josh Poimboeuf Signed-off-by: Thomas Gleixner Reviewed-by: Dave Hansen Signed-off-by: Greg Kroah-Hartman commit 6b5145c74f91dd46cb299f9e0a42a0b6df1055bd Author: Josh Poimboeuf Date: Mon Jul 8 11:52:25 2019 -0500 x86/speculation: Prepare entry code for Spectre v1 swapgs mitigations commit 18ec54fdd6d18d92025af097cd042a75cf0ea24c upstream Spectre v1 isn't only about array bounds checks. It can affect any conditional checks. The kernel entry code interrupt, exception, and NMI handlers all have conditional swapgs checks. Those may be problematic in the context of Spectre v1, as kernel code can speculatively run with a user GS. For example: if (coming from user space) swapgs mov %gs:, %reg mov (%reg), %reg1 When coming from user space, the CPU can speculatively skip the swapgs, and then do a speculative percpu load using the user GS value. So the user can speculatively force a read of any kernel value. If a gadget exists which uses the percpu value as an address in another load/store, then the contents of the kernel value may become visible via an L1 side channel attack. A similar attack exists when coming from kernel space. The CPU can speculatively do the swapgs, causing the user GS to get used for the rest of the speculative window. The mitigation is similar to a traditional Spectre v1 mitigation, except: a) index masking isn't possible; because the index (percpu offset) isn't user-controlled; and b) an lfence is needed in both the "from user" swapgs path and the "from kernel" non-swapgs path (because of the two attacks described above). The user entry swapgs paths already have SWITCH_TO_KERNEL_CR3, which has a CR3 write when PTI is enabled. Since CR3 writes are serializing, the lfences can be skipped in those cases. On the other hand, the kernel entry swapgs paths don't depend on PTI. To avoid unnecessary lfences for the user entry case, create two separate features for alternative patching: X86_FEATURE_FENCE_SWAPGS_USER X86_FEATURE_FENCE_SWAPGS_KERNEL Use these features in entry code to patch in lfences where needed. The features aren't enabled yet, so there's no functional change. Signed-off-by: Josh Poimboeuf Signed-off-by: Thomas Gleixner Reviewed-by: Dave Hansen Signed-off-by: Greg Kroah-Hartman commit 4bd635fe7bfc05cd9cb6d369fc3b26714b13257a Author: Fenghua Yu Date: Wed Jun 19 18:51:09 2019 +0200 x86/cpufeatures: Combine word 11 and 12 into a new scattered features word commit acec0ce081de0c36459eea91647faf99296445a3 upstream It's a waste for the four X86_FEATURE_CQM_* feature bits to occupy two whole feature bits words. To better utilize feature words, re-define word 11 to host scattered features and move the four X86_FEATURE_CQM_* features into Linux defined word 11. More scattered features can be added in word 11 in the future. Rename leaf 11 in cpuid_leafs to CPUID_LNX_4 to reflect it's a Linux-defined leaf. Rename leaf 12 as CPUID_DUMMY which will be replaced by a meaningful name in the next patch when CPUID.7.1:EAX occupies world 12. Maximum number of RMID and cache occupancy scale are retrieved from CPUID.0xf.1 after scattered CQM features are enumerated. Carve out the code into a separate function. KVM doesn't support resctrl now. So it's safe to move the X86_FEATURE_CQM_* features to scattered features word 11 for KVM. Signed-off-by: Fenghua Yu Signed-off-by: Borislav Petkov Signed-off-by: Thomas Gleixner Cc: Aaron Lewis Cc: Andy Lutomirski Cc: Babu Moger Cc: "Chang S. Bae" Cc: "Sean J Christopherson" Cc: Frederic Weisbecker Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Jann Horn Cc: Juergen Gross Cc: Konrad Rzeszutek Wilk Cc: kvm ML Cc: Masahiro Yamada Cc: Masami Hiramatsu Cc: Nadav Amit Cc: Paolo Bonzini Cc: Pavel Tatashin Cc: Peter Feiner Cc: "Peter Zijlstra (Intel)" Cc: "Radim Krčmář" Cc: "Rafael J. Wysocki" Cc: Ravi V Shankar Cc: Sherry Hurwitz Cc: Thomas Gleixner Cc: Thomas Lendacky Cc: x86 Link: https://lkml.kernel.org/r/1560794416-217638-2-git-send-email-fenghua.yu@intel.com Signed-off-by: Greg Kroah-Hartman commit b52f9368b05aaeb98834037d9cedd22e863bd4e3 Author: Borislav Petkov Date: Wed Jun 19 17:24:34 2019 +0200 x86/cpufeatures: Carve out CQM features retrieval commit 45fc56e629caa451467e7664fbd4c797c434a6c4 upstream ... into a separate function for better readability. Split out from a patch from Fenghua Yu to keep the mechanical, sole code movement separate for easy review. No functional changes. Signed-off-by: Borislav Petkov Signed-off-by: Thomas Gleixner Cc: Fenghua Yu Cc: x86@kernel.org Signed-off-by: Greg Kroah-Hartman commit ca3592eed8d5a77c4fe7f4d79bb873abf6d271cf Author: Xiaolin Zhang Date: Thu Jul 18 01:10:24 2019 +0800 drm/i915/gvt: fix incorrect cache entry for guest page mapping commit 7366aeb77cd840f3edea02c65065d40affaa7f45 upstream. GPU hang observed during the guest OCL conformance test which is caused by THP GTT feature used durning the test. It was observed the same GFN with different size (4K and 2M) requested from the guest in GVT. So during the guest page dma map stage, it is required to unmap first with orginal size and then remap again with requested size. Fixes: b901b252b6cf ("drm/i915/gvt: Add 2M huge gtt support") Cc: stable@vger.kernel.org Reviewed-by: Zhenyu Wang Signed-off-by: Xiaolin Zhang Signed-off-by: Zhenyu Wang Signed-off-by: Greg Kroah-Hartman commit 00f1fc603ca3d499048f2b2da2dd36eb7c975f5b Author: Lionel Landwerlin Date: Mon Jun 10 11:19:14 2019 +0300 drm/i915/perf: fix ICL perf register offsets commit 95eef14cdad150fed43147bcd4f29eea3d0a3f03 upstream. We got the wrong offsets (could they have changed?). New values were computed off an error state by looking up the register offset in the context image as written by the HW. Signed-off-by: Lionel Landwerlin Fixes: 1de401c08fa805 ("drm/i915/perf: enable perf support on ICL") Cc: # v4.18+ Acked-by: Kenneth Graunke Link: https://patchwork.freedesktop.org/patch/msgid/20190610081914.25428-1-lionel.g.landwerlin@intel.com (cherry picked from commit 8dcfdfb4501012a8d36d2157dc73925715f2befb) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 37bf2523c81836d651d7dedbe1003ad983190ac1 Author: Kaike Wan Date: Mon Jul 15 12:45:34 2019 -0400 IB/hfi1: Field not zero-ed when allocating TID flow memory commit dc25b239ebeaa3c58e5ceaa732140427d386aa16 upstream. The field flow->resync_npkts is added for TID RDMA WRITE request and zero-ed when a TID RDMA WRITE RESP packet is received by the requester. This field is used to rewind a request during retry in the function hfi1_tid_rdma_restart_req() shared by both TID RDMA WRITE and TID RDMA READ requests. Therefore, when a TID RDMA READ request is retried, this field may not be initialized at all, which causes the retry to start at an incorrect psn, leading to the drop of the retry request by the responder. This patch fixes the problem by zeroing out the field when the flow memory is allocated. Fixes: 838b6fd2d9ca ("IB/hfi1: TID RDMA RcvArray programming and TID allocation") Cc: Link: https://lore.kernel.org/r/20190715164534.74174.6177.stgit@awfm-01.aw.intel.com Reviewed-by: Mike Marciniszyn Signed-off-by: Kaike Wan Signed-off-by: Mike Marciniszyn Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 24f386fa19bd73edc80d802aafececa4f161ac32 Author: Kaike Wan Date: Mon Jul 15 12:45:40 2019 -0400 IB/hfi1: Drop all TID RDMA READ RESP packets after r_next_psn commit f4d46119f214f9a7620b0d18b153d7e0e8c90b4f upstream. When a TID sequence error occurs while receiving TID RDMA READ RESP packets, all packets after flow->flow_state.r_next_psn should be dropped, including those response packets for subsequent segments. The current implementation will drop the subsequent response packets for the segment to complete next, but may accept packets for subsequent segments and therefore mistakenly advance the r_next_psn fields for the corresponding software flows. This may result in failures to complete subsequent segments after the current segment is completed. The fix is to only use the flow pointed by req->clear_tail for checking KDETH PSN instead of finding a flow from the request's flow array. Fixes: b885d5be9ca1 ("IB/hfi1: Unify the software PSN check for TID RDMA READ/WRITE") Cc: Link: https://lore.kernel.org/r/20190715164540.74174.54702.stgit@awfm-01.aw.intel.com Reviewed-by: Mike Marciniszyn Signed-off-by: Kaike Wan Signed-off-by: Mike Marciniszyn Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 84d5f6cd65b6b14f0735c961c3a45eecb779a735 Author: John Fleck Date: Mon Jul 15 12:45:21 2019 -0400 IB/hfi1: Check for error on call to alloc_rsm_map_table commit cd48a82087231fdba0e77521102386c6ed0168d6 upstream. The call to alloc_rsm_map_table does not check if the kmalloc fails. Check for a NULL on alloc, and bail if it fails. Fixes: 372cc85a13c9 ("IB/hfi1: Extract RSM map table init from QOS") Link: https://lore.kernel.org/r/20190715164521.74174.27047.stgit@awfm-01.aw.intel.com Cc: Reviewed-by: Mike Marciniszyn Signed-off-by: John Fleck Signed-off-by: Mike Marciniszyn Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit cb85a6f72531f215f3605839f0af9b579c45e18b Author: Yishai Hadas Date: Tue Jul 23 09:57:29 2019 +0300 IB/mlx5: Fix RSS Toeplitz setup to be aligned with the HW specification commit b7165bd0d6cbb93732559be6ea8774653b204480 upstream. The specification for the Toeplitz function doesn't require to set the key explicitly to be symmetric. In case a symmetric functionality is required a symmetric key can be simply used. Wrongly forcing the algorithm to symmetric causes the wrong packet distribution and a performance degradation. Link: https://lore.kernel.org/r/20190723065733.4899-7-leon@kernel.org Cc: # 4.7 Fixes: 28d6137008b2 ("IB/mlx5: Add RSS QP support") Signed-off-by: Yishai Hadas Reviewed-by: Alex Vainman Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 23a76c01c92dac9d58e12b18e9abbb764ccbf127 Author: Yishai Hadas Date: Tue Jul 23 09:57:28 2019 +0300 IB/mlx5: Fix clean_mr() to work in the expected order commit b9332dad987018745a0c0bb718d12dacfa760489 upstream. Any dma map underlying the MR should only be freed once the MR is fenced at the hardware. As of the above we first destroy the MKEY and just after that can safely call to dma_unmap_single(). Link: https://lore.kernel.org/r/20190723065733.4899-6-leon@kernel.org Cc: # 4.3 Fixes: 8a187ee52b04 ("IB/mlx5: Support the new memory registration API") Signed-off-by: Yishai Hadas Reviewed-by: Artemy Kovalyov Signed-off-by: Leon Romanovsky Reviewed-by: Jason Gunthorpe Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 93ead300bb99dbac9cc2b138b43ce7696892e777 Author: Yishai Hadas Date: Tue Jul 23 09:57:27 2019 +0300 IB/mlx5: Move MRs to a kernel PD when freeing them to the MR cache commit 9ec4483a3f0f71a228a5933bc040441322bfb090 upstream. Fix unreg_umr to move the MR to a kernel owned PD (i.e. the UMR PD) which can't be accessed by userspace. This ensures that nothing can continue to access the MR once it has been placed in the kernels cache for reuse. MRs in the cache continue to have their HW state, including DMA tables, present. Even though the MR has been invalidated, changing the PD provides an additional layer of protection against use of the MR. Link: https://lore.kernel.org/r/20190723065733.4899-5-leon@kernel.org Cc: # 3.10 Fixes: e126ba97dba9 ("mlx5: Add driver for Mellanox Connect-IB adapters") Signed-off-by: Yishai Hadas Reviewed-by: Artemy Kovalyov Signed-off-by: Leon Romanovsky Reviewed-by: Jason Gunthorpe Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 7e0d21ffae84c36bacba402d51b41a5ad6840568 Author: Yishai Hadas Date: Tue Jul 23 09:57:26 2019 +0300 IB/mlx5: Use direct mkey destroy command upon UMR unreg failure commit afd1417404fba6dbfa6c0a8e5763bd348da682e4 upstream. Use a direct firmware command to destroy the mkey in case the unreg UMR operation has failed. This prevents a case that a mkey will leak out from the cache post a failure to be destroyed by a UMR WR. In case the MR cache limit didn't reach a call to add another entry to the cache instead of the destroyed one is issued. In addition, replaced a warn message to WARN_ON() as this flow is fatal and can't happen unless some bug around. Link: https://lore.kernel.org/r/20190723065733.4899-4-leon@kernel.org Cc: # 4.10 Fixes: 49780d42dfc9 ("IB/mlx5: Expose MR cache for mlx5_ib") Signed-off-by: Yishai Hadas Reviewed-by: Artemy Kovalyov Signed-off-by: Leon Romanovsky Reviewed-by: Jason Gunthorpe Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 4b46f258d7fa1f11d641332fd595df7ab5fa23ea Author: Yishai Hadas Date: Tue Jul 23 09:57:25 2019 +0300 IB/mlx5: Fix unreg_umr to ignore the mkey state commit 6a053953739d23694474a5f9c81d1a30093da81a upstream. Fix unreg_umr to ignore the mkey state and do not fail if was freed. This prevents a case that a user space application already changed the mkey state to free and then the UMR operation will fail leaving the mkey in an inappropriate state. Link: https://lore.kernel.org/r/20190723065733.4899-3-leon@kernel.org Cc: # 3.19 Fixes: 968e78dd9644 ("IB/mlx5: Enhance UMR support to allow partial page table update") Signed-off-by: Yishai Hadas Reviewed-by: Artemy Kovalyov Signed-off-by: Leon Romanovsky Reviewed-by: Jason Gunthorpe Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit e2aa2bdc546fb65851e15c010bccd448108284f8 Author: Jason Gunthorpe Date: Wed Jul 31 11:18:40 2019 +0300 RDMA/devices: Do not deadlock during client removal commit 621e55ff5b8e0ab5d1063f0eae0ef3960bef8f6e upstream. lockdep reports: WARNING: possible circular locking dependency detected modprobe/302 is trying to acquire lock: 0000000007c8919c ((wq_completion)ib_cm){+.+.}, at: flush_workqueue+0xdf/0x990 but task is already holding lock: 000000002d3d2ca9 (&device->client_data_rwsem){++++}, at: remove_client_context+0x79/0xd0 [ib_core] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&device->client_data_rwsem){++++}: down_read+0x3f/0x160 ib_get_net_dev_by_params+0xd5/0x200 [ib_core] cma_ib_req_handler+0x5f6/0x2090 [rdma_cm] cm_process_work+0x29/0x110 [ib_cm] cm_req_handler+0x10f5/0x1c00 [ib_cm] cm_work_handler+0x54c/0x311d [ib_cm] process_one_work+0x4aa/0xa30 worker_thread+0x62/0x5b0 kthread+0x1ca/0x1f0 ret_from_fork+0x24/0x30 -> #1 ((work_completion)(&(&work->work)->work)){+.+.}: process_one_work+0x45f/0xa30 worker_thread+0x62/0x5b0 kthread+0x1ca/0x1f0 ret_from_fork+0x24/0x30 -> #0 ((wq_completion)ib_cm){+.+.}: lock_acquire+0xc8/0x1d0 flush_workqueue+0x102/0x990 cm_remove_one+0x30e/0x3c0 [ib_cm] remove_client_context+0x94/0xd0 [ib_core] disable_device+0x10a/0x1f0 [ib_core] __ib_unregister_device+0x5a/0xe0 [ib_core] ib_unregister_device+0x21/0x30 [ib_core] mlx5_ib_stage_ib_reg_cleanup+0x9/0x10 [mlx5_ib] __mlx5_ib_remove+0x3d/0x70 [mlx5_ib] mlx5_ib_remove+0x12e/0x140 [mlx5_ib] mlx5_remove_device+0x144/0x150 [mlx5_core] mlx5_unregister_interface+0x3f/0xf0 [mlx5_core] mlx5_ib_cleanup+0x10/0x3a [mlx5_ib] __x64_sys_delete_module+0x227/0x350 do_syscall_64+0xc3/0x6a4 entry_SYSCALL_64_after_hwframe+0x49/0xbe Which is due to the read side of the client_data_rwsem being obtained recursively through a work queue flush during cm client removal. The lock is being held across the remove in remove_client_context() so that the function is a fence, once it returns the client is removed. This is required so that the two callers do not proceed with destruction until the client completes removal. Instead of using client_data_rwsem use the existing device unregistration refcount and add a similar client unregistration (client->uses) refcount. This will fence the two unregistration paths without holding any locks. Cc: Fixes: 921eab1143aa ("RDMA/devices: Re-organize device.c locking") Signed-off-by: Jason Gunthorpe Signed-off-by: Leon Romanovsky Link: https://lore.kernel.org/r/20190731081841.32345-2-leon@kernel.org Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit c6d57e4e2821522e524b7404355f65756f8edaab Author: Selvin Xavier Date: Mon Jul 15 05:19:13 2019 -0400 RDMA/bnxt_re: Honor vlan_id in GID entry comparison commit c56b593d2af4cbd189c6af5fd6790728fade80cc upstream. A GID entry consists of GID, vlan, netdev and smac. Extend GID duplicate check comparisons to consider vlan_id as well to support IPv6 VLAN based link local addresses. Introduce a new structure (bnxt_qplib_gid_info) to hold gid and vlan_id information. The issue is discussed in the following thread https://lore.kernel.org/r/AM0PR05MB4866CFEDCDF3CDA1D7D18AA5D1F20@AM0PR05MB4866.eurprd05.prod.outlook.com Fixes: 823b23da7113 ("IB/core: Allow vlan link local address based RoCE GIDs") Cc: # v5.2+ Link: https://lore.kernel.org/r/20190715091913.15726-1-selvin.xavier@broadcom.com Reported-by: Yi Zhang Co-developed-by: Parav Pandit Signed-off-by: Parav Pandit Signed-off-by: Selvin Xavier Tested-by: Yi Zhang Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 946c3d239f32820b0d08f82d4f86b4873c0456fe Author: Souptick Joarder Date: Wed Jul 31 00:04:56 2019 +0530 xen/gntdev.c: Replace vm_map_pages() with vm_map_pages_zero() commit 8d1502f629c9966743de45744f4c1ba93a57d105 upstream. 'commit df9bde015a72 ("xen/gntdev.c: convert to use vm_map_pages()")' breaks gntdev driver. If vma->vm_pgoff > 0, vm_map_pages() will: - use map->pages starting at vma->vm_pgoff instead of 0 - verify map->count against vma_pages()+vma->vm_pgoff instead of just vma_pages(). In practice, this breaks using a single gntdev FD for mapping multiple grants. relevant strace output: [pid 857] ioctl(7, IOCTL_GNTDEV_MAP_GRANT_REF, 0x7ffd3407b6d0) = 0 [pid 857] mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 7, 0) = 0x777f1211b000 [pid 857] ioctl(7, IOCTL_GNTDEV_SET_UNMAP_NOTIFY, 0x7ffd3407b710) = 0 [pid 857] ioctl(7, IOCTL_GNTDEV_MAP_GRANT_REF, 0x7ffd3407b6d0) = 0 [pid 857] mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 7, 0x1000) = -1 ENXIO (No such device or address) details here: https://github.com/QubesOS/qubes-issues/issues/5199 The reason is -> ( copying Marek's word from discussion) vma->vm_pgoff is used as index passed to gntdev_find_map_index. It's basically using this parameter for "which grant reference to map". map struct returned by gntdev_find_map_index() describes just the pages to be mapped. Specifically map->pages[0] should be mapped at vma->vm_start, not vma->vm_start+vma->vm_pgoff*PAGE_SIZE. When trying to map grant with index (aka vma->vm_pgoff) > 1, __vm_map_pages() will refuse to map it because it will expect map->count to be at least vma_pages(vma)+vma->vm_pgoff, while it is exactly vma_pages(vma). Converting vm_map_pages() to use vm_map_pages_zero() will fix the problem. Marek has tested and confirmed the same. Cc: stable@vger.kernel.org # v5.2+ Fixes: df9bde015a72 ("xen/gntdev.c: convert to use vm_map_pages()") Reported-by: Marek Marczykowski-Górecki Signed-off-by: Souptick Joarder Tested-by: Marek Marczykowski-Górecki Reviewed-by: Boris Ostrovsky Signed-off-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman commit 95488feef0c193008132445bfc2831fb83914204 Author: Juergen Gross Date: Fri Jun 14 07:46:02 2019 +0200 xen/swiotlb: fix condition for calling xen_destroy_contiguous_region() commit 50f6393f9654c561df4cdcf8e6cfba7260143601 upstream. The condition in xen_swiotlb_free_coherent() for deciding whether to call xen_destroy_contiguous_region() is wrong: in case the region to be freed is not contiguous calling xen_destroy_contiguous_region() is the wrong thing to do: it would result in inconsistent mappings of multiple PFNs to the same MFN. This will lead to various strange crashes or data corruption. Instead of calling xen_destroy_contiguous_region() in that case a warning should be issued as that situation should never occur. Cc: stable@vger.kernel.org Signed-off-by: Juergen Gross Reviewed-by: Boris Ostrovsky Reviewed-by: Jan Beulich Acked-by: Konrad Rzeszutek Wilk Signed-off-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman commit c9fa2619f350bbc0337721596c51fc8bbbec503f Author: Munehisa Kamata Date: Wed Jul 31 20:13:10 2019 +0800 nbd: replace kill_bdev() with __invalidate_device() again commit 2b5c8f0063e4b263cf2de82029798183cf85c320 upstream. Commit abbbdf12497d ("replace kill_bdev() with __invalidate_device()") once did this, but 29eaadc03649 ("nbd: stop using the bdev everywhere") resurrected kill_bdev() and it has been there since then. So buffer_head mappings still get killed on a server disconnection, and we can still hit the BUG_ON on a filesystem on the top of the nbd device. EXT4-fs (nbd0): mounted filesystem with ordered data mode. Opts: (null) block nbd0: Receive control failed (result -32) block nbd0: shutting down sockets print_req_error: I/O error, dev nbd0, sector 66264 flags 3000 EXT4-fs warning (device nbd0): htree_dirblock_to_tree:979: inode #2: lblock 0: comm ls: error -5 reading directory block print_req_error: I/O error, dev nbd0, sector 2264 flags 3000 EXT4-fs error (device nbd0): __ext4_get_inode_loc:4690: inode #2: block 283: comm ls: unable to read itable block EXT4-fs error (device nbd0) in ext4_reserve_inode_write:5894: IO failure ------------[ cut here ]------------ kernel BUG at fs/buffer.c:3057! invalid opcode: 0000 [#1] SMP PTI CPU: 7 PID: 40045 Comm: jbd2/nbd0-8 Not tainted 5.1.0-rc3+ #4 Hardware name: Amazon EC2 m5.12xlarge/, BIOS 1.0 10/16/2017 RIP: 0010:submit_bh_wbc+0x18b/0x190 ... Call Trace: jbd2_write_superblock+0xf1/0x230 [jbd2] ? account_entity_enqueue+0xc5/0xf0 jbd2_journal_update_sb_log_tail+0x94/0xe0 [jbd2] jbd2_journal_commit_transaction+0x12f/0x1d20 [jbd2] ? __switch_to_asm+0x40/0x70 ... ? lock_timer_base+0x67/0x80 kjournald2+0x121/0x360 [jbd2] ? remove_wait_queue+0x60/0x60 kthread+0xf8/0x130 ? commit_timeout+0x10/0x10 [jbd2] ? kthread_bind+0x10/0x10 ret_from_fork+0x35/0x40 With __invalidate_device(), I no longer hit the BUG_ON with sync or unmount on the disconnected device. Fixes: 29eaadc03649 ("nbd: stop using the bdev everywhere") Cc: linux-block@vger.kernel.org Cc: Ratna Manoj Bolla Cc: nbd@other.debian.org Cc: stable@vger.kernel.org Cc: David Woodhouse Reviewed-by: Josef Bacik Signed-off-by: Munehisa Kamata Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit e6652555512ae64acf81879957cc9cfad8a3adf6 Author: Suganath Prabu Date: Tue Jul 30 03:43:57 2019 -0400 scsi: mpt3sas: Use 63-bit DMA addressing on SAS35 HBA commit df9a606184bfdb5ae3ca9d226184e9489f5c24f7 upstream. Although SAS3 & SAS3.5 IT HBA controllers support 64-bit DMA addressing, as per hardware design, if DMA-able range contains all 64-bits set (0xFFFFFFFF-FFFFFFFF) then it results in a firmware fault. E.g. SGE's start address is 0xFFFFFFFF-FFFF000 and data length is 0x1000 bytes. when HBA tries to DMA the data at 0xFFFFFFFF-FFFFFFFF location then HBA will fault the firmware. Driver will set 63-bit DMA mask to ensure the above address will not be used. Cc: # 5.1.20+ Signed-off-by: Suganath Prabu Reviewed-by: Christoph Hellwig Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 244e3a4e40f861454f940d603e48983d56582103 Author: Weiyi Lu Date: Fri Jun 28 15:22:34 2019 +0800 clk: mediatek: mt8183: Register 13MHz clock earlier for clocksource commit c93d059a80450af99dd6c0e8c36790579343675a upstream. The 13MHz clock should be registered before clocksource driver is initialized. Use CLK_OF_DECLARE_DRIVER() to guarantee. Fixes: acddfc2c261b ("clk: mediatek: Add MT8183 clock support") Cc: Signed-off-by: Weiyi Lu Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit b42addb918dc95fd8719cff5278e37b5d47b033d Author: Jackie Liu Date: Wed Jul 31 14:39:33 2019 +0800 io_uring: fix KASAN use after free in io_sq_wq_submit_work commit d0ee879187df966ef638031b5f5183078d672141 upstream. [root@localhost ~]# ./liburing/test/link QEMU Standard PC report that: [ 29.379892] CPU: 0 PID: 84 Comm: kworker/u2:2 Not tainted 5.3.0-rc2-00051-g4010b622f1d2-dirty #86 [ 29.379902] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 [ 29.379913] Workqueue: io_ring-wq io_sq_wq_submit_work [ 29.379929] Call Trace: [ 29.379953] dump_stack+0xa9/0x10e [ 29.379970] ? io_sq_wq_submit_work+0xbf4/0xe90 [ 29.379986] print_address_description.cold.6+0x9/0x317 [ 29.379999] ? io_sq_wq_submit_work+0xbf4/0xe90 [ 29.380010] ? io_sq_wq_submit_work+0xbf4/0xe90 [ 29.380026] __kasan_report.cold.7+0x1a/0x34 [ 29.380044] ? io_sq_wq_submit_work+0xbf4/0xe90 [ 29.380061] kasan_report+0xe/0x12 [ 29.380076] io_sq_wq_submit_work+0xbf4/0xe90 [ 29.380104] ? io_sq_thread+0xaf0/0xaf0 [ 29.380152] process_one_work+0xb59/0x19e0 [ 29.380184] ? pwq_dec_nr_in_flight+0x2c0/0x2c0 [ 29.380221] worker_thread+0x8c/0xf40 [ 29.380248] ? __kthread_parkme+0xab/0x110 [ 29.380265] ? process_one_work+0x19e0/0x19e0 [ 29.380278] kthread+0x30b/0x3d0 [ 29.380292] ? kthread_create_on_node+0xe0/0xe0 [ 29.380311] ret_from_fork+0x3a/0x50 [ 29.380635] Allocated by task 209: [ 29.381255] save_stack+0x19/0x80 [ 29.381268] __kasan_kmalloc.constprop.6+0xc1/0xd0 [ 29.381279] kmem_cache_alloc+0xc0/0x240 [ 29.381289] io_submit_sqe+0x11bc/0x1c70 [ 29.381300] io_ring_submit+0x174/0x3c0 [ 29.381311] __x64_sys_io_uring_enter+0x601/0x780 [ 29.381322] do_syscall_64+0x9f/0x4d0 [ 29.381336] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 29.381633] Freed by task 84: [ 29.382186] save_stack+0x19/0x80 [ 29.382198] __kasan_slab_free+0x11d/0x160 [ 29.382210] kmem_cache_free+0x8c/0x2f0 [ 29.382220] io_put_req+0x22/0x30 [ 29.382230] io_sq_wq_submit_work+0x28b/0xe90 [ 29.382241] process_one_work+0xb59/0x19e0 [ 29.382251] worker_thread+0x8c/0xf40 [ 29.382262] kthread+0x30b/0x3d0 [ 29.382272] ret_from_fork+0x3a/0x50 [ 29.382569] The buggy address belongs to the object at ffff888067172140 which belongs to the cache io_kiocb of size 224 [ 29.384692] The buggy address is located 120 bytes inside of 224-byte region [ffff888067172140, ffff888067172220) [ 29.386723] The buggy address belongs to the page: [ 29.387575] page:ffffea00019c5c80 refcount:1 mapcount:0 mapping:ffff88806ace5180 index:0x0 [ 29.387587] flags: 0x100000000000200(slab) [ 29.387603] raw: 0100000000000200 dead000000000100 dead000000000122 ffff88806ace5180 [ 29.387617] raw: 0000000000000000 00000000800c000c 00000001ffffffff 0000000000000000 [ 29.387624] page dumped because: kasan: bad access detected [ 29.387920] Memory state around the buggy address: [ 29.388771] ffff888067172080: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc [ 29.390062] ffff888067172100: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb [ 29.391325] >ffff888067172180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 29.392578] ^ [ 29.393480] ffff888067172200: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc [ 29.394744] ffff888067172280: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 29.396003] ================================================================== [ 29.397260] Disabling lock debugging due to kernel taint io_sq_wq_submit_work free and read req again. Cc: Zhengyuan Liu Cc: linux-block@vger.kernel.org Cc: stable@vger.kernel.org Fixes: f7b76ac9d17e ("io_uring: fix counter inc/dec mismatch in async_list") Signed-off-by: Jackie Liu Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit a08a3cc1c0a8b32cf444bc187ce0882e67868343 Author: Will Deacon Date: Tue Jul 30 15:40:20 2019 +0100 arm64: cpufeature: Fix feature comparison for CTR_EL0.{CWG,ERG} commit 147b9635e6347104b91f48ca9dca61eb0fbf2a54 upstream. If CTR_EL0.{CWG,ERG} are 0b0000 then they must be interpreted to have their architecturally maximum values, which defeats the use of FTR_HIGHER_SAFE when sanitising CPU ID registers on heterogeneous machines. Introduce FTR_HIGHER_OR_ZERO_SAFE so that these fields effectively saturate at zero. Fixes: 3c739b571084 ("arm64: Keep track of CPU feature registers") Cc: # 4.4.x- Reviewed-by: Suzuki K Poulose Acked-by: Mark Rutland Signed-off-by: Will Deacon Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 40b6dd1eb3b46536b9a731d000abf8d6e128a6a5 Author: Will Deacon Date: Mon Jul 29 11:06:17 2019 +0100 arm64: compat: Allow single-byte watchpoints on all addresses commit 849adec41203ac5837c40c2d7e08490ffdef3c2c upstream. Commit d968d2b801d8 ("ARM: 7497/1: hw_breakpoint: allow single-byte watchpoints on all addresses") changed the validation requirements for hardware watchpoints on arch/arm/. Update our compat layer to implement the same relaxation. Cc: Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 787a183b305a8bd0dea27eb29d7a4787bd75ebe6 Author: Will Deacon Date: Mon Jul 29 11:43:48 2019 +0100 drivers/perf: arm_pmu: Fix failure path in PM notifier commit 0d7fd70f26039bd4b33444ca47f0e69ce3ae0354 upstream. Handling of the CPU_PM_ENTER_FAILED transition in the Arm PMU PM notifier code incorrectly skips restoration of the counters. Fix the logic so that CPU_PM_ENTER_FAILED follows the same path as CPU_PM_EXIT. Cc: Fixes: da4e4f18afe0f372 ("drivers/perf: arm_pmu: implement CPU_PM notifier") Reported-by: Anders Roxell Acked-by: Lorenzo Pieralisi Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 3a512c8be94d18748cb566ef47d0e68ae3cf9842 Author: Helge Deller Date: Thu Aug 1 13:33:39 2019 +0200 parisc: Fix build of compressed kernel even with debug enabled commit 3fe6c873af2f2247544debdbe51ec29f690a2ccf upstream. With debug info enabled (CONFIG_DEBUG_INFO=y) the resulting vmlinux may get that huge that we need to increase the start addresss for the decompression text section otherwise one will face a linker error. Reported-by: Sven Schnelle Tested-by: Sven Schnelle Cc: stable@vger.kernel.org # v4.14+ Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit cb97609af9b1aa196b9339f447121700b303bd6d Author: Helge Deller Date: Thu Aug 1 13:42:18 2019 +0200 parisc: Strip debug info from kernel before creating compressed vmlinuz commit e50beea8e7738377b4fa664078547be338038ff9 upstream. Same as on x86-64, strip the .comment, .note and debug sections from the Linux kernel before creating the compressed image for the boot loader. Reported-by: James Bottomley Reported-by: Sven Schnelle Cc: stable@vger.kernel.org # v4.20+ Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit e4b128c7c03bebd3964384849a74d98ea4ce1070 Author: James Bottomley Date: Thu Aug 1 13:47:03 2019 +0200 parisc: Add archclean Makefile target commit f2c5ed0dd5004c2cff5c0e3d430a107576fcc17f upstream. Apparently we don't have an archclean target in our arch/parisc/Makefile, so files in there never get cleaned out by make mrproper. This, in turn means that the sizes.h file in arch/parisc/boot/compressed never gets removed and worse, when you transition to an O=build/parisc[64] build model it overrides the generated file. The upshot being my bzImage was building with a SZ_end that was too small. I fixed it by making mrproper clean everything. Signed-off-by: James Bottomley Cc: stable@vger.kernel.org # v4.20+ Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 207742502aac2964bd000faeeb3cfbea813838a0 Author: Chris Down Date: Fri Aug 2 21:49:15 2019 -0700 cgroup: kselftest: relax fs_spec checks commit b59b1baab789eacdde809135542e3d4f256f6878 upstream. On my laptop most memcg kselftests were being skipped because it claimed cgroup v2 hierarchy wasn't mounted, but this isn't correct. Instead, it seems current systemd HEAD mounts it with the name "cgroup2" instead of "cgroup": % grep cgroup /proc/mounts cgroup2 /sys/fs/cgroup cgroup2 rw,nosuid,nodev,noexec,relatime,nsdelegate 0 0 I can't think of a reason to need to check fs_spec explicitly since it's arbitrary, so we can just rely on fs_vfstype. After these changes, `make TARGETS=cgroup kselftest` actually runs the cgroup v2 tests in more cases. Link: http://lkml.kernel.org/r/20190723210737.GA487@chrisdown.name Signed-off-by: Chris Down Cc: Johannes Weiner Cc: Tejun Heo Cc: Roman Gushchin Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 79977e8995541d7a0671305d0df053e3bc54366a Author: Stefan Haberland Date: Thu Aug 1 13:06:30 2019 +0200 s390/dasd: fix endless loop after read unit address configuration commit 41995342b40c418a47603e1321256d2c4a2ed0fb upstream. After getting a storage server event that causes the DASD device driver to update its unit address configuration during a device shutdown there is the possibility of an endless loop in the device driver. In the system log there will be ongoing DASD error messages with RC: -19. The reason is that the loop starting the ruac request only terminates when the retry counter is decreased to 0. But in the sleep_on function there are early exit paths that do not decrease the retry counter. Prevent an endless loop by handling those cases separately. Remove the unnecessary do..while loop since the sleep_on function takes care of retries by itself. Fixes: 8e09f21574ea ("[S390] dasd: add hyper PAV support to DASD device driver, part 1") Cc: stable@vger.kernel.org # 2.6.25+ Signed-off-by: Stefan Haberland Reviewed-by: Jan Hoeppner Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 4c825540af16197d84e6cf943972eccf6ea54ff6 Author: Jan Kara Date: Tue Jul 30 13:10:14 2019 +0200 loop: Fix mount(2) failure due to race with LOOP_SET_FD commit 89e524c04fa966330e2e80ab2bc50b9944c5847a upstream. Commit 33ec3e53e7b1 ("loop: Don't change loop device under exclusive opener") made LOOP_SET_FD ioctl acquire exclusive block device reference while it updates loop device binding. However this can make perfectly valid mount(2) fail with EBUSY due to racing LOOP_SET_FD holding temporarily the exclusive bdev reference in cases like this: for i in {a..z}{a..z}; do dd if=/dev/zero of=$i.image bs=1k count=0 seek=1024 mkfs.ext2 $i.image mkdir mnt$i done echo "Run" for i in {a..z}{a..z}; do mount -o loop -t ext2 $i.image mnt$i & done Fix the problem by not getting full exclusive bdev reference in LOOP_SET_FD but instead just mark the bdev as being claimed while we update the binding information. This just blocks new exclusive openers instead of failing them with EBUSY thus fixing the problem. Fixes: 33ec3e53e7b1 ("loop: Don't change loop device under exclusive opener") Cc: stable@vger.kernel.org Tested-by: Kai-Heng Feng Signed-off-by: Jan Kara Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 4461f834098f88df90abaefbfe283d60a117feea Author: Ralph Campbell Date: Fri Aug 2 21:49:08 2019 -0700 mm/migrate.c: initialize pud_entry in migrate_vma() commit 7b358c6f12dc82364f6d317f8c8f1d794adbc3f5 upstream. 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: Greg Kroah-Hartman commit d80bce352ad2fe22fa223a607ee18f5eced5d234 Author: Arnd Bergmann Date: Fri Aug 2 21:48:58 2019 -0700 ubsan: build ubsan.c more conservatively commit af700eaed0564d5d3963a7a51cb0843629d7fe3d upstream. objtool points out several conditions that it does not like, depending on the combination with other configuration options and compiler variants: stack protector: lib/ubsan.o: warning: objtool: __ubsan_handle_type_mismatch()+0xbf: call to __stack_chk_fail() with UACCESS enabled lib/ubsan.o: warning: objtool: __ubsan_handle_type_mismatch_v1()+0xbe: call to __stack_chk_fail() with UACCESS enabled stackleak plugin: lib/ubsan.o: warning: objtool: __ubsan_handle_type_mismatch()+0x4a: call to stackleak_track_stack() with UACCESS enabled lib/ubsan.o: warning: objtool: __ubsan_handle_type_mismatch_v1()+0x4a: call to stackleak_track_stack() with UACCESS enabled kasan: lib/ubsan.o: warning: objtool: __ubsan_handle_type_mismatch()+0x25: call to memcpy() with UACCESS enabled lib/ubsan.o: warning: objtool: __ubsan_handle_type_mismatch_v1()+0x25: call to memcpy() with UACCESS enabled The stackleak and kasan options just need to be disabled for this file as we do for other files already. For the stack protector, we already attempt to disable it, but this fails on clang because the check is mixed with the gcc specific -fno-conserve-stack option. According to Andrey Ryabinin, that option is not even needed, dropping it here fixes the stackprotector issue. Link: http://lkml.kernel.org/r/20190722125139.1335385-1-arnd@arndb.de Link: https://lore.kernel.org/lkml/20190617123109.667090-1-arnd@arndb.de/t/ Link: https://lore.kernel.org/lkml/20190722091050.2188664-1-arnd@arndb.de/t/ Fixes: d08965a27e84 ("x86/uaccess, ubsan: Fix UBSAN vs. SMAP") Signed-off-by: Arnd Bergmann Reviewed-by: Andrey Ryabinin Cc: Josh Poimboeuf Cc: Peter Zijlstra Cc: Arnd Bergmann Cc: Borislav Petkov Cc: Dmitry Vyukov Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Kees Cook Cc: Matthew Wilcox Cc: Ard Biesheuvel Cc: Andy Shevchenko Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit c7e8100a760fd63019ceb29f2e074716a0756962 Author: Mel Gorman Date: Fri Aug 2 21:48:51 2019 -0700 mm: compaction: avoid 100% CPU usage during compaction when a task is killed commit 670105a25608affe01cb0ccdc2a1f4bd2327172b upstream. "howaboutsynergy" reported via kernel buzilla number 204165 that compact_zone_order was consuming 100% CPU during a stress test for prolonged periods of time. Specifically the following command, which should exit in 10 seconds, was taking an excessive time to finish while the CPU was pegged at 100%. stress -m 220 --vm-bytes 1000000000 --timeout 10 Tracing indicated a pattern as follows stress-3923 [007] 519.106208: mm_compaction_isolate_migratepages: range=(0x70bb80 ~ 0x70bb80) nr_scanned=0 nr_taken=0 stress-3923 [007] 519.106212: mm_compaction_isolate_migratepages: range=(0x70bb80 ~ 0x70bb80) nr_scanned=0 nr_taken=0 stress-3923 [007] 519.106216: mm_compaction_isolate_migratepages: range=(0x70bb80 ~ 0x70bb80) nr_scanned=0 nr_taken=0 stress-3923 [007] 519.106219: mm_compaction_isolate_migratepages: range=(0x70bb80 ~ 0x70bb80) nr_scanned=0 nr_taken=0 stress-3923 [007] 519.106223: mm_compaction_isolate_migratepages: range=(0x70bb80 ~ 0x70bb80) nr_scanned=0 nr_taken=0 stress-3923 [007] 519.106227: mm_compaction_isolate_migratepages: range=(0x70bb80 ~ 0x70bb80) nr_scanned=0 nr_taken=0 stress-3923 [007] 519.106231: mm_compaction_isolate_migratepages: range=(0x70bb80 ~ 0x70bb80) nr_scanned=0 nr_taken=0 stress-3923 [007] 519.106235: mm_compaction_isolate_migratepages: range=(0x70bb80 ~ 0x70bb80) nr_scanned=0 nr_taken=0 stress-3923 [007] 519.106238: mm_compaction_isolate_migratepages: range=(0x70bb80 ~ 0x70bb80) nr_scanned=0 nr_taken=0 stress-3923 [007] 519.106242: mm_compaction_isolate_migratepages: range=(0x70bb80 ~ 0x70bb80) nr_scanned=0 nr_taken=0 Note that compaction is entered in rapid succession while scanning and isolating nothing. The problem is that when a task that is compacting receives a fatal signal, it retries indefinitely instead of exiting while making no progress as a fatal signal is pending. It's not easy to trigger this condition although enabling zswap helps on the basis that the timing is altered. A very small window has to be hit for the problem to occur (signal delivered while compacting and isolating a PFN for migration that is not aligned to SWAP_CLUSTER_MAX). This was reproduced locally -- 16G single socket system, 8G swap, 30% zswap configured, vm-bytes 22000000000 using Colin Kings stress-ng implementation from github running in a loop until the problem hits). Tracing recorded the problem occurring almost 200K times in a short window. With this patch, the problem hit 4 times but the task existed normally instead of consuming CPU. This problem has existed for some time but it was made worse by commit cf66f0700c8f ("mm, compaction: do not consider a need to reschedule as contention"). Before that commit, if the same condition was hit then locks would be quickly contended and compaction would exit that way. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204165 Link: http://lkml.kernel.org/r/20190718085708.GE24383@techsingularity.net Fixes: cf66f0700c8f ("mm, compaction: do not consider a need to reschedule as contention") Signed-off-by: Mel Gorman Reviewed-by: Vlastimil Babka Cc: [5.1+] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 03f288eff9752eef25e320b7ef7ee9f644656d91 Author: Jan Kara Date: Fri Aug 2 21:48:47 2019 -0700 mm: migrate: fix reference check race between __find_get_block() and migration commit ebdf4de5642fb6580b0763158b6b4b791c4d6a4d upstream. buffer_migrate_page_norefs() can race with bh users in the following way: CPU1 CPU2 buffer_migrate_page_norefs() buffer_migrate_lock_buffers() checks bh refs spin_unlock(&mapping->private_lock) __find_get_block() spin_lock(&mapping->private_lock) grab bh ref spin_unlock(&mapping->private_lock) move page do bh work This can result in various issues like lost updates to buffers (i.e. metadata corruption) or use after free issues for the old page. This patch closes the race by holding mapping->private_lock while the mapping is being moved to a new page. Ordinarily, a reference can be taken outside of the private_lock using the per-cpu BH LRU but the references are checked and the LRU invalidated if necessary. The private_lock is held once the references are known so the buffer lookup slow path will spin on the private_lock. Between the page lock and private_lock, it should be impossible for other references to be acquired and updates to happen during the migration. A user had reported data corruption issues on a distribution kernel with a similar page migration implementation as mainline. The data corruption could not be reproduced with this patch applied. A small number of migration-intensive tests were run and no performance problems were noted. [mgorman@techsingularity.net: Changelog, removed tracing] Link: http://lkml.kernel.org/r/20190718090238.GF24383@techsingularity.net Fixes: 89cb0888ca14 "mm: migrate: provide buffer_migrate_page_norefs()" Signed-off-by: Jan Kara Signed-off-by: Mel Gorman Cc: [5.0+] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit e57197b0fd7aee9a20ef72bb65464a180a572ec3 Author: Yang Shi Date: Fri Aug 2 21:48:44 2019 -0700 mm: vmscan: check if mem cgroup is disabled or not before calling memcg slab shrinker commit fa1e512fac717f34e7c12d7a384c46e90a647392 upstream. Shakeel Butt reported premature oom on kernel with "cgroup_disable=memory" since mem_cgroup_is_root() returns false even though memcg is actually NULL. The drop_caches is also broken. It is because commit aeed1d325d42 ("mm/vmscan.c: generalize shrink_slab() calls in shrink_node()") removed the !memcg check before !mem_cgroup_is_root(). And, surprisingly root memcg is allocated even though memory cgroup is disabled by kernel boot parameter. Add mem_cgroup_disabled() check to make reclaimer work as expected. Link: http://lkml.kernel.org/r/1563385526-20805-1-git-send-email-yang.shi@linux.alibaba.com Fixes: aeed1d325d42 ("mm/vmscan.c: generalize shrink_slab() calls in shrink_node()") Signed-off-by: Yang Shi Reported-by: Shakeel Butt Reviewed-by: Shakeel Butt Reviewed-by: Kirill Tkhai Acked-by: Michal Hocko Cc: Jan Hadrava Cc: Vladimir Davydov Cc: Johannes Weiner Cc: Roman Gushchin Cc: Hugh Dickins Cc: Qian Cai Cc: Kirill A. Shutemov Cc: [4.19+] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 35e05c7ae9d311d4204ca8187a46b030129a2009 Author: Samuel Thibault Date: Fri Jul 26 23:47:02 2019 +0200 ALSA: hda: Fix 1-minute detection delay when i915 module is not available commit 74bf71ed792ab0f64631cc65ccdb54c356c36d45 upstream. Distribution installation images such as Debian include different sets of modules which can be downloaded dynamically. Such images may notably include the hda sound modules but not the i915 DRM module, even if the latter was enabled at build time, as reported on https://bugs.debian.org/931507 In such a case hdac_i915 would be linked in and try to load the i915 module, fail since it is not there, but still wait for a whole minute before giving up binding with it. This fixes such as case by only waiting for the binding if the module was properly loaded (or module support is disabled, in which case i915 is already compiled-in anyway). Fixes: f9b54e1961c7 ("ALSA: hda/i915: Allow delayed i915 audio component binding") Signed-off-by: Samuel Thibault Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit a06eed8e7c2193193c327355711af0b7cbe9f430 Author: Ondrej Mosnacek Date: Thu Jul 25 12:52:43 2019 +0200 selinux: fix memory leak in policydb_init() commit 45385237f65aeee73641f1ef737d7273905a233f upstream. Since roles_init() adds some entries to the role hash table, we need to destroy also its keys/values on error, otherwise we get a memory leak in the error path. Cc: Reported-by: syzbot+fee3a14d4cdf92646287@syzkaller.appspotmail.com Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Ondrej Mosnacek Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 5040b84bd31ab5b501f5906fbf7a0e7036cc62ca Author: Christophe Leroy Date: Wed Jul 31 06:01:42 2019 +0000 powerpc/kasan: fix early boot failure on PPC32 commit d7e23b887f67178c4f840781be7a6aa6aeb52ab1 upstream. Due to commit 4a6d8cf90017 ("powerpc/mm: don't use pte_alloc_kernel() until slab is available on PPC32"), pte_alloc_kernel() cannot be used during early KASAN init. Fix it by using memblock_alloc() instead. Fixes: 2edb16efc899 ("powerpc/32: Add KASAN support") Cc: stable@vger.kernel.org # v5.2+ Reported-by: Erhard F. Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/da89670093651437f27d2975224712e0a130b055.1564552796.git.christophe.leroy@c-s.fr Signed-off-by: Greg Kroah-Hartman commit d28fa78fd052e8950347e9aad771a6e5bc773972 Author: Michał Mirosław Date: Mon Jul 22 21:05:56 2019 +0200 i2c: at91: fix clk_offset for sama5d2 commit b1ac6704493fa14b5dc19eb6b69a73932361a131 upstream. 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: Greg Kroah-Hartman commit c304e1a5fbfb1dde63d55263a8a7b01bb1a70add Author: Michał Mirosław Date: Mon Jul 22 20:55:27 2019 +0200 i2c: at91: disable TXRDY interrupt after sending data commit d12e3aae160fb26b534c4496b211d6e60a5179ed upstream. 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: Greg Kroah-Hartman commit fa6d4f0fb2cc769bfd47f20ea1680b30b757328d Author: Rayagonda Kokatanur Date: Wed Jul 24 13:58:27 2019 +0530 i2c: iproc: Fix i2c master read more than 63 bytes commit fd01eecdf9591453177d7b06faaabef8c300114a upstream. Use SMBUS_MASTER_DATA_READ.MASTER_RD_STATUS bit to check for RX FIFO empty condition because SMBUS_MASTER_FIFO_CONTROL.MASTER_RX_PKT_COUNT is not updated for read >= 64 bytes. This fixes the issue when trying to read from the I2C slave more than 63 bytes. Fixes: c24b8d574b7c ("i2c: iproc: Extend I2C read up to 255 bytes") Cc: stable@kernel.org Signed-off-by: Rayagonda Kokatanur Reviewed-by: Ray Jui Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit b34a11fd865ec865d5a915777ae192020665faaa Author: Jean Delvare Date: Sun Jul 28 18:41:38 2019 +0200 eeprom: at24: make spd world-readable again commit 25e5ef302c24a6fead369c0cfe88c073d7b97ca8 upstream. The integration of the at24 driver into the nvmem framework broke the world-readability of spd EEPROMs. Fix it. Signed-off-by: Jean Delvare Cc: stable@vger.kernel.org Fixes: 57d155506dd5 ("eeprom: at24: extend driver to plug into the NVMEM framework") Cc: Andrew Lunn Cc: Srinivas Kandagatla Cc: Greg Kroah-Hartman Cc: Bartosz Golaszewski Cc: Arnd Bergmann Signed-off-by: Bartosz Golaszewski Signed-off-by: Greg Kroah-Hartman commit b88a3fe40b1f10ec3d3b3d2b8d6f8ecda35eb927 Author: Marco Felsch Date: Tue Jul 30 15:44:07 2019 +0200 mtd: rawnand: micron: handle on-die "ECC-off" devices correctly commit 8493b2a06fc5b77ef5c579dc32b12761f7b7a84c upstream. Some devices are not supposed to support on-die ECC but experience shows that internal ECC machinery can actually be enabled through the "SET FEATURE (EFh)" command, even if a read of the "READ ID Parameter Tables" returns that it is not. Currently, the driver checks the "READ ID Parameter" field directly after having enabled the feature. If the check fails it returns immediately but leaves the ECC on. When using buggy chips like MT29F2G08ABAGA and MT29F2G08ABBGA, all future read/program cycles will go through the on-die ECC, confusing the host controller which is supposed to be the one handling correction. To address this in a common way we need to turn off the on-die ECC directly after reading the "READ ID Parameter" and before checking the "ECC status". Cc: stable@vger.kernel.org Fixes: dbc44edbf833 ("mtd: rawnand: micron: Fix on-die ECC detection logic") Signed-off-by: Marco Felsch Reviewed-by: Boris Brezillon Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit fcb4d250ab4938e714c26ad6c4838a7bc667d071 Author: Lyude Paul Date: Thu Aug 1 18:02:15 2019 -0400 drm/nouveau: Only release VCPI slots on mode changes commit 412e85b605315fd129a849599cf4a5a7959573a8 upstream. Looks like a regression got introduced into nv50_mstc_atomic_check() that somehow didn't get found until now. If userspace changes crtc_state->active to false but leaves the CRTC enabled, we end up calling drm_dp_atomic_find_vcpi_slots() using the PBN calculated in asyh->dp.pbn. However, if the display is inactive we end up calculating a PBN of 0, which inadvertently causes us to have an allocation of 0. >From there, if userspace then disables the CRTC afterwards we end up accidentally attempting to free the VCPI twice: WARNING: CPU: 0 PID: 1484 at drivers/gpu/drm/drm_dp_mst_topology.c:3336 drm_dp_atomic_release_vcpi_slots+0x87/0xb0 [drm_kms_helper] RIP: 0010:drm_dp_atomic_release_vcpi_slots+0x87/0xb0 [drm_kms_helper] Call Trace: drm_atomic_helper_check_modeset+0x3f3/0xa60 [drm_kms_helper] ? drm_atomic_check_only+0x43/0x780 [drm] drm_atomic_helper_check+0x15/0x90 [drm_kms_helper] nv50_disp_atomic_check+0x83/0x1d0 [nouveau] drm_atomic_check_only+0x54d/0x780 [drm] ? drm_atomic_set_crtc_for_connector+0xec/0x100 [drm] drm_atomic_commit+0x13/0x50 [drm] drm_atomic_helper_set_config+0x81/0x90 [drm_kms_helper] drm_mode_setcrtc+0x194/0x6a0 [drm] ? vprintk_emit+0x16a/0x230 ? drm_ioctl+0x163/0x390 [drm] ? drm_mode_getcrtc+0x180/0x180 [drm] drm_ioctl_kernel+0xaa/0xf0 [drm] drm_ioctl+0x208/0x390 [drm] ? drm_mode_getcrtc+0x180/0x180 [drm] nouveau_drm_ioctl+0x63/0xb0 [nouveau] do_vfs_ioctl+0x405/0x660 ? recalc_sigpending+0x17/0x50 ? _copy_from_user+0x37/0x60 ksys_ioctl+0x5e/0x90 ? exit_to_usermode_loop+0x92/0xe0 __x64_sys_ioctl+0x16/0x20 do_syscall_64+0x59/0x190 entry_SYSCALL_64_after_hwframe+0x44/0xa9 WARNING: CPU: 0 PID: 1484 at drivers/gpu/drm/drm_dp_mst_topology.c:3336 drm_dp_atomic_release_vcpi_slots+0x87/0xb0 [drm_kms_helper] ---[ end trace 4c395c0c51b1f88d ]--- [drm:drm_dp_atomic_release_vcpi_slots [drm_kms_helper]] *ERROR* no VCPI for [MST PORT:00000000e288eb7d] found in mst state 000000008e642070 So, fix this by doing what we probably should have done from the start: only call drm_dp_atomic_find_vcpi_slots() when crtc_state->mode_changed is set, so that VCPI allocations remain for as long as the CRTC is enabled. Signed-off-by: Lyude Paul Fixes: 232c9eec417a ("drm/nouveau: Use atomic VCPI helpers for MST") Cc: Lyude Paul Cc: Ben Skeggs Cc: Daniel Vetter Cc: David Airlie Cc: Jerry Zuo Cc: Harry Wentland Cc: Juston Li Cc: Karol Herbst Cc: Laurent Pinchart Cc: Ilia Mirkin Cc: # v5.1+ Acked-by: Ben Skeggs Signed-off-by: Dave Airlie Link: https://patchwork.freedesktop.org/patch/msgid/20190801220216.15323-1-lyude@redhat.com Signed-off-by: Greg Kroah-Hartman commit 7f6589f114a668fe9a796247102e9b1892d2d72d Author: Gustavo A. R. Silva Date: Wed Jul 31 12:54:28 2019 -0500 IB/hfi1: Fix Spectre v1 vulnerability commit 6497d0a9c53df6e98b25e2b79f2295d7caa47b6e upstream. sl is controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. Fix this by sanitizing sl before using it to index ibp->sl_to_sc. Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1]. [1] https://lore.kernel.org/lkml/20180423164740.GY17484@dhcp22.suse.cz/ Cc: stable@vger.kernel.org Signed-off-by: Gustavo A. R. Silva Link: https://lore.kernel.org/r/20190731175428.GA16736@embeddedor Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit 4453c332136583fcb97a9e4f5851eaf33c91a378 Author: Michael Wu Date: Mon Jul 8 13:23:08 2019 +0800 gpiolib: fix incorrect IRQ requesting of an active-low lineevent commit 223ecaf140b1dd1c1d2a1a1d96281efc5c906984 upstream. When a pin is active-low, logical trigger edge should be inverted to match the same interrupt opportunity. For example, a button pushed triggers falling edge in ACTIVE_HIGH case; in ACTIVE_LOW case, the button pushed triggers rising edge. For user space the IRQ requesting doesn't need to do any modification except to configuring GPIOHANDLE_REQUEST_ACTIVE_LOW. For example, we want to catch the event when the button is pushed. The button on the original board drives level to be low when it is pushed, and drives level to be high when it is released. In user space we can do: req.handleflags = GPIOHANDLE_REQUEST_INPUT; req.eventflags = GPIOEVENT_REQUEST_FALLING_EDGE; while (1) { read(fd, &dat, sizeof(dat)); if (dat.id == GPIOEVENT_EVENT_FALLING_EDGE) printf("button pushed\n"); } Run the same logic on another board which the polarity of the button is inverted; it drives level to be high when pushed, and level to be low when released. For this inversion we add flag GPIOHANDLE_REQUEST_ACTIVE_LOW: req.handleflags = GPIOHANDLE_REQUEST_INPUT | GPIOHANDLE_REQUEST_ACTIVE_LOW; req.eventflags = GPIOEVENT_REQUEST_FALLING_EDGE; At the result, there are no any events caught when the button is pushed. By the way, button releasing will emit a "falling" event. The timing of "falling" catching is not expected. Cc: stable@vger.kernel.org Signed-off-by: Michael Wu Tested-by: Bartosz Golaszewski Signed-off-by: Bartosz Golaszewski Signed-off-by: Greg Kroah-Hartman commit 3fd455ca927b4e06d84ffc5e4eb097addd88b7f3 Author: Bartosz Golaszewski Date: Mon Jul 8 10:23:43 2019 +0200 gpio: don't WARN() on NULL descs if gpiolib is disabled commit ffe0bbabb0cffceceae07484fde1ec2a63b1537c upstream. 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: Greg Kroah-Hartman commit cda67846b748a9d9005587e3bed35ba22e2d0d5e Author: Chris Packham Date: Mon Jul 8 08:35:58 2019 +1200 gpiolib: Preserve desc->flags when setting state commit d95da993383c78f7efd25957ba3af23af4b1c613 upstream. desc->flags may already have values set by of_gpiochip_add() so make sure that this isn't undone when setting the initial direction. Cc: stable@vger.kernel.org Fixes: 3edfb7bd76bd1cba ("gpiolib: Show correct direction from the beginning") Signed-off-by: Chris Packham Link: https://lore.kernel.org/r/20190707203558.10993-1-chris.packham@alliedtelesis.co.nz Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 8acd3fc56a6f6dd2b5de148033e2d8fbfd871947 Author: Andreas Koop Date: Mon Jul 22 12:03:06 2019 +0800 mmc: mmc_spi: Enable stable writes commit 3a6ffb3c8c3274a39dc8f2514526e645c5d21753 upstream. While using the mmc_spi driver occasionally errors like this popped up: mmcblk0: error -84 transferring data end_request: I/O error, dev mmcblk0, sector 581756 I looked on the Internet for occurrences of the same problem and came across a helpful post [1]. It includes source code to reproduce the bug. There is also an analysis about the cause. During transmission data in the supplied buffer is being modified. Thus the previously calculated checksum is not correct anymore. After some digging I found out that device drivers are supposed to report they need stable writes. To fix this I set the appropriate flag at queue initialization if CRC checksumming is enabled for that SPI host. [1] https://groups.google.com/forum/#!msg/sim1/gLlzWeXGFr8/KevXinUXfc8J Signed-off-by: Andreas Koop [shihpo: Rebase on top of v5.3-rc1] Signed-off-by: ShihPo Hung Cc: Paul Walmsley CC: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 632def0075be32563ac3a699606e4587f30b1d49 Author: Baolin Wang Date: Mon Jul 15 18:00:14 2019 +0800 mmc: host: sdhci-sprd: Fix the missing pm_runtime_put_noidle() commit fc62113b32c95906b3ea8ba42e91014c7d0c6fa6 upstream. When the SD host controller tries to probe again due to the derferred probe mechanism, it will always keep the SD host device as runtime resume state due to missing the runtime put operation in error path last time. Thus add the pm_runtime_put_noidle() in error path to make the PM runtime counter balance, which can make the SD host device's PM runtime work well. Signed-off-by: Baolin Wang Acked-by: Adrian Hunter Fixes: fb8bd90f83c4 ("mmc: sdhci-sprd: Add Spreadtrum's initial host controller") Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 72df8803c3ae25114b7e82b4af725b0dbf1447f2 Author: Joe Perches Date: Tue Jul 9 22:04:19 2019 -0700 mmc: meson-mx-sdio: Fix misuse of GENMASK macro commit 665e985c2f41bebc3e6cee7e04c36a44afbc58f7 upstream. Arguments are supposed to be ordered high then low. Signed-off-by: Joe Perches Reviewed-by: Neil Armstrong Fixes: ed80a13bb4c4 ("mmc: meson-mx-sdio: Add a driver for the Amlogic Meson8 and Meson8b SoCs") Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit d1810586cf3d4066139accf695a5d421b1a6076d Author: Douglas Anderson Date: Mon Jul 8 12:56:13 2019 -0700 mmc: dw_mmc: Fix occasional hang after tuning on eMMC commit ba2d139b02ba684c6c101de42fed782d6cd2b997 upstream. In commit 46d179525a1f ("mmc: dw_mmc: Wait for data transfer after response errors.") we fixed a tuning-induced hang that I saw when stress testing tuning on certain SD cards. I won't re-hash that whole commit, but the summary is that as a normal part of tuning you need to deal with transfer errors and there were cases where these transfer errors was putting my system into a bad state causing all future transfers to fail. That commit fixed handling of the transfer errors for me. In downstream Chrome OS my fix landed and had the same behavior for all SD/MMC commands. However, it looks like when the commit landed upstream we limited it to only SD tuning commands. Presumably this was to try to get around problems that Alim Akhtar reported on exynos [1]. Unfortunately while stress testing reboots (and suspend/resume) on some rk3288-based Chromebooks I found the same problem on the eMMC on some of my Chromebooks (the ones with Hynix eMMC). Since the eMMC tuning command is different (MMC_SEND_TUNING_BLOCK_HS200 vs. MMC_SEND_TUNING_BLOCK) we were basically getting back into the same situation. I'm hoping that whatever problems exynos was having in the past are somehow magically fixed now and we can make the behavior the same for all commands. [1] https://lkml.kernel.org/r/CAGOxZ53WfNbaMe0_AM0qBqU47kAfgmPBVZC8K8Y-_J3mDMqW4A@mail.gmail.com Fixes: 46d179525a1f ("mmc: dw_mmc: Wait for data transfer after response errors.") Signed-off-by: Douglas Anderson Cc: Marek Szyprowski Cc: Alim Akhtar Cc: Enric Balletbo i Serra Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit e4287f51fcb456f6e4f41a8d41073e63d8ea4fdb Author: Changbin Du Date: Tue Jul 30 22:08:50 2019 +0800 fgraph: Remove redundant ftrace_graph_notrace_addr() test commit 6c77221df96177da0520847ce91e33f539fb8b2d upstream. We already have tested it before. The second one should be removed. With this change, the performance should have little improvement. Link: http://lkml.kernel.org/r/20190730140850.7927-1-changbin.du@gmail.com Cc: stable@vger.kernel.org Fixes: 9cd2992f2d6c ("fgraph: Have set_graph_notrace only affect function_graph tracer") Signed-off-by: Changbin Du Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 349cd3dcbf9b73fcebe9206db124078188d1b9f5 Author: Jan Kara Date: Mon Jul 29 13:57:49 2019 +0200 dax: Fix missed wakeup in put_unlocked_entry() commit 61c30c98ef17e5a330d7bb8494b78b3d6dffe9b8 upstream. The condition checking whether put_unlocked_entry() needs to wake up following waiter got broken by commit 23c84eb78375 ("dax: Fix missed wakeup with PMD faults"). We need to wake the waiter whenever the passed entry is valid (i.e., non-NULL and not special conflict entry). This could lead to processes never being woken up when waiting for entry lock. Fix the condition. Cc: Link: http://lore.kernel.org/r/20190729120228.GC17833@quack2.suse.cz Fixes: 23c84eb78375 ("dax: Fix missed wakeup with PMD faults") Signed-off-by: Jan Kara Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit 32553c35c88040f21beeb20ec96532eb182d3b5e Author: Filipe Manana Date: Thu Jul 25 11:27:04 2019 +0100 Btrfs: fix race leading to fs corruption after transaction abort commit cb2d3daddbfb6318d170e79aac1f7d5e4d49f0d7 upstream. When one transaction is finishing its commit, it is possible for another transaction to start and enter its initial commit phase as well. If the first ends up getting aborted, we have a small time window where the second transaction commit does not notice that the previous transaction aborted and ends up committing, writing a superblock that points to btrees that reference extent buffers (nodes and leafs) that were not persisted to disk. The consequence is that after mounting the filesystem again, we will be unable to load some btree nodes/leafs, either because the content on disk is either garbage (or just zeroes) or corresponds to the old content of a previouly COWed or deleted node/leaf, resulting in the well known error messages "parent transid verify failed on ...". The following sequence diagram illustrates how this can happen. CPU 1 CPU 2 btrfs_commit_transaction() (...) --> sets transaction state to TRANS_STATE_UNBLOCKED --> sets fs_info->running_transaction to NULL (...) btrfs_start_transaction() start_transaction() wait_current_trans() --> returns immediately because fs_info->running_transaction is NULL join_transaction() --> creates transaction N + 1 --> sets fs_info->running_transaction to transaction N + 1 --> adds transaction N + 1 to the fs_info->trans_list list --> returns transaction handle pointing to the new transaction N + 1 (...) btrfs_sync_file() btrfs_start_transaction() --> returns handle to transaction N + 1 (...) btrfs_write_and_wait_transaction() --> writeback of some extent buffer fails, returns an error btrfs_handle_fs_error() --> sets BTRFS_FS_STATE_ERROR in fs_info->fs_state --> jumps to label "scrub_continue" cleanup_transaction() btrfs_abort_transaction(N) --> sets BTRFS_FS_STATE_TRANS_ABORTED flag in fs_info->fs_state --> sets aborted field in the transaction and transaction handle structures, for transaction N only --> removes transaction from the list fs_info->trans_list btrfs_commit_transaction(N + 1) --> transaction N + 1 was not aborted, so it proceeds (...) --> sets the transaction's state to TRANS_STATE_COMMIT_START --> does not find the previous transaction (N) in the fs_info->trans_list, so it doesn't know that transaction was aborted, and the commit of transaction N + 1 proceeds (...) --> sets transaction N + 1 state to TRANS_STATE_UNBLOCKED btrfs_write_and_wait_transaction() --> succeeds writing all extent buffers created in the transaction N + 1 write_all_supers() --> succeeds --> we now have a superblock on disk that points to trees that refer to at least one extent buffer that was never persisted So fix this by updating the transaction commit path to check if the flag BTRFS_FS_STATE_TRANS_ABORTED is set on fs_info->fs_state if after setting the transaction to the TRANS_STATE_COMMIT_START we do not find any previous transaction in the fs_info->trans_list. If the flag is set, just fail the transaction commit with -EROFS, as we do in other places. The exact error code for the previous transaction abort was already logged and reported. Fixes: 49b25e0540904b ("btrfs: enhance transaction abort infrastructure") CC: stable@vger.kernel.org # 4.4+ Reviewed-by: Josef Bacik Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit ab6345fcb82ae0daf28fc0e23f32d2161fb8fb66 Author: Filipe Manana Date: Wed Jul 17 13:23:39 2019 +0100 Btrfs: fix incremental send failure after deduplication commit b4f9a1a87a48c255bb90d8a6c3d555a1abb88130 upstream. When doing an incremental send operation we can fail if we previously did deduplication operations against a file that exists in both snapshots. In that case we will fail the send operation with -EIO and print a message to dmesg/syslog like the following: BTRFS error (device sdc): Send: inconsistent snapshot, found updated \ extent for inode 257 without updated inode item, send root is 258, \ parent root is 257 This requires that we deduplicate to the same file in both snapshots for the same amount of times on each snapshot. The issue happens because a deduplication only updates the iversion of an inode and does not update any other field of the inode, therefore if we deduplicate the file on each snapshot for the same amount of time, the inode will have the same iversion value (stored as the "sequence" field on the inode item) on both snapshots, therefore it will be seen as unchanged between in the send snapshot while there are new/updated/deleted extent items when comparing to the parent snapshot. This makes the send operation return -EIO and print an error message. Example reproducer: $ mkfs.btrfs -f /dev/sdb $ mount /dev/sdb /mnt # Create our first file. The first half of the file has several 64Kb # extents while the second half as a single 512Kb extent. $ xfs_io -f -s -c "pwrite -S 0xb8 -b 64K 0 512K" /mnt/foo $ xfs_io -c "pwrite -S 0xb8 512K 512K" /mnt/foo # Create the base snapshot and the parent send stream from it. $ btrfs subvolume snapshot -r /mnt /mnt/mysnap1 $ btrfs send -f /tmp/1.snap /mnt/mysnap1 # Create our second file, that has exactly the same data as the first # file. $ xfs_io -f -c "pwrite -S 0xb8 0 1M" /mnt/bar # Create the second snapshot, used for the incremental send, before # doing the file deduplication. $ btrfs subvolume snapshot -r /mnt /mnt/mysnap2 # Now before creating the incremental send stream: # # 1) Deduplicate into a subrange of file foo in snapshot mysnap1. This # will drop several extent items and add a new one, also updating # the inode's iversion (sequence field in inode item) by 1, but not # any other field of the inode; # # 2) Deduplicate into a different subrange of file foo in snapshot # mysnap2. This will replace an extent item with a new one, also # updating the inode's iversion by 1 but not any other field of the # inode. # # After these two deduplication operations, the inode items, for file # foo, are identical in both snapshots, but we have different extent # items for this inode in both snapshots. We want to check this doesn't # cause send to fail with an error or produce an incorrect stream. $ xfs_io -r -c "dedupe /mnt/bar 0 0 512K" /mnt/mysnap1/foo $ xfs_io -r -c "dedupe /mnt/bar 512K 512K 512K" /mnt/mysnap2/foo # Create the incremental send stream. $ btrfs send -p /mnt/mysnap1 -f /tmp/2.snap /mnt/mysnap2 ERROR: send ioctl failed with -5: Input/output error This issue started happening back in 2015 when deduplication was updated to not update the inode's ctime and mtime and update only the iversion. Back then we would hit a BUG_ON() in send, but later in 2016 send was updated to return -EIO and print the error message instead of doing the BUG_ON(). A test case for fstests follows soon. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203933 Fixes: 1c919a5e13702c ("btrfs: don't update mtime/ctime on deduped inodes") CC: stable@vger.kernel.org # 4.4+ Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 94d41b0f841ae4d2caaa00a71773879a4c258e27 Author: Milan Broz Date: Thu Jul 4 09:26:15 2019 +0200 tpm: Fix null pointer dereference on chip register error path commit 1e5ac6300a07ceecfc70a893ebef3352be21e6f8 upstream. If clk_enable is not defined and chip initialization is canceled code hits null dereference. Easily reproducible with vTPM init fail: swtpm chardev --tpmstate dir=nonexistent_dir --tpm2 --vtpm-proxy BUG: kernel NULL pointer dereference, address: 00000000 ... Call Trace: tpm_chip_start+0x9d/0xa0 [tpm] tpm_chip_register+0x10/0x1a0 [tpm] vtpm_proxy_work+0x11/0x30 [tpm_vtpm_proxy] process_one_work+0x214/0x5a0 worker_thread+0x134/0x3e0 ? process_one_work+0x5a0/0x5a0 kthread+0xd4/0x100 ? process_one_work+0x5a0/0x5a0 ? kthread_park+0x90/0x90 ret_from_fork+0x19/0x24 Fixes: 719b7d81f204 ("tpm: introduce tpm_chip_start() and tpm_chip_stop()") Cc: stable@vger.kernel.org # v5.1+ Signed-off-by: Milan Broz Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit 5478e5fddc7f8525b1c2c7ab53eadce866505388 Author: Masahiro Yamada Date: Wed Jul 31 00:58:59 2019 +0900 kbuild: modpost: include .*.cmd files only when targets exist commit 944cfe9be1fbbec73bab2f7e77fe2e8f9c72970f upstream. If a build rule fails, the .DELETE_ON_ERROR special target removes the target, but does nothing for the .*.cmd file, which might be corrupted. So, .*.cmd files should be included only when the corresponding targets exist. Commit 392885ee82d3 ("kbuild: let fixdep directly write to .*.cmd files") missed to fix up this file. Fixes: 392885ee82d3 ("kbuild: let fixdep directly write to .*.cmd") Cc: # v5.0+ Signed-off-by: Masahiro Yamada Signed-off-by: Greg Kroah-Hartman commit 57134d56a30d0550795283be1aa9236580d1dd04 Author: Masahiro Yamada Date: Mon Jul 29 18:15:17 2019 +0900 kbuild: initialize CLANG_FLAGS correctly in the top Makefile commit 5241ab4cf42d3a93b933b55d3d53f43049081fa1 upstream. CLANG_FLAGS is initialized by the following line: CLANG_FLAGS := --target=$(notdir $(CROSS_COMPILE:%-=%)) ..., which is run only when CROSS_COMPILE is set. Some build targets (bindeb-pkg etc.) recurse to the top Makefile. When you build the kernel with Clang but without CROSS_COMPILE, the same compiler flags such as -no-integrated-as are accumulated into CLANG_FLAGS. If you run 'make CC=clang' and then 'make CC=clang bindeb-pkg', Kbuild will recompile everything needlessly due to the build command change. Fix this by correctly initializing CLANG_FLAGS. Fixes: 238bcbc4e07f ("kbuild: consolidate Clang compiler flags") Cc: # v5.0+ Signed-off-by: Masahiro Yamada Reviewed-by: Nathan Chancellor Acked-by: Nick Desaulniers Signed-off-by: Greg Kroah-Hartman commit b4844fcd79cd8773d55880635ad3729a30381c70 Author: M. Vefa Bicakci Date: Sat Aug 3 06:02:12 2019 -0400 kconfig: Clear "written" flag to avoid data loss commit 0c5b6c28ed68becb692b43eae5e44d5aa7e160ce upstream. Prior to this commit, starting nconfig, xconfig or gconfig, and saving the .config file more than once caused data loss, where a .config file that contained only comments would be written to disk starting from the second save operation. This bug manifests itself because the SYMBOL_WRITTEN flag is never cleared after the first call to conf_write, and subsequent calls to conf_write then skip all of the configuration symbols due to the SYMBOL_WRITTEN flag being set. This commit resolves this issue by clearing the SYMBOL_WRITTEN flag from all symbols before conf_write returns. Fixes: 8e2442a5f86e ("kconfig: fix missing choice values in auto.conf") Cc: linux-stable # 4.19+ Signed-off-by: M. Vefa Bicakci Signed-off-by: Masahiro Yamada Signed-off-by: Greg Kroah-Hartman commit 38ae6fe4c744c683d2933359cb16e42b19528caa Author: Ralph Campbell Date: Fri Jun 14 13:20:03 2019 -0700 drm/nouveau/dmem: missing mutex_lock in error path [ Upstream commit d304654bd79332ace9ac46b9a3d8de60acb15da3 ] In nouveau_dmem_pages_alloc(), the drm->dmem->mutex is unlocked before calling nouveau_dmem_chunk_alloc() as shown when CONFIG_PROVE_LOCKING is enabled: [ 1294.871933] ===================================== [ 1294.876656] WARNING: bad unlock balance detected! [ 1294.881375] 5.2.0-rc3+ #5 Not tainted [ 1294.885048] ------------------------------------- [ 1294.889773] test-malloc-vra/6299 is trying to release lock (&drm->dmem->mutex) at: [ 1294.897482] [] nouveau_dmem_migrate_alloc_and_copy+0x79f/0xbf0 [nouveau] [ 1294.905782] but there are no more locks to release! [ 1294.910690] [ 1294.910690] other info that might help us debug this: [ 1294.917249] 1 lock held by test-malloc-vra/6299: [ 1294.921881] #0: 0000000016e10454 (&mm->mmap_sem#2){++++}, at: nouveau_svmm_bind+0x142/0x210 [nouveau] [ 1294.931313] [ 1294.931313] stack backtrace: [ 1294.935702] CPU: 4 PID: 6299 Comm: test-malloc-vra Not tainted 5.2.0-rc3+ #5 [ 1294.942786] Hardware name: ASUS X299-A/PRIME X299-A, BIOS 1401 05/21/2018 [ 1294.949590] Call Trace: [ 1294.952059] dump_stack+0x7c/0xc0 [ 1294.955469] ? nouveau_dmem_migrate_alloc_and_copy+0x79f/0xbf0 [nouveau] [ 1294.962213] print_unlock_imbalance_bug.cold.52+0xca/0xcf [ 1294.967641] lock_release+0x306/0x380 [ 1294.971383] ? nouveau_dmem_migrate_alloc_and_copy+0x79f/0xbf0 [nouveau] [ 1294.978089] ? lock_downgrade+0x2d0/0x2d0 [ 1294.982121] ? find_held_lock+0xac/0xd0 [ 1294.985979] __mutex_unlock_slowpath+0x8f/0x3f0 [ 1294.990540] ? wait_for_completion+0x230/0x230 [ 1294.995002] ? rwlock_bug.part.2+0x60/0x60 [ 1294.999197] nouveau_dmem_migrate_alloc_and_copy+0x79f/0xbf0 [nouveau] [ 1295.005751] ? page_mapping+0x98/0x110 [ 1295.009511] migrate_vma+0xa74/0x1090 [ 1295.013186] ? move_to_new_page+0x480/0x480 [ 1295.017400] ? __kmalloc+0x153/0x300 [ 1295.021052] ? nouveau_dmem_migrate_vma+0xd8/0x1e0 [nouveau] [ 1295.026796] nouveau_dmem_migrate_vma+0x157/0x1e0 [nouveau] [ 1295.032466] ? nouveau_dmem_init+0x490/0x490 [nouveau] [ 1295.037612] ? vmacache_find+0xc2/0x110 [ 1295.041537] nouveau_svmm_bind+0x1b4/0x210 [nouveau] [ 1295.046583] ? nouveau_svm_fault+0x13e0/0x13e0 [nouveau] [ 1295.051912] drm_ioctl_kernel+0x14d/0x1a0 [ 1295.055930] ? drm_setversion+0x330/0x330 [ 1295.059971] drm_ioctl+0x308/0x530 [ 1295.063384] ? drm_version+0x150/0x150 [ 1295.067153] ? find_held_lock+0xac/0xd0 [ 1295.070996] ? __pm_runtime_resume+0x3f/0xa0 [ 1295.075285] ? mark_held_locks+0x29/0xa0 [ 1295.079230] ? _raw_spin_unlock_irqrestore+0x3c/0x50 [ 1295.084232] ? lockdep_hardirqs_on+0x17d/0x250 [ 1295.088768] nouveau_drm_ioctl+0x9a/0x100 [nouveau] [ 1295.093661] do_vfs_ioctl+0x137/0x9a0 [ 1295.097341] ? ioctl_preallocate+0x140/0x140 [ 1295.101623] ? match_held_lock+0x1b/0x230 [ 1295.105646] ? match_held_lock+0x1b/0x230 [ 1295.109660] ? find_held_lock+0xac/0xd0 [ 1295.113512] ? __do_page_fault+0x324/0x630 [ 1295.117617] ? lock_downgrade+0x2d0/0x2d0 [ 1295.121648] ? mark_held_locks+0x79/0xa0 [ 1295.125583] ? handle_mm_fault+0x352/0x430 [ 1295.129687] ksys_ioctl+0x60/0x90 [ 1295.133020] ? mark_held_locks+0x29/0xa0 [ 1295.136964] __x64_sys_ioctl+0x3d/0x50 [ 1295.140726] do_syscall_64+0x68/0x250 [ 1295.144400] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 1295.149465] RIP: 0033:0x7f1a3495809b [ 1295.153053] Code: 0f 1e fa 48 8b 05 ed bd 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d bd bd 0c 00 f7 d8 64 89 01 48 [ 1295.171850] RSP: 002b:00007ffef7ed1358 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 1295.179451] RAX: ffffffffffffffda RBX: 00007ffef7ed1628 RCX: 00007f1a3495809b [ 1295.186601] RDX: 00007ffef7ed13b0 RSI: 0000000040406449 RDI: 0000000000000004 [ 1295.193759] RBP: 00007ffef7ed13b0 R08: 0000000000000000 R09: 000000000157e770 [ 1295.200917] R10: 000000000151c010 R11: 0000000000000246 R12: 0000000040406449 [ 1295.208083] R13: 0000000000000004 R14: 0000000000000000 R15: 0000000000000000 Reacquire the lock before continuing to the next page. Signed-off-by: Ralph Campbell Signed-off-by: Ben Skeggs Signed-off-by: Sasha Levin commit cdec20297900d8d6a1a1d093257d09b4be196d53 Author: Yongxin Liu Date: Mon Jul 1 09:46:22 2019 +0800 drm/nouveau: fix memory leak in nouveau_conn_reset() [ Upstream commit 09b90e2fe35faeace2488234e2a7728f2ea8ba26 ] In nouveau_conn_reset(), if connector->state is true, __drm_atomic_helper_connector_destroy_state() will be called, but the memory pointed by asyc isn't freed. Memory leak happens in the following function __drm_atomic_helper_connector_reset(), where newly allocated asyc->state will be assigned to connector->state. So using nouveau_conn_atomic_destroy_state() instead of __drm_atomic_helper_connector_destroy_state to free the "old" asyc. Here the is the log showing memory leak. unreferenced object 0xffff8c5480483c80 (size 192): comm "kworker/0:2", pid 188, jiffies 4294695279 (age 53.179s) hex dump (first 32 bytes): 00 f0 ba 7b 54 8c ff ff 00 00 00 00 00 00 00 00 ...{T........... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000005005c0d0>] kmem_cache_alloc_trace+0x195/0x2c0 [<00000000a122baed>] nouveau_conn_reset+0x25/0xc0 [nouveau] [<000000004fd189a2>] nouveau_connector_create+0x3a7/0x610 [nouveau] [<00000000c73343a8>] nv50_display_create+0x343/0x980 [nouveau] [<000000002e2b03c3>] nouveau_display_create+0x51f/0x660 [nouveau] [<00000000c924699b>] nouveau_drm_device_init+0x182/0x7f0 [nouveau] [<00000000cc029436>] nouveau_drm_probe+0x20c/0x2c0 [nouveau] [<000000007e961c3e>] local_pci_probe+0x47/0xa0 [<00000000da14d569>] work_for_cpu_fn+0x1a/0x30 [<0000000028da4805>] process_one_work+0x27c/0x660 [<000000001d415b04>] worker_thread+0x22b/0x3f0 [<0000000003b69f1f>] kthread+0x12f/0x150 [<00000000c94c29b7>] ret_from_fork+0x3a/0x50 Signed-off-by: Yongxin Liu Signed-off-by: Ben Skeggs Signed-off-by: Sasha Levin commit 33260ae248358a7b0064edd27e85c142505463ca Author: Josh Poimboeuf Date: Wed Jul 17 20:36:45 2019 -0500 bpf: Disable GCC -fgcse optimization for ___bpf_prog_run() [ Upstream commit 3193c0836f203a91bef96d88c64cccf0be090d9c ] On x86-64, with CONFIG_RETPOLINE=n, GCC's "global common subexpression elimination" optimization results in ___bpf_prog_run()'s jumptable code changing from this: select_insn: jmp *jumptable(, %rax, 8) ... ALU64_ADD_X: ... jmp *jumptable(, %rax, 8) ALU_ADD_X: ... jmp *jumptable(, %rax, 8) to this: select_insn: mov jumptable, %r12 jmp *(%r12, %rax, 8) ... ALU64_ADD_X: ... jmp *(%r12, %rax, 8) ALU_ADD_X: ... jmp *(%r12, %rax, 8) The jumptable address is placed in a register once, at the beginning of the function. The function execution can then go through multiple indirect jumps which rely on that same register value. This has a few issues: 1) Objtool isn't smart enough to be able to track such a register value across multiple recursive indirect jumps through the jump table. 2) With CONFIG_RETPOLINE enabled, this optimization actually results in a small slowdown. I measured a ~4.7% slowdown in the test_bpf "tcpdump port 22" selftest. This slowdown is actually predicted by the GCC manual: Note: When compiling a program using computed gotos, a GCC extension, you may get better run-time performance if you disable the global common subexpression elimination pass by adding -fno-gcse to the command line. So just disable the optimization for this function. Fixes: e55a73251da3 ("bpf: Fix ORC unwinding in non-JIT BPF code") Reported-by: Randy Dunlap Signed-off-by: Josh Poimboeuf Signed-off-by: Thomas Gleixner Acked-by: Alexei Starovoitov Acked-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/30c3ca29ba037afcbd860a8672eef0021addf9fe.1563413318.git.jpoimboe@redhat.com Signed-off-by: Sasha Levin commit 55ae5a6f092cead498ef7b93705975d8c3d714e6 Author: Zhenzhong Duan Date: Tue Jul 16 21:18:12 2019 +0800 x86, boot: Remove multiple copy of static function sanitize_boot_params() [ Upstream commit 8c5477e8046ca139bac250386c08453da37ec1ae ] Kernel build warns: 'sanitize_boot_params' defined but not used [-Wunused-function] at below files: arch/x86/boot/compressed/cmdline.c arch/x86/boot/compressed/error.c arch/x86/boot/compressed/early_serial_console.c arch/x86/boot/compressed/acpi.c That's becausethey each include misc.h which includes a definition of sanitize_boot_params() via bootparam_utils.h. Remove the inclusion from misc.h and have the c file including bootparam_utils.h directly. Signed-off-by: Zhenzhong Duan Signed-off-by: Thomas Gleixner Link: https://lkml.kernel.org/r/1563283092-1189-1-git-send-email-zhenzhong.duan@oracle.com Signed-off-by: Sasha Levin commit aff33bcd752038cb331b6e3a795d0ba288405264 Author: Josh Poimboeuf Date: Wed Jul 17 20:36:36 2019 -0500 x86/paravirt: Fix callee-saved function ELF sizes [ Upstream commit 083db6764821996526970e42d09c1ab2f4155dd4 ] The __raw_callee_save_*() functions have an ELF symbol size of zero, which confuses objtool and other tools. Fixes a bunch of warnings like the following: arch/x86/xen/mmu_pv.o: warning: objtool: __raw_callee_save_xen_pte_val() is missing an ELF size annotation arch/x86/xen/mmu_pv.o: warning: objtool: __raw_callee_save_xen_pgd_val() is missing an ELF size annotation arch/x86/xen/mmu_pv.o: warning: objtool: __raw_callee_save_xen_make_pte() is missing an ELF size annotation arch/x86/xen/mmu_pv.o: warning: objtool: __raw_callee_save_xen_make_pgd() is missing an ELF size annotation Signed-off-by: Josh Poimboeuf Signed-off-by: Thomas Gleixner Reviewed-by: Juergen Gross Acked-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/afa6d49bb07497ca62e4fc3b27a2d0cece545b4e.1563413318.git.jpoimboe@redhat.com Signed-off-by: Sasha Levin commit 4c6015446114c1a84b5e1775af063723eb6db4b0 Author: Josh Poimboeuf Date: Wed Jul 17 20:36:39 2019 -0500 x86/kvm: Don't call kvm_spurious_fault() from .fixup [ Upstream commit 3901336ed9887b075531bffaeef7742ba614058b ] After making a change to improve objtool's sibling call detection, it started showing the following warning: arch/x86/kvm/vmx/nested.o: warning: objtool: .fixup+0x15: sibling call from callable instruction with modified stack frame The problem is the ____kvm_handle_fault_on_reboot() macro. It does a fake call by pushing a fake RIP and doing a jump. That tricks the unwinder into printing the function which triggered the exception, rather than the .fixup code. Instead of the hack to make it look like the original function made the call, just change the macro so that the original function actually does make the call. This allows removal of the hack, and also makes objtool happy. I triggered a vmx instruction exception and verified that the stack trace is still sane: kernel BUG at arch/x86/kvm/x86.c:358! invalid opcode: 0000 [#1] SMP PTI CPU: 28 PID: 4096 Comm: qemu-kvm Not tainted 5.2.0+ #16 Hardware name: Lenovo THINKSYSTEM SD530 -[7X2106Z000]-/-[7X2106Z000]-, BIOS -[TEE113Z-1.00]- 07/17/2017 RIP: 0010:kvm_spurious_fault+0x5/0x10 Code: 00 00 00 00 00 8b 44 24 10 89 d2 45 89 c9 48 89 44 24 10 8b 44 24 08 48 89 44 24 08 e9 d4 40 22 00 0f 1f 40 00 0f 1f 44 00 00 <0f> 0b 66 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 41 55 49 89 fd 41 RSP: 0018:ffffbf91c683bd00 EFLAGS: 00010246 RAX: 000061f040000000 RBX: ffff9e159c77bba0 RCX: ffff9e15a5c87000 RDX: 0000000665c87000 RSI: ffff9e15a5c87000 RDI: ffff9e159c77bba0 RBP: 0000000000000000 R08: 0000000000000000 R09: ffff9e15a5c87000 R10: 0000000000000000 R11: fffff8f2d99721c0 R12: ffff9e159c77bba0 R13: ffffbf91c671d960 R14: ffff9e159c778000 R15: 0000000000000000 FS: 00007fa341cbe700(0000) GS:ffff9e15b7400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fdd38356804 CR3: 00000006759de003 CR4: 00000000007606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: loaded_vmcs_init+0x4f/0xe0 alloc_loaded_vmcs+0x38/0xd0 vmx_create_vcpu+0xf7/0x600 kvm_vm_ioctl+0x5e9/0x980 ? __switch_to_asm+0x40/0x70 ? __switch_to_asm+0x34/0x70 ? __switch_to_asm+0x40/0x70 ? __switch_to_asm+0x34/0x70 ? free_one_page+0x13f/0x4e0 do_vfs_ioctl+0xa4/0x630 ksys_ioctl+0x60/0x90 __x64_sys_ioctl+0x16/0x20 do_syscall_64+0x55/0x1c0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7fa349b1ee5b Signed-off-by: Josh Poimboeuf Signed-off-by: Thomas Gleixner Acked-by: Paolo Bonzini Acked-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/64a9b64d127e87b6920a97afde8e96ea76f6524e.1563413318.git.jpoimboe@redhat.com Signed-off-by: Sasha Levin commit 308f2134d0c5cd85dc9489cadb86ad1982f67eba Author: Zhenzhong Duan Date: Sun Jul 14 17:15:32 2019 +0800 xen/pv: Fix a boot up hang revealed by int3 self test [ Upstream commit b23e5844dfe78a80ba672793187d3f52e4b528d7 ] Commit 7457c0da024b ("x86/alternatives: Add int3_emulate_call() selftest") is used to ensure there is a gap setup in int3 exception stack which could be used for inserting call return address. This gap is missed in XEN PV int3 exception entry path, then below panic triggered: [ 0.772876] general protection fault: 0000 [#1] SMP NOPTI [ 0.772886] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.2.0+ #11 [ 0.772893] RIP: e030:int3_magic+0x0/0x7 [ 0.772905] RSP: 3507:ffffffff82203e98 EFLAGS: 00000246 [ 0.773334] Call Trace: [ 0.773334] alternative_instructions+0x3d/0x12e [ 0.773334] check_bugs+0x7c9/0x887 [ 0.773334] ? __get_locked_pte+0x178/0x1f0 [ 0.773334] start_kernel+0x4ff/0x535 [ 0.773334] ? set_init_arg+0x55/0x55 [ 0.773334] xen_start_kernel+0x571/0x57a For 64bit PV guests, Xen's ABI enters the kernel with using SYSRET, with %rcx/%r11 on the stack. To convert back to "normal" looking exceptions, the xen thunks do 'xen_*: pop %rcx; pop %r11; jmp *'. E.g. Extracting 'xen_pv_trap xenint3' we have: xen_xenint3: pop %rcx; pop %r11; jmp xenint3 As xenint3 and int3 entry code are same except xenint3 doesn't generate a gap, we can fix it by using int3 and drop useless xenint3. Signed-off-by: Zhenzhong Duan Reviewed-by: Juergen Gross Cc: Boris Ostrovsky Cc: Juergen Gross Cc: Stefano Stabellini Cc: Andy Lutomirski Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: Andrew Cooper Signed-off-by: Juergen Gross Signed-off-by: Sasha Levin commit b8a98fff64deffe441901b8d7e2b8f6127c68e9e Author: David Rientjes Date: Fri Jul 12 13:41:58 2019 -0700 crypto: ccp - Fix SEV_VERSION_GREATER_OR_EQUAL [ Upstream commit 83bf42510d7f7e1daa692c096e8e9919334d7b57 ] SEV_VERSION_GREATER_OR_EQUAL() will fail if upgrading from 2.2 to 3.1, for example, because the minor version is not equal to or greater than the major. Fix this and move to a static inline function for appropriate type checking. Fixes: edd303ff0e9e ("crypto: ccp - Add DOWNLOAD_FIRMWARE SEV command") Reported-by: Cfir Cohen Signed-off-by: David Rientjes Acked-by: Tom Lendacky Acked-by: Gary R Hook Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 1b3ecd64aaae6bd6fa97059a29f07a2b2e20b2c9 Author: Peter Zijlstra Date: Thu Jul 18 10:47:47 2019 +0200 stacktrace: Force USER_DS for stack_trace_save_user() [ Upstream commit cac9b9a4b08304f11daace03b8b48659355e44c1 ] When walking userspace stacks, USER_DS needs to be set, otherwise access_ok() will not function as expected. Reported-by: Vegard Nossum Reported-by: Eiichi Tsukata Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Thomas Gleixner Tested-by: Vegard Nossum Reviewed-by: Joel Fernandes (Google) Link: https://lkml.kernel.org/r/20190718085754.GM3402@hirez.programming.kicks-ass.net Signed-off-by: Sasha Levin commit 71494c7b6f0c70b5a291e5ce5dd1d2cd77599b31 Author: Pavel Tatashin Date: Tue Jul 16 16:30:31 2019 -0700 mm/hotplug: make remove_memory() interface usable [ Upstream commit eca499ab3749a4537dee77ffead47a1a2c0dee19 ] Presently the remove_memory() interface is inherently broken. It tries to remove memory but panics if some memory is not offline. The problem is that it is impossible to ensure that all memory blocks are offline as this function also takes lock_device_hotplug that is required to change memory state via sysfs. So, between calling this function and offlining all memory blocks there is always a window when lock_device_hotplug is released, and therefore, there is always a chance for a panic during this window. Make this interface to return an error if memory removal fails. This way it is safe to call this function without panicking machine, and also makes it symmetric to add_memory() which already returns an error. Link: http://lkml.kernel.org/r/20190517215438.6487-3-pasha.tatashin@soleen.com Signed-off-by: Pavel Tatashin Reviewed-by: David Hildenbrand Acked-by: Michal Hocko Cc: Bjorn Helgaas Cc: Borislav Petkov Cc: Dan Williams Cc: Dave Hansen Cc: Dave Hansen Cc: Dave Jiang Cc: Fengguang Wu Cc: Huang Ying Cc: James Morris Cc: Jérôme Glisse Cc: Keith Busch Cc: Ross Zwisler Cc: Sasha Levin Cc: Takashi Iwai Cc: Tom Lendacky Cc: Vishal Verma Cc: Yaowei Bai Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 0f15dd0543920e63a87f4639a721ffa83c3034f2 Author: Pavel Tatashin Date: Tue Jul 16 16:30:27 2019 -0700 device-dax: fix memory and resource leak if hotplug fails [ Upstream commit 31e4ca92a7dd4cdebd7fe1456b3b0b6ace9a816f ] Patch series ""Hotremove" persistent memory", v6. Recently, adding a persistent memory to be used like a regular RAM was added to Linux. This work extends this functionality to also allow hot removing persistent memory. We (Microsoft) have an important use case for this functionality. The requirement is for physical machines with small amount of RAM (~8G) to be able to reboot in a very short period of time (<1s). Yet, there is a userland state that is expensive to recreate (~2G). The solution is to boot machines with 2G preserved for persistent memory. Copy the state, and hotadd the persistent memory so machine still has all 8G available for runtime. Before reboot, offline and hotremove device-dax 2G, copy the memory that is needed to be preserved to pmem0 device, and reboot. The series of operations look like this: 1. After boot restore /dev/pmem0 to ramdisk to be consumed by apps. and free ramdisk. 2. Convert raw pmem0 to devdax ndctl create-namespace --mode devdax --map mem -e namespace0.0 -f 3. Hotadd to System RAM echo dax0.0 > /sys/bus/dax/drivers/device_dax/unbind echo dax0.0 > /sys/bus/dax/drivers/kmem/new_id echo online_movable > /sys/devices/system/memoryXXX/state 4. Before reboot hotremove device-dax memory from System RAM echo offline > /sys/devices/system/memoryXXX/state echo dax0.0 > /sys/bus/dax/drivers/kmem/unbind 5. Create raw pmem0 device ndctl create-namespace --mode raw -e namespace0.0 -f 6. Copy the state that was stored by apps to ramdisk to pmem device 7. Do kexec reboot or reboot through firmware if firmware does not zero memory in pmem0 region (These machines have only regular volatile memory). So to have pmem0 device either memmap kernel parameter is used, or devices nodes in dtb are specified. This patch (of 3): When add_memory() fails, the resource and the memory should be freed. Link: http://lkml.kernel.org/r/20190517215438.6487-2-pasha.tatashin@soleen.com Fixes: c221c0b0308f ("device-dax: "Hotplug" persistent memory for use like normal RAM") Signed-off-by: Pavel Tatashin Reviewed-by: Dave Hansen Cc: Bjorn Helgaas Cc: Borislav Petkov Cc: Dan Williams Cc: Dave Hansen Cc: Dave Jiang Cc: David Hildenbrand Cc: Fengguang Wu Cc: Huang Ying Cc: James Morris Cc: Jérôme Glisse Cc: Keith Busch Cc: Michal Hocko Cc: Ross Zwisler Cc: Sasha Levin Cc: Takashi Iwai Cc: Tom Lendacky Cc: Vishal Verma Cc: Yaowei Bai Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 4b301607af01ec85ca73c60caebbd2fb966d05f2 Author: Dmitry V. Levin Date: Tue Jul 16 16:29:24 2019 -0700 nds32: fix asm/syscall.h [ Upstream commit 33644b95eb342201511fc951d8fcd10362bd435b ] PTRACE_GET_SYSCALL_INFO is a generic ptrace API that lets ptracer obtain details of the syscall the tracee is blocked in. There are two reasons for a special syscall-related ptrace request. Firstly, with the current ptrace API there are cases when ptracer cannot retrieve necessary information about syscalls. Some examples include: * The notorious int-0x80-from-64-bit-task issue. See [1] for details. In short, if a 64-bit task performs a syscall through int 0x80, its tracer has no reliable means to find out that the syscall was, in fact, a compat syscall, and misidentifies it. * Syscall-enter-stop and syscall-exit-stop look the same for the tracer. Common practice is to keep track of the sequence of ptrace-stops in order not to mix the two syscall-stops up. But it is not as simple as it looks; for example, strace had a (just recently fixed) long-standing bug where attaching strace to a tracee that is performing the execve system call led to the tracer identifying the following syscall-exit-stop as syscall-enter-stop, which messed up all the state tracking. * Since the introduction of commit 84d77d3f06e7 ("ptrace: Don't allow accessing an undumpable mm"), both PTRACE_PEEKDATA and process_vm_readv become unavailable when the process dumpable flag is cleared. On such architectures as ia64 this results in all syscall arguments being unavailable for the tracer. Secondly, ptracers also have to support a lot of arch-specific code for obtaining information about the tracee. For some architectures, this requires a ptrace(PTRACE_PEEKUSER, ...) invocation for every syscall argument and return value. PTRACE_GET_SYSCALL_INFO returns the following structure: struct ptrace_syscall_info { __u8 op; /* PTRACE_SYSCALL_INFO_* */ __u32 arch __attribute__((__aligned__(sizeof(__u32)))); __u64 instruction_pointer; __u64 stack_pointer; union { struct { __u64 nr; __u64 args[6]; } entry; struct { __s64 rval; __u8 is_error; } exit; struct { __u64 nr; __u64 args[6]; __u32 ret_data; } seccomp; }; }; The structure was chosen according to [2], except for the following changes: * seccomp substructure was added as a superset of entry substructure * the type of nr field was changed from int to __u64 because syscall numbers are, as a practical matter, 64 bits * stack_pointer field was added along with instruction_pointer field since it is readily available and can save the tracer from extra PTRACE_GETREGS/PTRACE_GETREGSET calls * arch is always initialized to aid with tracing system calls such as execve() * instruction_pointer and stack_pointer are always initialized so they could be easily obtained for non-syscall stops * a boolean is_error field was added along with rval field, this way the tracer can more reliably distinguish a return value from an error value strace has been ported to PTRACE_GET_SYSCALL_INFO. Starting with release 4.26, strace uses PTRACE_GET_SYSCALL_INFO API as the preferred mechanism of obtaining syscall information. [1] https://lore.kernel.org/lkml/CA+55aFzcSVmdDj9Lh_gdbz1OzHyEm6ZrGPBDAJnywm2LF_eVyg@mail.gmail.com/ [2] https://lore.kernel.org/lkml/CAObL_7GM0n80N7J_DFw_eQyfLyzq+sf4y2AvsCCV88Tb3AwEHA@mail.gmail.com/ This patch (of 7): All syscall_get_*() and syscall_set_*() functions must be defined as static inline as on all other architectures, otherwise asm/syscall.h cannot be included in more than one compilation unit. This bug has to be fixed in order to extend the generic ptrace API with PTRACE_GET_SYSCALL_INFO request. Link: http://lkml.kernel.org/r/20190510152749.GA28558@altlinux.org Fixes: 1932fbe36e02 ("nds32: System calls handling") Signed-off-by: Dmitry V. Levin Reported-by: kbuild test robot Acked-by: Greentime Hu Cc: Vincent Chen Cc: Elvira Khabirova Cc: Eugene Syromyatnikov Cc: Oleg Nesterov Cc: Andy Lutomirski Cc: Benjamin Herrenschmidt Cc: Helge Deller [parisc] Cc: James E.J. Bottomley Cc: James Hogan Cc: Kees Cook Cc: Michael Ellerman Cc: Paul Burton Cc: Paul Mackerras Cc: Ralf Baechle Cc: Richard Kuo Cc: Shuah Khan Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit ab4e43005b9b8b87cfd078c44ef553dd808830d2 Author: Kees Cook Date: Tue Jul 16 16:30:21 2019 -0700 ipc/mqueue.c: only perform resource calculation if user valid [ Upstream commit a318f12ed8843cfac53198390c74a565c632f417 ] Andreas Christoforou reported: UBSAN: Undefined behaviour in ipc/mqueue.c:414:49 signed integer overflow: 9 * 2305843009213693951 cannot be represented in type 'long int' ... Call Trace: mqueue_evict_inode+0x8e7/0xa10 ipc/mqueue.c:414 evict+0x472/0x8c0 fs/inode.c:558 iput_final fs/inode.c:1547 [inline] iput+0x51d/0x8c0 fs/inode.c:1573 mqueue_get_inode+0x8eb/0x1070 ipc/mqueue.c:320 mqueue_create_attr+0x198/0x440 ipc/mqueue.c:459 vfs_mkobj+0x39e/0x580 fs/namei.c:2892 prepare_open ipc/mqueue.c:731 [inline] do_mq_open+0x6da/0x8e0 ipc/mqueue.c:771 Which could be triggered by: struct mq_attr attr = { .mq_flags = 0, .mq_maxmsg = 9, .mq_msgsize = 0x1fffffffffffffff, .mq_curmsgs = 0, }; if (mq_open("/testing", 0x40, 3, &attr) == (mqd_t) -1) perror("mq_open"); mqueue_get_inode() was correctly rejecting the giant mq_msgsize, and preparing to return -EINVAL. During the cleanup, it calls mqueue_evict_inode() which performed resource usage tracking math for updating "user", before checking if there was a valid "user" at all (which would indicate that the calculations would be sane). Instead, delay this check to after seeing a valid "user". The overflow was real, but the results went unused, so while the flaw is harmless, it's noisy for kernel fuzzers, so just fix it by moving the calculation under the non-NULL "user" where it actually gets used. Link: http://lkml.kernel.org/r/201906072207.ECB65450@keescook Signed-off-by: Kees Cook Reported-by: Andreas Christoforou Acked-by: "Eric W. Biederman" Cc: Al Viro Cc: Arnd Bergmann Cc: Davidlohr Bueso Cc: Manfred Spraul Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit c6ec03306ca05e3cae9ad92df6c693f95f2fc8ec Author: Dan Carpenter Date: Tue Jul 16 16:30:03 2019 -0700 drivers/rapidio/devices/rio_mport_cdev.c: NUL terminate some strings [ Upstream commit 156e0b1a8112b76e351684ac948c59757037ac36 ] The dev_info.name[] array has space for RIO_MAX_DEVNAME_SZ + 1 characters. But the problem here is that we don't ensure that the user put a NUL terminator on the end of the string. It could lead to an out of bounds read. Link: http://lkml.kernel.org/r/20190529110601.GB19119@mwanda Fixes: e8de370188d0 ("rapidio: add mport char device driver") Signed-off-by: Dan Carpenter Acked-by: Alexandre Bounine Cc: Ira Weiny Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 4efe530bc3101b7edb24cb2cfe5e8e41a8bdaaf5 Author: Mikko Rapeli Date: Tue Jul 16 16:28:10 2019 -0700 uapi linux/coda_psdev.h: move upc_req definition from uapi to kernel side headers [ Upstream commit f90fb3c7e2c13ae829db2274b88b845a75038b8a ] Only users of upc_req in kernel side fs/coda/psdev.c and fs/coda/upcall.c already include linux/coda_psdev.h. Suggested by Jan Harkes in https://lore.kernel.org/lkml/20150531111913.GA23377@cs.cmu.edu/ Fixes these include/uapi/linux/coda_psdev.h compilation errors in userspace: linux/coda_psdev.h:12:19: error: field `uc_chain' has incomplete type struct list_head uc_chain; ^ linux/coda_psdev.h:13:2: error: unknown type name `caddr_t' caddr_t uc_data; ^ linux/coda_psdev.h:14:2: error: unknown type name `u_short' u_short uc_flags; ^ linux/coda_psdev.h:15:2: error: unknown type name `u_short' u_short uc_inSize; /* Size is at most 5000 bytes */ ^ linux/coda_psdev.h:16:2: error: unknown type name `u_short' u_short uc_outSize; ^ linux/coda_psdev.h:17:2: error: unknown type name `u_short' u_short uc_opcode; /* copied from data to save lookup */ ^ linux/coda_psdev.h:19:2: error: unknown type name `wait_queue_head_t' wait_queue_head_t uc_sleep; /* process' wait queue */ ^ Link: http://lkml.kernel.org/r/9f99f5ce6a0563d5266e6cf7aa9585aac2cae971.1558117389.git.jaharkes@cs.cmu.edu Signed-off-by: Mikko Rapeli Signed-off-by: Jan Harkes Cc: Arnd Bergmann Cc: Colin Ian King Cc: Dan Carpenter Cc: David Howells Cc: Fabian Frederick Cc: Sam Protsenko Cc: Yann Droneaud Cc: Zhouyang Jia Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 4878313cf359a7f846c32840c329306855273b73 Author: Sam Protsenko Date: Tue Jul 16 16:28:20 2019 -0700 coda: fix build using bare-metal toolchain [ Upstream commit b2a57e334086602be56b74958d9f29b955cd157f ] The kernel is self-contained project and can be built with bare-metal toolchain. But bare-metal toolchain doesn't define __linux__. Because of this u_quad_t type is not defined when using bare-metal toolchain and codafs build fails. This patch fixes it by defining u_quad_t type unconditionally. Link: http://lkml.kernel.org/r/3cbb40b0a57b6f9923a9d67b53473c0b691a3eaa.1558117389.git.jaharkes@cs.cmu.edu Signed-off-by: Sam Protsenko Signed-off-by: Jan Harkes Cc: Arnd Bergmann Cc: Colin Ian King Cc: Dan Carpenter Cc: David Howells Cc: Fabian Frederick Cc: Mikko Rapeli Cc: Yann Droneaud Cc: Zhouyang Jia Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 4587bd7818faa405440b2901d60669d5036f2509 Author: Zhouyang Jia Date: Tue Jul 16 16:28:13 2019 -0700 coda: add error handling for fget [ Upstream commit 02551c23bcd85f0c68a8259c7b953d49d44f86af ] When fget fails, the lack of error-handling code may cause unexpected results. This patch adds error-handling code after calling fget. Link: http://lkml.kernel.org/r/2514ec03df9c33b86e56748513267a80dd8004d9.1558117389.git.jaharkes@cs.cmu.edu Signed-off-by: Zhouyang Jia Signed-off-by: Jan Harkes Cc: Arnd Bergmann Cc: Colin Ian King Cc: Dan Carpenter Cc: David Howells Cc: Fabian Frederick Cc: Mikko Rapeli Cc: Sam Protsenko Cc: Yann Droneaud Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 9c283c282397226a3ee208f5b8d2370229d4de41 Author: Anshuman Khandual Date: Tue Jul 16 16:27:30 2019 -0700 mm/ioremap: check virtual address alignment while creating huge mappings [ Upstream commit 6b95ab4218bfa59bc315105127ffe03aef3b5742 ] Virtual address alignment is essential in ensuring correct clearing for all intermediate level pgtable entries and freeing associated pgtable pages. An unaligned address can end up randomly freeing pgtable page that potentially still contains valid mappings. Hence also check it's alignment along with existing phys_addr check. Signed-off-by: Anshuman Khandual Reviewed-by: Catalin Marinas Cc: Toshi Kani Cc: Will Deacon Cc: Chintan Pandya Cc: Thomas Gleixner Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 4c546fa3e8163072996fb24d39a6489a1d5ecb8e Author: Peter Rosin Date: Tue Jul 16 16:27:18 2019 -0700 lib/test_string.c: avoid masking memset16/32/64 failures [ Upstream commit 33d6e0ff68af74be0c846c8e042e84a9a1a0561e ] If a memsetXX implementation is completely broken and fails in the first iteration, when i, j, and k are all zero, the failure is masked as zero is returned. Failing in the first iteration is perhaps the most likely failure, so this makes the tests pretty much useless. Avoid the situation by always setting a random unused bit in the result on failure. Link: http://lkml.kernel.org/r/20190506124634.6807-3-peda@axentia.se Fixes: 03270c13c5ff ("lib/string.c: add testcases for memset16/32/64") Signed-off-by: Peter Rosin Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 48dd083805cd0391b3a25a180fcd9d7ba12390a6 Author: Kees Cook Date: Tue Jul 16 16:27:24 2019 -0700 lib/test_overflow.c: avoid tainting the kernel and fix wrap size [ Upstream commit 8e060c21ae2c265a2b596e9e7f9f97ec274151a4 ] This adds __GFP_NOWARN to the kmalloc()-portions of the overflow test to avoid tainting the kernel. Additionally fixes up the math on wrap size to be architecture and page size agnostic. Link: http://lkml.kernel.org/r/201905282012.0A8767E24@keescook Fixes: ca90800a91ba ("test_overflow: Add memory allocation overflow tests") Signed-off-by: Kees Cook Reported-by: Randy Dunlap Suggested-by: Rasmus Villemoes Cc: Joe Perches Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 3657012671b7529a02fb86b38cebe203739edf53 Author: Doug Berger Date: Tue Jul 16 16:26:24 2019 -0700 mm/cma.c: fail if fixed declaration can't be honored [ Upstream commit c633324e311243586675e732249339685e5d6faa ] The description of cma_declare_contiguous() indicates that if the 'fixed' argument is true the reserved contiguous area must be exactly at the address of the 'base' argument. However, the function currently allows the 'base', 'size', and 'limit' arguments to be silently adjusted to meet alignment constraints. This commit enforces the documented behavior through explicit checks that return an error if the region does not fit within a specified region. Link: http://lkml.kernel.org/r/1561422051-16142-1-git-send-email-opendmb@gmail.com Fixes: 5ea3b1b2f8ad ("cma: add placement specifier for "cma=" kernel parameter") Signed-off-by: Doug Berger Acked-by: Michal Nazarewicz Cc: Yue Hu Cc: Mike Rapoport Cc: Laura Abbott Cc: Peng Fan Cc: Thomas Gleixner Cc: Marek Szyprowski Cc: Andrey Konovalov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit af7202977fc9c2e08f888f1ce8f9eb49df7b3a3b Author: Arnd Bergmann Date: Fri Jul 12 11:08:05 2019 +0200 x86: math-emu: Hide clang warnings for 16-bit overflow [ Upstream commit 29e7e9664aec17b94a9c8c5a75f8d216a206aa3a ] clang warns about a few parts of the math-emu implementation where a 16-bit integer becomes negative during assignment: arch/x86/math-emu/poly_tan.c:88:35: error: implicit conversion from 'int' to 'short' changes value from 49216 to -16320 [-Werror,-Wconstant-conversion] (0x41 + EXTENDED_Ebias) | SIGN_Negative); ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~ arch/x86/math-emu/fpu_emu.h:180:58: note: expanded from macro 'setexponent16' #define setexponent16(x,y) { (*(short *)&((x)->exp)) = (y); } ~ ^ arch/x86/math-emu/reg_constant.c:37:32: error: implicit conversion from 'int' to 'short' changes value from 49085 to -16451 [-Werror,-Wconstant-conversion] FPU_REG const CONST_PI2extra = MAKE_REG(NEG, -66, ^~~~~~~~~~~~~~~~~~ arch/x86/math-emu/reg_constant.c:21:25: note: expanded from macro 'MAKE_REG' ((EXTENDED_Ebias+(e)) | ((SIGN_##s != 0)*0x8000)) } ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~ arch/x86/math-emu/reg_constant.c:48:28: error: implicit conversion from 'int' to 'short' changes value from 65535 to -1 [-Werror,-Wconstant-conversion] FPU_REG const CONST_QNaN = MAKE_REG(NEG, EXP_OVER, 0x00000000, 0xC0000000); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ arch/x86/math-emu/reg_constant.c:21:25: note: expanded from macro 'MAKE_REG' ((EXTENDED_Ebias+(e)) | ((SIGN_##s != 0)*0x8000)) } ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~ The code is correct as is, so add a typecast to shut up the warnings. Signed-off-by: Arnd Bergmann Signed-off-by: Thomas Gleixner Link: https://lkml.kernel.org/r/20190712090816.350668-1-arnd@arndb.de Signed-off-by: Sasha Levin commit 75a40ae745abaa9e1a6588df71ae93627403c31c Author: Qian Cai Date: Mon Jul 8 17:36:45 2019 -0400 x86/apic: Silence -Wtype-limits compiler warnings [ Upstream commit ec6335586953b0df32f83ef696002063090c7aef ] There are many compiler warnings like this, In file included from ./arch/x86/include/asm/smp.h:13, from ./arch/x86/include/asm/mmzone_64.h:11, from ./arch/x86/include/asm/mmzone.h:5, from ./include/linux/mmzone.h:969, from ./include/linux/gfp.h:6, from ./include/linux/mm.h:10, from arch/x86/kernel/apic/io_apic.c:34: arch/x86/kernel/apic/io_apic.c: In function 'check_timer': ./arch/x86/include/asm/apic.h:37:11: warning: comparison of unsigned expression >= 0 is always true [-Wtype-limits] if ((v) <= apic_verbosity) \ ^~ arch/x86/kernel/apic/io_apic.c:2160:2: note: in expansion of macro 'apic_printk' apic_printk(APIC_QUIET, KERN_INFO "..TIMER: vector=0x%02X " ^~~~~~~~~~~ ./arch/x86/include/asm/apic.h:37:11: warning: comparison of unsigned expression >= 0 is always true [-Wtype-limits] if ((v) <= apic_verbosity) \ ^~ arch/x86/kernel/apic/io_apic.c:2207:4: note: in expansion of macro 'apic_printk' apic_printk(APIC_QUIET, KERN_ERR "..MP-BIOS bug: " ^~~~~~~~~~~ APIC_QUIET is 0, so silence them by making apic_verbosity type int. Signed-off-by: Qian Cai Signed-off-by: Thomas Gleixner Link: https://lkml.kernel.org/r/1562621805-24789-1-git-send-email-cai@lca.pw Signed-off-by: Sasha Levin commit 8a3dfde5a2b2b914ff1a8c9112dd9c0b08580a11 Author: Henry Burns Date: Tue Jul 16 16:26:21 2019 -0700 mm/z3fold.c: reinitialize zhdr structs after migration [ Upstream commit c92d2f38563db20c20c8db2f98fa1349290477d5 ] z3fold_page_migration() calls memcpy(new_zhdr, zhdr, PAGE_SIZE). However, zhdr contains fields that can't be directly coppied over (ex: list_head, a circular linked list). We only need to initialize the linked lists in new_zhdr, as z3fold_isolate_page() already ensures that these lists are empty Additionally it is possible that zhdr->work has been placed in a workqueue. In this case we shouldn't migrate the page, as zhdr->work references zhdr as opposed to new_zhdr. Link: http://lkml.kernel.org/r/20190716000520.230595-1-henryburns@google.com Fixes: 1f862989b04ade61d3 ("mm/z3fold.c: support page migration") Signed-off-by: Henry Burns Reviewed-by: Shakeel Butt Cc: Vitaly Vul Cc: Vitaly Wool Cc: Jonathan Adams Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 882217a1a54fd76f81e5a0e00fe330c956aff73f Author: Yafang Shao Date: Tue Jul 16 16:26:06 2019 -0700 mm/memcontrol.c: keep local VM counters in sync with the hierarchical ones [ Upstream commit 766a4c19d880887c457811b86f1f68525e416965 ] After commit 815744d75152 ("mm: memcontrol: don't batch updates of local VM stats and events"), the local VM counter are not in sync with the hierarchical ones. Below is one example in a leaf memcg on my server (with 8 CPUs): inactive_file 3567570944 total_inactive_file 3568029696 We find that the deviation is very great because the 'val' in __mod_memcg_state() is in pages while the effective value in memcg_stat_show() is in bytes. So the maximum of this deviation between local VM stats and total VM stats can be (32 * number_of_cpu * PAGE_SIZE), that may be an unacceptably great value. We should keep the local VM stats in sync with the total stats. In order to keep this behavior the same across counters, this patch updates __mod_lruvec_state() and __count_memcg_events() as well. Link: http://lkml.kernel.org/r/1562851979-10610-1-git-send-email-laoar.shao@gmail.com Signed-off-by: Yafang Shao Acked-by: Johannes Weiner Cc: Michal Hocko Cc: Vladimir Davydov Cc: Yafang Shao Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 271e0ab9b98f6562980446e08fb4454876af6cf7 Author: Arnd Bergmann Date: Tue Jul 16 16:25:57 2019 -0700 mm/slab_common.c: work around clang bug #42570 [ Upstream commit a07057dce2823e10d64a2b73cefbf09d8645efe9 ] Clang gets rather confused about two variables in the same special section when one of them is not initialized, leading to an assembler warning later: /tmp/slab_common-18f869.s: Assembler messages: /tmp/slab_common-18f869.s:7526: Warning: ignoring changed section attributes for .data..ro_after_init Adding an initialization to kmalloc_caches is rather silly here but does avoid the issue. Link: https://bugs.llvm.org/show_bug.cgi?id=42570 Link: http://lkml.kernel.org/r/20190712090455.266021-1-arnd@arndb.de Signed-off-by: Arnd Bergmann Acked-by: David Rientjes Reviewed-by: Andrew Morton Cc: Christoph Lameter Cc: Pekka Enberg Cc: Joonsoo Kim Cc: Stephen Rothwell Cc: Roman Gushchin Cc: Shakeel Butt Cc: Vladimir Davydov Cc: Andrey Konovalov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 8bd71641fc130b609246bb3433d09d06a5567a7a Author: Vitaly Wool Date: Tue Jul 16 16:25:48 2019 -0700 mm/z3fold: don't try to use buddy slots after free [ Upstream commit bb9a374dfa3a2f46581455ab66cd1d24c5e3d183 ] As reported by Henry Burns: Running z3fold stress testing with address sanitization showed zhdr->slots was being used after it was freed. z3fold_free(z3fold_pool, handle) free_handle(handle) kmem_cache_free(pool->c_handle, zhdr->slots) release_z3fold_page_locked_list(kref) __release_z3fold_page(zhdr, true) zhdr_to_pool(zhdr) slots_to_pool(zhdr->slots) *BOOM* To fix this, add pointer to the pool back to z3fold_header and modify zhdr_to_pool to return zhdr->pool. Link: http://lkml.kernel.org/r/20190708134808.e89f3bfadd9f6ffd7eff9ba9@gmail.com Fixes: 7c2b8baa61fe ("mm/z3fold.c: add structure for buddy handles") Signed-off-by: Vitaly Wool Reported-by: Henry Burns Reviewed-by: Shakeel Butt Cc: Jonathan Adams Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 7848564811cfa780a9797bceafd538bdaf38a194 Author: Benjamin Poirier Date: Tue Jul 16 17:16:55 2019 +0900 be2net: Signal that the device cannot transmit during reconfiguration [ Upstream commit 7429c6c0d9cb086d8e79f0d2a48ae14851d2115e ] While changing the number of interrupt channels, be2net stops adapter operation (including netif_tx_disable()) but it doesn't signal that it cannot transmit. This may lead dev_watchdog() to falsely trigger during that time. Add the missing call to netif_carrier_off(), following the pattern used in many other drivers. netif_carrier_on() is already taken care of in be_open(). Signed-off-by: Benjamin Poirier Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a381e158c784538ea1efb6c573f4714e38433719 Author: Andrii Nakryiko Date: Fri Jul 12 10:25:55 2019 -0700 bpf: fix BTF verifier size resolution logic [ Upstream commit 1acc5d5c5832da9a98b22374a8fae08ffe31b3f8 ] BTF verifier has a size resolution bug which in some circumstances leads to invalid size resolution for, e.g., TYPEDEF modifier. This happens if we have [1] PTR -> [2] TYPEDEF -> [3] ARRAY, in which case due to being in pointer context ARRAY size won't be resolved (because for pointer it doesn't matter, so it's a sink in pointer context), but it will be permanently remembered as zero for TYPEDEF and TYPEDEF will be marked as RESOLVED. Eventually ARRAY size will be resolved correctly, but TYPEDEF resolved_size won't be updated anymore. This, subsequently, will lead to erroneous map creation failure, if that TYPEDEF is specified as either key or value, as key_size/value_size won't correspond to resolved size of TYPEDEF (kernel will believe it's zero). Note, that if BTF was ordered as [1] ARRAY <- [2] TYPEDEF <- [3] PTR, this won't be a problem, as by the time we get to TYPEDEF, ARRAY's size is already calculated and stored. This bug manifests itself in rejecting BTF-defined maps that use array typedef as a value type: typedef int array_t[16]; struct { __uint(type, BPF_MAP_TYPE_ARRAY); __type(value, array_t); /* i.e., array_t *value; */ } test_map SEC(".maps"); The fix consists on not relying on modifier's resolved_size and instead using modifier's resolved_id (type ID for "concrete" type to which modifier eventually resolves) and doing size determination for that resolved type. This allow to preserve existing "early DFS termination" logic for PTR or STRUCT_OR_ARRAY contexts, but still do correct size determination for modifier types. Fixes: eb3f595dab40 ("bpf: btf: Validate type reference") Cc: Martin KaFai Lau Signed-off-by: Andrii Nakryiko Acked-by: Martin KaFai Lau Signed-off-by: Daniel Borkmann Signed-off-by: Sasha Levin commit 273192b35c2b34e8765be199bee3e21cbcc6286c Author: Liran Alon Date: Mon Jul 15 18:47:44 2019 +0300 KVM: nVMX: Ignore segment base for VMX memory operand when segment not FS or GS [ Upstream commit 6694e48012826351036fd10fc506ca880023e25f ] As reported by Maxime at https://bugzilla.kernel.org/show_bug.cgi?id=204175: In vmx/nested.c::get_vmx_mem_address(), when the guest runs in long mode, the base address of the memory operand is computed with a simple: *ret = s.base + off; This is incorrect, the base applies only to FS and GS, not to the others. Because of that, if the guest uses a VMX instruction based on DS and has a DS.base that is non-zero, KVM wrongfully adds the base to the resulting address. Reported-by: Maxime Villard Reviewed-by: Joao Martins Signed-off-by: Liran Alon Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 673e7696a9c093ebd33743dbca7f0bf06a231bdb Author: Arnd Bergmann Date: Fri Jul 12 11:01:21 2019 +0200 ACPI: fix false-positive -Wuninitialized warning [ Upstream commit dfd6f9ad36368b8dbd5f5a2b2f0a4705ae69a323 ] clang gets confused by an uninitialized variable in what looks to it like a never executed code path: arch/x86/kernel/acpi/boot.c:618:13: error: variable 'polarity' is uninitialized when used here [-Werror,-Wuninitialized] polarity = polarity ? ACPI_ACTIVE_LOW : ACPI_ACTIVE_HIGH; ^~~~~~~~ arch/x86/kernel/acpi/boot.c:606:32: note: initialize the variable 'polarity' to silence this warning int rc, irq, trigger, polarity; ^ = 0 arch/x86/kernel/acpi/boot.c:617:12: error: variable 'trigger' is uninitialized when used here [-Werror,-Wuninitialized] trigger = trigger ? ACPI_LEVEL_SENSITIVE : ACPI_EDGE_SENSITIVE; ^~~~~~~ arch/x86/kernel/acpi/boot.c:606:22: note: initialize the variable 'trigger' to silence this warning int rc, irq, trigger, polarity; ^ = 0 This is unfortunately a design decision in clang and won't be fixed. Changing the acpi_get_override_irq() macro to an inline function reliably avoids the issue. Signed-off-by: Arnd Bergmann Reviewed-by: Andy Shevchenko Reviewed-by: Nathan Chancellor Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 4d133cd28f4a0ce90e093f9f97b16fe8fc0962be Author: Arnd Bergmann Date: Fri Jul 12 11:12:30 2019 +0200 x86: kvm: avoid constant-conversion warning [ Upstream commit a6a6d3b1f867d34ba5bd61aa7bb056b48ca67cff ] clang finds a contruct suspicious that converts an unsigned character to a signed integer and back, causing an overflow: arch/x86/kvm/mmu.c:4605:39: error: implicit conversion from 'int' to 'u8' (aka 'unsigned char') changes value from -205 to 51 [-Werror,-Wconstant-conversion] u8 wf = (pfec & PFERR_WRITE_MASK) ? ~w : 0; ~~ ^~ arch/x86/kvm/mmu.c:4607:38: error: implicit conversion from 'int' to 'u8' (aka 'unsigned char') changes value from -241 to 15 [-Werror,-Wconstant-conversion] u8 uf = (pfec & PFERR_USER_MASK) ? ~u : 0; ~~ ^~ arch/x86/kvm/mmu.c:4609:39: error: implicit conversion from 'int' to 'u8' (aka 'unsigned char') changes value from -171 to 85 [-Werror,-Wconstant-conversion] u8 ff = (pfec & PFERR_FETCH_MASK) ? ~x : 0; ~~ ^~ Add an explicit cast to tell clang that everything works as intended here. Signed-off-by: Arnd Bergmann Link: https://github.com/ClangBuiltLinux/linux/issues/95 Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit d9b49dcbef6386a5ac992821e4a51f2825675a80 Author: Ravi Bangoria Date: Tue Jun 11 08:31:09 2019 +0530 perf version: Fix segfault due to missing OPT_END() [ Upstream commit 916c31fff946fae0e05862f9b2435fdb29fd5090 ] 'perf version' on powerpc segfaults when used with non-supported option: # perf version -a Segmentation fault (core dumped) Fix this. Signed-off-by: Ravi Bangoria Reviewed-by: Kamalesh Babulal Tested-by: Mamatha Inamdar Cc: Jiri Olsa Cc: Kamalesh Babulal Link: http://lkml.kernel.org/r/20190611030109.20228-1-ravi.bangoria@linux.ibm.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit a288e51c6864f5e8a630d2d14ca29c4fb31b07bb Author: Ronnie Sahlberg Date: Thu Jul 11 13:46:58 2019 +1000 cifs: fix crash in cifs_dfs_do_automount [ Upstream commit ce465bf94b70f03136171a62b607864f00093b19 ] RHBZ: 1649907 Fix a crash that happens while attempting to mount a DFS referral from the same server on the root of a filesystem. Signed-off-by: Ronnie Sahlberg Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 3a4d7f5e2bdf1050a365a1e1814af3a46d5015a8 Author: Nicholas Kazlauskas Date: Fri Jun 28 13:39:41 2019 -0400 drm/amd/display: Expose audio inst from DC to DM [ Upstream commit 5fdb7c4c7f2691efd760b0b0dc00da4a3699f1a6 ] [Why] In order to give pin notifications to the sound driver from DM we need to know whether audio is enabled on a stream and what pin it's using from DC. [How] Expose the instance via stream status if it's a mapped resource for the stream. It will be -1 if there's no audio mapped. Cc: Leo Li Cc: Harry Wentland Signed-off-by: Nicholas Kazlauskas Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit d8ed48f2378018bdef53cef1cb254b44cf8f2a26 Author: Ilya Leoshkevich Date: Thu Jul 11 11:12:49 2019 +0200 selftests/bpf: do not ignore clang failures [ Upstream commit 9cae4ace80ef39005da106fbb89c952b27d7b89e ] When compiling an eBPF prog fails, make still returns 0, because failing clang command's output is piped to llc and therefore its exit status is ignored. When clang fails, pipe the string "clang failed" to llc. This will make llc fail with an informative error message. This solution was chosen over using pipefail, having separate targets or getting rid of llc invocation due to its simplicity. In addition, pull Kbuild.include in order to get .DELETE_ON_ERROR target, which would cause partial .o files to be removed. Signed-off-by: Ilya Leoshkevich Acked-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Signed-off-by: Sasha Levin commit 0a3df1d1800c88cb8c042a51ea67b0b4e76b880c Author: Benjamin Block Date: Tue Jul 2 23:02:02 2019 +0200 scsi: zfcp: fix GCC compiler warning emitted with -Wmaybe-uninitialized [ Upstream commit 484647088826f2f651acbda6bcf9536b8a466703 ] GCC v9 emits this warning: CC drivers/s390/scsi/zfcp_erp.o drivers/s390/scsi/zfcp_erp.c: In function 'zfcp_erp_action_enqueue': drivers/s390/scsi/zfcp_erp.c:217:26: warning: 'erp_action' may be used uninitialized in this function [-Wmaybe-uninitialized] 217 | struct zfcp_erp_action *erp_action; | ^~~~~~~~~~ This is a possible false positive case, as also documented in the GCC documentations: https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wmaybe-uninitialized The actual code-sequence is like this: Various callers can invoke the function below with the argument "want" being one of: ZFCP_ERP_ACTION_REOPEN_ADAPTER, ZFCP_ERP_ACTION_REOPEN_PORT_FORCED, ZFCP_ERP_ACTION_REOPEN_PORT, or ZFCP_ERP_ACTION_REOPEN_LUN. zfcp_erp_action_enqueue(want, ...) ... need = zfcp_erp_required_act(want, ...) need = want ... maybe: need = ZFCP_ERP_ACTION_REOPEN_PORT maybe: need = ZFCP_ERP_ACTION_REOPEN_ADAPTER ... return need ... zfcp_erp_setup_act(need, ...) struct zfcp_erp_action *erp_action; // <== line 217 ... switch(need) { case ZFCP_ERP_ACTION_REOPEN_LUN: ... erp_action = &zfcp_sdev->erp_action; WARN_ON_ONCE(erp_action->port != port); // <== access ... break; case ZFCP_ERP_ACTION_REOPEN_PORT: case ZFCP_ERP_ACTION_REOPEN_PORT_FORCED: ... erp_action = &port->erp_action; WARN_ON_ONCE(erp_action->port != port); // <== access ... break; case ZFCP_ERP_ACTION_REOPEN_ADAPTER: ... erp_action = &adapter->erp_action; WARN_ON_ONCE(erp_action->port != NULL); // <== access ... break; } ... WARN_ON_ONCE(erp_action->adapter != adapter); // <== access When zfcp_erp_setup_act() is called, 'need' will never be anything else than one of the 4 possible enumeration-names that are used in the switch-case, and 'erp_action' is initialized for every one of them, before it is used. Thus the warning is a false positive, as documented. We introduce the extra if{} in the beginning to create an extra code-flow, so the compiler can be convinced that the switch-case will never see any other value. BUG_ON()/BUG() is intentionally not used to not crash anything, should this ever happen anyway - right now it's impossible, as argued above; and it doesn't introduce a 'default:' switch-case to retain warnings should 'enum zfcp_erp_act_type' ever be extended and no explicit case be introduced. See also v5.0 commit 399b6c8bc9f7 ("scsi: zfcp: drop old default switch case which might paper over missing case"). Signed-off-by: Benjamin Block Reviewed-by: Jens Remus Reviewed-by: Steffen Maier Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 71703ba873ee8e9722a8d800b292bc7594d7dc30 Author: Arnd Bergmann Date: Wed Jul 10 15:05:43 2019 +0200 ACPI: blacklist: fix clang warning for unused DMI table [ Upstream commit b80d6a42bdc97bdb6139107d6034222e9843c6e2 ] When CONFIG_DMI is disabled, we only have a tentative declaration, which causes a warning from clang: drivers/acpi/blacklist.c:20:35: error: tentative array definition assumed to have one element [-Werror] static const struct dmi_system_id acpi_rev_dmi_table[] __initconst; As the variable is not actually used here, hide it entirely in an #ifdef to shut up the warning. Signed-off-by: Arnd Bergmann Reviewed-by: Nathan Chancellor Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 4e4bc0aa7d85d5ca01c86687f8f6f8c43b98b08e Author: Ihor Matushchak Date: Tue Jul 2 17:48:18 2019 +0300 virtio-mmio: add error check for platform_get_irq [ Upstream commit 5e663f0410fa2f355042209154029842ba1abd43 ] in vm_find_vqs() irq has a wrong type so, in case of no IRQ resource defined, wrong parameter will be passed to request_irq() Signed-off-by: Ihor Matushchak Signed-off-by: Michael S. Tsirkin Reviewed-by: Ivan T. Ivanov Signed-off-by: Sasha Levin commit 35c1f07ca23370ef65d5c29ed9a02f07e65fbf1b Author: Jeff Layton Date: Thu Jun 13 15:17:00 2019 -0400 ceph: return -ERANGE if virtual xattr value didn't fit in buffer [ Upstream commit 3b421018f48c482bdc9650f894aa1747cf90e51d ] The getxattr manpage states that we should return ERANGE if the destination buffer size is too small to hold the value. ceph_vxattrcb_layout does this internally, but we should be doing this for all vxattrs. Fix the only caller of getxattr_cb to check the returned size against the buffer length and return -ERANGE if it doesn't fit. Drop the same check in ceph_vxattrcb_layout and just rely on the caller to handle it. Signed-off-by: Jeff Layton Reviewed-by: "Yan, Zheng" Acked-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 1e1fab8df2aa44ae3377e0b0112179b85cb900ce Author: Yan, Zheng Date: Wed May 22 17:26:27 2019 +0800 ceph: fix dir_lease_is_valid() [ Upstream commit feab6ac25dbfe3ab96299cb741925dc8d2da0caf ] It should call __ceph_dentry_dir_lease_touch() under dentry->d_lock. Besides, ceph_dentry(dentry) can be NULL when called by LOOKUP_RCU d_revalidate() Signed-off-by: "Yan, Zheng" Reviewed-by: Jeff Layton Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit f7d3cd5a75a5f807e4ea80cff28ce1ff4832021e Author: Andrea Parri Date: Mon May 20 19:23:58 2019 +0200 ceph: fix improper use of smp_mb__before_atomic() [ Upstream commit 749607731e26dfb2558118038c40e9c0c80d23b5 ] This barrier only applies to the read-modify-write operations; in particular, it does not apply to the atomic64_set() primitive. Replace the barrier with an smp_mb(). Fixes: fdd4e15838e59 ("ceph: rework dcache readdir") Reported-by: "Paul E. McKenney" Reported-by: Peter Zijlstra Signed-off-by: Andrea Parri Reviewed-by: "Yan, Zheng" Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit d5fc61f4f7f1c6a8346f70e9b9c688547766b1b8 Author: Ronnie Sahlberg Date: Sat Jul 6 06:52:46 2019 +1000 cifs: Fix a race condition with cifs_echo_request [ Upstream commit f2caf901c1b7ce65f9e6aef4217e3241039db768 ] There is a race condition with how we send (or supress and don't send) smb echos that will cause the client to incorrectly think the server is unresponsive and thus needs to be reconnected. Summary of the race condition: 1) Daisy chaining scheduling creates a gap. 2) If traffic comes unfortunate shortly after the last echo, the planned echo is suppressed. 3) Due to the gap, the next echo transmission is delayed until after the timeout, which is set hard to twice the echo interval. This is fixed by changing the timeouts from 2 to three times the echo interval. Detailed description of the bug: https://lutz.donnerhacke.de/eng/Blog/Groundhog-Day-with-SMB-remount Signed-off-by: Ronnie Sahlberg Reviewed-by: Pavel Shilovsky Signed-off-by: Steve French Signed-off-by: Sasha Levin commit d7762d0604a33eb1307301532919c10b7db7dc65 Author: Qu Wenruo Date: Thu Jun 13 17:31:24 2019 +0800 btrfs: qgroup: Don't hold qgroup_ioctl_lock in btrfs_qgroup_inherit() [ Upstream commit e88439debd0a7f969b3ddba6f147152cd0732676 ] [BUG] Lockdep will report the following circular locking dependency: WARNING: possible circular locking dependency detected 5.2.0-rc2-custom #24 Tainted: G O ------------------------------------------------------ btrfs/8631 is trying to acquire lock: 000000002536438c (&fs_info->qgroup_ioctl_lock#2){+.+.}, at: btrfs_qgroup_inherit+0x40/0x620 [btrfs] but task is already holding lock: 000000003d52cc23 (&fs_info->tree_log_mutex){+.+.}, at: create_pending_snapshot+0x8b6/0xe60 [btrfs] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&fs_info->tree_log_mutex){+.+.}: __mutex_lock+0x76/0x940 mutex_lock_nested+0x1b/0x20 btrfs_commit_transaction+0x475/0xa00 [btrfs] btrfs_commit_super+0x71/0x80 [btrfs] close_ctree+0x2bd/0x320 [btrfs] btrfs_put_super+0x15/0x20 [btrfs] generic_shutdown_super+0x72/0x110 kill_anon_super+0x18/0x30 btrfs_kill_super+0x16/0xa0 [btrfs] deactivate_locked_super+0x3a/0x80 deactivate_super+0x51/0x60 cleanup_mnt+0x3f/0x80 __cleanup_mnt+0x12/0x20 task_work_run+0x94/0xb0 exit_to_usermode_loop+0xd8/0xe0 do_syscall_64+0x210/0x240 entry_SYSCALL_64_after_hwframe+0x49/0xbe -> #1 (&fs_info->reloc_mutex){+.+.}: __mutex_lock+0x76/0x940 mutex_lock_nested+0x1b/0x20 btrfs_commit_transaction+0x40d/0xa00 [btrfs] btrfs_quota_enable+0x2da/0x730 [btrfs] btrfs_ioctl+0x2691/0x2b40 [btrfs] do_vfs_ioctl+0xa9/0x6d0 ksys_ioctl+0x67/0x90 __x64_sys_ioctl+0x1a/0x20 do_syscall_64+0x65/0x240 entry_SYSCALL_64_after_hwframe+0x49/0xbe -> #0 (&fs_info->qgroup_ioctl_lock#2){+.+.}: lock_acquire+0xa7/0x190 __mutex_lock+0x76/0x940 mutex_lock_nested+0x1b/0x20 btrfs_qgroup_inherit+0x40/0x620 [btrfs] create_pending_snapshot+0x9d7/0xe60 [btrfs] create_pending_snapshots+0x94/0xb0 [btrfs] btrfs_commit_transaction+0x415/0xa00 [btrfs] btrfs_mksubvol+0x496/0x4e0 [btrfs] btrfs_ioctl_snap_create_transid+0x174/0x180 [btrfs] btrfs_ioctl_snap_create_v2+0x11c/0x180 [btrfs] btrfs_ioctl+0xa90/0x2b40 [btrfs] do_vfs_ioctl+0xa9/0x6d0 ksys_ioctl+0x67/0x90 __x64_sys_ioctl+0x1a/0x20 do_syscall_64+0x65/0x240 entry_SYSCALL_64_after_hwframe+0x49/0xbe other info that might help us debug this: Chain exists of: &fs_info->qgroup_ioctl_lock#2 --> &fs_info->reloc_mutex --> &fs_info->tree_log_mutex Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&fs_info->tree_log_mutex); lock(&fs_info->reloc_mutex); lock(&fs_info->tree_log_mutex); lock(&fs_info->qgroup_ioctl_lock#2); *** DEADLOCK *** 6 locks held by btrfs/8631: #0: 00000000ed8f23f6 (sb_writers#12){.+.+}, at: mnt_want_write_file+0x28/0x60 #1: 000000009fb1597a (&type->i_mutex_dir_key#10/1){+.+.}, at: btrfs_mksubvol+0x70/0x4e0 [btrfs] #2: 0000000088c5ad88 (&fs_info->subvol_sem){++++}, at: btrfs_mksubvol+0x128/0x4e0 [btrfs] #3: 000000009606fc3e (sb_internal#2){.+.+}, at: start_transaction+0x37a/0x520 [btrfs] #4: 00000000f82bbdf5 (&fs_info->reloc_mutex){+.+.}, at: btrfs_commit_transaction+0x40d/0xa00 [btrfs] #5: 000000003d52cc23 (&fs_info->tree_log_mutex){+.+.}, at: create_pending_snapshot+0x8b6/0xe60 [btrfs] [CAUSE] Due to the delayed subvolume creation, we need to call btrfs_qgroup_inherit() inside commit transaction code, with a lot of other mutex hold. This hell of lock chain can lead to above problem. [FIX] On the other hand, we don't really need to hold qgroup_ioctl_lock if we're in the context of create_pending_snapshot(). As in that context, we're the only one being able to modify qgroup. All other qgroup functions which needs qgroup_ioctl_lock are either holding a transaction handle, or will start a new transaction: Functions will start a new transaction(): * btrfs_quota_enable() * btrfs_quota_disable() Functions hold a transaction handler: * btrfs_add_qgroup_relation() * btrfs_del_qgroup_relation() * btrfs_create_qgroup() * btrfs_remove_qgroup() * btrfs_limit_qgroup() * btrfs_qgroup_inherit() call inside create_subvol() So we have a higher level protection provided by transaction, thus we don't need to always hold qgroup_ioctl_lock in btrfs_qgroup_inherit(). Only the btrfs_qgroup_inherit() call in create_subvol() needs to hold qgroup_ioctl_lock, while the btrfs_qgroup_inherit() call in create_pending_snapshot() is already protected by transaction. So the fix is to detect the context by checking trans->transaction->state. If we're at TRANS_STATE_COMMIT_DOING, then we're in commit transaction context and no need to get the mutex. Reported-by: Nikolay Borisov Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 85a0cc34a11668e4bff3132582e794da132d4aa0 Author: Clement Leger Date: Mon Jul 1 09:02:45 2019 +0200 remoteproc: copy parent dma_pfn_offset for vdev [ Upstream commit 72f64cabc4bd6985c7355f5547bd3637c82762ac ] When preparing the subdevice for the vdev, also copy dma_pfn_offset since this is used for sub device dma allocations. Without that, there is incoherency between the parent dma settings and the childs one, potentially leading to dma_alloc_coherent failure (due to phys_to_dma using dma_pfn_offset for translation). Fixes: 086d08725d34 ("remoteproc: create vdev subdevice with specific dma memory pool") Signed-off-by: Clement Leger Acked-by: Loic Pallardy Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit a47284d50315e6b76b771e6da1527fa63505afba Author: Qu Wenruo Date: Wed May 8 18:49:58 2019 +0800 btrfs: Flush before reflinking any extent to prevent NOCOW write falling back to COW without data reservation [ Upstream commit a94d1d0cb3bf1983fcdf05b59d914dbff4f1f52c ] [BUG] The following script can cause unexpected fsync failure: #!/bin/bash dev=/dev/test/test mnt=/mnt/btrfs mkfs.btrfs -f $dev -b 512M > /dev/null mount $dev $mnt -o nospace_cache # Prealloc one extent xfs_io -f -c "falloc 8k 64m" $mnt/file1 # Fill the remaining data space xfs_io -f -c "pwrite 0 -b 4k 512M" $mnt/padding sync # Write into the prealloc extent xfs_io -c "pwrite 1m 16m" $mnt/file1 # Reflink then fsync, fsync would fail due to ENOSPC xfs_io -c "reflink $mnt/file1 8k 0 4k" -c "fsync" $mnt/file1 umount $dev The fsync fails with ENOSPC, and the last page of the buffered write is lost. [CAUSE] This is caused by: - Btrfs' back reference only has extent level granularity So write into shared extent must be COWed even only part of the extent is shared. So for above script we have: - fallocate Create a preallocated extent where we can do NOCOW write. - fill all the remaining data and unallocated space - buffered write into preallocated space As we have not enough space available for data and the extent is not shared (yet) we fall into NOCOW mode. - reflink Now part of the large preallocated extent is shared, later write into that extent must be COWed. - fsync triggers writeback But now the extent is shared and therefore we must fallback into COW mode, which fails with ENOSPC since there's not enough space to allocate data extents. [WORKAROUND] The workaround is to ensure any buffered write in the related extents (not just the reflink source range) get flushed before reflink/dedupe, so that NOCOW writes succeed that happened before reflinking succeed. The workaround is expensive, we could do it better by only flushing NOCOW range, but that needs extra accounting for NOCOW range. For now, fix the possible data loss first. Reviewed-by: Filipe Manana Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit f0fad72327f5bd1bc033292e3c5866d89c632b12 Author: David Sterba Date: Fri May 17 11:43:13 2019 +0200 btrfs: fix minimum number of chunk errors for DUP [ Upstream commit 0ee5f8ae082e1f675a2fb6db601c31ac9958a134 ] The list of profiles in btrfs_chunk_max_errors lists DUP as a profile DUP able to tolerate 1 device missing. Though this profile is special with 2 copies, it still needs the device, unlike the others. Looking at the history of changes, thre's no clear reason why DUP is there, functions were refactored and blocks of code merged to one helper. d20983b40e828 Btrfs: fix writing data into the seed filesystem - factor code to a helper de11cc12df173 Btrfs: don't pre-allocate btrfs bio - unrelated change, DUP still in the list with max errors 1 a236aed14ccb0 Btrfs: Deal with failed writes in mirrored configurations - introduced the max errors, leaves DUP and RAID1 in the same group Reviewed-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 5843b137a28e2c6b6a95df0101ce333b654e0929 Author: Qu Wenruo Date: Fri May 3 08:30:54 2019 +0800 btrfs: tree-checker: Check if the file extent end overflows [ Upstream commit 4c094c33c9ed4b8d0d814bd1d7ff78e123d15d00 ] Under certain conditions, we could have strange file extent item in log tree like: item 18 key (69599 108 397312) itemoff 15208 itemsize 53 extent data disk bytenr 0 nr 0 extent data offset 0 nr 18446744073709547520 ram 18446744073709547520 The num_bytes + ram_bytes overflow 64 bit type. For num_bytes part, we can detect such overflow along with file offset (key->offset), as file_offset + num_bytes should never go beyond u64. For ram_bytes part, it's about the decompressed size of the extent, not directly related to the size. In theory it is OK to have a large value, and put extra limitation on RAM bytes may cause unexpected false alerts. So in tree-checker, we only check if the file offset and num bytes overflow. Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 9d3d7e8fc3652bb5399d4b0da506578d469ce30e Author: Vicente Bergas Date: Thu Jun 27 15:12:28 2019 +0200 arm64: dts: rockchip: Fix USB3 Type-C on rk3399-sapphire [ Upstream commit e1d9149e8389f1690cdd4e4056766dd26488a0fe ] Before this patch, the Type-C port on the Sapphire board is dead. If setting the 'regulator-always-on' property to 'vcc5v0_typec0' then the port works for about 4 seconds at start-up. This is a sample trace with a memory stick plugged in: 1.- The memory stick LED lights on and kernel reports: [ 4.782999] scsi 0:0:0:0: Direct-Access USB DISK PMAP PQ: 0 ANSI: 4 [ 5.904580] sd 0:0:0:0: [sdb] 3913344 512-byte logical blocks: (2.00 GB/1.87 GiB) [ 5.906860] sd 0:0:0:0: [sdb] Write Protect is off [ 5.908973] sd 0:0:0:0: [sdb] Mode Sense: 23 00 00 00 [ 5.909122] sd 0:0:0:0: [sdb] No Caching mode page found [ 5.911214] sd 0:0:0:0: [sdb] Assuming drive cache: write through [ 5.951585] sdb: sdb1 [ 5.954816] sd 0:0:0:0: [sdb] Attached SCSI removable disk 2.- 4 seconds later the memory stick LED lights off and kernel reports: [ 9.082822] phy phy-ff770000.syscon:usb2-phy@e450.2: charger = USB_DCP_CHARGER 3.- After a minute the kernel reports: [ 71.666761] usb 5-1: USB disconnect, device number 2 It has been checked that, although the LED is off, VBUS is present. If, instead, the dr_mode is changed to host and the phy-supply changed accordingly, then it works. It has only been tested in host mode. Signed-off-by: Vicente Bergas Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit ed819dab668919fac7129ff18c1772801f6899fc Author: Chunyan Zhang Date: Wed May 22 09:15:03 2019 +0800 clk: sprd: Add check for return value of sprd_clk_regmap_init() [ Upstream commit c974c48deeb969c5e4250e4f06af91edd84b1f10 ] sprd_clk_regmap_init() doesn't always return success, adding check for its return value should make the code more strong. Signed-off-by: Chunyan Zhang Reviewed-by: Baolin Wang [sboyd@kernel.org: Add a missing int ret] Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 48f8287631099323e7f95cf98b113a7cd967170f Author: Russell King Date: Tue Jun 4 14:50:14 2019 +0100 fs/adfs: super: fix use-after-free bug [ Upstream commit 5808b14a1f52554de612fee85ef517199855e310 ] Fix a use-after-free bug during filesystem initialisation, where we access the disc record (which is stored in a buffer) after we have released the buffer. Signed-off-by: Russell King Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit dc8421eca19868d0a954163e9089669696bf4af5 Author: JC Kuo Date: Wed Jun 12 11:14:34 2019 +0800 clk: tegra210: fix PLLU and PLLU_OUT1 [ Upstream commit 0d34dfbf3023cf119b83f6470692c0b10c832495 ] Full-speed and low-speed USB devices do not work with Tegra210 platforms because of incorrect PLLU/PLLU_OUT1 clock settings. When full-speed device is connected: [ 14.059886] usb 1-3: new full-speed USB device number 2 using tegra-xusb [ 14.196295] usb 1-3: device descriptor read/64, error -71 [ 14.436311] usb 1-3: device descriptor read/64, error -71 [ 14.675749] usb 1-3: new full-speed USB device number 3 using tegra-xusb [ 14.812335] usb 1-3: device descriptor read/64, error -71 [ 15.052316] usb 1-3: device descriptor read/64, error -71 [ 15.164799] usb usb1-port3: attempt power cycle When low-speed device is connected: [ 37.610949] usb usb1-port3: Cannot enable. Maybe the USB cable is bad? [ 38.557376] usb usb1-port3: Cannot enable. Maybe the USB cable is bad? [ 38.564977] usb usb1-port3: attempt power cycle This commit fixes the issue by: 1. initializing PLLU_OUT1 before initializing XUSB_FS_SRC clock because PLLU_OUT1 is parent of XUSB_FS_SRC. 2. changing PLLU post-divider to /2 (DIVP=1) according to Technical Reference Manual. Fixes: e745f992cf4b ("clk: tegra: Rework pll_u") Signed-off-by: JC Kuo Acked-By: Peter De Schrijver Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 2537142f5cc8637efc160ffbb0eba15c80bffa31 Author: Arnd Bergmann Date: Wed Jun 19 14:55:29 2019 +0200 ARM: exynos: Only build MCPM support if used [ Upstream commit 24d2c73ff28bcda48607eacc4bc804002dbf78d9 ] We get a link error for configurations that enable an Exynos SoC that does not require MCPM, but then manually enable MCPM anyway without also turning on the arm-cci: arch/arm/mach-exynos/mcpm-exynos.o: In function `exynos_pm_power_up_setup': mcpm-exynos.c:(.text+0x8): undefined reference to `cci_enable_port_for_self' Change it back to only build the code we actually need, by introducing a CONFIG_EXYNOS_MCPM that serves the same purpose as the older CONFIG_EXYNOS5420_MCPM. Fixes: 2997520c2d4e ("ARM: exynos: Set MCPM as mandatory for Exynos542x/5800 SoCs") Signed-off-by: Arnd Bergmann Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit 10e7c4fe278164954e6f4ff528e9df9377c68ab3 Author: Geert Uytterhoeven Date: Mon Jun 24 14:38:18 2019 +0200 dmaengine: rcar-dmac: Reject zero-length slave DMA requests [ Upstream commit 78efb76ab4dfb8f74f290ae743f34162cd627f19 ] While the .device_prep_slave_sg() callback rejects empty scatterlists, it still accepts single-entry scatterlists with a zero-length segment. These may happen if a driver calls dmaengine_prep_slave_single() with a zero len parameter. The corresponding DMA request will never complete, leading to messages like: rcar-dmac e7300000.dma-controller: Channel Address Error happen and DMA timeouts. Although requesting a zero-length DMA request is a driver bug, rejecting it early eases debugging. Note that the .device_prep_dma_memcpy() callback already rejects requests to copy zero bytes. Reported-by: Eugeniu Rosca Analyzed-by: Yoshihiro Shimoda Signed-off-by: Geert Uytterhoeven Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 5b14588f001d9cb47ea5a816f00b2efe6f8c1d7e Author: Petr Cvek Date: Thu Jun 20 23:39:37 2019 +0200 MIPS: lantiq: Fix bitfield masking [ Upstream commit ba1bc0fcdeaf3bf583c1517bd2e3e29cf223c969 ] The modification of EXIN register doesn't clean the bitfield before the writing of a new value. After a few modifications the bitfield would accumulate only '1's. Signed-off-by: Petr Cvek Signed-off-by: Paul Burton Cc: hauke@hauke-m.de Cc: john@phrozen.org Cc: linux-mips@vger.kernel.org Cc: openwrt-devel@lists.openwrt.org Cc: pakahmar@hotmail.com Signed-off-by: Sasha Levin commit aaf15ffc6b678c6f9477f672eca7af3165195428 Author: Arnd Bergmann Date: Mon Jun 17 15:28:43 2019 +0200 swiotlb: fix phys_addr_t overflow warning [ Upstream commit 9c106119f6538f65bdddb7948a157d90625effa7 ] On architectures that have a larger dma_addr_t than phys_addr_t, the swiotlb_tbl_map_single() function truncates its return code in the failure path, making it impossible to identify the error later, as we compare to the original value: kernel/dma/swiotlb.c:551:9: error: implicit conversion from 'dma_addr_t' (aka 'unsigned long long') to 'phys_addr_t' (aka 'unsigned int') changes value from 18446744073709551615 to 4294967295 [-Werror,-Wconstant-conversion] return DMA_MAPPING_ERROR; Use an explicit typecast here to convert it to the narrower type, and use the same expression in the error handling later. Fixes: b907e20508d0 ("swiotlb: remove SWIOTLB_MAP_ERROR") Acked-by: Stefano Stabellini Signed-off-by: Arnd Bergmann Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Sasha Levin commit ad6c055cc8099719013331476de70e2bf31f293b Author: Andy Gross Date: Sat Jun 8 23:19:32 2019 -0500 arm64: qcom: qcs404: Add reset-cells to GCC node [ Upstream commit 0763d0c2273a3c72247d325c48fbac3d918d6b87 ] This patch adds a reset-cells property to the gcc controller on the QCS404. Without this in place, we get warnings like the following if nodes reference a gcc reset: arch/arm64/boot/dts/qcom/qcs404.dtsi:261.38-310.5: Warning (resets_property): /soc@0/remoteproc@b00000: Missing property '#reset-cells' in node /soc@0/clock-controller@1800000 or bad phandle (referred from resets[0]) also defined at arch/arm64/boot/dts/qcom/qcs404-evb.dtsi:82.18-84.3 DTC arch/arm64/boot/dts/qcom/qcs404-evb-4000.dtb arch/arm64/boot/dts/qcom/qcs404.dtsi:261.38-310.5: Warning (resets_property): /soc@0/remoteproc@b00000: Missing property '#reset-cells' in node /soc@0/clock-controller@1800000 or bad phandle (referred from resets[0]) also defined at arch/arm64/boot/dts/qcom/qcs404-evb.dtsi:82.18-84.3 Signed-off-by: Andy Gross Reviewed-by: Niklas Cassel Reviewed-by: Vinod Koul Signed-off-by: Olof Johansson Signed-off-by: Sasha Levin commit 98e40b4b528acc0451322be749106c4257d8b0c3 Author: Anson Huang Date: Fri Jun 14 16:07:47 2019 +0800 soc: imx8: Fix potential kernel dump in error path [ Upstream commit 1bcbe7300815e91fef18ee905b04f65490ad38c9 ] When SoC's revision value is 0, SoC driver will print out "unknown" in sysfs's revision node, this "unknown" is a static string which can NOT be freed, this will caused below kernel dump in later error path which calls kfree: kernel BUG at mm/slub.c:3942! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP Modules linked in: CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.2.0-rc4-next-20190611-00023-g705146c-dirty #2197 Hardware name: NXP i.MX8MQ EVK (DT) pstate: 60000005 (nZCv daif -PAN -UAO) pc : kfree+0x170/0x1b0 lr : imx8_soc_init+0xc0/0xe4 sp : ffff00001003bd10 x29: ffff00001003bd10 x28: ffff00001121e0a0 x27: ffff000011482000 x26: ffff00001117068c x25: ffff00001121e100 x24: ffff000011482000 x23: ffff000010fe2b58 x22: ffff0000111b9ab0 x21: ffff8000bd9dfba0 x20: ffff0000111b9b70 x19: ffff7e000043f880 x18: 0000000000001000 x17: ffff000010d05fa0 x16: ffff0000122e0000 x15: 0140000000000000 x14: 0000000030360000 x13: ffff8000b94b5bb0 x12: 0000000000000038 x11: ffffffffffffffff x10: ffffffffffffffff x9 : 0000000000000003 x8 : ffff8000b9488147 x7 : ffff00001003bc00 x6 : 0000000000000000 x5 : 0000000000000003 x4 : 0000000000000003 x3 : 0000000000000003 x2 : b8793acd604edf00 x1 : ffff7e000043f880 x0 : ffff7e000043f888 Call trace: kfree+0x170/0x1b0 imx8_soc_init+0xc0/0xe4 do_one_initcall+0x58/0x1b8 kernel_init_freeable+0x1cc/0x288 kernel_init+0x10/0x100 ret_from_fork+0x10/0x18 This patch fixes this potential kernel dump when a chip's revision is "unknown", it is done by checking whether the revision space can be freed. Fixes: a7e26f356ca1 ("soc: imx: Add generic i.MX8 SoC driver") Signed-off-by: Anson Huang Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit bd29d93d6b77194c0b0a3e5af4591d2b4f148ade Author: Jean-Philippe Brucker Date: Mon Jun 10 18:38:29 2019 +0100 firmware/psci: psci_checker: Park kthreads before stopping them [ Upstream commit 92e074acf6f7694e96204265eb18ac113f546e80 ] Since commit 85f1abe0019f ("kthread, sched/wait: Fix kthread_parkme() completion issue"), kthreads that are bound to a CPU must be parked before being stopped. At the moment the PSCI checker calls kthread_stop() directly on the suspend kthread, which triggers the following warning: [ 6.068288] WARNING: CPU: 1 PID: 1 at kernel/kthread.c:398 __kthread_bind_mask+0x20/0x78 ... [ 6.190151] Call trace: [ 6.192566] __kthread_bind_mask+0x20/0x78 [ 6.196615] kthread_unpark+0x74/0x80 [ 6.200235] kthread_stop+0x44/0x1d8 [ 6.203769] psci_checker+0x3bc/0x484 [ 6.207389] do_one_initcall+0x48/0x260 [ 6.211180] kernel_init_freeable+0x2c8/0x368 [ 6.215488] kernel_init+0x10/0x100 [ 6.218935] ret_from_fork+0x10/0x1c [ 6.222467] ---[ end trace e05e22863d043cd3 ]--- kthread_unpark() tries to bind the thread to its CPU and aborts with a WARN() if the thread wasn't in TASK_PARKED state. Park the kthreads before stopping them. Fixes: 85f1abe0019f ("kthread, sched/wait: Fix kthread_parkme() completion issue") Signed-off-by: Jean-Philippe Brucker Reviewed-by: Sudeep Holla Acked-by: Lorenzo Pieralisi Signed-off-by: Olof Johansson Signed-off-by: Sasha Levin commit f3cd7c074f32445a6990e1b55842a928c4c73ff5 Author: Jean-Philippe Brucker Date: Tue Jan 15 12:19:56 2019 +0000 PCI: OF: Initialize dev->fwnode appropriately [ Upstream commit 59b099a6c75e4ddceeaf9676422d8d91d0049755 ] For PCI devices that have an OF node, set the fwnode as well. This way drivers that rely on fwnode don't need the special case described by commit f94277af03ea ("of/platform: Initialise dev->fwnode appropriately"). Acked-by: Bjorn Helgaas Signed-off-by: Jean-Philippe Brucker Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit 768cb58039dbb27bfc2793394f358715017cfe09 Author: Prarit Bhargava Date: Wed May 29 07:26:25 2019 -0400 kernel/module.c: Only return -EEXIST for modules that have finished loading [ Upstream commit 6e6de3dee51a439f76eb73c22ae2ffd2c9384712 ] Microsoft HyperV disables the X86_FEATURE_SMCA bit on AMD systems, and linux guests boot with repeated errors: amd64_edac_mod: Unknown symbol amd_unregister_ecc_decoder (err -2) amd64_edac_mod: Unknown symbol amd_register_ecc_decoder (err -2) amd64_edac_mod: Unknown symbol amd_report_gart_errors (err -2) amd64_edac_mod: Unknown symbol amd_unregister_ecc_decoder (err -2) amd64_edac_mod: Unknown symbol amd_register_ecc_decoder (err -2) amd64_edac_mod: Unknown symbol amd_report_gart_errors (err -2) The warnings occur because the module code erroneously returns -EEXIST for modules that have failed to load and are in the process of being removed from the module list. module amd64_edac_mod has a dependency on module edac_mce_amd. Using modules.dep, systemd will load edac_mce_amd for every request of amd64_edac_mod. When the edac_mce_amd module loads, the module has state MODULE_STATE_UNFORMED and once the module load fails and the state becomes MODULE_STATE_GOING. Another request for edac_mce_amd module executes and add_unformed_module() will erroneously return -EEXIST even though the previous instance of edac_mce_amd has MODULE_STATE_GOING. Upon receiving -EEXIST, systemd attempts to load amd64_edac_mod, which fails because of unknown symbols from edac_mce_amd. add_unformed_module() must wait to return for any case other than MODULE_STATE_LIVE to prevent a race between multiple loads of dependent modules. Signed-off-by: Prarit Bhargava Signed-off-by: Barret Rhoden Cc: David Arcari Cc: Jessica Yu Cc: Heiko Carstens Signed-off-by: Jessica Yu Signed-off-by: Sasha Levin commit 78431a1ce524921c9ef583c8ac540f2c7462ab5b Author: Helen Koike Date: Mon Jun 3 11:22:15 2019 -0300 arm64: dts: rockchip: fix isp iommu clocks and power domain [ Upstream commit c432a29d3fc9ee928caeca2f5cf68b3aebfa6817 ] isp iommu requires wrapper variants of the clocks. noc variants are always on and using the wrapper variants will activate {A,H}CLK_ISP{0,1} due to the hierarchy. Tested using the pending isp patch set (which is not upstream yet). Without this patch, streaming from the isp stalls. Also add the respective power domain and remove the "disabled" status. Refer: RK3399 TRM v1.4 Fig. 2-4 RK3399 Clock Architecture Diagram RK3399 TRM v1.4 Fig. 8-1 RK3399 Power Domain Partition Signed-off-by: Helen Koike Tested-by: Manivannan Sadhasivam Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 640628263904ef19f9f18019dd440f98fb7e812b Author: Dmitry Osipenko Date: Thu May 30 00:43:55 2019 +0300 dmaengine: tegra-apb: Error out if DMA_PREP_INTERRUPT flag is unset [ Upstream commit dc161064beb83c668e0f85766b92b1e7ed186e58 ] Apparently driver was never tested with DMA_PREP_INTERRUPT flag being unset since it completely disables interrupt handling instead of skipping the callbacks invocations, hence putting channel into unusable state. The flag is always set by all of kernel drivers that use APB DMA, so let's error out in otherwise case for consistency. It won't be difficult to support that case properly if ever will be needed. Signed-off-by: Dmitry Osipenko Acked-by: Jon Hunter Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit c92e475cc170cd781e210345deecaded737baba0 Author: Anson Huang Date: Fri May 24 13:51:01 2019 +0800 soc: imx: soc-imx8: Correct return value of error handle [ Upstream commit 4c396a604a57da8f883a8b3368d83181680d6907 ] Current implementation of i.MX8 SoC driver returns -ENODEV for all cases of error during initialization, this is incorrect. This patch fixes them using correct return value according to different errors. Signed-off-by: Anson Huang Reviewed-by: Leonard Crestez Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 5a90ad019dc4b57070f4c2f441fa798ecaae4837 Author: Heinrich Schuchardt Date: Fri May 17 18:11:23 2019 +0200 arm64: dts: marvell: mcbin: enlarge PCI memory window [ Upstream commit d3446b266a8c72a7bbc94b65f5fc6d206be77d24 ] Running a graphics adapter on the MACCHIATObin fails due to an insufficiently sized memory window. Enlarge the memory window for the PCIe slot to 512 MiB. With the patch I am able to use a GT710 graphics adapter with 1 GB onboard memory. These are the mapped memory areas that the graphics adapter is actually using: Region 0: Memory at cc000000 (32-bit, non-prefetchable) [size=16M] Region 1: Memory at c0000000 (64-bit, prefetchable) [size=128M] Region 3: Memory at c8000000 (64-bit, prefetchable) [size=32M] Region 5: I/O ports at 1000 [size=128] Expansion ROM at ca000000 [disabled] [size=512K] Signed-off-by: Heinrich Schuchardt Signed-off-by: Gregory CLEMENT Signed-off-by: Sasha Levin commit 24288fd098702423f43b6f2e48cdb094566102a0 Author: Sibi Sankar Date: Mon May 13 15:50:07 2019 +0530 soc: qcom: rpmpd: fixup rpmpd set performance state [ Upstream commit 8b3344422f097debe52296b87a39707d56ca3abe ] Remoteproc q6v5-mss calls set_performance_state with INT_MAX on rpmpd. This is currently ignored since it is greater than the max supported state. Fixup rpmpd state to max if the required state is greater than all the supported states. Fixes: 075d3db8d10d ("soc: qcom: rpmpd: Add support for get/set performance state") Reviewed-by: Marc Gonzalez Reviewed-by: Vinod Koul Reviewed-by: Jeffrey Hugo Signed-off-by: Sibi Sankar Signed-off-by: Bjorn Andersson Signed-off-by: Andy Gross Signed-off-by: Sasha Levin commit 41979b6c0baae98abc4ed601ee6c03fd8850b9c2 Author: Niklas Cassel Date: Thu Apr 25 14:34:01 2019 +0200 arm64: dts: qcom: qcs404-evb: fix l3 min voltage [ Upstream commit 887b528c958f40b064d53edd0bfa9fea3a69eccd ] The current l3 min voltage level is not supported by the regulator (the voltage is not a multiple of the regulator step size), so a driver requesting this exact voltage would fail, see discussion in: https://patchwork.kernel.org/comment/22461199/ It was agreed upon to set a min voltage level that is a multiple of the regulator step size. There was actually a patch sent that did this: https://patchwork.kernel.org/patch/10819313/ However, the commit 331ab98f8c4a ("arm64: dts: qcom: qcs404: Fix voltages l3") that was applied is not identical to that patch. Signed-off-by: Niklas Cassel Signed-off-by: Bjorn Andersson Signed-off-by: Andy Gross Signed-off-by: Sasha Levin commit 004e0c5d77e8ad6d5adcce358209ce061d7eb5ef Author: Cheng Jian Date: Sat May 4 19:39:39 2019 +0800 ftrace: Enable trampoline when rec count returns back to one [ Upstream commit a124692b698b00026a58d89831ceda2331b2e1d0 ] Custom trampolines can only be enabled if there is only a single ops attached to it. If there's only a single callback registered to a function, and the ops has a trampoline registered for it, then we can call the trampoline directly. This is very useful for improving the performance of ftrace and livepatch. If more than one callback is registered to a function, the general trampoline is used, and the custom trampoline is not restored back to the direct call even if all the other callbacks were unregistered and we are back to one callback for the function. To fix this, set FTRACE_FL_TRAMP flag if rec count is decremented to one, and the ops that left has a trampoline. Testing After this patch : insmod livepatch_unshare_files.ko cat /sys/kernel/debug/tracing/enabled_functions unshare_files (1) R I tramp: 0xffffffffc0000000(klp_ftrace_handler+0x0/0xa0) ->ftrace_ops_assist_func+0x0/0xf0 echo unshare_files > /sys/kernel/debug/tracing/set_ftrace_filter echo function > /sys/kernel/debug/tracing/current_tracer cat /sys/kernel/debug/tracing/enabled_functions unshare_files (2) R I ->ftrace_ops_list_func+0x0/0x150 echo nop > /sys/kernel/debug/tracing/current_tracer cat /sys/kernel/debug/tracing/enabled_functions unshare_files (1) R I tramp: 0xffffffffc0000000(klp_ftrace_handler+0x0/0xa0) ->ftrace_ops_assist_func+0x0/0xf0 Link: http://lkml.kernel.org/r/1556969979-111047-1-git-send-email-cj.chengjian@huawei.com Signed-off-by: Cheng Jian Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit 1ddffe0f40e74211cfda876d3964865ab9700b36 Author: Douglas Anderson Date: Tue May 21 16:49:33 2019 -0700 ARM: dts: rockchip: Mark that the rk3288 timer might stop in suspend [ Upstream commit 8ef1ba39a9fa53d2205e633bc9b21840a275908e ] This is similar to commit e6186820a745 ("arm64: dts: rockchip: Arch counter doesn't tick in system suspend"). Specifically on the rk3288 it can be seen that the timer stops ticking in suspend if we end up running through the "osc_disable" path in rk3288_slp_mode_set(). In that path the 24 MHz clock will turn off and the timer stops. To test this, I ran this on a Chrome OS filesystem: before=$(date); \ suspend_stress_test -c1 --suspend_min=30 --suspend_max=31; \ echo ${before}; date ...and I found that unless I plug in a device that requests USB wakeup to be active that the two calls to "date" would show that fewer than 30 seconds passed. NOTE: deep suspend (where the 24 MHz clock gets disabled) isn't supported yet on upstream Linux so this was tested on a downstream kernel. Signed-off-by: Douglas Anderson Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit b0155cc19200fc9c844dafb5f8dfa7cf3c3cc72c Author: Jerome Brunet Date: Mon May 13 14:31:09 2019 +0200 clk: meson: mpll: properly handle spread spectrum [ Upstream commit f9b3eeebef6aabaa37a351715374de53b6da860c ] The bit 'SSEN' available on some MPLL DSS outputs is not related to the fractional part of the divider but to the function called 'Spread Spectrum'. This function might be used to solve EM issues by adding a jitter on clock signal. This widens the signal spectrum and weakens the peaks in it. While spread spectrum might be useful for some application, it is problematic for others, such as audio. This patch introduce a new flag to the MPLL driver to enable (or not) the spread spectrum function. Fixes: 1f737ffa13ef ("clk: meson: mpll: fix mpll0 fractional part ignored") Tested-by: Martin Blumenstingl Signed-off-by: Jerome Brunet Signed-off-by: Sasha Levin commit 0ffa4026ae086053a865fd9365e6c4741fbd5990 Author: Douglas Anderson Date: Fri May 3 16:45:37 2019 -0700 ARM: dts: rockchip: Make rk3288-veyron-mickey's emmc work again [ Upstream commit 99fa066710f75f18f4d9a5bc5f6a711968a581d5 ] When I try to boot rk3288-veyron-mickey I totally fail to make the eMMC work. Specifically my logs (on Chrome OS 4.19): mmc_host mmc1: card is non-removable. mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0) mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req 52000000Hz, actual 50000000HZ div = 0) mmc1: switch to bus width 8 failed mmc1: switch to bus width 4 failed mmc1: new high speed MMC card at address 0001 mmcblk1: mmc1:0001 HAG2e 14.7 GiB mmcblk1boot0: mmc1:0001 HAG2e partition 1 4.00 MiB mmcblk1boot1: mmc1:0001 HAG2e partition 2 4.00 MiB mmcblk1rpmb: mmc1:0001 HAG2e partition 3 4.00 MiB, chardev (243:0) mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0) mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req 52000000Hz, actual 50000000HZ div = 0) mmc1: switch to bus width 8 failed mmc1: switch to bus width 4 failed mmc1: tried to HW reset card, got error -110 mmcblk1: error -110 requesting status mmcblk1: recovery failed! print_req_error: I/O error, dev mmcblk1, sector 0 ... When I remove the '/delete-property/mmc-hs200-1_8v' then everything is hunky dory. That line comes from the original submission of the mickey dts upstream, so presumably at the time the HS200 was failing and just enumerating things as a high speed device was fine. ...or maybe it's just that some mickey devices work when enumerating at "high speed", just not mine? In any case, hs200 seems good now. Let's turn it on. Signed-off-by: Douglas Anderson Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 3066561a1b82de8f693d95bc95e317924c1e08b8 Author: Douglas Anderson Date: Fri May 3 16:41:42 2019 -0700 ARM: dts: rockchip: Make rk3288-veyron-minnie run at hs200 [ Upstream commit 1c0479023412ab7834f2e98b796eb0d8c627cd62 ] As some point hs200 was failing on rk3288-veyron-minnie. See commit 984926781122 ("ARM: dts: rockchip: temporarily remove emmc hs200 speed from rk3288 minnie"). Although I didn't track down exactly when it started working, it seems to work OK now, so let's turn it back on. To test this, I booted from SD card and then used this script to stress the enumeration process after fixing a memory leak [1]: cd /sys/bus/platform/drivers/dwmmc_rockchip for i in $(seq 1 3000); do echo "========================" $i echo ff0f0000.dwmmc > unbind sleep .5 echo ff0f0000.dwmmc > bind while true; do if [ -e /dev/mmcblk2 ]; then break; fi sleep .1 done done It worked fine. [1] https://lkml.kernel.org/r/20190503233526.226272-1-dianders@chromium.org Signed-off-by: Douglas Anderson Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 2ceaeaa1668a14d540c44ed9b139b1ed5fbef323 Author: Russell King Date: Thu May 2 17:19:18 2019 +0100 ARM: riscpc: fix DMA [ Upstream commit ffd9a1ba9fdb7f2bd1d1ad9b9243d34e96756ba2 ] DMA got broken a while back in two different ways: 1) a change in the behaviour of disable_irq() to wait for the interrupt to finish executing causes us to deadlock at the end of DMA. 2) a change to avoid modifying the scatterlist left the first transfer uninitialised. DMA is only used with expansion cards, so has gone unnoticed. Fixes: fa4e99899932 ("[ARM] dma: RiscPC: don't modify DMA SG entries") Signed-off-by: Russell King Signed-off-by: Sasha Levin