commit 9b15f7fae677336e04b9e026ff91854e43165455 Author: Greg Kroah-Hartman Date: Fri Feb 14 16:33:28 2020 -0500 Linux 4.19.104 commit cad926f70b5a3ac61de0274c28891dc7fbd8d2ad Author: Daniel Jordan Date: Fri Feb 14 13:28:21 2020 -0500 padata: fix null pointer deref of pd->pinst The 4.19 backport dc34710a7aba ("padata: Remove broken queue flushing") removed padata_alloc_pd()'s assignment to pd->pinst, resulting in: Unable to handle kernel NULL pointer dereference ... ... pc : padata_reorder+0x144/0x2e0 ... Call trace: padata_reorder+0x144/0x2e0 padata_do_serial+0xc8/0x128 pcrypt_aead_enc+0x60/0x70 [pcrypt] padata_parallel_worker+0xd8/0x138 process_one_work+0x1bc/0x4b8 worker_thread+0x164/0x580 kthread+0x134/0x138 ret_from_fork+0x10/0x18 This happened because the backport was based on an enhancement that moved this assignment but isn't in 4.19: bfde23ce200e ("padata: unbind parallel jobs from specific CPUs") Simply restore the assignment to fix the crash. Fixes: dc34710a7aba ("padata: Remove broken queue flushing") Reported-by: Yang Yingliang Signed-off-by: Daniel Jordan Cc: Greg Kroah-Hartman Cc: Herbert Xu Cc: Sasha Levin Cc: Steffen Klassert Cc: linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 77bad0ab1b725e6c348277fcdb8790908286ca20 Author: Shubhrajyoti Datta Date: Fri May 24 14:41:28 2019 +0530 serial: uartps: Move the spinlock after the read of the tx empty commit 107475685abfdee504bb0ef4824f15797f6d2d4d upstream. Currently we are doing a read of the status register. Move the spinlock after that as the reads need not be spinlock protected. This patch prevents relaxing the cpu with spinlock held. Signed-off-by: Shubhrajyoti Datta Cc: Pavel Machek Signed-off-by: Greg Kroah-Hartman commit 2cdef3b47a404cb913efb192f280673da6f6e227 Author: Peter Zijlstra Date: Tue May 7 23:25:50 2019 +0200 x86/stackframe, x86/ftrace: Add pt_regs frame annotations commit ea1ed38dba64b64a245ab8ca1406269d17b99485 upstream. When CONFIG_FRAME_POINTER, we should mark pt_regs frames. Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Josh Poimboeuf Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Signed-off-by: Ingo Molnar [4.19 backport; added user-visible changelog] Signed-off-by: Dmitry Safonov Signed-off-by: Greg Kroah-Hartman commit 510cd44619e873098283e0093bacfba1d7401160 Author: Peter Zijlstra Date: Wed May 8 14:30:48 2019 +0200 x86/stackframe: Move ENCODE_FRAME_POINTER to asm/frame.h commit a9b3c6998d4a7d53a787cf4d0fd4a4c11239e517 upstream. In preparation for wider use, move the ENCODE_FRAME_POINTER macros to a common header and provide inline asm versions. These macros are used to encode a pt_regs frame for the unwinder; see unwind_frame.c:decode_frame_pointer(). Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Josh Poimboeuf Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Signed-off-by: Ingo Molnar Signed-off-by: Dmitry Safonov Signed-off-by: Greg Kroah-Hartman commit 1cb14cce72a9f814d3bb6f6db34559a103dbbca2 Author: Anand Lodnoor Date: Tue Jan 14 16:51:19 2020 +0530 scsi: megaraid_sas: Do not initiate OCR if controller is not in ready state commit 6d7537270e3283b92f9b327da9d58a4de40fe8d0 upstream. Driver initiates OCR if a DCMD command times out. But there is a deadlock if the driver attempts to invoke another OCR before the mutex lock (reset_mutex) is released from the previous session of OCR. This patch takes care of the above scenario using new flag MEGASAS_FUSION_OCR_NOT_POSSIBLE to indicate if OCR is possible. Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/1579000882-20246-9-git-send-email-anand.lodnoor@broadcom.com Signed-off-by: Shivasharan S Signed-off-by: Anand Lodnoor Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 1de085c83fad8d66fa1fb57880730a92367d8984 Author: Nicolai Stange Date: Tue Jan 14 11:39:03 2020 +0100 libertas: make lbs_ibss_join_existing() return error code on rates overflow [ Upstream commit 1754c4f60aaf1e17d886afefee97e94d7f27b4cb ] Commit e5e884b42639 ("libertas: Fix two buffer overflows at parsing bss descriptor") introduced a bounds check on the number of supplied rates to lbs_ibss_join_existing() and made it to return on overflow. However, the aforementioned commit doesn't set the return value accordingly and thus, lbs_ibss_join_existing() would return with zero even though it failed. Make lbs_ibss_join_existing return -EINVAL in case the bounds check on the number of supplied rates fails. Fixes: e5e884b42639 ("libertas: Fix two buffer overflows at parsing bss descriptor") Signed-off-by: Nicolai Stange Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 8ffeb2114dc105c7b47a18a85dd8acd611242b5d Author: Nicolai Stange Date: Tue Jan 14 11:39:02 2020 +0100 libertas: don't exit from lbs_ibss_join_existing() with RCU read lock held [ Upstream commit c7bf1fb7ddca331780b9a733ae308737b39f1ad4 ] Commit e5e884b42639 ("libertas: Fix two buffer overflows at parsing bss descriptor") introduced a bounds check on the number of supplied rates to lbs_ibss_join_existing(). Unfortunately, it introduced a return path from within a RCU read side critical section without a corresponding rcu_read_unlock(). Fix this. Fixes: e5e884b42639 ("libertas: Fix two buffer overflows at parsing bss descriptor") Signed-off-by: Nicolai Stange Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 48247f7e14911a4d18e9c774ba3a1d368f5d8a6f Author: Qing Xu Date: Thu Jan 2 10:39:27 2020 +0800 mwifiex: Fix possible buffer overflows in mwifiex_cmd_append_vsie_tlv() [ Upstream commit b70261a288ea4d2f4ac7cd04be08a9f0f2de4f4d ] mwifiex_cmd_append_vsie_tlv() calls memcpy() without checking the destination size may trigger a buffer overflower, which a local user could use to cause denial of service or the execution of arbitrary code. Fix it by putting the length check before calling memcpy(). Signed-off-by: Qing Xu Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit fab5ca79960b7fbda4e9a79a4754c749fdea2bd0 Author: Qing Xu Date: Thu Jan 2 10:39:26 2020 +0800 mwifiex: Fix possible buffer overflows in mwifiex_ret_wmm_get_status() [ Upstream commit 3a9b153c5591548612c3955c9600a98150c81875 ] mwifiex_ret_wmm_get_status() calls memcpy() without checking the destination size.Since the source is given from remote AP which contains illegal wmm elements , this may trigger a heap buffer overflow. Fix it by putting the length check before calling memcpy(). Signed-off-by: Qing Xu Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 920d65a77277e7ca1897336c913733c5f26cd96f Author: Geert Uytterhoeven Date: Wed Dec 18 20:48:07 2019 +0100 pinctrl: sh-pfc: r8a7778: Fix duplicate SDSELF_B and SD1_CLK_B commit 805f635703b2562b5ddd822c62fc9124087e5dd5 upstream. The FN_SDSELF_B and FN_SD1_CLK_B enum IDs are used twice, which means one set of users must be wrong. Replace them by the correct enum IDs. Fixes: 87f8c988636db0d4 ("sh-pfc: Add r8a7778 pinmux support") Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20191218194812.12741-2-geert+renesas@glider.be Signed-off-by: Greg Kroah-Hartman commit db5c14546684ea4bfab0f0439c9ee0999f8cdd5e Author: Gustavo A. R. Silva Date: Tue Oct 22 15:25:22 2019 +0200 media: i2c: adv748x: Fix unsafe macros commit 0d962e061abcf1b9105f88fb850158b5887fbca3 upstream. Enclose multiple macro parameters in parentheses in order to make such macros safer and fix the Clang warning below: drivers/media/i2c/adv748x/adv748x-afe.c:452:12: warning: operator '?:' has lower precedence than '|'; '|' will be evaluated first [-Wbitwise-conditional-parentheses] ret = sdp_clrset(state, ADV748X_SDP_FRP, ADV748X_SDP_FRP_MASK, enable ? ctrl->val - 1 : 0); Fixes: 3e89586a64df ("media: i2c: adv748x: add adv748x driver") Reported-by: Dmitry Vyukov Signed-off-by: Gustavo A. R. Silva Reviewed-by: Kieran Bingham Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit b772f3c499aac9a5d95ff2fddeb99a721ed39a80 Author: Eric Biggers Date: Mon Dec 30 21:19:33 2019 -0600 crypto: atmel-sha - fix error handling when setting hmac key commit b529f1983b2dcc46354f311feda92e07b6e9e2da upstream. HMAC keys can be of any length, and atmel_sha_hmac_key_set() can only fail due to -ENOMEM. But atmel_sha_hmac_setkey() incorrectly treated any error as a "bad key length" error. Fix it to correctly propagate the -ENOMEM error code and not set any tfm result flags. Fixes: 81d8750b2b59 ("crypto: atmel-sha - add support to hmac(shaX)") Cc: Nicolas Ferre Cc: Alexandre Belloni Cc: Ludovic Desroches Signed-off-by: Eric Biggers Reviewed-by: Tudor Ambarus Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit e1254ca723ecf5159e13a09508294cd71b215fa9 Author: Eric Biggers Date: Mon Dec 30 21:19:32 2019 -0600 crypto: artpec6 - return correct error code for failed setkey() commit b828f905904cd76424230c69741a4cabb0174168 upstream. ->setkey() is supposed to retun -EINVAL for invalid key lengths, not -1. Fixes: a21eb94fc4d3 ("crypto: axis - add ARTPEC-6/7 crypto accelerator driver") Cc: Jesper Nilsson Cc: Lars Persson Signed-off-by: Eric Biggers Acked-by: Lars Persson Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit a23409cee466c636eb74e42c8a139ba9a714b0f5 Author: YueHaibing Date: Mon Dec 30 11:29:45 2019 +0800 mtd: sharpslpart: Fix unsigned comparison to zero commit f33113b542219448fa02d77ca1c6f4265bd7f130 upstream. The unsigned variable log_num is being assigned a return value from the call to sharpsl_nand_get_logical_num that can return -EINVAL. Detected using Coccinelle: ./drivers/mtd/parsers/sharpslpart.c:207:6-13: WARNING: Unsigned expression compared with zero: log_num > 0 Fixes: 8a4580e4d298 ("mtd: sharpslpart: Add sharpslpart partition parser") Signed-off-by: YueHaibing Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit ad13249bfa13ca20c66ad40345a97b72f739566f Author: Nathan Chancellor Date: Mon Dec 9 14:44:23 2019 -0700 mtd: onenand_base: Adjust indentation in onenand_read_ops_nolock commit 0e7ca83e82d021c928dadf4c13c137d57337540d upstream. Clang warns: ../drivers/mtd/nand/onenand/onenand_base.c:1269:3: warning: misleading indentation; statement is not part of the previous 'if' [-Wmisleading-indentation] while (!ret) { ^ ../drivers/mtd/nand/onenand/onenand_base.c:1266:2: note: previous statement is here if (column + thislen > writesize) ^ 1 warning generated. This warning occurs because there is a space before the tab of the while loop. There are spaces at the beginning of a lot of the lines in this block, remove them so that the indentation is consistent with the Linux kernel coding style and clang no longer warns. Fixes: a8de85d55700 ("[MTD] OneNAND: Implement read-while-load") Link: https://github.com/ClangBuiltLinux/linux/issues/794 Signed-off-by: Nathan Chancellor Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit b818a55bc4e8f9598c0ea9fd3848e58f74cf0686 Author: Eric Auger Date: Fri Jan 24 15:25:32 2020 +0100 KVM: arm64: pmu: Don't increment SW_INCR if PMCR.E is unset commit 3837407c1aa1101ed5e214c7d6041e7a23335c6e upstream. The specification says PMSWINC increments PMEVCNTR_EL1 by 1 if PMEVCNTR_EL0 is enabled and configured to count SW_INCR. For PMEVCNTR_EL0 to be enabled, we need both PMCNTENSET to be set for the corresponding event counter but we also need the PMCR.E bit to be set. Fixes: 7a0adc7064b8 ("arm64: KVM: Add access handler for PMSWINC register") Signed-off-by: Eric Auger Signed-off-by: Marc Zyngier Reviewed-by: Andrew Murray Acked-by: Marc Zyngier Link: https://lore.kernel.org/r/20200124142535.29386-2-eric.auger@redhat.com Signed-off-by: Greg Kroah-Hartman commit f8d4dfffbb4a3e3f8fcc97a1cfe6797b39cc053b Author: James Morse Date: Tue Jan 21 12:33:56 2020 +0000 KVM: arm: Make inject_abt32() inject an external abort instead commit 21aecdbd7f3ab02c9b82597dc733ee759fb8b274 upstream. KVM's inject_abt64() injects an external-abort into an aarch64 guest. The KVM_CAP_ARM_INJECT_EXT_DABT is intended to do exactly this, but for an aarch32 guest inject_abt32() injects an implementation-defined exception, 'Lockdown fault'. Change this to external abort. For non-LPAE we now get the documented: | Unhandled fault: external abort on non-linefetch (0x008) at 0x9c800f00 and for LPAE: | Unhandled fault: synchronous external abort (0x210) at 0x9c800f00 Fixes: 74a64a981662a ("KVM: arm/arm64: Unify 32bit fault injection") Reported-by: Beata Michalska Signed-off-by: James Morse Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20200121123356.203000-3-james.morse@arm.com Signed-off-by: Greg Kroah-Hartman commit 8ea83328b2bc11f4d115e7dd21afcf51889f350a Author: James Morse Date: Tue Jan 21 12:33:55 2020 +0000 KVM: arm: Fix DFSR setting for non-LPAE aarch32 guests commit 018f22f95e8a6c3e27188b7317ef2c70a34cb2cd upstream. Beata reports that KVM_SET_VCPU_EVENTS doesn't inject the expected exception to a non-LPAE aarch32 guest. The host intends to inject DFSR.FS=0x14 "IMPLEMENTATION DEFINED fault (Lockdown fault)", but the guest receives DFSR.FS=0x04 "Fault on instruction cache maintenance". This fault is hooked by do_translation_fault() since ARMv6, which goes on to silently 'handle' the exception, and restart the faulting instruction. It turns out, when TTBCR.EAE is clear DFSR is split, and FS[4] has to shuffle up to DFSR[10]. As KVM only does this in one place, fix up the static values. We now get the expected: | Unhandled fault: lock abort (0x404) at 0x9c800f00 Fixes: 74a64a981662a ("KVM: arm/arm64: Unify 32bit fault injection") Reported-by: Beata Michalska Signed-off-by: James Morse Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20200121123356.203000-2-james.morse@arm.com Signed-off-by: Greg Kroah-Hartman commit 5b63ffb30b8148f87e3585f916772adf76e05765 Author: Gavin Shan Date: Tue Jan 21 16:56:59 2020 +1100 KVM: arm/arm64: Fix young bit from mmu notifier commit cf2d23e0bac9f6b5cd1cba8898f5f05ead40e530 upstream. kvm_test_age_hva() is called upon mmu_notifier_test_young(), but wrong address range has been passed to handle_hva_to_gpa(). With the wrong address range, no young bits will be checked in handle_hva_to_gpa(). It means zero is always returned from mmu_notifier_test_young(). This fixes the issue by passing correct address range to the underly function handle_hva_to_gpa(), so that the hardware young (access) bit will be visited. Fixes: 35307b9a5f7e ("arm/arm64: KVM: Implement Stage-2 page aging") Signed-off-by: Gavin Shan Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20200121055659.19560-1-gshan@redhat.com Signed-off-by: Greg Kroah-Hartman commit 0e0310adf2207cc175fb86833b0e61b8237edb25 Author: Suzuki K Poulose Date: Mon Jan 13 23:30:21 2020 +0000 arm64: ptrace: nofpsimd: Fail FP/SIMD regset operations commit c9d66999f064947e6b577ceacc1eb2fbca6a8d3c upstream. When fp/simd is not supported on the system, fail the operations of FP/SIMD regsets. Fixes: 82e0191a1aa11abf ("arm64: Support systems without FP/ASIMD") Cc: Will Deacon Cc: Mark Rutland Reviewed-by: Ard Biesheuvel Reviewed-by: Catalin Marinas Signed-off-by: Suzuki K Poulose Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 12e2dca1f224fde0ec1dec10a3c6e178c6dd8a7a Author: Suzuki K Poulose Date: Mon Jan 13 23:30:19 2020 +0000 arm64: cpufeature: Fix the type of no FP/SIMD capability commit 449443c03d8cfdacf7313e17779a2594ebf87e6d upstream. The NO_FPSIMD capability is defined with scope SYSTEM, which implies that the "absence" of FP/SIMD on at least one CPU is detected only after all the SMP CPUs are brought up. However, we use the status of this capability for every context switch. So, let us change the scope to LOCAL_CPU to allow the detection of this capability as and when the first CPU without FP is brought up. Also, the current type allows hotplugged CPU to be brought up without FP/SIMD when all the current CPUs have FP/SIMD and we have the userspace up. Fix both of these issues by changing the capability to BOOT_RESTRICTED_LOCAL_CPU_FEATURE. Fixes: 82e0191a1aa11abf ("arm64: Support systems without FP/ASIMD") Cc: Will Deacon Cc: Mark Rutland Reviewed-by: Ard Biesheuvel Reviewed-by: Catalin Marinas Signed-off-by: Suzuki K Poulose Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit f1025b2f75a0e2ad037e1d875e43d996aed78dfb Author: Olof Johansson Date: Wed Dec 18 01:18:49 2019 +0100 ARM: 8949/1: mm: mark free_memmap as __init commit 31f3010e60522ede237fb145a63b4af5a41718c2 upstream. As of commit ac7c3e4ff401 ("compiler: enable CONFIG_OPTIMIZE_INLINING forcibly"), free_memmap() might not always be inlined, and thus is triggering a section warning: WARNING: vmlinux.o(.text.unlikely+0x904): Section mismatch in reference from the function free_memmap() to the function .meminit.text:memblock_free() Mark it as __init, since the faller (free_unused_memmap) already is. Fixes: ac7c3e4ff401 ("compiler: enable CONFIG_OPTIMIZE_INLINING forcibly") Signed-off-by: Olof Johansson Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 092c84fdac555086bec0d6de64274062d2add748 Author: Eric Auger Date: Fri Dec 13 10:42:37 2019 +0100 KVM: arm/arm64: vgic-its: Fix restoration of unmapped collections commit 8c58be34494b7f1b2adb446e2d8beeb90e5de65b upstream. Saving/restoring an unmapped collection is a valid scenario. For example this happens if a MAPTI command was sent, featuring an unmapped collection. At the moment the CTE fails to be restored. Only compare against the number of online vcpus if the rdist base is set. Fixes: ea1ad53e1e31a ("KVM: arm64: vgic-its: Collection table save/restore") Signed-off-by: Eric Auger Signed-off-by: Marc Zyngier Reviewed-by: Zenghui Yu Link: https://lore.kernel.org/r/20191213094237.19627-1-eric.auger@redhat.com Signed-off-by: Greg Kroah-Hartman commit 0703c46a76c1bb16e2d5a1e27349436351ba08a8 Author: Shameer Kolothum Date: Wed Nov 13 16:11:38 2019 +0000 iommu/arm-smmu-v3: Populate VMID field for CMDQ_OP_TLBI_NH_VA commit 935d43ba272e0001f8ef446a3eff15d8175cb11b upstream. CMDQ_OP_TLBI_NH_VA requires VMID and this was missing since commit 1c27df1c0a82 ("iommu/arm-smmu: Use correct address mask for CMD_TLBI_S2_IPA"). Add it back. Fixes: 1c27df1c0a82 ("iommu/arm-smmu: Use correct address mask for CMD_TLBI_S2_IPA") Signed-off-by: Shameer Kolothum Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 9ed7b9085e13c335cd1cf69bc70673d41a43ca14 Author: Alexey Kardashevskiy Date: Mon Dec 16 15:19:22 2019 +1100 powerpc/pseries: Allow not having ibm, hypertas-functions::hcall-multi-tce for DDW commit 7559d3d295f3365ea7ac0c0274c05e633fe4f594 upstream. By default a pseries guest supports a H_PUT_TCE hypercall which maps a single IOMMU page in a DMA window. Additionally the hypervisor may support H_PUT_TCE_INDIRECT/H_STUFF_TCE which update multiple TCEs at once; this is advertised via the device tree /rtas/ibm,hypertas-functions property which Linux converts to FW_FEATURE_MULTITCE. FW_FEATURE_MULTITCE is checked when dma_iommu_ops is used; however the code managing the huge DMA window (DDW) ignores it and calls H_PUT_TCE_INDIRECT even if it is explicitly disabled via the "multitce=off" kernel command line parameter. This adds FW_FEATURE_MULTITCE checking to the DDW code path. This changes tce_build_pSeriesLP to take liobn and page size as the huge window does not have iommu_table descriptor which usually the place to store these numbers. Fixes: 4e8b0cf46b25 ("powerpc/pseries: Add support for dynamic dma windows") Signed-off-by: Alexey Kardashevskiy Reviewed-by: Thiago Jung Bauermann Tested-by: Thiago Jung Bauermann Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20191216041924.42318-3-aik@ozlabs.ru Signed-off-by: Greg Kroah-Hartman commit 802d704669097ecfb2ea582c04785e168c026eee Author: Tyrel Datwyler Date: Mon Jan 20 14:10:02 2020 -0800 powerpc/pseries/vio: Fix iommu_table use-after-free refcount warning commit aff8c8242bc638ba57247ae1ec5f272ac3ed3b92 upstream. Commit e5afdf9dd515 ("powerpc/vfio_spapr_tce: Add reference counting to iommu_table") missed an iommu_table allocation in the pseries vio code. The iommu_table is allocated with kzalloc and as a result the associated kref gets a value of zero. This has the side effect that during a DLPAR remove of the associated virtual IOA the iommu_tce_table_put() triggers a use-after-free underflow warning. Call Trace: [c0000002879e39f0] [c00000000071ecb4] refcount_warn_saturate+0x184/0x190 (unreliable) [c0000002879e3a50] [c0000000000500ac] iommu_tce_table_put+0x9c/0xb0 [c0000002879e3a70] [c0000000000f54e4] vio_dev_release+0x34/0x70 [c0000002879e3aa0] [c00000000087cfa4] device_release+0x54/0xf0 [c0000002879e3b10] [c000000000d64c84] kobject_cleanup+0xa4/0x240 [c0000002879e3b90] [c00000000087d358] put_device+0x28/0x40 [c0000002879e3bb0] [c0000000007a328c] dlpar_remove_slot+0x15c/0x250 [c0000002879e3c50] [c0000000007a348c] remove_slot_store+0xac/0xf0 [c0000002879e3cd0] [c000000000d64220] kobj_attr_store+0x30/0x60 [c0000002879e3cf0] [c0000000004ff13c] sysfs_kf_write+0x6c/0xa0 [c0000002879e3d10] [c0000000004fde4c] kernfs_fop_write+0x18c/0x260 [c0000002879e3d60] [c000000000410f3c] __vfs_write+0x3c/0x70 [c0000002879e3d80] [c000000000415408] vfs_write+0xc8/0x250 [c0000002879e3dd0] [c0000000004157dc] ksys_write+0x7c/0x120 [c0000002879e3e20] [c00000000000b278] system_call+0x5c/0x68 Further, since the refcount was always zero the iommu_tce_table_put() fails to call the iommu_table release function resulting in a leak. Fix this issue be initilizing the iommu_table kref immediately after allocation. Fixes: e5afdf9dd515 ("powerpc/vfio_spapr_tce: Add reference counting to iommu_table") Signed-off-by: Tyrel Datwyler Reviewed-by: Alexey Kardashevskiy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/1579558202-26052-1-git-send-email-tyreld@linux.ibm.com Signed-off-by: Greg Kroah-Hartman commit 63a01158cfe6887847c119c7bc17ba8673fe4479 Author: Zhengyuan Liu Date: Sat Dec 14 00:27:12 2019 +0800 tools/power/acpi: fix compilation error commit 1985f8c7f9a42a651a9750d6fcadc74336d182df upstream. If we compile tools/acpi target in the top source directory, we'd get a compilation error showing as bellow: # make tools/acpi DESCEND power/acpi DESCEND tools/acpidbg CC tools/acpidbg/acpidbg.o Assembler messages: Fatal error: can't create /home/lzy/kernel-upstream/power/acpi/\ tools/acpidbg/acpidbg.o: No such file or directory ../../Makefile.rules:26: recipe for target '/home/lzy/kernel-upstream/\ power/acpi/tools/acpidbg/acpidbg.o' failed make[3]: *** [/home/lzy/kernel-upstream//power/acpi/tools/acpidbg/\ acpidbg.o] Error 1 Makefile:19: recipe for target 'acpidbg' failed make[2]: *** [acpidbg] Error 2 Makefile:54: recipe for target 'acpi' failed make[1]: *** [acpi] Error 2 Makefile:1607: recipe for target 'tools/acpi' failed make: *** [tools/acpi] Error 2 Fixes: d5a4b1a540b8 ("tools/power/acpi: Remove direct kernel source include reference") Signed-off-by: Zhengyuan Liu Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 939d63b8e2b92746c348eadbbbaa700debb22f87 Author: Alexandre Belloni Date: Fri Jan 10 18:20:07 2020 +0100 ARM: dts: at91: sama5d3: define clock rate range for tcb1 commit a7e0f3fc01df4b1b7077df777c37feae8c9e8b6d upstream. The clock rate range for the TCB1 clock is missing. define it in the device tree. Reported-by: Karl Rudbæk Olsen Fixes: d2e8190b7916 ("ARM: at91/dt: define sama5d3 clocks") Link: https://lore.kernel.org/r/20200110172007.1253659-2-alexandre.belloni@bootlin.com Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit 7afef92485dea535066e2edb05cd58a19efa3737 Author: Alexandre Belloni Date: Fri Jan 10 18:20:06 2020 +0100 ARM: dts: at91: sama5d3: fix maximum peripheral clock rates commit ee0aa926ddb0bd8ba59e33e3803b3b5804e3f5da upstream. Currently the maximum rate for peripheral clock is calculated based on a typical 133MHz MCK. The maximum frequency is defined in the datasheet as a ratio to MCK. Some sama5d3 platforms are using a 166MHz MCK. Update the device trees to match the maximum rate based on 166MHz. Reported-by: Karl Rudbæk Olsen Fixes: d2e8190b7916 ("ARM: at91/dt: define sama5d3 clocks") Link: https://lore.kernel.org/r/20200110172007.1253659-1-alexandre.belloni@bootlin.com Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit 95427f9a169fd39151d223221cc714457f209a64 Author: Tero Kristo Date: Wed Dec 11 08:07:18 2019 -0600 ARM: dts: am43xx: add support for clkout1 clock commit 01053dadb79d63b65f7b353e68b4b6ccf4effedb upstream. clkout1 clock node and its generation tree was missing. Add this based on the data on TRM and PRCM functional spec. commit 664ae1ab2536 ("ARM: dts: am43xx: add clkctrl nodes") effectively reverted this commit 8010f13a40d3 ("ARM: dts: am43xx: add support for clkout1 clock") which is needed for the ov2659 camera sensor clock definition hence it is being re-applied here. Note that because of the current dts node name dependency for mapping to clock domain, we must still use "clkout1-*ck" naming instead of generic "clock@" naming for the node. And because of this, it's probably best to apply the dts node addition together along with the other clock changes. Fixes: 664ae1ab2536 ("ARM: dts: am43xx: add clkctrl nodes") Signed-off-by: Tero Kristo Tested-by: Benoit Parrot Acked-by: Tony Lindgren Signed-off-by: Benoit Parrot Signed-off-by: Tony Lindgren Signed-off-by: Greg Kroah-Hartman commit 27866f367698e2637f2bd49fcc84ce0402608bb9 Author: Ingo van Lil Date: Tue Dec 3 15:21:47 2019 +0100 ARM: dts: at91: Reenable UART TX pull-ups commit 9d39d86cd4af2b17b970d63307daad71f563d207 upstream. Pull-ups for SAM9 UART/USART TX lines were disabled in a previous commit. However, several chips in the SAM9 family require pull-ups to prevent the TX lines from falling (and causing an endless break condition) when the transceiver is disabled. From the SAM9G20 datasheet, 32.5.1: "To prevent the TXD line from falling when the USART is disabled, the use of an internal pull up is mandatory.". This commit reenables the pull-ups for all chips having that sentence in their datasheets. Fixes: 5e04822f7db5 ("ARM: dts: at91: fixes uart pinctrl, set pullup on rx, clear pullup on tx") Signed-off-by: Ingo van Lil Cc: Peter Rosin Link: https://lore.kernel.org/r/20191203142147.875227-1-inguin@gmx.de Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit 73124cba81443a23c633f1238546881ef10d3a91 Author: Mika Westerberg Date: Wed Jan 22 19:05:20 2020 +0300 platform/x86: intel_mid_powerbtn: Take a copy of ddata commit 5e0c94d3aeeecc68c573033f08d9678fecf253bd upstream. The driver gets driver_data from memory that is marked as const (which is probably put to read-only memory) and it then modifies it. This likely causes some sort of fault to happen. Fix this by taking a copy of the structure. Fixes: c94a8ff14de3 ("platform/x86: intel_mid_powerbtn: make mid_pb_ddata const") Signed-off-by: Mika Westerberg Reviewed-by: Andy Shevchenko Signed-off-by: Andy Shevchenko Signed-off-by: Greg Kroah-Hartman commit f2b55429200853f75d2193682c69752cdbd13c27 Author: Jose Abreu Date: Tue Jan 14 17:09:24 2020 +0100 ARC: [plat-axs10x]: Add missing multicast filter number to GMAC node commit 7980dff398f86a618f502378fa27cf7e77449afa upstream. Add a missing property to GMAC node so that multicast filtering works correctly. Fixes: 556cc1c5f528 ("ARC: [axs101] Add support for AXS101 SDP (software development platform)") Acked-by: Alexey Brodkin Signed-off-by: Jose Abreu Signed-off-by: Vineet Gupta Signed-off-by: Greg Kroah-Hartman commit 25992fd9d88884c7ee6a2acd507cedcff832320b Author: Andy Shevchenko Date: Thu Jan 23 15:14:35 2020 +0200 rtc: cmos: Stop using shared IRQ commit b6da197a2e9670df6f07e6698629e9ce95ab614e upstream. As reported by Guilherme G. Piccoli: ---8<---8<---8<--- The rtc-cmos interrupt setting was changed in the commit 079062b28fb4 ("rtc: cmos: prevent kernel warning on IRQ flags mismatch") in order to allow shared interrupts; according to that commit's description, some machine got kernel warnings due to the interrupt line being shared between rtc-cmos and other hardware, and rtc-cmos didn't allow IRQ sharing that time. After the aforementioned commit though it was observed a huge increase in lost HPET interrupts in some systems, observed through the following kernel message: [...] hpet1: lost 35 rtc interrupts After investigation, it was narrowed down to the shared interrupts usage when having the kernel option "irqpoll" enabled. In this case, all IRQ handlers are called for non-timer interrupts, if such handlers are setup in shared IRQ lines. The rtc-cmos IRQ handler could be set to hpet_rtc_interrupt(), which will produce the kernel "lost interrupts" message after doing work - lots of readl/writel to HPET registers, which are known to be slow. Although "irqpoll" is not a default kernel option, it's used in some contexts, one being the kdump kernel (which is an already "impaired" kernel usually running with 1 CPU available), so the performance burden could be considerable. Also, the same issue would happen (in a shorter extent though) when using "irqfixup" kernel option. In a quick experiment, a virtual machine with uptime of 2 minutes produced >300 calls to hpet_rtc_interrupt() when "irqpoll" was set, whereas without sharing interrupts this number reduced to 1 interrupt. Machines with more hardware than a VM should generate even more unnecessary HPET interrupts in this scenario. ---8<---8<---8<--- After looking into the rtc-cmos driver history and DSDT table from the Microsoft Surface 3, we may notice that Hans de Goede submitted a correct fix (see dependency below). Thus, we simply revert the culprit commit. Fixes: 079062b28fb4 ("rtc: cmos: prevent kernel warning on IRQ flags mismatch") Depends-on: a1e23a42f1bd ("rtc: cmos: Do not assume irq 8 for rtc when there are no legacy irqs") Reported-by: Guilherme G. Piccoli Cc: Hans de Goede Signed-off-by: Andy Shevchenko Tested-by: Guilherme G. Piccoli Reviewed-by: Hans de Goede Link: https://lore.kernel.org/r/20200123131437.28157-1-andriy.shevchenko@linux.intel.com Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit 3abc9c46a5e219ec14623d8f804864ff0ae03f63 Author: Paul Kocialkowski Date: Thu Dec 12 16:31:10 2019 +0100 rtc: hym8563: Return -EINVAL if the time is known to be invalid commit f236a2a2ebabad0848ad0995af7ad1dc7029e895 upstream. The current code returns -EPERM when the voltage loss bit is set. Since the bit indicates that the time value is not valid, return -EINVAL instead, which is the appropriate error code for this situation. Fixes: dcaf03849352 ("rtc: add hym8563 rtc-driver") Signed-off-by: Paul Kocialkowski Link: https://lore.kernel.org/r/20191212153111.966923-1-paul.kocialkowski@bootlin.com Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit 490ab7fce10990b91bb57d73bff57fc48ce2012b Author: Geert Uytterhoeven Date: Tue Sep 25 11:46:55 2018 +0200 spi: spi-mem: Fix inverted logic in op sanity check [ Upstream commit aea3877e24f3acc6145094848dbb85f9ce85674a ] On r8a7791/koelsch: m25p80 spi0.0: error -22 reading 9f m25p80: probe of spi0.0 failed with error -22 Apparently the logic in spi_mem_check_op() is wrong, rejecting the spi-mem operation if any buswidth is valid, instead of invalid. Fixes: 380583227c0c7f52 ("spi: spi-mem: Add extra sanity checks on the op param") Signed-off-by: Geert Uytterhoeven Reviewed-by: Boris Brezillon Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit b237f078cb25e1e1819e372b8876b106d0d2dbe1 Author: Boris Brezillon Date: Mon Feb 10 10:18:27 2020 -0700 spi: spi-mem: Add extra sanity checks on the op param commit 380583227c0c7f52383b0cd5c0e2de93ed31d553 upstream Some combinations are simply not valid and should be rejected before the op is passed to the SPI controller driver. Add an spi_mem_check_op() helper and use it in spi_mem_exec_op() and spi_mem_supports_op() to make sure the spi-mem operation is valid. Signed-off-by: Boris Brezillon Signed-off-by: Mark Brown Cc: stable # 4.19 Signed-off-by: Mathieu Poirier Signed-off-by: Sasha Levin commit 1503649d8f0f6f3cf5d220fb7455bd980ceb26ab Author: Brandon Maier Date: Mon Feb 10 10:18:26 2020 -0700 gpio: zynq: Report gpio direction at boot commit 6169005ceb8c715582eca70df3912cd2b351ede2 upstream The Zynq's gpios can be configured by the bootloader. But Linux will erroneously report all gpios as inputs unless we implement get_direction(). Signed-off-by: Brandon Maier Tested-by: Michal Simek Signed-off-by: Linus Walleij Cc: stable # 4.19 Signed-off-by: Mathieu Poirier Signed-off-by: Sasha Levin commit 4d905fc227cec77ecd85d8235fae55ac19b89659 Author: Shubhrajyoti Datta Date: Mon Feb 10 10:18:25 2020 -0700 serial: uartps: Add a timeout to the tx empty wait commit 277375b864e8147975b064b513f491e2a910e66a upstream In case the cable is not connected then the target gets into an infinite wait for tx empty. Add a timeout to the tx empty wait. Reported-by: Jean-Francois Dagenais Signed-off-by: Shubhrajyoti Datta Signed-off-by: Greg Kroah-Hartman Cc: stable # 4.19 Signed-off-by: Mathieu Poirier Signed-off-by: Sasha Levin commit 070818b71dca057ba69c53f2a3c8098508ece818 Author: Robert Milkowski Date: Tue Jan 28 08:37:47 2020 +0000 NFSv4: try lease recovery on NFS4ERR_EXPIRED commit 924491f2e476f7234d722b24171a4daff61bbe13 upstream. Currently, if an nfs server returns NFS4ERR_EXPIRED to open(), we return EIO to applications without even trying to recover. Fixes: 272289a3df72 ("NFSv4: nfs4_do_handle_exception() handle revoke/expiry of a single stateid") Signed-off-by: Robert Milkowski Reviewed-by: Trond Myklebust Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit 056d1656704016990311ecae5a751c91942192c8 Author: Trond Myklebust Date: Mon Jan 6 15:25:04 2020 -0500 NFS/pnfs: Fix pnfs_generic_prepare_to_resend_writes() commit 221203ce6406273cf00e5c6397257d986c003ee6 upstream. Instead of making assumptions about the commit verifier contents, change the commit code to ensure we always check that the verifier was set by the XDR code. Fixes: f54bcf2ecee9 ("pnfs: Prepare for flexfiles by pulling out common code") Signed-off-by: Trond Myklebust Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit 3060883146e59cb60c7e2d8981bc256f7c5283df Author: Trond Myklebust Date: Mon Jan 6 15:25:00 2020 -0500 NFS: Revalidate the file size on a fatal write error commit 0df68ced55443243951d02cc497be31fadf28173 upstream. If we suffer a fatal error upon writing a file, which causes us to need to revalidate the entire mapping, then we should also revalidate the file size. Fixes: d2ceb7e57086 ("NFS: Don't use page_file_mapping after removing the page") Signed-off-by: Trond Myklebust Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit 008ff93deec291d3ab69f020537f0813f83ed23a Author: Geert Uytterhoeven Date: Mon Dec 30 16:32:38 2019 +0100 nfs: NFS_SWAP should depend on SWAP commit 474c4f306eefbb21b67ebd1de802d005c7d7ecdc upstream. If CONFIG_SWAP=n, it does not make much sense to offer the user the option to enable support for swapping over NFS, as that will still fail at run time: # swapon /swap swapon: /swap: swapon failed: Function not implemented Fix this by adding a dependency on CONFIG_SWAP. Fixes: a564b8f0398636ba ("nfs: enable swap on NFS") Signed-off-by: Geert Uytterhoeven Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit 412cb7a7b0a0bbaf32a23951d604f59b8a8b0f20 Author: Logan Gunthorpe Date: Wed Jan 8 14:32:08 2020 -0700 PCI: Don't disable bridge BARs when assigning bus resources commit 9db8dc6d0785225c42a37be7b44d1b07b31b8957 upstream. Some PCI bridges implement BARs in addition to bridge windows. For example, here's a PLX switch: 04:00.0 PCI bridge: PLX Technology, Inc. PEX 8724 24-Lane, 6-Port PCI Express Gen 3 (8 GT/s) Switch, 19 x 19mm FCBGA (rev ca) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0, IRQ 30, NUMA node 0 Memory at 90a00000 (32-bit, non-prefetchable) [size=256K] Bus: primary=04, secondary=05, subordinate=0a, sec-latency=0 I/O behind bridge: 00002000-00003fff Memory behind bridge: 90000000-909fffff Prefetchable memory behind bridge: 0000380000800000-0000380000bfffff Previously, when the kernel assigned resource addresses (with the pci=realloc command line parameter, for example) it could clear the struct resource corresponding to the BAR. When this happened, lspci would report this BAR as "ignored": Region 0: Memory at (32-bit, non-prefetchable) [size=256K] This is because the kernel reports a zero start address and zero flags in the corresponding sysfs resource file and in /proc/bus/pci/devices. Investigation with 'lspci -x', however, shows the BIOS-assigned address will still be programmed in the device's BAR registers. It's clearly a bug that the kernel lost track of the BAR value, but in most cases, this still won't result in a visible issue because nothing uses the memory, so nothing is affected. However, when an IOMMU is in use, it will not reserve this space in the IOVA because the kernel no longer thinks the range is valid. (See dmar_init_reserved_ranges() for the Intel implementation of this.) Without the proper reserved range, a DMA mapping may allocate an IOVA that matches a bridge BAR, which results in DMA accesses going to the BAR instead of the intended RAM. The problem was in pci_assign_unassigned_root_bus_resources(). When any resource from a bridge device fails to get assigned, the code set the resource's flags to zero. This makes sense for bridge windows, as they will be re-enabled later, but for regular BARs, it makes the kernel permanently lose track of the fact that they decode address space. Change pci_assign_unassigned_root_bus_resources() and pci_assign_unassigned_bridge_resources() so they only clear "res->flags" for bridge *windows*, not bridge BARs. Fixes: da7822e5ad71 ("PCI: update bridge resources to get more big ranges when allocating space (again)") Link: https://lore.kernel.org/r/20200108213208.4612-1-logang@deltatee.com [bhelgaas: commit log, check for pci_is_bridge()] Reported-by: Kit Chow Signed-off-by: Logan Gunthorpe Signed-off-by: Bjorn Helgaas Signed-off-by: Greg Kroah-Hartman commit 239514d16ff776eed0e4e8513d3abd6895c7c718 Author: Logan Gunthorpe Date: Mon Jan 6 12:03:27 2020 -0700 PCI/switchtec: Fix vep_vector_number ioread width commit 9375646b4cf03aee81bc6c305aa18cc80b682796 upstream. vep_vector_number is actually a 16 bit register which should be read with ioread16() instead of ioread32(). Fixes: 080b47def5e5 ("MicroSemi Switchtec management interface driver") Link: https://lore.kernel.org/r/20200106190337.2428-3-logang@deltatee.com Reported-by: Doug Meyer Signed-off-by: Logan Gunthorpe Signed-off-by: Bjorn Helgaas Signed-off-by: Greg Kroah-Hartman commit 654ba8dcc30fc6c0411beaa5e48f6a5a640d76e1 Author: Bryan O'Donoghue Date: Thu Dec 19 13:15:38 2019 +0000 ath10k: pci: Only dump ATH10K_MEM_REGION_TYPE_IOREG when safe commit d239380196c4e27a26fa4bea73d2bf994c14ec2d upstream. ath10k_pci_dump_memory_reg() will try to access memory of type ATH10K_MEM_REGION_TYPE_IOREG however, if a hardware restart is in progress this can crash a system. Individual ioread32() time has been observed to jump from 15-20 ticks to > 80k ticks followed by a secure-watchdog bite and a system reset. Work around this corner case by only issuing the read transaction when the driver state is ATH10K_STATE_ON. Tested-on: QCA9988 PCI 10.4-3.9.0.2-00044 Fixes: 219cc084c6706 ("ath10k: add memory dump support QCA9984") Signed-off-by: Bryan O'Donoghue Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit 93b5c76198a57c44522a654e4dba64ef990f7b54 Author: Navid Emamdoost Date: Mon Nov 25 13:52:52 2019 -0600 PCI/IOV: Fix memory leak in pci_iov_add_virtfn() commit 8c386cc817878588195dde38e919aa6ba9409d58 upstream. In the implementation of pci_iov_add_virtfn() the allocated virtfn is leaked if pci_setup_device() fails. The error handling is not calling pci_stop_and_remove_bus_device(). Change the goto label to failed2. Fixes: 156c55325d30 ("PCI: Check for pci_setup_device() failure in pci_iov_add_virtfn()") Link: https://lore.kernel.org/r/20191125195255.23740-1-navid.emamdoost@gmail.com Signed-off-by: Navid Emamdoost Signed-off-by: Bjorn Helgaas Signed-off-by: Greg Kroah-Hartman commit 960e54416becfef12baceeb4d7a1a7bd4c049765 Author: Bean Huo Date: Mon Jan 20 14:08:13 2020 +0100 scsi: ufs: Fix ufshcd_probe_hba() reture value in case ufshcd_scsi_add_wlus() fails commit b9fc5320212efdfb4e08b825aaa007815fd11d16 upstream. A non-zero error value likely being returned by ufshcd_scsi_add_wlus() in case of failure of adding the WLs, but ufshcd_probe_hba() doesn't use this value, and doesn't report this failure to upper caller. This patch is to fix this issue. Fixes: 2a8fa600445c ("ufs: manually add well known logical units") Link: https://lore.kernel.org/r/20200120130820.1737-2-huobean@gmail.com Reviewed-by: Asutosh Das Reviewed-by: Alim Akhtar Reviewed-by: Stanley Chu Signed-off-by: Bean Huo Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit eb22d5e307d80bd09dcdab187b904de2f53c56c0 Author: Michael Guralnik Date: Wed Jan 8 20:05:35 2020 +0200 RDMA/uverbs: Verify MR access flags commit ca95c1411198c2d87217c19d44571052cdc94725 upstream. Verify that MR access flags that are passed from user are all supported ones, otherwise an error is returned. Fixes: 4fca03778351 ("IB/uverbs: Move ib_access_flags and ib_read_counters_flags to uapi") Link: https://lore.kernel.org/r/1578506740-22188-6-git-send-email-yishaih@mellanox.com Signed-off-by: Michael Guralnik Signed-off-by: Yishai Hadas Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 14d37518a97843eae6951e77f0d4510f30d4d90c Author: Jason Gunthorpe Date: Wed Jan 8 19:22:03 2020 +0200 RDMA/core: Fix locking in ib_uverbs_event_read commit 14e23bd6d22123f6f3b2747701fa6cd4c6d05873 upstream. This should not be using ib_dev to test for disassociation, during disassociation is_closed is set under lock and the waitq is triggered. Instead check is_closed and be sure to re-obtain the lock to test the value after the wait_event returns. Fixes: 036b10635739 ("IB/uverbs: Enable device removal when there are active user space applications") Link: https://lore.kernel.org/r/1578504126-9400-12-git-send-email-yishaih@mellanox.com Signed-off-by: Yishai Hadas Reviewed-by: Håkon Bugge Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit ab40fc36d6b39d65e0f5fdb950f2155e1250c8f1 Author: Håkon Bugge Date: Mon Dec 16 13:04:36 2019 +0100 RDMA/netlink: Do not always generate an ACK for some netlink operations commit a242c36951ecd24bc16086940dbe6b522205c461 upstream. In rdma_nl_rcv_skb(), the local variable err is assigned the return value of the supplied callback function, which could be one of ib_nl_handle_resolve_resp(), ib_nl_handle_set_timeout(), or ib_nl_handle_ip_res_resp(). These three functions all return skb->len on success. rdma_nl_rcv_skb() is merely a copy of netlink_rcv_skb(). The callback functions used by the latter have the convention: "Returns 0 on success or a negative error code". In particular, the statement (equal for both functions): if (nlh->nlmsg_flags & NLM_F_ACK || err) implies that rdma_nl_rcv_skb() always will ack a message, independent of the NLM_F_ACK being set in nlmsg_flags or not. The fix could be to change the above statement, but it is better to keep the two *_rcv_skb() functions equal in this respect and instead change the three callback functions in the rdma subsystem to the correct convention. Fixes: 2ca546b92a02 ("IB/sa: Route SA pathrecord query through netlink") Fixes: ae43f8286730 ("IB/core: Add IP to GID netlink offload") Link: https://lore.kernel.org/r/20191216120436.3204814-1-haakon.bugge@oracle.com Suggested-by: Mark Haywood Signed-off-by: Håkon Bugge Tested-by: Mark Haywood Reviewed-by: Leon Romanovsky Reviewed-by: Jason Gunthorpe Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 6ddcb30256b2fa18e15ab36ba33a156cfe436661 Author: Jack Morgenstein Date: Wed Jan 15 10:50:50 2020 +0200 IB/mlx4: Fix memory leak in add_gid error flow commit eaad647e5cc27f7b46a27f3b85b14c4c8a64bffa upstream. In procedure mlx4_ib_add_gid(), if the driver is unable to update the FW gid table, there is a memory leak in the driver's copy of the gid table: the gid entry's context buffer is not freed. If such an error occurs, free the entry's context buffer, and mark the entry as available (by setting its context pointer to NULL). Fixes: e26be1bfef81 ("IB/mlx4: Implement ib_device callbacks") Link: https://lore.kernel.org/r/20200115085050.73746-1-leon@kernel.org Signed-off-by: Jack Morgenstein Reviewed-by: Parav Pandit Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 9a7f8a176a73cfc4d966aaea183f2cabf20206e5 Author: Sunil Muthuswamy Date: Fri Jan 24 03:08:18 2020 +0000 hv_sock: Remove the accept port restriction [ Upstream commit c742c59e1fbd022b64d91aa9a0092b3a699d653c ] Currently, hv_sock restricts the port the guest socket can accept connections on. hv_sock divides the socket port namespace into two parts for server side (listening socket), 0-0x7FFFFFFF & 0x80000000-0xFFFFFFFF (there are no restrictions on client port namespace). The first part (0-0x7FFFFFFF) is reserved for sockets where connections can be accepted. The second part (0x80000000-0xFFFFFFFF) is reserved for allocating ports for the peer (host) socket, once a connection is accepted. This reservation of the port namespace is specific to hv_sock and not known by the generic vsock library (ex: af_vsock). This is problematic because auto-binds/ephemeral ports are handled by the generic vsock library and it has no knowledge of this port reservation and could allocate a port that is not compatible with hv_sock (and legitimately so). The issue hasn't surfaced so far because the auto-bind code of vsock (__vsock_bind_stream) prior to the change 'VSOCK: bind to random port for VMADDR_PORT_ANY' would start walking up from LAST_RESERVED_PORT (1023) and start assigning ports. That will take a large number of iterations to hit 0x7FFFFFFF. But, after the above change to randomize port selection, the issue has started coming up more frequently. There has really been no good reason to have this port reservation logic in hv_sock from the get go. Reserving a local port for peer ports is not how things are handled generally. Peer ports should reflect the peer port. This fixes the issue by lifting the port reservation, and also returns the right peer port. Since the code converts the GUID to the peer port (by using the first 4 bytes), there is a possibility of conflicts, but that seems like a reasonable risk to take, given this is limited to vsock and that only applies to all local sockets. Signed-off-by: Sunil Muthuswamy Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e7751a4bb72fb787649e03fc1dd85a18a2d5fa90 Author: Ranjani Sridharan Date: Mon Nov 4 14:48:11 2019 -0800 ASoC: pcm: update FE/BE trigger order based on the command [ Upstream commit acbf27746ecfa96b290b54cc7f05273482ea128a ] Currently, the trigger orders SND_SOC_DPCM_TRIGGER_PRE/POST determine the order in which FE DAI and BE DAI are triggered. In the case of SND_SOC_DPCM_TRIGGER_PRE, the FE DAI is triggered before the BE DAI and in the case of SND_SOC_DPCM_TRIGGER_POST, the BE DAI is triggered before the FE DAI. And this order remains the same irrespective of the trigger command. In the case of the SOF driver, during playback, the FW expects the BE DAI to be triggered before the FE DAI during the START trigger. The BE DAI trigger handles the starting of Link DMA and so it must be started before the FE DAI is started to prevent xruns during pause/release. This can be addressed by setting the trigger order for the FE dai link to SND_SOC_DPCM_TRIGGER_POST. But during the STOP trigger, the FW expects the FE DAI to be triggered before the BE DAI. Retaining the same order during the START and STOP commands, results in FW error as the DAI component in the FW is still active. The issue can be fixed by mirroring the trigger order of FE and BE DAI's during the START and STOP trigger. So, with the trigger order set to SND_SOC_DPCM_TRIGGER_PRE, the FE DAI will be trigger first during SNDRV_PCM_TRIGGER_START/STOP/RESUME and the BE DAI will be triggered first during the STOP/SUSPEND/PAUSE commands. Conversely, with the trigger order set to SND_SOC_DPCM_TRIGGER_POST, the BE DAI will be triggered first during the SNDRV_PCM_TRIGGER_START/STOP/RESUME commands and the FE DAI will be triggered first during the SNDRV_PCM_TRIGGER_STOP/SUSPEND/PAUSE commands. Signed-off-by: Ranjani Sridharan Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20191104224812.3393-2-ranjani.sridharan@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin