From: Greg Kroah-Hartman Date: Mon, 26 Feb 2018 16:18:02 +0000 (+0100) Subject: 4.14-stable patches X-Git-Tag: v3.18.97~15 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=a6064fd73aa5ab5036de8b37e7fa391be347a585;p=thirdparty%2Fkernel%2Fstable-queue.git 4.14-stable patches added patches: add-delay-init-quirk-for-corsair-k70-rgb-keyboards.patch arm64-cpufeature-fix-ctr_el0-field-definitions.patch arm64-disable-unhandled-signal-log-messages-by-default.patch arm64-remove-unimplemented-syscall-log-message.patch cfg80211-fix-cfg80211_beacon_dup.patch drm-amdgpu-add-atpx-quirk-handling-v2.patch drm-amdgpu-add-dpm-quirk-for-jet-pro-v2.patch drm-amdgpu-add-new-device-to-use-atpx-quirk.patch drm-amdgpu-avoid-leaking-pm-domain-on-driver-unbind-v2.patch drm-amdgpu-disable-mmhub-power-gating-on-raven.patch drm-amdgpu-only-check-mmbif_iov_func_identifier-on-tonga-fiji.patch drm-cirrus-load-lut-in-crtc_commit.patch drm-edid-add-6-bpc-quirk-for-cpt-panel-in-asus-ux303la.patch drm-handle-unexpected-holes-in-color-eviction.patch extcon-int3496-process-id-pin-first-so-that-we-start-with-the-right-status.patch i2c-bcm2835-set-up-the-rising-falling-edge-delays.patch i2c-designware-must-wait-for-enable.patch iio-adc-stm32-fix-stm32h7_adc_enable-error-handling.patch iio-adis_lib-initialize-trigger-before-requesting-interrupt.patch iio-buffer-check-if-a-buffer-has-been-set-up-when-poll-is-called.patch iio-srf08-fix-link-error-devm_iio_triggered_buffer_setup-undefined.patch irqchip-gic-v3-use-wmb-instead-of-smb_wmb-in-gic_raise_softirq.patch irqchip-mips-gic-avoid-spuriously-handling-masked-interrupts.patch kbuild-always-define-endianess-in-kconfig.h.patch mips-drop-spurious-__unused-in-struct-compat_flock.patch mm-swap-frontswap-fix-thp-swap-if-frontswap-enabled.patch ohci-hcd-fix-race-condition-caused-by-ohci_urb_enqueue-and-io_watchdog_func.patch pci-cxgb4-extend-t3-pci-quirk-to-t4-devices.patch pkcs-7-fix-certificate-blacklisting.patch pkcs-7-fix-certificate-chain-verification.patch rdma-uverbs-fix-bad-unlock-balance-in-ib_uverbs_close_xrcd.patch rdma-uverbs-fix-circular-locking-dependency.patch rdma-uverbs-protect-from-command-mask-overflow.patch rdma-uverbs-protect-from-races-between-lookup-and-destroy-of-uobjects.patch rdma-uverbs-sanitize-user-entered-port-numbers-prior-to-access-it.patch revert-usb-musb-host-don-t-start-next-rx-urb-if-current-one-failed.patch scsi-ibmvfc-fix-misdefined-reserved-field-in-ibmvfc_fcp_rsp_info.patch usb-dwc3-ep0-reset-trb-counter-for-ep0-in.patch usb-dwc3-gadget-set-maxpacket-size-for-ep0-in.patch usb-gadget-f_fs-process-all-descriptors-during-bind.patch usb-gadget-f_fs-use-config_ep_by_speed.patch usb-host-ehci-use-correct-device-pointer-for-dma-ops.patch usb-ldusb-add-pids-for-new-cassy-devices-supported-by-this-driver.patch usb-ohci-proper-handling-of-ed_rm_list-to-handle-race-condition-between-usb_kill_urb-and-finish_unlinks.patch usb-renesas_usbhs-missed-the-running-flag-in-usb_dmac-with-rx-path.patch x.509-fix-bug_on-when-hash-algorithm-is-unsupported.patch x.509-fix-null-dereference-when-restricting-key-with-unsupported_sig.patch x86-oprofile-fix-bogus-gcc-8-warning-in-nmi_setup.patch xtensa-fix-high-memory-reserved-memory-collision.patch --- diff --git a/queue-4.14/add-delay-init-quirk-for-corsair-k70-rgb-keyboards.patch b/queue-4.14/add-delay-init-quirk-for-corsair-k70-rgb-keyboards.patch new file mode 100644 index 00000000000..58ead39c8c1 --- /dev/null +++ b/queue-4.14/add-delay-init-quirk-for-corsair-k70-rgb-keyboards.patch @@ -0,0 +1,38 @@ +From 7a1646d922577b5b48c0d222e03831141664bb59 Mon Sep 17 00:00:00 2001 +From: Jack Stocker +Date: Thu, 15 Feb 2018 18:24:10 +0000 +Subject: Add delay-init quirk for Corsair K70 RGB keyboards + +From: Jack Stocker + +commit 7a1646d922577b5b48c0d222e03831141664bb59 upstream. + +Following on from this patch: https://lkml.org/lkml/2017/11/3/516, +Corsair K70 RGB keyboards also require the DELAY_INIT quirk to +start correctly at boot. + +Device ids found here: +usb 3-3: New USB device found, idVendor=1b1c, idProduct=1b13 +usb 3-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 +usb 3-3: Product: Corsair K70 RGB Gaming Keyboard + +Signed-off-by: Jack Stocker +Cc: stable +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/core/quirks.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/drivers/usb/core/quirks.c ++++ b/drivers/usb/core/quirks.c +@@ -225,6 +225,9 @@ static const struct usb_device_id usb_qu + { USB_DEVICE(0x1a0a, 0x0200), .driver_info = + USB_QUIRK_LINEAR_UFRAME_INTR_BINTERVAL }, + ++ /* Corsair K70 RGB */ ++ { USB_DEVICE(0x1b1c, 0x1b13), .driver_info = USB_QUIRK_DELAY_INIT }, ++ + /* Corsair Strafe RGB */ + { USB_DEVICE(0x1b1c, 0x1b20), .driver_info = USB_QUIRK_DELAY_INIT }, + diff --git a/queue-4.14/arm64-cpufeature-fix-ctr_el0-field-definitions.patch b/queue-4.14/arm64-cpufeature-fix-ctr_el0-field-definitions.patch new file mode 100644 index 00000000000..4bfb9a3b270 --- /dev/null +++ b/queue-4.14/arm64-cpufeature-fix-ctr_el0-field-definitions.patch @@ -0,0 +1,47 @@ +From be68a8aaf925aaf35574260bf820bb09d2f9e07f Mon Sep 17 00:00:00 2001 +From: Will Deacon +Date: Mon, 19 Feb 2018 14:41:44 +0000 +Subject: arm64: cpufeature: Fix CTR_EL0 field definitions + +From: Will Deacon + +commit be68a8aaf925aaf35574260bf820bb09d2f9e07f upstream. + +Our field definitions for CTR_EL0 suffer from a number of problems: + + - The IDC and DIC fields are missing, which causes us to enable CTR + trapping on CPUs with either of these returning non-zero values. + + - The ERG is FTR_LOWER_SAFE, whereas it should be treated like CWG as + FTR_HIGHER_SAFE so that applications can use it to avoid false sharing. + + - [nit] A RES1 field is described as "RAO" + +This patch updates the CTR_EL0 field definitions to fix these issues. + +Cc: +Cc: Shanker Donthineni +Signed-off-by: Will Deacon +Signed-off-by: Catalin Marinas +Signed-off-by: Greg Kroah-Hartman + +--- + arch/arm64/kernel/cpufeature.c | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +--- a/arch/arm64/kernel/cpufeature.c ++++ b/arch/arm64/kernel/cpufeature.c +@@ -175,9 +175,11 @@ static const struct arm64_ftr_bits ftr_i + }; + + static const struct arm64_ftr_bits ftr_ctr[] = { +- ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_EXACT, 31, 1, 1), /* RAO */ ++ ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_EXACT, 31, 1, 1), /* RES1 */ ++ ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, 29, 1, 1), /* DIC */ ++ ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, 28, 1, 1), /* IDC */ + ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_HIGHER_SAFE, 24, 4, 0), /* CWG */ +- ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, 20, 4, 0), /* ERG */ ++ ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_HIGHER_SAFE, 20, 4, 0), /* ERG */ + ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, 16, 4, 1), /* DminLine */ + /* + * Linux can handle differing I-cache policies. Userspace JITs will diff --git a/queue-4.14/arm64-disable-unhandled-signal-log-messages-by-default.patch b/queue-4.14/arm64-disable-unhandled-signal-log-messages-by-default.patch new file mode 100644 index 00000000000..bd59530925f --- /dev/null +++ b/queue-4.14/arm64-disable-unhandled-signal-log-messages-by-default.patch @@ -0,0 +1,59 @@ +From 5ee39a71fd89ab7240c5339d04161c44a8e03269 Mon Sep 17 00:00:00 2001 +From: Michael Weiser +Date: Thu, 1 Feb 2018 23:13:38 +0100 +Subject: arm64: Disable unhandled signal log messages by default + +From: Michael Weiser + +commit 5ee39a71fd89ab7240c5339d04161c44a8e03269 upstream. + +aarch64 unhandled signal kernel messages are very verbose, suggesting +them to be more of a debugging aid: + +sigsegv[33]: unhandled level 2 translation fault (11) at 0x00000000, esr +0x92000046, in sigsegv[400000+71000] +CPU: 1 PID: 33 Comm: sigsegv Tainted: G W 4.15.0-rc3+ #3 +Hardware name: linux,dummy-virt (DT) +pstate: 60000000 (nZCv daif -PAN -UAO) +pc : 0x4003f4 +lr : 0x4006bc +sp : 0000fffffe94a060 +x29: 0000fffffe94a070 x28: 0000000000000000 +x27: 0000000000000000 x26: 0000000000000000 +x25: 0000000000000000 x24: 00000000004001b0 +x23: 0000000000486ac8 x22: 00000000004001c8 +x21: 0000000000000000 x20: 0000000000400be8 +x19: 0000000000400b30 x18: 0000000000484728 +x17: 000000000865ffc8 x16: 000000000000270f +x15: 00000000000000b0 x14: 0000000000000002 +x13: 0000000000000001 x12: 0000000000000000 +x11: 0000000000000000 x10: 0008000020008008 +x9 : 000000000000000f x8 : ffffffffffffffff +x7 : 0004000000000000 x6 : ffffffffffffffff +x5 : 0000000000000000 x4 : 0000000000000000 +x3 : 00000000004003e4 x2 : 0000fffffe94a1e8 +x1 : 000000000000000a x0 : 0000000000000000 + +Disable them by default, so they can be enabled using +/proc/sys/debug/exception-trace. + +Cc: +Signed-off-by: Michael Weiser +Signed-off-by: Will Deacon +Signed-off-by: Greg Kroah-Hartman + +--- + arch/arm64/kernel/traps.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/arm64/kernel/traps.c ++++ b/arch/arm64/kernel/traps.c +@@ -56,7 +56,7 @@ static const char *handler[]= { + "Error" + }; + +-int show_unhandled_signals = 1; ++int show_unhandled_signals = 0; + + /* + * Dump out the contents of some kernel memory nicely... diff --git a/queue-4.14/arm64-remove-unimplemented-syscall-log-message.patch b/queue-4.14/arm64-remove-unimplemented-syscall-log-message.patch new file mode 100644 index 00000000000..5fa6ab57238 --- /dev/null +++ b/queue-4.14/arm64-remove-unimplemented-syscall-log-message.patch @@ -0,0 +1,44 @@ +From 1962682d2b2fbe6cfa995a85c53c069fadda473e Mon Sep 17 00:00:00 2001 +From: Michael Weiser +Date: Thu, 1 Feb 2018 23:13:36 +0100 +Subject: arm64: Remove unimplemented syscall log message + +From: Michael Weiser + +commit 1962682d2b2fbe6cfa995a85c53c069fadda473e upstream. + +Stop printing a (ratelimited) kernel message for each instance of an +unimplemented syscall being called. Userland making an unimplemented +syscall is not necessarily misbehaviour and to be expected with a +current userland running on an older kernel. Also, the current message +looks scary to users but does not actually indicate a real problem nor +help them narrow down the cause. Just rely on sys_ni_syscall() to return +-ENOSYS. + +Cc: +Acked-by: Will Deacon +Signed-off-by: Michael Weiser +Signed-off-by: Will Deacon +Signed-off-by: Greg Kroah-Hartman + +--- + arch/arm64/kernel/traps.c | 8 -------- + 1 file changed, 8 deletions(-) + +--- a/arch/arm64/kernel/traps.c ++++ b/arch/arm64/kernel/traps.c +@@ -573,14 +573,6 @@ asmlinkage long do_ni_syscall(struct pt_ + } + #endif + +- if (show_unhandled_signals_ratelimited()) { +- pr_info("%s[%d]: syscall %d\n", current->comm, +- task_pid_nr(current), regs->syscallno); +- dump_instr("", regs); +- if (user_mode(regs)) +- __show_regs(regs); +- } +- + return sys_ni_syscall(); + } + diff --git a/queue-4.14/cfg80211-fix-cfg80211_beacon_dup.patch b/queue-4.14/cfg80211-fix-cfg80211_beacon_dup.patch new file mode 100644 index 00000000000..e6b754e5793 --- /dev/null +++ b/queue-4.14/cfg80211-fix-cfg80211_beacon_dup.patch @@ -0,0 +1,38 @@ +From bee92d06157fc39d5d7836a061c7d41289a55797 Mon Sep 17 00:00:00 2001 +From: Arnd Bergmann +Date: Fri, 2 Feb 2018 16:31:23 +0100 +Subject: cfg80211: fix cfg80211_beacon_dup + +From: Arnd Bergmann + +commit bee92d06157fc39d5d7836a061c7d41289a55797 upstream. + +gcc-8 warns about some obviously incorrect code: + +net/mac80211/cfg.c: In function 'cfg80211_beacon_dup': +net/mac80211/cfg.c:2896:3: error: 'memcpy' source argument is the same as destination [-Werror=restrict] + +From the context, I conclude that we want to copy from beacon into +new_beacon, as we do in the rest of the function. + +Cc: stable@vger.kernel.org +Fixes: 73da7d5bab79 ("mac80211: add channel switch command and beacon callbacks") +Signed-off-by: Arnd Bergmann +Signed-off-by: Johannes Berg +Signed-off-by: Greg Kroah-Hartman + +--- + net/mac80211/cfg.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/net/mac80211/cfg.c ++++ b/net/mac80211/cfg.c +@@ -2863,7 +2863,7 @@ cfg80211_beacon_dup(struct cfg80211_beac + } + if (beacon->probe_resp_len) { + new_beacon->probe_resp_len = beacon->probe_resp_len; +- beacon->probe_resp = pos; ++ new_beacon->probe_resp = pos; + memcpy(pos, beacon->probe_resp, beacon->probe_resp_len); + pos += beacon->probe_resp_len; + } diff --git a/queue-4.14/drm-amdgpu-add-atpx-quirk-handling-v2.patch b/queue-4.14/drm-amdgpu-add-atpx-quirk-handling-v2.patch new file mode 100644 index 00000000000..44fc98a39f7 --- /dev/null +++ b/queue-4.14/drm-amdgpu-add-atpx-quirk-handling-v2.patch @@ -0,0 +1,131 @@ +From 052c299080cd6859f82a8154a7a673fafabe644c Mon Sep 17 00:00:00 2001 +From: Alex Deucher +Date: Wed, 20 Dec 2017 13:29:58 -0500 +Subject: drm/amdgpu: add atpx quirk handling (v2) +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Alex Deucher + +commit 052c299080cd6859f82a8154a7a673fafabe644c upstream. + +Add quirks for handling PX/HG systems. In this case, add +a quirk for a weston dGPU that only seems to properly power +down using ATPX power control rather than HG (_PR3). + +v2: append a new weston XT + +Signed-off-by: Alex Deucher +Signed-off-by: Junwei Zhang (v2) +Reviewed-and-Tested-by: Junwei Zhang +Reviewed-by: Alex Deucher +Acked-by: Christian König +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 57 ++++++++++++++++++++--- + 1 file changed, 50 insertions(+), 7 deletions(-) + +--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c ++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c +@@ -14,6 +14,16 @@ + + #include "amd_acpi.h" + ++#define AMDGPU_PX_QUIRK_FORCE_ATPX (1 << 0) ++ ++struct amdgpu_px_quirk { ++ u32 chip_vendor; ++ u32 chip_device; ++ u32 subsys_vendor; ++ u32 subsys_device; ++ u32 px_quirk_flags; ++}; ++ + struct amdgpu_atpx_functions { + bool px_params; + bool power_cntl; +@@ -35,6 +45,7 @@ struct amdgpu_atpx { + static struct amdgpu_atpx_priv { + bool atpx_detected; + bool bridge_pm_usable; ++ unsigned int quirks; + /* handle for device - and atpx */ + acpi_handle dhandle; + acpi_handle other_handle; +@@ -205,13 +216,19 @@ static int amdgpu_atpx_validate(struct a + + atpx->is_hybrid = false; + if (valid_bits & ATPX_MS_HYBRID_GFX_SUPPORTED) { +- printk("ATPX Hybrid Graphics\n"); +- /* +- * Disable legacy PM methods only when pcie port PM is usable, +- * otherwise the device might fail to power off or power on. +- */ +- atpx->functions.power_cntl = !amdgpu_atpx_priv.bridge_pm_usable; +- atpx->is_hybrid = true; ++ if (amdgpu_atpx_priv.quirks & AMDGPU_PX_QUIRK_FORCE_ATPX) { ++ printk("ATPX Hybrid Graphics, forcing to ATPX\n"); ++ atpx->functions.power_cntl = true; ++ atpx->is_hybrid = false; ++ } else { ++ printk("ATPX Hybrid Graphics\n"); ++ /* ++ * Disable legacy PM methods only when pcie port PM is usable, ++ * otherwise the device might fail to power off or power on. ++ */ ++ atpx->functions.power_cntl = !amdgpu_atpx_priv.bridge_pm_usable; ++ atpx->is_hybrid = true; ++ } + } + + atpx->dgpu_req_power_for_displays = false; +@@ -547,6 +564,30 @@ static const struct vga_switcheroo_handl + .get_client_id = amdgpu_atpx_get_client_id, + }; + ++static const struct amdgpu_px_quirk amdgpu_px_quirk_list[] = { ++ /* HG _PR3 doesn't seem to work on this A+A weston board */ ++ { 0x1002, 0x6900, 0x1002, 0x0124, AMDGPU_PX_QUIRK_FORCE_ATPX }, ++ { 0x1002, 0x6900, 0x1028, 0x0812, AMDGPU_PX_QUIRK_FORCE_ATPX }, ++ { 0, 0, 0, 0, 0 }, ++}; ++ ++static void amdgpu_atpx_get_quirks(struct pci_dev *pdev) ++{ ++ const struct amdgpu_px_quirk *p = amdgpu_px_quirk_list; ++ ++ /* Apply PX quirks */ ++ while (p && p->chip_device != 0) { ++ if (pdev->vendor == p->chip_vendor && ++ pdev->device == p->chip_device && ++ pdev->subsystem_vendor == p->subsys_vendor && ++ pdev->subsystem_device == p->subsys_device) { ++ amdgpu_atpx_priv.quirks |= p->px_quirk_flags; ++ break; ++ } ++ ++p; ++ } ++} ++ + /** + * amdgpu_atpx_detect - detect whether we have PX + * +@@ -570,6 +611,7 @@ static bool amdgpu_atpx_detect(void) + + parent_pdev = pci_upstream_bridge(pdev); + d3_supported |= parent_pdev && parent_pdev->bridge_d3; ++ amdgpu_atpx_get_quirks(pdev); + } + + while ((pdev = pci_get_class(PCI_CLASS_DISPLAY_OTHER << 8, pdev)) != NULL) { +@@ -579,6 +621,7 @@ static bool amdgpu_atpx_detect(void) + + parent_pdev = pci_upstream_bridge(pdev); + d3_supported |= parent_pdev && parent_pdev->bridge_d3; ++ amdgpu_atpx_get_quirks(pdev); + } + + if (has_atpx && vga_count == 2) { diff --git a/queue-4.14/drm-amdgpu-add-dpm-quirk-for-jet-pro-v2.patch b/queue-4.14/drm-amdgpu-add-dpm-quirk-for-jet-pro-v2.patch new file mode 100644 index 00000000000..eddde5ac0af --- /dev/null +++ b/queue-4.14/drm-amdgpu-add-dpm-quirk-for-jet-pro-v2.patch @@ -0,0 +1,40 @@ +From f2e5262f75ecb40a6e56554e156a292ab9e1d1b7 Mon Sep 17 00:00:00 2001 +From: Alex Deucher +Date: Tue, 21 Nov 2017 12:10:57 -0500 +Subject: drm/amdgpu: Add dpm quirk for Jet PRO (v2) +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Alex Deucher + +commit f2e5262f75ecb40a6e56554e156a292ab9e1d1b7 upstream. + +Fixes stability issues. + +v2: clamp sclk to 600 Mhz + +Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103370 +Acked-by: Christian König +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/amd/amdgpu/si_dpm.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/drivers/gpu/drm/amd/amdgpu/si_dpm.c ++++ b/drivers/gpu/drm/amd/amdgpu/si_dpm.c +@@ -3465,6 +3465,11 @@ static void si_apply_state_adjust_rules( + (adev->pdev->device == 0x6667)) { + max_sclk = 75000; + } ++ if ((adev->pdev->revision == 0xC3) || ++ (adev->pdev->device == 0x6665)) { ++ max_sclk = 60000; ++ max_mclk = 80000; ++ } + } else if (adev->asic_type == CHIP_OLAND) { + if ((adev->pdev->revision == 0xC7) || + (adev->pdev->revision == 0x80) || diff --git a/queue-4.14/drm-amdgpu-add-new-device-to-use-atpx-quirk.patch b/queue-4.14/drm-amdgpu-add-new-device-to-use-atpx-quirk.patch new file mode 100644 index 00000000000..0903bcfdb34 --- /dev/null +++ b/queue-4.14/drm-amdgpu-add-new-device-to-use-atpx-quirk.patch @@ -0,0 +1,31 @@ +From 6e59de2048eb375a9bfcd39461ef841cd2a78962 Mon Sep 17 00:00:00 2001 +From: Kai-Heng Feng +Date: Thu, 8 Feb 2018 17:46:01 +0800 +Subject: drm/amdgpu: add new device to use atpx quirk + +From: Kai-Heng Feng + +commit 6e59de2048eb375a9bfcd39461ef841cd2a78962 upstream. + +The affected system (0x0813) is pretty similar to another one (0x0812), +it also needs to use ATPX power control. + +Signed-off-by: Kai-Heng Feng +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c ++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c +@@ -568,6 +568,7 @@ static const struct amdgpu_px_quirk amdg + /* HG _PR3 doesn't seem to work on this A+A weston board */ + { 0x1002, 0x6900, 0x1002, 0x0124, AMDGPU_PX_QUIRK_FORCE_ATPX }, + { 0x1002, 0x6900, 0x1028, 0x0812, AMDGPU_PX_QUIRK_FORCE_ATPX }, ++ { 0x1002, 0x6900, 0x1028, 0x0813, AMDGPU_PX_QUIRK_FORCE_ATPX }, + { 0, 0, 0, 0, 0 }, + }; + diff --git a/queue-4.14/drm-amdgpu-avoid-leaking-pm-domain-on-driver-unbind-v2.patch b/queue-4.14/drm-amdgpu-avoid-leaking-pm-domain-on-driver-unbind-v2.patch new file mode 100644 index 00000000000..325d92487d3 --- /dev/null +++ b/queue-4.14/drm-amdgpu-avoid-leaking-pm-domain-on-driver-unbind-v2.patch @@ -0,0 +1,40 @@ +From 458d876eb869d5a88b53074c6c271b8b9adc0f07 Mon Sep 17 00:00:00 2001 +From: Alex Deucher +Date: Mon, 22 Jan 2018 23:13:32 -0500 +Subject: drm/amdgpu: Avoid leaking PM domain on driver unbind (v2) + +From: Alex Deucher + +commit 458d876eb869d5a88b53074c6c271b8b9adc0f07 upstream. + +We only support vga_switcheroo and runtime pm on PX/HG systems +so forcing runpm to 1 doesn't do anything useful anyway. + +Only call vga_switcheroo_init_domain_pm_ops() for PX/HG so +that the cleanup path is correct as well. This mirrors what +radeon does as well. + +v2: rework the patch originally sent by Lukas (Alex) + +Acked-by: Lukas Wunner +Reported-by: Lukas Wunner +Signed-off-by: Alex Deucher +Signed-off-by: Lukas Wunner (v1) +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 -- + 1 file changed, 2 deletions(-) + +--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c ++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +@@ -2076,8 +2076,6 @@ int amdgpu_device_init(struct amdgpu_dev + * ignore it */ + vga_client_register(adev->pdev, adev, NULL, amdgpu_vga_set_decode); + +- if (amdgpu_runtime_pm == 1) +- runtime = true; + if (amdgpu_device_is_px(ddev)) + runtime = true; + if (!pci_is_thunderbolt_attached(adev->pdev)) diff --git a/queue-4.14/drm-amdgpu-disable-mmhub-power-gating-on-raven.patch b/queue-4.14/drm-amdgpu-disable-mmhub-power-gating-on-raven.patch new file mode 100644 index 00000000000..d6e54bb8e0e --- /dev/null +++ b/queue-4.14/drm-amdgpu-disable-mmhub-power-gating-on-raven.patch @@ -0,0 +1,36 @@ +From 400b6afbaa949914460e5fd1d769c5e26ef1f6b8 Mon Sep 17 00:00:00 2001 +From: Huang Rui +Date: Thu, 14 Dec 2017 13:47:16 +0800 +Subject: drm/amdgpu: disable MMHUB power gating on raven + +From: Huang Rui + +commit 400b6afbaa949914460e5fd1d769c5e26ef1f6b8 upstream. + +MMHUB power gating still has issue, and doesn't work on raven at current. So +disable it for the moment. + +Signed-off-by: Huang Rui +Acked-by: Hawking Zhang +Acked-by: Alex Deucher +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/amd/amdgpu/soc15.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/gpu/drm/amd/amdgpu/soc15.c ++++ b/drivers/gpu/drm/amd/amdgpu/soc15.c +@@ -661,8 +661,8 @@ static int soc15_common_early_init(void + AMD_CG_SUPPORT_MC_LS | + AMD_CG_SUPPORT_SDMA_MGCG | + AMD_CG_SUPPORT_SDMA_LS; +- adev->pg_flags = AMD_PG_SUPPORT_SDMA | +- AMD_PG_SUPPORT_MMHUB; ++ adev->pg_flags = AMD_PG_SUPPORT_SDMA; ++ + adev->external_rev_id = 0x1; + break; + default: diff --git a/queue-4.14/drm-amdgpu-only-check-mmbif_iov_func_identifier-on-tonga-fiji.patch b/queue-4.14/drm-amdgpu-only-check-mmbif_iov_func_identifier-on-tonga-fiji.patch new file mode 100644 index 00000000000..c1ce0e85bb8 --- /dev/null +++ b/queue-4.14/drm-amdgpu-only-check-mmbif_iov_func_identifier-on-tonga-fiji.patch @@ -0,0 +1,51 @@ +From 57ad33a307bf85cafda3a77c03a555c9f9ee4139 Mon Sep 17 00:00:00 2001 +From: Alex Deucher +Date: Tue, 19 Dec 2017 09:52:31 -0500 +Subject: drm/amdgpu: only check mmBIF_IOV_FUNC_IDENTIFIER on tonga/fiji + +From: Alex Deucher + +commit 57ad33a307bf85cafda3a77c03a555c9f9ee4139 upstream. + +We only support SR-IOV on tonga/fiji. Don't check this register +on other VI parts. + +Fixes: 048765ad5af7c89 (amdgpu: fix asic initialization for virtualized environments (v2)) +Reviewed-by: Xiangliang Yu +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/amd/amdgpu/vi.c | 19 ++++++++++++------- + 1 file changed, 12 insertions(+), 7 deletions(-) + +--- a/drivers/gpu/drm/amd/amdgpu/vi.c ++++ b/drivers/gpu/drm/amd/amdgpu/vi.c +@@ -448,14 +448,19 @@ static bool vi_read_bios_from_rom(struct + + static void vi_detect_hw_virtualization(struct amdgpu_device *adev) + { +- uint32_t reg = RREG32(mmBIF_IOV_FUNC_IDENTIFIER); +- /* bit0: 0 means pf and 1 means vf */ +- /* bit31: 0 means disable IOV and 1 means enable */ +- if (reg & 1) +- adev->virt.caps |= AMDGPU_SRIOV_CAPS_IS_VF; ++ uint32_t reg = 0; + +- if (reg & 0x80000000) +- adev->virt.caps |= AMDGPU_SRIOV_CAPS_ENABLE_IOV; ++ if (adev->asic_type == CHIP_TONGA || ++ adev->asic_type == CHIP_FIJI) { ++ reg = RREG32(mmBIF_IOV_FUNC_IDENTIFIER); ++ /* bit0: 0 means pf and 1 means vf */ ++ /* bit31: 0 means disable IOV and 1 means enable */ ++ if (reg & 1) ++ adev->virt.caps |= AMDGPU_SRIOV_CAPS_IS_VF; ++ ++ if (reg & 0x80000000) ++ adev->virt.caps |= AMDGPU_SRIOV_CAPS_ENABLE_IOV; ++ } + + if (reg == 0) { + if (is_virtual_machine()) /* passthrough mode exclus sr-iov mode */ diff --git a/queue-4.14/drm-cirrus-load-lut-in-crtc_commit.patch b/queue-4.14/drm-cirrus-load-lut-in-crtc_commit.patch new file mode 100644 index 00000000000..9bf56a1a9bf --- /dev/null +++ b/queue-4.14/drm-cirrus-load-lut-in-crtc_commit.patch @@ -0,0 +1,98 @@ +From 745fd50f3b044db6a3922e1718306555613164b0 Mon Sep 17 00:00:00 2001 +From: Daniel Vetter +Date: Wed, 31 Jan 2018 12:04:50 +0100 +Subject: drm/cirrus: Load lut in crtc_commit + +From: Daniel Vetter + +commit 745fd50f3b044db6a3922e1718306555613164b0 upstream. + +In the past the ast driver relied upon the fbdev emulation helpers to +call ->load_lut at boot-up. But since + +commit b8e2b0199cc377617dc238f5106352c06dcd3fa2 +Author: Peter Rosin +Date: Tue Jul 4 12:36:57 2017 +0200 + +drm/fb-helper: factor out pseudo-palette + +that's cleaned up and drivers are expected to boot into a consistent +lut state. This patch fixes that. + +Fixes: b8e2b0199cc3 ("drm/fb-helper: factor out pseudo-palette") +Cc: Peter Rosin +Cc: Daniel Vetter +Cc: # v4.14+ +References: https://bugzilla.kernel.org/show_bug.cgi?id=198123 +Signed-off-by: Daniel Vetter +Link: http://patchwork.freedesktop.org/patch/msgid/20180131110450.22153-1-daniel.vetter@ffwll.ch +Signed-off-by: Gerd Hoffmann +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/cirrus/cirrus_mode.c | 40 ++++++++++++++++++++--------------- + 1 file changed, 23 insertions(+), 17 deletions(-) + +--- a/drivers/gpu/drm/cirrus/cirrus_mode.c ++++ b/drivers/gpu/drm/cirrus/cirrus_mode.c +@@ -294,22 +294,7 @@ static void cirrus_crtc_prepare(struct d + { + } + +-/* +- * This is called after a mode is programmed. It should reverse anything done +- * by the prepare function +- */ +-static void cirrus_crtc_commit(struct drm_crtc *crtc) +-{ +-} +- +-/* +- * The core can pass us a set of gamma values to program. We actually only +- * use this for 8-bit mode so can't perform smooth fades on deeper modes, +- * but it's a requirement that we provide the function +- */ +-static int cirrus_crtc_gamma_set(struct drm_crtc *crtc, u16 *red, u16 *green, +- u16 *blue, uint32_t size, +- struct drm_modeset_acquire_ctx *ctx) ++static void cirrus_crtc_load_lut(struct drm_crtc *crtc) + { + struct drm_device *dev = crtc->dev; + struct cirrus_device *cdev = dev->dev_private; +@@ -317,7 +302,7 @@ static int cirrus_crtc_gamma_set(struct + int i; + + if (!crtc->enabled) +- return 0; ++ return; + + r = crtc->gamma_store; + g = r + crtc->gamma_size; +@@ -330,6 +315,27 @@ static int cirrus_crtc_gamma_set(struct + WREG8(PALETTE_DATA, *g++ >> 8); + WREG8(PALETTE_DATA, *b++ >> 8); + } ++} ++ ++/* ++ * This is called after a mode is programmed. It should reverse anything done ++ * by the prepare function ++ */ ++static void cirrus_crtc_commit(struct drm_crtc *crtc) ++{ ++ cirrus_crtc_load_lut(crtc); ++} ++ ++/* ++ * The core can pass us a set of gamma values to program. We actually only ++ * use this for 8-bit mode so can't perform smooth fades on deeper modes, ++ * but it's a requirement that we provide the function ++ */ ++static int cirrus_crtc_gamma_set(struct drm_crtc *crtc, u16 *red, u16 *green, ++ u16 *blue, uint32_t size, ++ struct drm_modeset_acquire_ctx *ctx) ++{ ++ cirrus_crtc_load_lut(crtc); + + return 0; + } diff --git a/queue-4.14/drm-edid-add-6-bpc-quirk-for-cpt-panel-in-asus-ux303la.patch b/queue-4.14/drm-edid-add-6-bpc-quirk-for-cpt-panel-in-asus-ux303la.patch new file mode 100644 index 00000000000..378050dcf22 --- /dev/null +++ b/queue-4.14/drm-edid-add-6-bpc-quirk-for-cpt-panel-in-asus-ux303la.patch @@ -0,0 +1,40 @@ +From 06998a756a3865817b87a129a7e5d5bb66dc1ec3 Mon Sep 17 00:00:00 2001 +From: Kai-Heng Feng +Date: Sun, 18 Feb 2018 16:53:59 +0800 +Subject: drm/edid: Add 6 bpc quirk for CPT panel in Asus UX303LA + +From: Kai-Heng Feng + +commit 06998a756a3865817b87a129a7e5d5bb66dc1ec3 upstream. + +Similar to commit e10aec652f31 ("drm/edid: Add 6 bpc quirk for display +AEO model 0."), the EDID reports "DFP 1.x compliant TMDS" but it support +6bpc instead of 8 bpc. + +Hence, use 6 bpc quirk for this panel. + +Fixes: 196f954e2509 ("drm/i915/dp: Revert "drm/i915/dp: fall back to 18 bpp when sink capability is unknown"") +BugLink: https://bugs.launchpad.net/bugs/1749420 +Signed-off-by: Kai-Heng Feng +Reviewed-by: Mario Kleiner +Cc: # v4.8+ +Signed-off-by: Daniel Vetter +Link: https://patchwork.freedesktop.org/patch/msgid/20180218085359.7817-1-kai.heng.feng@canonical.com +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/drm_edid.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/drivers/gpu/drm/drm_edid.c ++++ b/drivers/gpu/drm/drm_edid.c +@@ -111,6 +111,9 @@ static const struct edid_quirk { + /* AEO model 0 reports 8 bpc, but is a 6 bpc panel */ + { "AEO", 0, EDID_QUIRK_FORCE_6BPC }, + ++ /* CPT panel of Asus UX303LA reports 8 bpc, but is a 6 bpc panel */ ++ { "CPT", 0x17df, EDID_QUIRK_FORCE_6BPC }, ++ + /* Belinea 10 15 55 */ + { "MAX", 1516, EDID_QUIRK_PREFER_LARGE_60 }, + { "MAX", 0x77e, EDID_QUIRK_PREFER_LARGE_60 }, diff --git a/queue-4.14/drm-handle-unexpected-holes-in-color-eviction.patch b/queue-4.14/drm-handle-unexpected-holes-in-color-eviction.patch new file mode 100644 index 00000000000..47d662c4d3f --- /dev/null +++ b/queue-4.14/drm-handle-unexpected-holes-in-color-eviction.patch @@ -0,0 +1,130 @@ +From b8ff1802815913aad52695898cccbc9f77b7e726 Mon Sep 17 00:00:00 2001 +From: Chris Wilson +Date: Mon, 19 Feb 2018 11:35:43 +0000 +Subject: drm: Handle unexpected holes in color-eviction + +From: Chris Wilson + +commit b8ff1802815913aad52695898cccbc9f77b7e726 upstream. + +During eviction, the driver may free more than one hole in the drm_mm +due to the side-effects in evicting the scanned nodes. However, +drm_mm_scan_color_evict() expects that the scan result is the first +available hole (in the mru freed hole_stack list): + + kernel BUG at drivers/gpu/drm/drm_mm.c:844! + invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI + Dumping ftrace buffer: + (ftrace buffer empty) + Modules linked in: i915 snd_hda_codec_analog snd_hda_codec_generic coretemp snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core lpc_ich snd_pcm e1000e mei_me prime_numbers mei + CPU: 1 PID: 1490 Comm: gem_userptr_bli Tainted: G U 4.16.0-rc1-g740f57c54ecf-kasan_6+ #1 + Hardware name: Dell Inc. OptiPlex 755 /0PU052, BIOS A08 02/19/2008 + RIP: 0010:drm_mm_scan_color_evict+0x2b8/0x3d0 + RSP: 0018:ffff880057a573f8 EFLAGS: 00010287 + RAX: ffff8800611f5980 RBX: ffff880057a575d0 RCX: dffffc0000000000 + RDX: 00000000029d5000 RSI: 1ffff1000af4aec1 RDI: ffff8800611f5a10 + RBP: ffff88005ab884d0 R08: ffff880057a57600 R09: 000000000afff000 + R10: 1ffff1000b5710b5 R11: 0000000000001000 R12: 1ffff1000af4ae82 + R13: ffff8800611f59b0 R14: ffff8800611f5980 R15: ffff880057a57608 + FS: 00007f2de0c2e8c0(0000) GS:ffff88006ac40000(0000) knlGS:0000000000000000 + CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 + CR2: 00007f2ddde1e000 CR3: 00000000609b2000 CR4: 00000000000006e0 + Call Trace: + ? drm_mm_scan_remove_block+0x330/0x330 + ? drm_mm_scan_remove_block+0x151/0x330 + i915_gem_evict_something+0x711/0xbd0 [i915] + ? igt_evict_contexts+0x50/0x50 [i915] + ? nop_clear_range+0x10/0x10 [i915] + ? igt_evict_something+0x90/0x90 [i915] + ? i915_gem_gtt_reserve+0x1a1/0x320 [i915] + i915_gem_gtt_insert+0x237/0x400 [i915] + __i915_vma_do_pin+0xc25/0x1a20 [i915] + eb_lookup_vmas+0x1c63/0x3790 [i915] + ? i915_gem_check_execbuffer+0x250/0x250 [i915] + ? trace_hardirqs_on_caller+0x33f/0x590 + ? _raw_spin_unlock_irqrestore+0x39/0x60 + ? __pm_runtime_resume+0x7d/0xf0 + i915_gem_do_execbuffer+0x86a/0x2ff0 [i915] + ? __kmalloc+0x132/0x340 + ? i915_gem_execbuffer2_ioctl+0x10f/0x760 [i915] + ? drm_ioctl_kernel+0x12e/0x1c0 + ? drm_ioctl+0x662/0x980 + ? eb_relocate_slow+0xa90/0xa90 [i915] + ? i915_gem_execbuffer2_ioctl+0x10f/0x760 [i915] + ? __might_fault+0xea/0x1a0 + i915_gem_execbuffer2_ioctl+0x3cc/0x760 [i915] + ? i915_gem_execbuffer_ioctl+0xba0/0xba0 [i915] + ? lock_acquire+0x3c0/0x3c0 + ? i915_gem_execbuffer_ioctl+0xba0/0xba0 [i915] + drm_ioctl_kernel+0x12e/0x1c0 + drm_ioctl+0x662/0x980 + ? i915_gem_execbuffer_ioctl+0xba0/0xba0 [i915] + ? drm_getstats+0x20/0x20 + ? debug_check_no_obj_freed+0x2a6/0x8c0 + do_vfs_ioctl+0x170/0xe70 + ? ioctl_preallocate+0x170/0x170 + ? task_work_run+0xbe/0x160 + ? lock_acquire+0x3c0/0x3c0 + ? trace_hardirqs_on_caller+0x33f/0x590 + ? _raw_spin_unlock_irq+0x2f/0x50 + SyS_ioctl+0x36/0x70 + ? do_vfs_ioctl+0xe70/0xe70 + do_syscall_64+0x18c/0x5d0 + entry_SYSCALL_64_after_hwframe+0x26/0x9b + RIP: 0033:0x7f2ddf13b587 + RSP: 002b:00007fff15c4f9d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 + RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f2ddf13b587 + RDX: 00007fff15c4fa20 RSI: 0000000040406469 RDI: 0000000000000003 + RBP: 00007fff15c4fa20 R08: 0000000000000000 R09: 00007f2ddf3fe120 + R10: 0000000000000073 R11: 0000000000000246 R12: 0000000040406469 + R13: 0000000000000003 R14: 00007fff15c4fa20 R15: 00000000000000c7 + Code: 00 00 00 4a c7 44 22 08 00 00 00 00 42 c7 44 22 10 00 00 00 00 48 81 c4 b8 00 00 00 5b 5d 41 5c 41 5d 41 5e 41 5f c3 0f 0b 0f 0b <0f> 0b 31 c0 eb c0 4c 89 ef e8 9a 09 41 ff e9 1e fe ff ff 4c 89 + RIP: drm_mm_scan_color_evict+0x2b8/0x3d0 RSP: ffff880057a573f8 + +We can trivially relax this assumption by searching the hole_stack for +the scan result and warn instead if the driver called us without any +result. + +Fixes: 3fa489dabea9 ("drm: Apply tight eviction scanning to color_adjust") +Signed-off-by: Chris Wilson +Cc: Joonas Lahtinen +Cc: # v4.11+ +Reviewed-by: Joonas Lahtinen +Reviewed-by: Daniel Vetter +Link: https://patchwork.freedesktop.org/patch/msgid/20180219113543.8010-1-chris@chris-wilson.co.uk +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/drm_mm.c | 21 ++++++++++++++++++--- + 1 file changed, 18 insertions(+), 3 deletions(-) + +--- a/drivers/gpu/drm/drm_mm.c ++++ b/drivers/gpu/drm/drm_mm.c +@@ -834,9 +834,24 @@ struct drm_mm_node *drm_mm_scan_color_ev + if (!mm->color_adjust) + return NULL; + +- hole = list_first_entry(&mm->hole_stack, typeof(*hole), hole_stack); +- hole_start = __drm_mm_hole_node_start(hole); +- hole_end = hole_start + hole->hole_size; ++ /* ++ * The hole found during scanning should ideally be the first element ++ * in the hole_stack list, but due to side-effects in the driver it ++ * may not be. ++ */ ++ list_for_each_entry(hole, &mm->hole_stack, hole_stack) { ++ hole_start = __drm_mm_hole_node_start(hole); ++ hole_end = hole_start + hole->hole_size; ++ ++ if (hole_start <= scan->hit_start && ++ hole_end >= scan->hit_end) ++ break; ++ } ++ ++ /* We should only be called after we found the hole previously */ ++ DRM_MM_BUG_ON(&hole->hole_stack == &mm->hole_stack); ++ if (unlikely(&hole->hole_stack == &mm->hole_stack)) ++ return NULL; + + DRM_MM_BUG_ON(hole_start > scan->hit_start); + DRM_MM_BUG_ON(hole_end < scan->hit_end); diff --git a/queue-4.14/extcon-int3496-process-id-pin-first-so-that-we-start-with-the-right-status.patch b/queue-4.14/extcon-int3496-process-id-pin-first-so-that-we-start-with-the-right-status.patch new file mode 100644 index 00000000000..27be140a055 --- /dev/null +++ b/queue-4.14/extcon-int3496-process-id-pin-first-so-that-we-start-with-the-right-status.patch @@ -0,0 +1,43 @@ +From 0434352d3d2e950cf5e743f6062abd87de22f960 Mon Sep 17 00:00:00 2001 +From: Hans de Goede +Date: Tue, 13 Feb 2018 20:25:50 +0100 +Subject: extcon: int3496: process id-pin first so that we start with the right status + +From: Hans de Goede + +commit 0434352d3d2e950cf5e743f6062abd87de22f960 upstream. + +Some other drivers may be waiting for our extcon to show-up, exiting their +probe methods with -EPROBE_DEFER until we show up. + +These drivers will typically get the cable state directly after getting +the extcon, this commit changes the int3496 code to wait for the initial +processing of the id-pin to complete before exiting probe() with 0, which +will cause devices waiting on the defered probe to get reprobed. + +This fixes a race where the initial work might still be running while other +drivers were already calling extcon_get_state(). + +Fixes: 2f556bdb9f2e ("extcon: int3496: Add Intel INT3496 ACPI ... driver") +Cc: stable@vger.kernel.org +Signed-off-by: Hans de Goede +Signed-off-by: Chanwoo Choi +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/extcon/extcon-intel-int3496.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/extcon/extcon-intel-int3496.c ++++ b/drivers/extcon/extcon-intel-int3496.c +@@ -153,8 +153,9 @@ static int int3496_probe(struct platform + return ret; + } + +- /* queue initial processing of id-pin */ ++ /* process id-pin so that we start with the right status */ + queue_delayed_work(system_wq, &data->work, 0); ++ flush_delayed_work(&data->work); + + platform_set_drvdata(pdev, data); + diff --git a/queue-4.14/i2c-bcm2835-set-up-the-rising-falling-edge-delays.patch b/queue-4.14/i2c-bcm2835-set-up-the-rising-falling-edge-delays.patch new file mode 100644 index 00000000000..189be36d58d --- /dev/null +++ b/queue-4.14/i2c-bcm2835-set-up-the-rising-falling-edge-delays.patch @@ -0,0 +1,68 @@ +From fe32a815f05c8568669a062587435e15f9345764 Mon Sep 17 00:00:00 2001 +From: Eric Anholt +Date: Thu, 8 Feb 2018 14:54:05 +0100 +Subject: i2c: bcm2835: Set up the rising/falling edge delays + +From: Eric Anholt + +commit fe32a815f05c8568669a062587435e15f9345764 upstream. + +We were leaving them in the power on state (or the state the firmware +had set up for some client, if we were taking over from them). The +boot state was 30 core clocks, when we actually want to sample some +time after (to make sure that the new input bit has actually arrived). + +Signed-off-by: Eric Anholt +Signed-off-by: Boris Brezillon +Signed-off-by: Wolfram Sang +Cc: stable@kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/i2c/busses/i2c-bcm2835.c | 21 ++++++++++++++++++++- + 1 file changed, 20 insertions(+), 1 deletion(-) + +--- a/drivers/i2c/busses/i2c-bcm2835.c ++++ b/drivers/i2c/busses/i2c-bcm2835.c +@@ -50,6 +50,9 @@ + #define BCM2835_I2C_S_CLKT BIT(9) + #define BCM2835_I2C_S_LEN BIT(10) /* Fake bit for SW error reporting */ + ++#define BCM2835_I2C_FEDL_SHIFT 16 ++#define BCM2835_I2C_REDL_SHIFT 0 ++ + #define BCM2835_I2C_CDIV_MIN 0x0002 + #define BCM2835_I2C_CDIV_MAX 0xFFFE + +@@ -81,7 +84,7 @@ static inline u32 bcm2835_i2c_readl(stru + + static int bcm2835_i2c_set_divider(struct bcm2835_i2c_dev *i2c_dev) + { +- u32 divider; ++ u32 divider, redl, fedl; + + divider = DIV_ROUND_UP(clk_get_rate(i2c_dev->clk), + i2c_dev->bus_clk_rate); +@@ -100,6 +103,22 @@ static int bcm2835_i2c_set_divider(struc + + bcm2835_i2c_writel(i2c_dev, BCM2835_I2C_DIV, divider); + ++ /* ++ * Number of core clocks to wait after falling edge before ++ * outputting the next data bit. Note that both FEDL and REDL ++ * can't be greater than CDIV/2. ++ */ ++ fedl = max(divider / 16, 1u); ++ ++ /* ++ * Number of core clocks to wait after rising edge before ++ * sampling the next incoming data bit. ++ */ ++ redl = max(divider / 4, 1u); ++ ++ bcm2835_i2c_writel(i2c_dev, BCM2835_I2C_DEL, ++ (fedl << BCM2835_I2C_FEDL_SHIFT) | ++ (redl << BCM2835_I2C_REDL_SHIFT)); + return 0; + } + diff --git a/queue-4.14/i2c-designware-must-wait-for-enable.patch b/queue-4.14/i2c-designware-must-wait-for-enable.patch new file mode 100644 index 00000000000..8e75a6c24ba --- /dev/null +++ b/queue-4.14/i2c-designware-must-wait-for-enable.patch @@ -0,0 +1,52 @@ +From fba4adbbf670577e605f9ad306629db6031cd48b Mon Sep 17 00:00:00 2001 +From: Ben Gardner +Date: Wed, 14 Feb 2018 09:29:52 -0600 +Subject: i2c: designware: must wait for enable +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Ben Gardner + +commit fba4adbbf670577e605f9ad306629db6031cd48b upstream. + +One I2C bus on my Atom E3845 board has been broken since 4.9. +It has two devices, both declared by ACPI and with built-in drivers. + +There are two back-to-back transactions originating from the kernel, one +targeting each device. The first transaction works, the second one locks +up the I2C controller. The controller never recovers. + +These kernel logs show up whenever an I2C transaction is attempted after +this failure. +i2c-designware-pci 0000:00:18.3: timeout in disabling adapter +i2c-designware-pci 0000:00:18.3: timeout waiting for bus ready + +Waiting for the I2C controller status to indicate that it is enabled +before programming it fixes the issue. + +I have tested this patch on 4.14 and 4.15. + +Fixes: commit 2702ea7dbec5 ("i2c: designware: wait for disable/enable only if necessary") +Cc: linux-stable #4.13+ +Signed-off-by: Ben Gardner +Acked-by: Jarkko Nikula +Reviewed-by: José Roberto de Souza +Signed-off-by: Wolfram Sang +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/i2c/busses/i2c-designware-master.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/i2c/busses/i2c-designware-master.c ++++ b/drivers/i2c/busses/i2c-designware-master.c +@@ -207,7 +207,7 @@ static void i2c_dw_xfer_init(struct dw_i + i2c_dw_disable_int(dev); + + /* Enable the adapter */ +- __i2c_dw_enable(dev, true); ++ __i2c_dw_enable_and_wait(dev, true); + + /* Clear and enable interrupts */ + dw_readl(dev, DW_IC_CLR_INTR); diff --git a/queue-4.14/iio-adc-stm32-fix-stm32h7_adc_enable-error-handling.patch b/queue-4.14/iio-adc-stm32-fix-stm32h7_adc_enable-error-handling.patch new file mode 100644 index 00000000000..0612a7c969c --- /dev/null +++ b/queue-4.14/iio-adc-stm32-fix-stm32h7_adc_enable-error-handling.patch @@ -0,0 +1,49 @@ +From a3b5655ebdb501a98a45c0d3265dca9f2fe0218a Mon Sep 17 00:00:00 2001 +From: Fabrice Gasnier +Date: Tue, 23 Jan 2018 17:04:56 +0100 +Subject: iio: adc: stm32: fix stm32h7_adc_enable error handling + +From: Fabrice Gasnier + +commit a3b5655ebdb501a98a45c0d3265dca9f2fe0218a upstream. + +Error handling in stm32h7_adc_enable routine doesn't unwind enable +sequence correctly. ADEN can only be cleared by hardware (e.g. by +writing one to ADDIS). +It's also better to clear ADRDY just after it's been set by hardware. + +Fixes: 95e339b6e85d ("iio: adc: stm32: add support for STM32H7") + +Signed-off-by: Fabrice Gasnier +Cc: +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/iio/adc/stm32-adc.c | 7 ++++--- + 1 file changed, 4 insertions(+), 3 deletions(-) + +--- a/drivers/iio/adc/stm32-adc.c ++++ b/drivers/iio/adc/stm32-adc.c +@@ -764,8 +764,6 @@ static int stm32h7_adc_enable(struct stm + int ret; + u32 val; + +- /* Clear ADRDY by writing one, then enable ADC */ +- stm32_adc_set_bits(adc, STM32H7_ADC_ISR, STM32H7_ADRDY); + stm32_adc_set_bits(adc, STM32H7_ADC_CR, STM32H7_ADEN); + + /* Poll for ADRDY to be set (after adc startup time) */ +@@ -773,8 +771,11 @@ static int stm32h7_adc_enable(struct stm + val & STM32H7_ADRDY, + 100, STM32_ADC_TIMEOUT_US); + if (ret) { +- stm32_adc_clr_bits(adc, STM32H7_ADC_CR, STM32H7_ADEN); ++ stm32_adc_set_bits(adc, STM32H7_ADC_CR, STM32H7_ADDIS); + dev_err(&indio_dev->dev, "Failed to enable ADC\n"); ++ } else { ++ /* Clear ADRDY by writing one */ ++ stm32_adc_set_bits(adc, STM32H7_ADC_ISR, STM32H7_ADRDY); + } + + return ret; diff --git a/queue-4.14/iio-adis_lib-initialize-trigger-before-requesting-interrupt.patch b/queue-4.14/iio-adis_lib-initialize-trigger-before-requesting-interrupt.patch new file mode 100644 index 00000000000..9aaa65fbacf --- /dev/null +++ b/queue-4.14/iio-adis_lib-initialize-trigger-before-requesting-interrupt.patch @@ -0,0 +1,97 @@ +From f027e0b3a774e10302207e91d304bbf99e3a8b36 Mon Sep 17 00:00:00 2001 +From: Lars-Peter Clausen +Date: Wed, 14 Feb 2018 15:43:00 +0100 +Subject: iio: adis_lib: Initialize trigger before requesting interrupt + +From: Lars-Peter Clausen + +commit f027e0b3a774e10302207e91d304bbf99e3a8b36 upstream. + +The adis_probe_trigger() creates a new IIO trigger and requests an +interrupt associated with the trigger. The interrupt uses the generic +iio_trigger_generic_data_rdy_poll() function as its interrupt handler. + +Currently the driver initializes some fields of the trigger structure after +the interrupt has been requested. But an interrupt can fire as soon as it +has been requested. This opens up a race condition. + +iio_trigger_generic_data_rdy_poll() will access the trigger data structure +and dereference the ops field. If the ops field is not yet initialized this +will result in a NULL pointer deref. + +It is not expected that the device generates an interrupt at this point, so +typically this issue did not surface unless e.g. due to a hardware +misconfiguration (wrong interrupt number, wrong polarity, etc.). + +But some newer devices from the ADIS family start to generate periodic +interrupts in their power-on reset configuration and unfortunately the +interrupt can not be masked in the device. This makes the race condition +much more visible and the following crash has been observed occasionally +when booting a system using the ADIS16460. + + Unable to handle kernel NULL pointer dereference at virtual address 00000008 + pgd = c0004000 + [00000008] *pgd=00000000 + Internal error: Oops: 5 [#1] PREEMPT SMP ARM + Modules linked in: + CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.0-04126-gf9739f0-dirty #257 + Hardware name: Xilinx Zynq Platform + task: ef04f640 task.stack: ef050000 + PC is at iio_trigger_notify_done+0x30/0x68 + LR is at iio_trigger_generic_data_rdy_poll+0x18/0x20 + pc : [] lr : [] psr: 60000193 + sp : ef051bb8 ip : 00000000 fp : ef106400 + r10: c081d80a r9 : ef3bfa00 r8 : 00000087 + r7 : ef051bec r6 : 00000000 r5 : ef3bfa00 r4 : ee92ab00 + r3 : 00000000 r2 : 00000000 r1 : 00000000 r0 : ee97e400 + Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment none + Control: 18c5387d Table: 0000404a DAC: 00000051 + Process swapper/0 (pid: 1, stack limit = 0xef050210) + [] (iio_trigger_notify_done) from [] (__handle_irq_event_percpu+0x88/0x118) + [] (__handle_irq_event_percpu) from [] (handle_irq_event_percpu+0x1c/0x58) + [] (handle_irq_event_percpu) from [] (handle_irq_event+0x38/0x5c) + [] (handle_irq_event) from [] (handle_level_irq+0xa4/0x130) + [] (handle_level_irq) from [] (generic_handle_irq+0x24/0x34) + [] (generic_handle_irq) from [] (zynq_gpio_irqhandler+0xb8/0x13c) + [] (zynq_gpio_irqhandler) from [] (generic_handle_irq+0x24/0x34) + [] (generic_handle_irq) from [] (__handle_domain_irq+0x5c/0xb4) + [] (__handle_domain_irq) from [] (gic_handle_irq+0x48/0x8c) + [] (gic_handle_irq) from [] (__irq_svc+0x6c/0xa8) + +To fix this make sure that the trigger is fully initialized before +requesting the interrupt. + +Fixes: ccd2b52f4ac6 ("staging:iio: Add common ADIS library") +Reported-by: Robin Getz +Signed-off-by: Lars-Peter Clausen +Cc: +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/iio/imu/adis_trigger.c | 7 ++++--- + 1 file changed, 4 insertions(+), 3 deletions(-) + +--- a/drivers/iio/imu/adis_trigger.c ++++ b/drivers/iio/imu/adis_trigger.c +@@ -47,6 +47,10 @@ int adis_probe_trigger(struct adis *adis + if (adis->trig == NULL) + return -ENOMEM; + ++ adis->trig->dev.parent = &adis->spi->dev; ++ adis->trig->ops = &adis_trigger_ops; ++ iio_trigger_set_drvdata(adis->trig, adis); ++ + ret = request_irq(adis->spi->irq, + &iio_trigger_generic_data_rdy_poll, + IRQF_TRIGGER_RISING, +@@ -55,9 +59,6 @@ int adis_probe_trigger(struct adis *adis + if (ret) + goto error_free_trig; + +- adis->trig->dev.parent = &adis->spi->dev; +- adis->trig->ops = &adis_trigger_ops; +- iio_trigger_set_drvdata(adis->trig, adis); + ret = iio_trigger_register(adis->trig); + + indio_dev->trig = iio_trigger_get(adis->trig); diff --git a/queue-4.14/iio-buffer-check-if-a-buffer-has-been-set-up-when-poll-is-called.patch b/queue-4.14/iio-buffer-check-if-a-buffer-has-been-set-up-when-poll-is-called.patch new file mode 100644 index 00000000000..427031eec11 --- /dev/null +++ b/queue-4.14/iio-buffer-check-if-a-buffer-has-been-set-up-when-poll-is-called.patch @@ -0,0 +1,33 @@ +From 4cd140bda6494543f1c1b0ccceceaa44b676eef6 Mon Sep 17 00:00:00 2001 +From: Stefan Windfeldt-Prytz +Date: Thu, 15 Feb 2018 15:02:53 +0100 +Subject: iio: buffer: check if a buffer has been set up when poll is called + +From: Stefan Windfeldt-Prytz + +commit 4cd140bda6494543f1c1b0ccceceaa44b676eef6 upstream. + +If no iio buffer has been set up and poll is called return 0. +Without this check there will be a null pointer dereference when +calling poll on a iio driver without an iio buffer. + +Cc: stable@vger.kernel.org +Signed-off-by: Stefan Windfeldt-Prytz +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/iio/industrialio-buffer.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/iio/industrialio-buffer.c ++++ b/drivers/iio/industrialio-buffer.c +@@ -175,7 +175,7 @@ unsigned int iio_buffer_poll(struct file + struct iio_dev *indio_dev = filp->private_data; + struct iio_buffer *rb = indio_dev->buffer; + +- if (!indio_dev->info) ++ if (!indio_dev->info || rb == NULL) + return 0; + + poll_wait(filp, &rb->pollq, wait); diff --git a/queue-4.14/iio-srf08-fix-link-error-devm_iio_triggered_buffer_setup-undefined.patch b/queue-4.14/iio-srf08-fix-link-error-devm_iio_triggered_buffer_setup-undefined.patch new file mode 100644 index 00000000000..24ae269ee82 --- /dev/null +++ b/queue-4.14/iio-srf08-fix-link-error-devm_iio_triggered_buffer_setup-undefined.patch @@ -0,0 +1,36 @@ +From 511051d509ec54642dd6d30fdf2caa33c23619cc Mon Sep 17 00:00:00 2001 +From: Andreas Klinger +Date: Thu, 1 Feb 2018 21:49:24 +0100 +Subject: iio: srf08: fix link error "devm_iio_triggered_buffer_setup" undefined + +From: Andreas Klinger + +commit 511051d509ec54642dd6d30fdf2caa33c23619cc upstream. + +Functions for triggered buffer support are needed by this module. +If they are not defined accidentally by another driver, there's an error +thrown out while linking. + +Add a select of IIO_BUFFER and IIO_TRIGGERED_BUFFER in the Kconfig file. + +Signed-off-by: Andreas Klinger +Fixes: a83195937151 ("iio: srf08: add triggered buffer support") +Cc: +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/iio/proximity/Kconfig | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/drivers/iio/proximity/Kconfig ++++ b/drivers/iio/proximity/Kconfig +@@ -58,6 +58,8 @@ config SX9500 + + config SRF08 + tristate "Devantech SRF02/SRF08/SRF10 ultrasonic ranger sensor" ++ select IIO_BUFFER ++ select IIO_TRIGGERED_BUFFER + depends on I2C + help + Say Y here to build a driver for Devantech SRF02/SRF08/SRF10 diff --git a/queue-4.14/irqchip-gic-v3-use-wmb-instead-of-smb_wmb-in-gic_raise_softirq.patch b/queue-4.14/irqchip-gic-v3-use-wmb-instead-of-smb_wmb-in-gic_raise_softirq.patch new file mode 100644 index 00000000000..9cc8c5b981c --- /dev/null +++ b/queue-4.14/irqchip-gic-v3-use-wmb-instead-of-smb_wmb-in-gic_raise_softirq.patch @@ -0,0 +1,40 @@ +From 21ec30c0ef5234fb1039cc7c7737d885bf875a9e Mon Sep 17 00:00:00 2001 +From: Shanker Donthineni +Date: Wed, 31 Jan 2018 18:03:42 -0600 +Subject: irqchip/gic-v3: Use wmb() instead of smb_wmb() in gic_raise_softirq() + +From: Shanker Donthineni + +commit 21ec30c0ef5234fb1039cc7c7737d885bf875a9e upstream. + +A DMB instruction can be used to ensure the relative order of only +memory accesses before and after the barrier. Since writes to system +registers are not memory operations, barrier DMB is not sufficient +for observability of memory accesses that occur before ICC_SGI1R_EL1 +writes. + +A DSB instruction ensures that no instructions that appear in program +order after the DSB instruction, can execute until the DSB instruction +has completed. + +Cc: stable@vger.kernel.org +Acked-by: Will Deacon , +Signed-off-by: Shanker Donthineni +Signed-off-by: Marc Zyngier +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/irqchip/irq-gic-v3.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/irqchip/irq-gic-v3.c ++++ b/drivers/irqchip/irq-gic-v3.c +@@ -660,7 +660,7 @@ static void gic_raise_softirq(const stru + * Ensure that stores to Normal memory are visible to the + * other CPUs before issuing the IPI. + */ +- smp_wmb(); ++ wmb(); + + for_each_cpu(cpu, mask) { + unsigned long cluster_id = cpu_logical_map(cpu) & ~0xffUL; diff --git a/queue-4.14/irqchip-mips-gic-avoid-spuriously-handling-masked-interrupts.patch b/queue-4.14/irqchip-mips-gic-avoid-spuriously-handling-masked-interrupts.patch new file mode 100644 index 00000000000..06b7894a0aa --- /dev/null +++ b/queue-4.14/irqchip-mips-gic-avoid-spuriously-handling-masked-interrupts.patch @@ -0,0 +1,58 @@ +From 285cb4f62319737e6538252cf1a67ce9da5cf3d5 Mon Sep 17 00:00:00 2001 +From: Matt Redfearn +Date: Mon, 5 Feb 2018 16:45:36 +0000 +Subject: irqchip/mips-gic: Avoid spuriously handling masked interrupts + +From: Matt Redfearn + +commit 285cb4f62319737e6538252cf1a67ce9da5cf3d5 upstream. + +Commit 7778c4b27cbe ("irqchip: mips-gic: Use pcpu_masks to avoid reading +GIC_SH_MASK*") removed the read of the hardware mask register when +handling shared interrupts, instead using the driver's shadow pcpu_masks +entry as the effective mask. Unfortunately this did not take account of +the write to pcpu_masks during gic_shared_irq_domain_map, which +effectively unmasks the interrupt early. If an interrupt is asserted, +gic_handle_shared_int decodes and processes the interrupt even though it +has not yet been unmasked via gic_unmask_irq, which also sets the +appropriate bit in pcpu_masks. + +On the MIPS Boston board, when a console command line of +"console=ttyS0,115200n8r" is passed, the modem status IRQ is enabled in +the UART, which is immediately raised to the GIC. The interrupt has been +mapped, but no handler has yet been registered, nor is it expected to be +unmasked. However, the write to pcpu_masks in gic_shared_irq_domain_map +has effectively unmasked it, resulting in endless reports of: + +[ 5.058454] irq 13, desc: ffffffff80a7ad80, depth: 1, count: 0, unhandled: 0 +[ 5.062057] ->handle_irq(): ffffffff801b1838, +[ 5.062175] handle_bad_irq+0x0/0x2c0 + +Where IRQ 13 is the UART interrupt. + +To fix this, just remove the write to pcpu_masks in +gic_shared_irq_domain_map. The existing write in gic_unmask_irq is the +correct place for what is now the effective unmasking. + +Cc: stable@vger.kernel.org +Fixes: 7778c4b27cbe ("irqchip: mips-gic: Use pcpu_masks to avoid reading GIC_SH_MASK*") +Signed-off-by: Matt Redfearn +Reviewed-by: Paul Burton +Signed-off-by: Marc Zyngier +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/irqchip/irq-mips-gic.c | 2 -- + 1 file changed, 2 deletions(-) + +--- a/drivers/irqchip/irq-mips-gic.c ++++ b/drivers/irqchip/irq-mips-gic.c +@@ -427,8 +427,6 @@ static int gic_shared_irq_domain_map(str + spin_lock_irqsave(&gic_lock, flags); + write_gic_map_pin(intr, GIC_MAP_PIN_MAP_TO_PIN | gic_cpu_pin); + write_gic_map_vp(intr, BIT(mips_cm_vp_id(cpu))); +- gic_clear_pcpu_masks(intr); +- set_bit(intr, per_cpu_ptr(pcpu_masks, cpu)); + irq_data_update_effective_affinity(data, cpumask_of(cpu)); + spin_unlock_irqrestore(&gic_lock, flags); + diff --git a/queue-4.14/kbuild-always-define-endianess-in-kconfig.h.patch b/queue-4.14/kbuild-always-define-endianess-in-kconfig.h.patch new file mode 100644 index 00000000000..acafe5ad328 --- /dev/null +++ b/queue-4.14/kbuild-always-define-endianess-in-kconfig.h.patch @@ -0,0 +1,95 @@ +From 101110f6271ce956a049250c907bc960030577f8 Mon Sep 17 00:00:00 2001 +From: Arnd Bergmann +Date: Wed, 21 Feb 2018 14:45:20 -0800 +Subject: Kbuild: always define endianess in kconfig.h + +From: Arnd Bergmann + +commit 101110f6271ce956a049250c907bc960030577f8 upstream. + +Build testing with LTO found a couple of files that get compiled +differently depending on whether asm/byteorder.h gets included early +enough or not. In particular, include/asm-generic/qrwlock_types.h is +affected by this, but there are probably others as well. + +The symptom is a series of LTO link time warnings, including these: + + net/netlabel/netlabel_unlabeled.h:223: error: type of 'netlbl_unlhsh_add' does not match original declaration [-Werror=lto-type-mismatch] + int netlbl_unlhsh_add(struct net *net, + net/netlabel/netlabel_unlabeled.c:377: note: 'netlbl_unlhsh_add' was previously declared here + + include/net/ipv6.h:360: error: type of 'ipv6_renew_options_kern' does not match original declaration [-Werror=lto-type-mismatch] + ipv6_renew_options_kern(struct sock *sk, + net/ipv6/exthdrs.c:1162: note: 'ipv6_renew_options_kern' was previously declared here + + net/core/dev.c:761: note: 'dev_get_by_name_rcu' was previously declared here + struct net_device *dev_get_by_name_rcu(struct net *net, const char *name) + net/core/dev.c:761: note: code may be misoptimized unless -fno-strict-aliasing is used + + drivers/gpu/drm/i915/i915_drv.h:3377: error: type of 'i915_gem_object_set_to_wc_domain' does not match original declaration [-Werror=lto-type-mismatch] + i915_gem_object_set_to_wc_domain(struct drm_i915_gem_object *obj, bool write); + drivers/gpu/drm/i915/i915_gem.c:3639: note: 'i915_gem_object_set_to_wc_domain' was previously declared here + + include/linux/debugfs.h:92:9: error: type of 'debugfs_attr_read' does not match original declaration [-Werror=lto-type-mismatch] + ssize_t debugfs_attr_read(struct file *file, char __user *buf, + fs/debugfs/file.c:318: note: 'debugfs_attr_read' was previously declared here + + include/linux/rwlock_api_smp.h:30: error: type of '_raw_read_unlock' does not match original declaration [-Werror=lto-type-mismatch] + void __lockfunc _raw_read_unlock(rwlock_t *lock) __releases(lock); + kernel/locking/spinlock.c:246:26: note: '_raw_read_unlock' was previously declared here + + include/linux/fs.h:3308:5: error: type of 'simple_attr_open' does not match original declaration [-Werror=lto-type-mismatch] + int simple_attr_open(struct inode *inode, struct file *file, + fs/libfs.c:795: note: 'simple_attr_open' was previously declared here + +All of the above are caused by include/asm-generic/qrwlock_types.h +failing to include asm/byteorder.h after commit e0d02285f16e +("locking/qrwlock: Use 'struct qrwlock' instead of 'struct __qrwlock'") +in linux-4.15. + +Similar bugs may or may not exist in older kernels as well, but there is +no easy way to test those with link-time optimizations, and kernels +before 4.14 are harder to fix because they don't have Babu's patch +series + +We had similar issues with CONFIG_ symbols in the past and ended up +always including the configuration headers though linux/kconfig.h. This +works around the issue through that same file, defining either +__BIG_ENDIAN or __LITTLE_ENDIAN depending on CONFIG_CPU_BIG_ENDIAN, +which is now always set on all architectures since commit 4c97a0c8fee3 +("arch: define CPU_BIG_ENDIAN for all fixed big endian archs"). + +Link: http://lkml.kernel.org/r/20180202154104.1522809-2-arnd@arndb.de +Signed-off-by: Arnd Bergmann +Cc: Babu Moger +Cc: Andi Kleen +Cc: Greg Kroah-Hartman +Cc: Masahiro Yamada +Cc: Nicolas Pitre +Cc: Peter Zijlstra +Cc: Thomas Gleixner +Cc: Will Deacon +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + include/linux/kconfig.h | 6 ++++++ + 1 file changed, 6 insertions(+) + +--- a/include/linux/kconfig.h ++++ b/include/linux/kconfig.h +@@ -4,6 +4,12 @@ + + #include + ++#ifdef CONFIG_CPU_BIG_ENDIAN ++#define __BIG_ENDIAN 4321 ++#else ++#define __LITTLE_ENDIAN 1234 ++#endif ++ + #define __ARG_PLACEHOLDER_1 0, + #define __take_second_arg(__ignored, val, ...) val + diff --git a/queue-4.14/mips-drop-spurious-__unused-in-struct-compat_flock.patch b/queue-4.14/mips-drop-spurious-__unused-in-struct-compat_flock.patch new file mode 100644 index 00000000000..6909d5f30d5 --- /dev/null +++ b/queue-4.14/mips-drop-spurious-__unused-in-struct-compat_flock.patch @@ -0,0 +1,45 @@ +From 6ae1756faddefd7494353380ee546dd38c2f97eb Mon Sep 17 00:00:00 2001 +From: James Hogan +Date: Tue, 20 Feb 2018 15:44:37 +0000 +Subject: MIPS: Drop spurious __unused in struct compat_flock + +From: James Hogan + +commit 6ae1756faddefd7494353380ee546dd38c2f97eb upstream. + +MIPS' struct compat_flock doesn't match the 32-bit struct flock, as it +has an extra short __unused before pad[4], which combined with alignment +increases the size to 40 bytes compared with struct flock's 36 bytes. + +Since commit 8c6657cb50cb ("Switch flock copyin/copyout primitives to +copy_{from,to}_user()"), put_compat_flock() writes the full compat_flock +struct to userland, which results in corruption of the userland word +after the struct flock when running 32-bit userlands on 64-bit kernels. + +This was observed to cause a bus error exception when starting Firefox +on Debian 8 (Jessie). + +Reported-by: Peter Mamonov +Signed-off-by: James Hogan +Tested-by: Peter Mamonov +Cc: Ralf Baechle +Cc: Al Viro +Cc: linux-mips@linux-mips.org +Cc: # 4.13+ +Patchwork: https://patchwork.linux-mips.org/patch/18646/ +Signed-off-by: Greg Kroah-Hartman + +--- + arch/mips/include/asm/compat.h | 1 - + 1 file changed, 1 deletion(-) + +--- a/arch/mips/include/asm/compat.h ++++ b/arch/mips/include/asm/compat.h +@@ -86,7 +86,6 @@ struct compat_flock { + compat_off_t l_len; + s32 l_sysid; + compat_pid_t l_pid; +- short __unused; + s32 pad[4]; + }; + diff --git a/queue-4.14/mm-swap-frontswap-fix-thp-swap-if-frontswap-enabled.patch b/queue-4.14/mm-swap-frontswap-fix-thp-swap-if-frontswap-enabled.patch new file mode 100644 index 00000000000..e8056605d79 --- /dev/null +++ b/queue-4.14/mm-swap-frontswap-fix-thp-swap-if-frontswap-enabled.patch @@ -0,0 +1,108 @@ +From 7ba716698cc53f8d5367766c93c538c7da6c68ce Mon Sep 17 00:00:00 2001 +From: Huang Ying +Date: Wed, 21 Feb 2018 14:45:39 -0800 +Subject: mm, swap, frontswap: fix THP swap if frontswap enabled + +From: Huang Ying + +commit 7ba716698cc53f8d5367766c93c538c7da6c68ce upstream. + +It was reported by Sergey Senozhatsky that if THP (Transparent Huge +Page) and frontswap (via zswap) are both enabled, when memory goes low +so that swap is triggered, segfault and memory corruption will occur in +random user space applications as follow, + +kernel: urxvt[338]: segfault at 20 ip 00007fc08889ae0d sp 00007ffc73a7fc40 error 6 in libc-2.26.so[7fc08881a000+1ae000] + #0 0x00007fc08889ae0d _int_malloc (libc.so.6) + #1 0x00007fc08889c2f3 malloc (libc.so.6) + #2 0x0000560e6004bff7 _Z14rxvt_wcstoutf8PKwi (urxvt) + #3 0x0000560e6005e75c n/a (urxvt) + #4 0x0000560e6007d9f1 _ZN16rxvt_perl_interp6invokeEP9rxvt_term9hook_typez (urxvt) + #5 0x0000560e6003d988 _ZN9rxvt_term9cmd_parseEv (urxvt) + #6 0x0000560e60042804 _ZN9rxvt_term6pty_cbERN2ev2ioEi (urxvt) + #7 0x0000560e6005c10f _Z17ev_invoke_pendingv (urxvt) + #8 0x0000560e6005cb55 ev_run (urxvt) + #9 0x0000560e6003b9b9 main (urxvt) + #10 0x00007fc08883af4a __libc_start_main (libc.so.6) + #11 0x0000560e6003f9da _start (urxvt) + +After bisection, it was found the first bad commit is bd4c82c22c36 ("mm, +THP, swap: delay splitting THP after swapped out"). + +The root cause is as follows: + +When the pages are written to swap device during swapping out in +swap_writepage(), zswap (fontswap) is tried to compress the pages to +improve performance. But zswap (frontswap) will treat THP as a normal +page, so only the head page is saved. After swapping in, tail pages +will not be restored to their original contents, causing memory +corruption in the applications. + +This is fixed by refusing to save page in the frontswap store functions +if the page is a THP. So that the THP will be swapped out to swap +device. + +Another choice is to split THP if frontswap is enabled. But it is found +that the frontswap enabling isn't flexible. For example, if +CONFIG_ZSWAP=y (cannot be module), frontswap will be enabled even if +zswap itself isn't enabled. + +Frontswap has multiple backends, to make it easy for one backend to +enable THP support, the THP checking is put in backend frontswap store +functions instead of the general interfaces. + +Link: http://lkml.kernel.org/r/20180209084947.22749-1-ying.huang@intel.com +Fixes: bd4c82c22c367e068 ("mm, THP, swap: delay splitting THP after swapped out") +Signed-off-by: "Huang, Ying" +Reported-by: Sergey Senozhatsky +Tested-by: Sergey Senozhatsky +Suggested-by: Minchan Kim [put THP checking in backend] +Cc: Konrad Rzeszutek Wilk +Cc: Dan Streetman +Cc: Seth Jennings +Cc: Tetsuo Handa +Cc: Shaohua Li +Cc: Michal Hocko +Cc: Johannes Weiner +Cc: Mel Gorman +Cc: Shakeel Butt +Cc: Boris Ostrovsky +Cc: Juergen Gross +Cc: [4.14] +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/xen/tmem.c | 4 ++++ + mm/zswap.c | 6 ++++++ + 2 files changed, 10 insertions(+) + +--- a/drivers/xen/tmem.c ++++ b/drivers/xen/tmem.c +@@ -284,6 +284,10 @@ static int tmem_frontswap_store(unsigned + int pool = tmem_frontswap_poolid; + int ret; + ++ /* THP isn't supported */ ++ if (PageTransHuge(page)) ++ return -1; ++ + if (pool < 0) + return -1; + if (ind64 != ind) +--- a/mm/zswap.c ++++ b/mm/zswap.c +@@ -970,6 +970,12 @@ static int zswap_frontswap_store(unsigne + u8 *src, *dst; + struct zswap_header *zhdr; + ++ /* THP isn't supported */ ++ if (PageTransHuge(page)) { ++ ret = -EINVAL; ++ goto reject; ++ } ++ + if (!zswap_enabled || !tree) { + ret = -ENODEV; + goto reject; diff --git a/queue-4.14/ohci-hcd-fix-race-condition-caused-by-ohci_urb_enqueue-and-io_watchdog_func.patch b/queue-4.14/ohci-hcd-fix-race-condition-caused-by-ohci_urb_enqueue-and-io_watchdog_func.patch new file mode 100644 index 00000000000..7e2ff54cbd0 --- /dev/null +++ b/queue-4.14/ohci-hcd-fix-race-condition-caused-by-ohci_urb_enqueue-and-io_watchdog_func.patch @@ -0,0 +1,148 @@ +From b2685bdacdaab065c172b97b55ab46c6be77a037 Mon Sep 17 00:00:00 2001 +From: Shigeru Yoshida +Date: Fri, 2 Feb 2018 13:51:39 +0800 +Subject: ohci-hcd: Fix race condition caused by ohci_urb_enqueue() and io_watchdog_func() + +From: Shigeru Yoshida + +commit b2685bdacdaab065c172b97b55ab46c6be77a037 upstream. + +Running io_watchdog_func() while ohci_urb_enqueue() is running can +cause a race condition where ohci->prev_frame_no is corrupted and the +watchdog can mis-detect following error: + + ohci-platform 664a0800.usb: frame counter not updating; disabled + ohci-platform 664a0800.usb: HC died; cleaning up + +Specifically, following scenario causes a race condition: + + 1. ohci_urb_enqueue() calls spin_lock_irqsave(&ohci->lock, flags) + and enters the critical section + 2. ohci_urb_enqueue() calls timer_pending(&ohci->io_watchdog) and it + returns false + 3. ohci_urb_enqueue() sets ohci->prev_frame_no to a frame number + read by ohci_frame_no(ohci) + 4. ohci_urb_enqueue() schedules io_watchdog_func() with mod_timer() + 5. ohci_urb_enqueue() calls spin_unlock_irqrestore(&ohci->lock, + flags) and exits the critical section + 6. Later, ohci_urb_enqueue() is called + 7. ohci_urb_enqueue() calls spin_lock_irqsave(&ohci->lock, flags) + and enters the critical section + 8. The timer scheduled on step 4 expires and io_watchdog_func() runs + 9. io_watchdog_func() calls spin_lock_irqsave(&ohci->lock, flags) + and waits on it because ohci_urb_enqueue() is already in the + critical section on step 7 + 10. ohci_urb_enqueue() calls timer_pending(&ohci->io_watchdog) and it + returns false + 11. ohci_urb_enqueue() sets ohci->prev_frame_no to new frame number + read by ohci_frame_no(ohci) because the frame number proceeded + between step 3 and 6 + 12. ohci_urb_enqueue() schedules io_watchdog_func() with mod_timer() + 13. ohci_urb_enqueue() calls spin_unlock_irqrestore(&ohci->lock, + flags) and exits the critical section, then wake up + io_watchdog_func() which is waiting on step 9 + 14. io_watchdog_func() enters the critical section + 15. io_watchdog_func() calls ohci_frame_no(ohci) and set frame_no + variable to the frame number + 16. io_watchdog_func() compares frame_no and ohci->prev_frame_no + +On step 16, because this calling of io_watchdog_func() is scheduled on +step 4, the frame number set in ohci->prev_frame_no is expected to the +number set on step 3. However, ohci->prev_frame_no is overwritten on +step 11. Because step 16 is executed soon after step 11, the frame +number might not proceed, so ohci->prev_frame_no must equals to +frame_no. + +To address above scenario, this patch introduces a special sentinel +value IO_WATCHDOG_OFF and set this value to ohci->prev_frame_no when +the watchdog is not pending or running. When ohci_urb_enqueue() +schedules the watchdog (step 4 and 12 above), it compares +ohci->prev_frame_no to IO_WATCHDOG_OFF so that ohci->prev_frame_no is +not overwritten while io_watchdog_func() is running. + +Signed-off-by: Shigeru Yoshida +Signed-off-by: Haiqing Bai +Acked-by: Alan Stern +Cc: stable +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/host/ohci-hcd.c | 10 +++++++--- + drivers/usb/host/ohci-hub.c | 4 +++- + 2 files changed, 10 insertions(+), 4 deletions(-) + +--- a/drivers/usb/host/ohci-hcd.c ++++ b/drivers/usb/host/ohci-hcd.c +@@ -73,6 +73,7 @@ static const char hcd_name [] = "ohci_hc + + #define STATECHANGE_DELAY msecs_to_jiffies(300) + #define IO_WATCHDOG_DELAY msecs_to_jiffies(275) ++#define IO_WATCHDOG_OFF 0xffffff00 + + #include "ohci.h" + #include "pci-quirks.h" +@@ -230,7 +231,7 @@ static int ohci_urb_enqueue ( + } + + /* Start up the I/O watchdog timer, if it's not running */ +- if (!timer_pending(&ohci->io_watchdog) && ++ if (ohci->prev_frame_no == IO_WATCHDOG_OFF && + list_empty(&ohci->eds_in_use) && + !(ohci->flags & OHCI_QUIRK_QEMU)) { + ohci->prev_frame_no = ohci_frame_no(ohci); +@@ -501,6 +502,7 @@ static int ohci_init (struct ohci_hcd *o + + setup_timer(&ohci->io_watchdog, io_watchdog_func, + (unsigned long) ohci); ++ ohci->prev_frame_no = IO_WATCHDOG_OFF; + + ohci->hcca = dma_alloc_coherent (hcd->self.controller, + sizeof(*ohci->hcca), &ohci->hcca_dma, GFP_KERNEL); +@@ -730,7 +732,7 @@ static void io_watchdog_func(unsigned lo + u32 head; + struct ed *ed; + struct td *td, *td_start, *td_next; +- unsigned frame_no; ++ unsigned frame_no, prev_frame_no = IO_WATCHDOG_OFF; + unsigned long flags; + + spin_lock_irqsave(&ohci->lock, flags); +@@ -835,7 +837,7 @@ static void io_watchdog_func(unsigned lo + } + } + if (!list_empty(&ohci->eds_in_use)) { +- ohci->prev_frame_no = frame_no; ++ prev_frame_no = frame_no; + ohci->prev_wdh_cnt = ohci->wdh_cnt; + ohci->prev_donehead = ohci_readl(ohci, + &ohci->regs->donehead); +@@ -845,6 +847,7 @@ static void io_watchdog_func(unsigned lo + } + + done: ++ ohci->prev_frame_no = prev_frame_no; + spin_unlock_irqrestore(&ohci->lock, flags); + } + +@@ -973,6 +976,7 @@ static void ohci_stop (struct usb_hcd *h + if (quirk_nec(ohci)) + flush_work(&ohci->nec_work); + del_timer_sync(&ohci->io_watchdog); ++ ohci->prev_frame_no = IO_WATCHDOG_OFF; + + ohci_writel (ohci, OHCI_INTR_MIE, &ohci->regs->intrdisable); + ohci_usb_reset(ohci); +--- a/drivers/usb/host/ohci-hub.c ++++ b/drivers/usb/host/ohci-hub.c +@@ -310,8 +310,10 @@ static int ohci_bus_suspend (struct usb_ + rc = ohci_rh_suspend (ohci, 0); + spin_unlock_irq (&ohci->lock); + +- if (rc == 0) ++ if (rc == 0) { + del_timer_sync(&ohci->io_watchdog); ++ ohci->prev_frame_no = IO_WATCHDOG_OFF; ++ } + return rc; + } + diff --git a/queue-4.14/pci-cxgb4-extend-t3-pci-quirk-to-t4-devices.patch b/queue-4.14/pci-cxgb4-extend-t3-pci-quirk-to-t4-devices.patch new file mode 100644 index 00000000000..03b48a7d2b1 --- /dev/null +++ b/queue-4.14/pci-cxgb4-extend-t3-pci-quirk-to-t4-devices.patch @@ -0,0 +1,112 @@ +From 7dcf688d4c78a18ba9538b2bf1b11dc7a43fe9be Mon Sep 17 00:00:00 2001 +From: Casey Leedom +Date: Thu, 15 Feb 2018 20:03:18 +0530 +Subject: PCI/cxgb4: Extend T3 PCI quirk to T4+ devices + +From: Casey Leedom + +commit 7dcf688d4c78a18ba9538b2bf1b11dc7a43fe9be upstream. + +We've run into a problem where our device is attached +to a Virtual Machine and the use of the new pci_set_vpd_size() +API doesn't help. The VM kernel has been informed that +the accesses are okay, but all of the actual VPD Capability +Accesses are trapped down into the KVM Hypervisor where it +goes ahead and imposes the silent denials. + +The right idea is to follow the kernel.org +commit 1c7de2b4ff88 ("PCI: Enable access to non-standard VPD for +Chelsio devices (cxgb3)") which Alexey Kardashevskiy authored +to establish a PCI Quirk for our T3-based adapters. This commit +extends that PCI Quirk to cover Chelsio T4 devices and later. + +The advantage of this approach is that the VPD Size gets set early +in the Base OS/Hypervisor Boot and doesn't require that the cxgb4 +driver even be available in the Base OS/Hypervisor. Thus PF4 can +be exported to a Virtual Machine and everything should work. + +Fixes: 67e658794ca1 ("cxgb4: Set VPD size so we can read both VPD structures") +Cc: # v4.9+ +Signed-off-by: Casey Leedom +Signed-off-by: Arjun Vynipadath +Signed-off-by: Ganesh Goudar +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 10 -------- + drivers/pci/quirks.c | 35 +++++++++++++++++------------ + 2 files changed, 21 insertions(+), 24 deletions(-) + +--- a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c ++++ b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c +@@ -2632,7 +2632,6 @@ void t4_get_regs(struct adapter *adap, v + } + + #define EEPROM_STAT_ADDR 0x7bfc +-#define VPD_SIZE 0x800 + #define VPD_BASE 0x400 + #define VPD_BASE_OLD 0 + #define VPD_LEN 1024 +@@ -2670,15 +2669,6 @@ int t4_get_raw_vpd_params(struct adapter + if (!vpd) + return -ENOMEM; + +- /* We have two VPD data structures stored in the adapter VPD area. +- * By default, Linux calculates the size of the VPD area by traversing +- * the first VPD area at offset 0x0, so we need to tell the OS what +- * our real VPD size is. +- */ +- ret = pci_set_vpd_size(adapter->pdev, VPD_SIZE); +- if (ret < 0) +- goto out; +- + /* Card information normally starts at VPD_BASE but early cards had + * it at 0. + */ +--- a/drivers/pci/quirks.c ++++ b/drivers/pci/quirks.c +@@ -3412,22 +3412,29 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_IN + + static void quirk_chelsio_extend_vpd(struct pci_dev *dev) + { +- pci_set_vpd_size(dev, 8192); ++ int chip = (dev->device & 0xf000) >> 12; ++ int func = (dev->device & 0x0f00) >> 8; ++ int prod = (dev->device & 0x00ff) >> 0; ++ ++ /* ++ * If this is a T3-based adapter, there's a 1KB VPD area at offset ++ * 0xc00 which contains the preferred VPD values. If this is a T4 or ++ * later based adapter, the special VPD is at offset 0x400 for the ++ * Physical Functions (the SR-IOV Virtual Functions have no VPD ++ * Capabilities). The PCI VPD Access core routines will normally ++ * compute the size of the VPD by parsing the VPD Data Structure at ++ * offset 0x000. This will result in silent failures when attempting ++ * to accesses these other VPD areas which are beyond those computed ++ * limits. ++ */ ++ if (chip == 0x0 && prod >= 0x20) ++ pci_set_vpd_size(dev, 8192); ++ else if (chip >= 0x4 && func < 0x8) ++ pci_set_vpd_size(dev, 2048); + } + +-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x20, quirk_chelsio_extend_vpd); +-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x21, quirk_chelsio_extend_vpd); +-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x22, quirk_chelsio_extend_vpd); +-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x23, quirk_chelsio_extend_vpd); +-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x24, quirk_chelsio_extend_vpd); +-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x25, quirk_chelsio_extend_vpd); +-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x26, quirk_chelsio_extend_vpd); +-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x30, quirk_chelsio_extend_vpd); +-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x31, quirk_chelsio_extend_vpd); +-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x32, quirk_chelsio_extend_vpd); +-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x35, quirk_chelsio_extend_vpd); +-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x36, quirk_chelsio_extend_vpd); +-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x37, quirk_chelsio_extend_vpd); ++DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, PCI_ANY_ID, ++ quirk_chelsio_extend_vpd); + + #ifdef CONFIG_ACPI + /* diff --git a/queue-4.14/pkcs-7-fix-certificate-blacklisting.patch b/queue-4.14/pkcs-7-fix-certificate-blacklisting.patch new file mode 100644 index 00000000000..c697cfb3af3 --- /dev/null +++ b/queue-4.14/pkcs-7-fix-certificate-blacklisting.patch @@ -0,0 +1,57 @@ +From 29f4a67c17e19314b7d74b8569be935e6c7edf50 Mon Sep 17 00:00:00 2001 +From: Eric Biggers +Date: Thu, 22 Feb 2018 14:38:33 +0000 +Subject: PKCS#7: fix certificate blacklisting + +From: Eric Biggers + +commit 29f4a67c17e19314b7d74b8569be935e6c7edf50 upstream. + +If there is a blacklisted certificate in a SignerInfo's certificate +chain, then pkcs7_verify_sig_chain() sets sinfo->blacklisted and returns +0. But, pkcs7_verify() fails to handle this case appropriately, as it +actually continues on to the line 'actual_ret = 0;', indicating that the +SignerInfo has passed verification. Consequently, PKCS#7 signature +verification ignores the certificate blacklist. + +Fix this by not considering blacklisted SignerInfos to have passed +verification. + +Also fix the function comment with regards to when 0 is returned. + +Fixes: 03bb79315ddc ("PKCS#7: Handle blacklisted certificates") +Cc: # v4.12+ +Signed-off-by: Eric Biggers +Signed-off-by: David Howells +Signed-off-by: Greg Kroah-Hartman + +--- + crypto/asymmetric_keys/pkcs7_verify.c | 10 ++++++---- + 1 file changed, 6 insertions(+), 4 deletions(-) + +--- a/crypto/asymmetric_keys/pkcs7_verify.c ++++ b/crypto/asymmetric_keys/pkcs7_verify.c +@@ -369,8 +369,7 @@ static int pkcs7_verify_one(struct pkcs7 + * + * (*) -EBADMSG if some part of the message was invalid, or: + * +- * (*) 0 if no signature chains were found to be blacklisted or to contain +- * unsupported crypto, or: ++ * (*) 0 if a signature chain passed verification, or: + * + * (*) -EKEYREJECTED if a blacklisted key was encountered, or: + * +@@ -426,8 +425,11 @@ int pkcs7_verify(struct pkcs7_message *p + + for (sinfo = pkcs7->signed_infos; sinfo; sinfo = sinfo->next) { + ret = pkcs7_verify_one(pkcs7, sinfo); +- if (sinfo->blacklisted && actual_ret == -ENOPKG) +- actual_ret = -EKEYREJECTED; ++ if (sinfo->blacklisted) { ++ if (actual_ret == -ENOPKG) ++ actual_ret = -EKEYREJECTED; ++ continue; ++ } + if (ret < 0) { + if (ret == -ENOPKG) { + sinfo->unsupported_crypto = true; diff --git a/queue-4.14/pkcs-7-fix-certificate-chain-verification.patch b/queue-4.14/pkcs-7-fix-certificate-chain-verification.patch new file mode 100644 index 00000000000..94817c36ae2 --- /dev/null +++ b/queue-4.14/pkcs-7-fix-certificate-chain-verification.patch @@ -0,0 +1,58 @@ +From 971b42c038dc83e3327872d294fe7131bab152fc Mon Sep 17 00:00:00 2001 +From: Eric Biggers +Date: Thu, 22 Feb 2018 14:38:33 +0000 +Subject: PKCS#7: fix certificate chain verification + +From: Eric Biggers + +commit 971b42c038dc83e3327872d294fe7131bab152fc upstream. + +When pkcs7_verify_sig_chain() is building the certificate chain for a +SignerInfo using the certificates in the PKCS#7 message, it is passing +the wrong arguments to public_key_verify_signature(). Consequently, +when the next certificate is supposed to be used to verify the previous +certificate, the next certificate is actually used to verify itself. + +An attacker can use this bug to create a bogus certificate chain that +has no cryptographic relationship between the beginning and end. + +Fortunately I couldn't quite find a way to use this to bypass the +overall signature verification, though it comes very close. Here's the +reasoning: due to the bug, every certificate in the chain beyond the +first actually has to be self-signed (where "self-signed" here refers to +the actual key and signature; an attacker might still manipulate the +certificate fields such that the self_signed flag doesn't actually get +set, and thus the chain doesn't end immediately). But to pass trust +validation (pkcs7_validate_trust()), either the SignerInfo or one of the +certificates has to actually be signed by a trusted key. Since only +self-signed certificates can be added to the chain, the only way for an +attacker to introduce a trusted signature is to include a self-signed +trusted certificate. + +But, when pkcs7_validate_trust_one() reaches that certificate, instead +of trying to verify the signature on that certificate, it will actually +look up the corresponding trusted key, which will succeed, and then try +to verify the *previous* certificate, which will fail. Thus, disaster +is narrowly averted (as far as I could tell). + +Fixes: 6c2dc5ae4ab7 ("X.509: Extract signature digest and make self-signed cert checks earlier") +Cc: # v4.7+ +Signed-off-by: Eric Biggers +Signed-off-by: David Howells +Signed-off-by: Greg Kroah-Hartman + +--- + crypto/asymmetric_keys/pkcs7_verify.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/crypto/asymmetric_keys/pkcs7_verify.c ++++ b/crypto/asymmetric_keys/pkcs7_verify.c +@@ -273,7 +273,7 @@ static int pkcs7_verify_sig_chain(struct + sinfo->index); + return 0; + } +- ret = public_key_verify_signature(p->pub, p->sig); ++ ret = public_key_verify_signature(p->pub, x509->sig); + if (ret < 0) + return ret; + x509->signer = p; diff --git a/queue-4.14/rdma-uverbs-fix-bad-unlock-balance-in-ib_uverbs_close_xrcd.patch b/queue-4.14/rdma-uverbs-fix-bad-unlock-balance-in-ib_uverbs_close_xrcd.patch new file mode 100644 index 00000000000..c0fde324715 --- /dev/null +++ b/queue-4.14/rdma-uverbs-fix-bad-unlock-balance-in-ib_uverbs_close_xrcd.patch @@ -0,0 +1,91 @@ +From 5c2e1c4f926856717f3fd31932e926dc3fe77ebd Mon Sep 17 00:00:00 2001 +From: Leon Romanovsky +Date: Wed, 14 Feb 2018 12:35:38 +0200 +Subject: RDMA/uverbs: Fix bad unlock balance in ib_uverbs_close_xrcd + +From: Leon Romanovsky + +commit 5c2e1c4f926856717f3fd31932e926dc3fe77ebd upstream. + +There is no matching lock for this mutex. Git history suggests this is +just a missed remnant from an earlier version of the function before +this locking was moved into uverbs_free_xrcd. + +Originally this lock was protecting the xrcd_table_delete() + +===================================== +WARNING: bad unlock balance detected! +4.15.0+ #87 Not tainted +------------------------------------- +syzkaller223405/269 is trying to release lock (&uverbs_dev->xrcd_tree_mutex) at: +[<00000000b8703372>] ib_uverbs_close_xrcd+0x195/0x1f0 +but there are no more locks to release! + +other info that might help us debug this: +1 lock held by syzkaller223405/269: + #0: (&uverbs_dev->disassociate_srcu){....}, at: [<000000005af3b960>] ib_uverbs_write+0x265/0xef0 + +stack backtrace: +CPU: 0 PID: 269 Comm: syzkaller223405 Not tainted 4.15.0+ #87 +Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014 +Call Trace: + dump_stack+0xde/0x164 + ? dma_virt_map_sg+0x22c/0x22c + ? ib_uverbs_write+0x265/0xef0 + ? console_unlock+0x502/0xbd0 + ? ib_uverbs_close_xrcd+0x195/0x1f0 + print_unlock_imbalance_bug+0x131/0x160 + lock_release+0x59d/0x1100 + ? ib_uverbs_close_xrcd+0x195/0x1f0 + ? lock_acquire+0x440/0x440 + ? lock_acquire+0x440/0x440 + __mutex_unlock_slowpath+0x88/0x670 + ? wait_for_completion+0x4c0/0x4c0 + ? rdma_lookup_get_uobject+0x145/0x2f0 + ib_uverbs_close_xrcd+0x195/0x1f0 + ? ib_uverbs_open_xrcd+0xdd0/0xdd0 + ib_uverbs_write+0x7f9/0xef0 + ? cyc2ns_read_end+0x10/0x10 + ? ib_uverbs_open_xrcd+0xdd0/0xdd0 + ? uverbs_devnode+0x110/0x110 + ? cyc2ns_read_end+0x10/0x10 + ? cyc2ns_read_end+0x10/0x10 + ? sched_clock_cpu+0x18/0x200 + __vfs_write+0x10d/0x700 + ? uverbs_devnode+0x110/0x110 + ? kernel_read+0x170/0x170 + ? __fget+0x358/0x5d0 + ? security_file_permission+0x93/0x260 + vfs_write+0x1b0/0x550 + SyS_write+0xc7/0x1a0 + ? SyS_read+0x1a0/0x1a0 + ? trace_hardirqs_on_thunk+0x1a/0x1c + entry_SYSCALL_64_fastpath+0x1e/0x8b +RIP: 0033:0x4335c9 + +Cc: syzkaller +Cc: # 4.11 +Fixes: fd3c7904db6e ("IB/core: Change idr objects to use the new schema") +Reported-by: Noa Osherovich +Signed-off-by: Leon Romanovsky +Signed-off-by: Jason Gunthorpe +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/infiniband/core/uverbs_cmd.c | 4 +--- + 1 file changed, 1 insertion(+), 3 deletions(-) + +--- a/drivers/infiniband/core/uverbs_cmd.c ++++ b/drivers/infiniband/core/uverbs_cmd.c +@@ -606,10 +606,8 @@ ssize_t ib_uverbs_close_xrcd(struct ib_u + + uobj = uobj_get_write(uobj_get_type(xrcd), cmd.xrcd_handle, + file->ucontext); +- if (IS_ERR(uobj)) { +- mutex_unlock(&file->device->xrcd_tree_mutex); ++ if (IS_ERR(uobj)) + return PTR_ERR(uobj); +- } + + ret = uobj_remove_commit(uobj); + return ret ?: in_len; diff --git a/queue-4.14/rdma-uverbs-fix-circular-locking-dependency.patch b/queue-4.14/rdma-uverbs-fix-circular-locking-dependency.patch new file mode 100644 index 00000000000..af056c3b2f8 --- /dev/null +++ b/queue-4.14/rdma-uverbs-fix-circular-locking-dependency.patch @@ -0,0 +1,154 @@ +From 1ff5325c3ca1843228a86549318bbd3b414b9207 Mon Sep 17 00:00:00 2001 +From: Leon Romanovsky +Date: Wed, 14 Feb 2018 12:35:39 +0200 +Subject: RDMA/uverbs: Fix circular locking dependency + +From: Leon Romanovsky + +commit 1ff5325c3ca1843228a86549318bbd3b414b9207 upstream. + +Avoid circular locking dependency by calling +to uobj_alloc_commit() outside of xrcd_tree_mutex lock. + +====================================================== +WARNING: possible circular locking dependency detected +4.15.0+ #87 Not tainted +------------------------------------------------------ +syzkaller401056/269 is trying to acquire lock: + (&uverbs_dev->xrcd_tree_mutex){+.+.}, at: [<000000006c12d2cd>] uverbs_free_xrcd+0xd2/0x360 + +but task is already holding lock: + (&ucontext->uobjects_lock){+.+.}, at: [<00000000da010f09>] uverbs_cleanup_ucontext+0x168/0x730 + +which lock already depends on the new lock. + +the existing dependency chain (in reverse order) is: + +-> #1 (&ucontext->uobjects_lock){+.+.}: + __mutex_lock+0x111/0x1720 + rdma_alloc_commit_uobject+0x22c/0x600 + ib_uverbs_open_xrcd+0x61a/0xdd0 + ib_uverbs_write+0x7f9/0xef0 + __vfs_write+0x10d/0x700 + vfs_write+0x1b0/0x550 + SyS_write+0xc7/0x1a0 + entry_SYSCALL_64_fastpath+0x1e/0x8b + +-> #0 (&uverbs_dev->xrcd_tree_mutex){+.+.}: + lock_acquire+0x19d/0x440 + __mutex_lock+0x111/0x1720 + uverbs_free_xrcd+0xd2/0x360 + remove_commit_idr_uobject+0x6d/0x110 + uverbs_cleanup_ucontext+0x2f0/0x730 + ib_uverbs_cleanup_ucontext.constprop.3+0x52/0x120 + ib_uverbs_close+0xf2/0x570 + __fput+0x2cd/0x8d0 + task_work_run+0xec/0x1d0 + do_exit+0x6a1/0x1520 + do_group_exit+0xe8/0x380 + SyS_exit_group+0x1e/0x20 + entry_SYSCALL_64_fastpath+0x1e/0x8b + +other info that might help us debug this: + + Possible unsafe locking scenario: + + CPU0 CPU1 + ---- ---- + lock(&ucontext->uobjects_lock); + lock(&uverbs_dev->xrcd_tree_mutex); + lock(&ucontext->uobjects_lock); + lock(&uverbs_dev->xrcd_tree_mutex); + + *** DEADLOCK *** + +3 locks held by syzkaller401056/269: + #0: (&file->cleanup_mutex){+.+.}, at: [<00000000c9f0c252>] ib_uverbs_close+0xac/0x570 + #1: (&ucontext->cleanup_rwsem){++++}, at: [<00000000b6994d49>] uverbs_cleanup_ucontext+0xf6/0x730 + #2: (&ucontext->uobjects_lock){+.+.}, at: [<00000000da010f09>] uverbs_cleanup_ucontext+0x168/0x730 + +stack backtrace: +CPU: 0 PID: 269 Comm: syzkaller401056 Not tainted 4.15.0+ #87 +Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014 +Call Trace: + dump_stack+0xde/0x164 + ? dma_virt_map_sg+0x22c/0x22c + ? uverbs_cleanup_ucontext+0x168/0x730 + ? console_unlock+0x502/0xbd0 + print_circular_bug.isra.24+0x35e/0x396 + ? print_circular_bug_header+0x12e/0x12e + ? find_usage_backwards+0x30/0x30 + ? entry_SYSCALL_64_fastpath+0x1e/0x8b + validate_chain.isra.28+0x25d1/0x40c0 + ? check_usage+0xb70/0xb70 + ? graph_lock+0x160/0x160 + ? find_usage_backwards+0x30/0x30 + ? cyc2ns_read_end+0x10/0x10 + ? print_irqtrace_events+0x280/0x280 + ? __lock_acquire+0x93d/0x1630 + __lock_acquire+0x93d/0x1630 + lock_acquire+0x19d/0x440 + ? uverbs_free_xrcd+0xd2/0x360 + __mutex_lock+0x111/0x1720 + ? uverbs_free_xrcd+0xd2/0x360 + ? uverbs_free_xrcd+0xd2/0x360 + ? __mutex_lock+0x828/0x1720 + ? mutex_lock_io_nested+0x1550/0x1550 + ? uverbs_cleanup_ucontext+0x168/0x730 + ? __lock_acquire+0x9a9/0x1630 + ? mutex_lock_io_nested+0x1550/0x1550 + ? uverbs_cleanup_ucontext+0xf6/0x730 + ? lock_contended+0x11a0/0x11a0 + ? uverbs_free_xrcd+0xd2/0x360 + uverbs_free_xrcd+0xd2/0x360 + remove_commit_idr_uobject+0x6d/0x110 + uverbs_cleanup_ucontext+0x2f0/0x730 + ? sched_clock_cpu+0x18/0x200 + ? uverbs_close_fd+0x1c0/0x1c0 + ib_uverbs_cleanup_ucontext.constprop.3+0x52/0x120 + ib_uverbs_close+0xf2/0x570 + ? ib_uverbs_remove_one+0xb50/0xb50 + ? ib_uverbs_remove_one+0xb50/0xb50 + __fput+0x2cd/0x8d0 + task_work_run+0xec/0x1d0 + do_exit+0x6a1/0x1520 + ? fsnotify_first_mark+0x220/0x220 + ? exit_notify+0x9f0/0x9f0 + ? entry_SYSCALL_64_fastpath+0x5/0x8b + ? entry_SYSCALL_64_fastpath+0x5/0x8b + ? trace_hardirqs_on_thunk+0x1a/0x1c + ? time_hardirqs_on+0x27/0x670 + ? time_hardirqs_off+0x27/0x490 + ? syscall_return_slowpath+0x6c/0x460 + ? entry_SYSCALL_64_fastpath+0x5/0x8b + do_group_exit+0xe8/0x380 + SyS_exit_group+0x1e/0x20 + entry_SYSCALL_64_fastpath+0x1e/0x8b +RIP: 0033:0x431ce9 + +Cc: syzkaller +Cc: # 4.11 +Fixes: fd3c7904db6e ("IB/core: Change idr objects to use the new schema") +Reported-by: Noa Osherovich +Signed-off-by: Leon Romanovsky +Signed-off-by: Jason Gunthorpe +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/infiniband/core/uverbs_cmd.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/infiniband/core/uverbs_cmd.c ++++ b/drivers/infiniband/core/uverbs_cmd.c +@@ -565,9 +565,10 @@ ssize_t ib_uverbs_open_xrcd(struct ib_uv + if (f.file) + fdput(f); + ++ mutex_unlock(&file->device->xrcd_tree_mutex); ++ + uobj_alloc_commit(&obj->uobject); + +- mutex_unlock(&file->device->xrcd_tree_mutex); + return in_len; + + err_copy: diff --git a/queue-4.14/rdma-uverbs-protect-from-command-mask-overflow.patch b/queue-4.14/rdma-uverbs-protect-from-command-mask-overflow.patch new file mode 100644 index 00000000000..02b85c522c3 --- /dev/null +++ b/queue-4.14/rdma-uverbs-protect-from-command-mask-overflow.patch @@ -0,0 +1,134 @@ +From 3f802b162dbf4a558ff98986449eddc717826209 Mon Sep 17 00:00:00 2001 +From: Leon Romanovsky +Date: Tue, 13 Feb 2018 12:18:41 +0200 +Subject: RDMA/uverbs: Protect from command mask overflow + +From: Leon Romanovsky + +commit 3f802b162dbf4a558ff98986449eddc717826209 upstream. + +The command number is not bounds checked against the command mask before it +is shifted, resulting in an ubsan hit. This does not cause malfunction since +the command number is eventually bounds checked, but we can make this ubsan +clean by moving the bounds check to before the mask check. + +================================================================================ +UBSAN: Undefined behaviour in +drivers/infiniband/core/uverbs_main.c:647:21 +shift exponent 207 is too large for 64-bit type 'long long unsigned int' +CPU: 0 PID: 446 Comm: syz-executor3 Not tainted 4.15.0-rc2+ #61 +Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS +rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014 +Call Trace: +dump_stack+0xde/0x164 +? dma_virt_map_sg+0x22c/0x22c +ubsan_epilogue+0xe/0x81 +__ubsan_handle_shift_out_of_bounds+0x293/0x2f7 +? debug_check_no_locks_freed+0x340/0x340 +? __ubsan_handle_load_invalid_value+0x19b/0x19b +? lock_acquire+0x440/0x440 +? lock_acquire+0x19d/0x440 +? __might_fault+0xf4/0x240 +? ib_uverbs_write+0x68d/0xe20 +ib_uverbs_write+0x68d/0xe20 +? __lock_acquire+0xcf7/0x3940 +? uverbs_devnode+0x110/0x110 +? cyc2ns_read_end+0x10/0x10 +? sched_clock_cpu+0x18/0x200 +? sched_clock_cpu+0x18/0x200 +__vfs_write+0x10d/0x700 +? uverbs_devnode+0x110/0x110 +? kernel_read+0x170/0x170 +? __fget+0x35b/0x5d0 +? security_file_permission+0x93/0x260 +vfs_write+0x1b0/0x550 +SyS_write+0xc7/0x1a0 +? SyS_read+0x1a0/0x1a0 +? trace_hardirqs_on_thunk+0x1a/0x1c +entry_SYSCALL_64_fastpath+0x18/0x85 +RIP: 0033:0x448e29 +RSP: 002b:00007f033f567c58 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 +RAX: ffffffffffffffda RBX: 00007f033f5686bc RCX: 0000000000448e29 +RDX: 0000000000000060 RSI: 0000000020001000 RDI: 0000000000000012 +RBP: 000000000070bea0 R08: 0000000000000000 R09: 0000000000000000 +R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff +R13: 00000000000056a0 R14: 00000000006e8740 R15: 0000000000000000 +================================================================================ + +Cc: syzkaller +Cc: # 4.5 +Fixes: 2dbd5186a39c ("IB/core: IB/core: Allow legacy verbs through extended interfaces") +Reported-by: Noa Osherovich +Reviewed-by: Matan Barak +Signed-off-by: Leon Romanovsky +Signed-off-by: Jason Gunthorpe +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/infiniband/core/uverbs_main.c | 27 ++++++++++++++++++++------- + 1 file changed, 20 insertions(+), 7 deletions(-) + +--- a/drivers/infiniband/core/uverbs_main.c ++++ b/drivers/infiniband/core/uverbs_main.c +@@ -647,12 +647,21 @@ static int verify_command_mask(struct ib + return -1; + } + ++static bool verify_command_idx(u32 command, bool extended) ++{ ++ if (extended) ++ return command < ARRAY_SIZE(uverbs_ex_cmd_table); ++ ++ return command < ARRAY_SIZE(uverbs_cmd_table); ++} ++ + static ssize_t ib_uverbs_write(struct file *filp, const char __user *buf, + size_t count, loff_t *pos) + { + struct ib_uverbs_file *file = filp->private_data; + struct ib_device *ib_dev; + struct ib_uverbs_cmd_hdr hdr; ++ bool extended_command; + __u32 command; + __u32 flags; + int srcu_key; +@@ -685,6 +694,15 @@ static ssize_t ib_uverbs_write(struct fi + } + + command = hdr.command & IB_USER_VERBS_CMD_COMMAND_MASK; ++ flags = (hdr.command & ++ IB_USER_VERBS_CMD_FLAGS_MASK) >> IB_USER_VERBS_CMD_FLAGS_SHIFT; ++ ++ extended_command = flags & IB_USER_VERBS_CMD_FLAG_EXTENDED; ++ if (!verify_command_idx(command, extended_command)) { ++ ret = -EINVAL; ++ goto out; ++ } ++ + if (verify_command_mask(ib_dev, command)) { + ret = -EOPNOTSUPP; + goto out; +@@ -696,12 +714,8 @@ static ssize_t ib_uverbs_write(struct fi + goto out; + } + +- flags = (hdr.command & +- IB_USER_VERBS_CMD_FLAGS_MASK) >> IB_USER_VERBS_CMD_FLAGS_SHIFT; +- + if (!flags) { +- if (command >= ARRAY_SIZE(uverbs_cmd_table) || +- !uverbs_cmd_table[command]) { ++ if (!uverbs_cmd_table[command]) { + ret = -EINVAL; + goto out; + } +@@ -722,8 +736,7 @@ static ssize_t ib_uverbs_write(struct fi + struct ib_udata uhw; + size_t written_count = count; + +- if (command >= ARRAY_SIZE(uverbs_ex_cmd_table) || +- !uverbs_ex_cmd_table[command]) { ++ if (!uverbs_ex_cmd_table[command]) { + ret = -ENOSYS; + goto out; + } diff --git a/queue-4.14/rdma-uverbs-protect-from-races-between-lookup-and-destroy-of-uobjects.patch b/queue-4.14/rdma-uverbs-protect-from-races-between-lookup-and-destroy-of-uobjects.patch new file mode 100644 index 00000000000..9f1b83246e8 --- /dev/null +++ b/queue-4.14/rdma-uverbs-protect-from-races-between-lookup-and-destroy-of-uobjects.patch @@ -0,0 +1,161 @@ +From 6623e3e3cd78020016d3fa42555763178e94ab64 Mon Sep 17 00:00:00 2001 +From: Leon Romanovsky +Date: Tue, 13 Feb 2018 12:18:37 +0200 +Subject: RDMA/uverbs: Protect from races between lookup and destroy of uobjects + +From: Leon Romanovsky + +commit 6623e3e3cd78020016d3fa42555763178e94ab64 upstream. + +The race is between lookup_get_idr_uobject and +uverbs_idr_remove_uobj -> uverbs_uobject_put. + +We deliberately do not call sychronize_rcu after the idr_remove in +uverbs_idr_remove_uobj for performance reasons, instead we call +kfree_rcu() during uverbs_uobject_put. + +However, this means we can obtain pointers to uobj's that have +already been released and must protect against krefing them +using kref_get_unless_zero. + +================================================================== +BUG: KASAN: use-after-free in copy_ah_attr_from_uverbs.isra.2+0x860/0xa00 +Read of size 4 at addr ffff88005fda1ac8 by task syz-executor2/441 + +CPU: 1 PID: 441 Comm: syz-executor2 Not tainted 4.15.0-rc2+ #56 +Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS +rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014 +Call Trace: +dump_stack+0x8d/0xd4 +print_address_description+0x73/0x290 +kasan_report+0x25c/0x370 +? copy_ah_attr_from_uverbs.isra.2+0x860/0xa00 +copy_ah_attr_from_uverbs.isra.2+0x860/0xa00 +? uverbs_try_lock_object+0x68/0xc0 +? modify_qp.isra.7+0xdc4/0x10e0 +modify_qp.isra.7+0xdc4/0x10e0 +ib_uverbs_modify_qp+0xfe/0x170 +? ib_uverbs_query_qp+0x970/0x970 +? __lock_acquire+0xa11/0x1da0 +ib_uverbs_write+0x55a/0xad0 +? ib_uverbs_query_qp+0x970/0x970 +? ib_uverbs_query_qp+0x970/0x970 +? ib_uverbs_open+0x760/0x760 +? futex_wake+0x147/0x410 +? sched_clock_cpu+0x18/0x180 +? check_prev_add+0x1680/0x1680 +? do_futex+0x3b6/0xa30 +? sched_clock_cpu+0x18/0x180 +__vfs_write+0xf7/0x5c0 +? ib_uverbs_open+0x760/0x760 +? kernel_read+0x110/0x110 +? lock_acquire+0x370/0x370 +? __fget+0x264/0x3b0 +vfs_write+0x18a/0x460 +SyS_write+0xc7/0x1a0 +? SyS_read+0x1a0/0x1a0 +? trace_hardirqs_on_thunk+0x1a/0x1c +entry_SYSCALL_64_fastpath+0x18/0x85 +RIP: 0033:0x448e29 +RSP: 002b:00007f443fee0c58 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 +RAX: ffffffffffffffda RBX: 00007f443fee16bc RCX: 0000000000448e29 +RDX: 0000000000000078 RSI: 00000000209f8000 RDI: 0000000000000012 +RBP: 000000000070bea0 R08: 0000000000000000 R09: 0000000000000000 +R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff +R13: 0000000000008e98 R14: 00000000006ebf38 R15: 0000000000000000 + +Allocated by task 1: +kmem_cache_alloc_trace+0x16c/0x2f0 +mlx5_alloc_cmd_msg+0x12e/0x670 +cmd_exec+0x419/0x1810 +mlx5_cmd_exec+0x40/0x70 +mlx5_core_mad_ifc+0x187/0x220 +mlx5_MAD_IFC+0xd7/0x1b0 +mlx5_query_mad_ifc_gids+0x1f3/0x650 +mlx5_ib_query_gid+0xa4/0xc0 +ib_query_gid+0x152/0x1a0 +ib_query_port+0x21e/0x290 +mlx5_port_immutable+0x30f/0x490 +ib_register_device+0x5dd/0x1130 +mlx5_ib_add+0x3e7/0x700 +mlx5_add_device+0x124/0x510 +mlx5_register_interface+0x11f/0x1c0 +mlx5_ib_init+0x56/0x61 +do_one_initcall+0xa3/0x250 +kernel_init_freeable+0x309/0x3b8 +kernel_init+0x14/0x180 +ret_from_fork+0x24/0x30 + +Freed by task 1: +kfree+0xeb/0x2f0 +mlx5_free_cmd_msg+0xcd/0x140 +cmd_exec+0xeba/0x1810 +mlx5_cmd_exec+0x40/0x70 +mlx5_core_mad_ifc+0x187/0x220 +mlx5_MAD_IFC+0xd7/0x1b0 +mlx5_query_mad_ifc_gids+0x1f3/0x650 +mlx5_ib_query_gid+0xa4/0xc0 +ib_query_gid+0x152/0x1a0 +ib_query_port+0x21e/0x290 +mlx5_port_immutable+0x30f/0x490 +ib_register_device+0x5dd/0x1130 +mlx5_ib_add+0x3e7/0x700 +mlx5_add_device+0x124/0x510 +mlx5_register_interface+0x11f/0x1c0 +mlx5_ib_init+0x56/0x61 +do_one_initcall+0xa3/0x250 +kernel_init_freeable+0x309/0x3b8 +kernel_init+0x14/0x180 +ret_from_fork+0x24/0x30 + +The buggy address belongs to the object at ffff88005fda1ab0 +which belongs to the cache kmalloc-32 of size 32 +The buggy address is located 24 bytes inside of +32-byte region [ffff88005fda1ab0, ffff88005fda1ad0) +The buggy address belongs to the page: +page:00000000d5655c19 count:1 mapcount:0 mapping: (null) +index:0xffff88005fda1fc0 +flags: 0x4000000000000100(slab) +raw: 4000000000000100 0000000000000000 ffff88005fda1fc0 0000000180550008 +raw: ffffea00017f6780 0000000400000004 ffff88006c803980 0000000000000000 +page dumped because: kasan: bad access detected + +Memory state around the buggy address: +ffff88005fda1980: fc fc fb fb fb fb fc fc fb fb fb fb fc fc fb fb +ffff88005fda1a00: fb fb fc fc fb fb fb fb fc fc 00 00 00 00 fc fc +ffff88005fda1a80: fb fb fb fb fc fc fb fb fb fb fc fc fb fb fb fb +ffff88005fda1b00: fc fc 00 00 00 00 fc fc fb fb fb fb fc fc fb fb +ffff88005fda1b80: fb fb fc fc fb fb fb fb fc fc fb fb fb fb fc fc +==================================================================@ + +Cc: syzkaller +Cc: # 4.11 +Fixes: 3832125624b7 ("IB/core: Add support for idr types") +Reported-by: Noa Osherovich +Signed-off-by: Leon Romanovsky +Signed-off-by: Jason Gunthorpe +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/infiniband/core/rdma_core.c | 10 +++++++++- + 1 file changed, 9 insertions(+), 1 deletion(-) + +--- a/drivers/infiniband/core/rdma_core.c ++++ b/drivers/infiniband/core/rdma_core.c +@@ -196,7 +196,15 @@ static struct ib_uobject *lookup_get_idr + goto free; + } + +- uverbs_uobject_get(uobj); ++ /* ++ * The idr_find is guaranteed to return a pointer to something that ++ * isn't freed yet, or NULL, as the free after idr_remove goes through ++ * kfree_rcu(). However the object may still have been released and ++ * kfree() could be called at any time. ++ */ ++ if (!kref_get_unless_zero(&uobj->ref)) ++ uobj = ERR_PTR(-ENOENT); ++ + free: + rcu_read_unlock(); + return uobj; diff --git a/queue-4.14/rdma-uverbs-sanitize-user-entered-port-numbers-prior-to-access-it.patch b/queue-4.14/rdma-uverbs-sanitize-user-entered-port-numbers-prior-to-access-it.patch new file mode 100644 index 00000000000..8d878e0283e --- /dev/null +++ b/queue-4.14/rdma-uverbs-sanitize-user-entered-port-numbers-prior-to-access-it.patch @@ -0,0 +1,133 @@ +From 5d4c05c3ee36f67ddc107ab5ea0898af01a62cc1 Mon Sep 17 00:00:00 2001 +From: Leon Romanovsky +Date: Wed, 14 Feb 2018 12:35:40 +0200 +Subject: RDMA/uverbs: Sanitize user entered port numbers prior to access it + +From: Leon Romanovsky + +commit 5d4c05c3ee36f67ddc107ab5ea0898af01a62cc1 upstream. + +================================================================== +BUG: KASAN: use-after-free in copy_ah_attr_from_uverbs+0x6f2/0x8c0 +Read of size 4 at addr ffff88006476a198 by task syzkaller697701/265 + +CPU: 0 PID: 265 Comm: syzkaller697701 Not tainted 4.15.0+ #90 +Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014 +Call Trace: + dump_stack+0xde/0x164 + ? dma_virt_map_sg+0x22c/0x22c + ? show_regs_print_info+0x17/0x17 + ? lock_contended+0x11a0/0x11a0 + print_address_description+0x83/0x3e0 + kasan_report+0x18c/0x4b0 + ? copy_ah_attr_from_uverbs+0x6f2/0x8c0 + ? copy_ah_attr_from_uverbs+0x6f2/0x8c0 + ? lookup_get_idr_uobject+0x120/0x200 + ? copy_ah_attr_from_uverbs+0x6f2/0x8c0 + copy_ah_attr_from_uverbs+0x6f2/0x8c0 + ? modify_qp+0xd0e/0x1350 + modify_qp+0xd0e/0x1350 + ib_uverbs_modify_qp+0xf9/0x170 + ? ib_uverbs_query_qp+0xa70/0xa70 + ib_uverbs_write+0x7f9/0xef0 + ? attach_entity_load_avg+0x8b0/0x8b0 + ? ib_uverbs_query_qp+0xa70/0xa70 + ? uverbs_devnode+0x110/0x110 + ? cyc2ns_read_end+0x10/0x10 + ? print_irqtrace_events+0x280/0x280 + ? sched_clock_cpu+0x18/0x200 + ? _raw_spin_unlock_irq+0x29/0x40 + ? _raw_spin_unlock_irq+0x29/0x40 + ? _raw_spin_unlock_irq+0x29/0x40 + ? time_hardirqs_on+0x27/0x670 + __vfs_write+0x10d/0x700 + ? uverbs_devnode+0x110/0x110 + ? kernel_read+0x170/0x170 + ? _raw_spin_unlock_irq+0x29/0x40 + ? finish_task_switch+0x1bd/0x7a0 + ? finish_task_switch+0x194/0x7a0 + ? prandom_u32_state+0xe/0x180 + ? rcu_read_unlock+0x80/0x80 + ? security_file_permission+0x93/0x260 + vfs_write+0x1b0/0x550 + SyS_write+0xc7/0x1a0 + ? SyS_read+0x1a0/0x1a0 + ? trace_hardirqs_on_thunk+0x1a/0x1c + entry_SYSCALL_64_fastpath+0x1e/0x8b +RIP: 0033:0x433c29 +RSP: 002b:00007ffcf2be82a8 EFLAGS: 00000217 + +Allocated by task 62: + kasan_kmalloc+0xa0/0xd0 + kmem_cache_alloc+0x141/0x480 + dup_fd+0x101/0xcc0 + copy_process.part.62+0x166f/0x4390 + _do_fork+0x1cb/0xe90 + kernel_thread+0x34/0x40 + call_usermodehelper_exec_work+0x112/0x260 + process_one_work+0x929/0x1aa0 + worker_thread+0x5c6/0x12a0 + kthread+0x346/0x510 + ret_from_fork+0x3a/0x50 + +Freed by task 259: + kasan_slab_free+0x71/0xc0 + kmem_cache_free+0xf3/0x4c0 + put_files_struct+0x225/0x2c0 + exit_files+0x88/0xc0 + do_exit+0x67c/0x1520 + do_group_exit+0xe8/0x380 + SyS_exit_group+0x1e/0x20 + entry_SYSCALL_64_fastpath+0x1e/0x8b + +The buggy address belongs to the object at ffff88006476a000 + which belongs to the cache files_cache of size 832 +The buggy address is located 408 bytes inside of + 832-byte region [ffff88006476a000, ffff88006476a340) +The buggy address belongs to the page: +page:ffffea000191da80 count:1 mapcount:0 mapping: (null) index:0x0 compound_mapcount: 0 +flags: 0x4000000000008100(slab|head) +raw: 4000000000008100 0000000000000000 0000000000000000 0000000100080008 +raw: 0000000000000000 0000000100000001 ffff88006bcf7a80 0000000000000000 +page dumped because: kasan: bad access detected + +Memory state around the buggy address: + ffff88006476a080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb + ffff88006476a100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb +>ffff88006476a180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb + ^ + ffff88006476a200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb + ffff88006476a280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb +================================================================== + +Cc: syzkaller +Cc: # 4.11 +Fixes: 44c58487d51a ("IB/core: Define 'ib' and 'roce' rdma_ah_attr types") +Reported-by: Noa Osherovich +Signed-off-by: Leon Romanovsky +Signed-off-by: Jason Gunthorpe +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/infiniband/core/uverbs_cmd.c | 9 ++++++++- + 1 file changed, 8 insertions(+), 1 deletion(-) + +--- a/drivers/infiniband/core/uverbs_cmd.c ++++ b/drivers/infiniband/core/uverbs_cmd.c +@@ -1981,8 +1981,15 @@ static int modify_qp(struct ib_uverbs_fi + goto release_qp; + } + ++ if ((cmd->base.attr_mask & IB_QP_AV) && ++ !rdma_is_port_valid(qp->device, cmd->base.dest.port_num)) { ++ ret = -EINVAL; ++ goto release_qp; ++ } ++ + if ((cmd->base.attr_mask & IB_QP_ALT_PATH) && +- !rdma_is_port_valid(qp->device, cmd->base.alt_port_num)) { ++ (!rdma_is_port_valid(qp->device, cmd->base.alt_port_num) || ++ !rdma_is_port_valid(qp->device, cmd->base.alt_dest.port_num))) { + ret = -EINVAL; + goto release_qp; + } diff --git a/queue-4.14/revert-usb-musb-host-don-t-start-next-rx-urb-if-current-one-failed.patch b/queue-4.14/revert-usb-musb-host-don-t-start-next-rx-urb-if-current-one-failed.patch new file mode 100644 index 00000000000..24e328c35b9 --- /dev/null +++ b/queue-4.14/revert-usb-musb-host-don-t-start-next-rx-urb-if-current-one-failed.patch @@ -0,0 +1,44 @@ +From 44eb5e12b845cc8a0634f21b70ef07d774eb4b25 Mon Sep 17 00:00:00 2001 +From: Bin Liu +Date: Tue, 20 Feb 2018 07:31:35 -0600 +Subject: Revert "usb: musb: host: don't start next rx urb if current one failed" + +From: Bin Liu + +commit 44eb5e12b845cc8a0634f21b70ef07d774eb4b25 upstream. + +This reverts commit dbac5d07d13e330e6706813c9fde477140fb5d80. + +commit dbac5d07d13e ("usb: musb: host: don't start next rx urb if current one failed") +along with commit b5801212229f ("usb: musb: host: clear rxcsr error bit if set") +try to solve the issue described in [1], but the latter alone is +sufficient, and the former causes the issue as in [2], so now revert it. + +[1] https://marc.info/?l=linux-usb&m=146173995117456&w=2 +[2] https://marc.info/?l=linux-usb&m=151689238420622&w=2 + +Cc: stable@vger.kernel.org # v4.7+ +Signed-off-by: Bin Liu +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/musb/musb_host.c | 8 +------- + 1 file changed, 1 insertion(+), 7 deletions(-) + +--- a/drivers/usb/musb/musb_host.c ++++ b/drivers/usb/musb/musb_host.c +@@ -418,13 +418,7 @@ static void musb_advance_schedule(struct + } + } + +- /* +- * The pipe must be broken if current urb->status is set, so don't +- * start next urb. +- * TODO: to minimize the risk of regression, only check urb->status +- * for RX, until we have a test case to understand the behavior of TX. +- */ +- if ((!status || !is_in) && qh && qh->is_ready) { ++ if (qh != NULL && qh->is_ready) { + musb_dbg(musb, "... next ep%d %cX urb %p", + hw_ep->epnum, is_in ? 'R' : 'T', next_urb(qh)); + musb_start_urb(musb, is_in, qh); diff --git a/queue-4.14/scsi-ibmvfc-fix-misdefined-reserved-field-in-ibmvfc_fcp_rsp_info.patch b/queue-4.14/scsi-ibmvfc-fix-misdefined-reserved-field-in-ibmvfc_fcp_rsp_info.patch new file mode 100644 index 00000000000..f7335dbc67b --- /dev/null +++ b/queue-4.14/scsi-ibmvfc-fix-misdefined-reserved-field-in-ibmvfc_fcp_rsp_info.patch @@ -0,0 +1,42 @@ +From c39813652700f3df552b6557530f1e5f782dbe2f Mon Sep 17 00:00:00 2001 +From: Tyrel Datwyler +Date: Tue, 23 Jan 2018 20:11:32 -0600 +Subject: scsi: ibmvfc: fix misdefined reserved field in ibmvfc_fcp_rsp_info + +From: Tyrel Datwyler + +commit c39813652700f3df552b6557530f1e5f782dbe2f upstream. + +The fcp_rsp_info structure as defined in the FC spec has an initial 3 +bytes reserved field. The ibmvfc driver mistakenly defined this field as +4 bytes resulting in the rsp_code field being defined in what should be +the start of the second reserved field and thus always being reported as +zero by the driver. + +Ideally, we should wire ibmvfc up with libfc for the sake of code +deduplication, and ease of maintaining standardized structures in a +single place. However, for now simply fixup the definition in ibmvfc for +backporting to distros on older kernels. Wiring up with libfc will be +done in a followup patch. + +Cc: +Reported-by: Hannes Reinecke +Signed-off-by: Tyrel Datwyler +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/scsi/ibmvscsi/ibmvfc.h | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/scsi/ibmvscsi/ibmvfc.h ++++ b/drivers/scsi/ibmvscsi/ibmvfc.h +@@ -367,7 +367,7 @@ enum ibmvfc_fcp_rsp_info_codes { + }; + + struct ibmvfc_fcp_rsp_info { +- __be16 reserved; ++ u8 reserved[3]; + u8 rsp_code; + u8 reserved2[4]; + }__attribute__((packed, aligned (2))); diff --git a/queue-4.14/series b/queue-4.14/series index d0c5fd2acf6..280ec4f75a4 100644 --- a/queue-4.14/series +++ b/queue-4.14/series @@ -2,3 +2,52 @@ netfilter-drop-outermost-socket-lock-in-getsockopt.patch arm64-mm-don-t-write-garbage-into-ttbr1_el1-register.patch kconfig.h-include-compiler-types-to-avoid-missed-struct-attributes.patch mips-boot-define-__assembly__-for-its.s-build.patch +xtensa-fix-high-memory-reserved-memory-collision.patch +scsi-ibmvfc-fix-misdefined-reserved-field-in-ibmvfc_fcp_rsp_info.patch +mips-drop-spurious-__unused-in-struct-compat_flock.patch +cfg80211-fix-cfg80211_beacon_dup.patch +i2c-designware-must-wait-for-enable.patch +i2c-bcm2835-set-up-the-rising-falling-edge-delays.patch +x.509-fix-bug_on-when-hash-algorithm-is-unsupported.patch +x.509-fix-null-dereference-when-restricting-key-with-unsupported_sig.patch +pkcs-7-fix-certificate-chain-verification.patch +pkcs-7-fix-certificate-blacklisting.patch +extcon-int3496-process-id-pin-first-so-that-we-start-with-the-right-status.patch +rdma-uverbs-protect-from-races-between-lookup-and-destroy-of-uobjects.patch +rdma-uverbs-protect-from-command-mask-overflow.patch +rdma-uverbs-fix-bad-unlock-balance-in-ib_uverbs_close_xrcd.patch +rdma-uverbs-fix-circular-locking-dependency.patch +rdma-uverbs-sanitize-user-entered-port-numbers-prior-to-access-it.patch +iio-adc-stm32-fix-stm32h7_adc_enable-error-handling.patch +iio-srf08-fix-link-error-devm_iio_triggered_buffer_setup-undefined.patch +iio-buffer-check-if-a-buffer-has-been-set-up-when-poll-is-called.patch +iio-adis_lib-initialize-trigger-before-requesting-interrupt.patch +kbuild-always-define-endianess-in-kconfig.h.patch +x86-oprofile-fix-bogus-gcc-8-warning-in-nmi_setup.patch +mm-swap-frontswap-fix-thp-swap-if-frontswap-enabled.patch +irqchip-gic-v3-use-wmb-instead-of-smb_wmb-in-gic_raise_softirq.patch +irqchip-mips-gic-avoid-spuriously-handling-masked-interrupts.patch +pci-cxgb4-extend-t3-pci-quirk-to-t4-devices.patch +ohci-hcd-fix-race-condition-caused-by-ohci_urb_enqueue-and-io_watchdog_func.patch +usb-ohci-proper-handling-of-ed_rm_list-to-handle-race-condition-between-usb_kill_urb-and-finish_unlinks.patch +arm64-remove-unimplemented-syscall-log-message.patch +arm64-disable-unhandled-signal-log-messages-by-default.patch +arm64-cpufeature-fix-ctr_el0-field-definitions.patch +add-delay-init-quirk-for-corsair-k70-rgb-keyboards.patch +drm-edid-add-6-bpc-quirk-for-cpt-panel-in-asus-ux303la.patch +usb-host-ehci-use-correct-device-pointer-for-dma-ops.patch +usb-dwc3-gadget-set-maxpacket-size-for-ep0-in.patch +usb-dwc3-ep0-reset-trb-counter-for-ep0-in.patch +usb-ldusb-add-pids-for-new-cassy-devices-supported-by-this-driver.patch +revert-usb-musb-host-don-t-start-next-rx-urb-if-current-one-failed.patch +usb-gadget-f_fs-process-all-descriptors-during-bind.patch +usb-gadget-f_fs-use-config_ep_by_speed.patch +usb-renesas_usbhs-missed-the-running-flag-in-usb_dmac-with-rx-path.patch +drm-cirrus-load-lut-in-crtc_commit.patch +drm-handle-unexpected-holes-in-color-eviction.patch +drm-amdgpu-disable-mmhub-power-gating-on-raven.patch +drm-amdgpu-add-dpm-quirk-for-jet-pro-v2.patch +drm-amdgpu-only-check-mmbif_iov_func_identifier-on-tonga-fiji.patch +drm-amdgpu-add-atpx-quirk-handling-v2.patch +drm-amdgpu-avoid-leaking-pm-domain-on-driver-unbind-v2.patch +drm-amdgpu-add-new-device-to-use-atpx-quirk.patch diff --git a/queue-4.14/usb-dwc3-ep0-reset-trb-counter-for-ep0-in.patch b/queue-4.14/usb-dwc3-ep0-reset-trb-counter-for-ep0-in.patch new file mode 100644 index 00000000000..a11c0582453 --- /dev/null +++ b/queue-4.14/usb-dwc3-ep0-reset-trb-counter-for-ep0-in.patch @@ -0,0 +1,41 @@ +From f035d139ffece7b6a7b8bfb17bd0ba715ee57a04 Mon Sep 17 00:00:00 2001 +From: Thinh Nguyen +Date: Fri, 12 Jan 2018 18:18:27 -0800 +Subject: usb: dwc3: ep0: Reset TRB counter for ep0 IN + +From: Thinh Nguyen + +commit f035d139ffece7b6a7b8bfb17bd0ba715ee57a04 upstream. + +DWC3 tracks TRB counter for each ep0 direction separately. In control +read transfer completion handler, the driver needs to reset the TRB +enqueue counter for ep0 IN direction. Currently the driver only resets +the TRB counter for control OUT endpoint. Check for the data direction +and properly reset the TRB counter from correct control endpoint. + +Cc: stable@vger.kernel.org +Fixes: c2da2ff00606 ("usb: dwc3: ep0: don't use ep0in for transfers") +Signed-off-by: Thinh Nguyen +Signed-off-by: Felipe Balbi +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/dwc3/ep0.c | 7 ++++++- + 1 file changed, 6 insertions(+), 1 deletion(-) + +--- a/drivers/usb/dwc3/ep0.c ++++ b/drivers/usb/dwc3/ep0.c +@@ -884,7 +884,12 @@ static void dwc3_ep0_complete_data(struc + trb++; + trb->ctrl &= ~DWC3_TRB_CTRL_HWO; + trace_dwc3_complete_trb(ep0, trb); +- ep0->trb_enqueue = 0; ++ ++ if (r->direction) ++ dwc->eps[1]->trb_enqueue = 0; ++ else ++ dwc->eps[0]->trb_enqueue = 0; ++ + dwc->ep0_bounced = false; + } + diff --git a/queue-4.14/usb-dwc3-gadget-set-maxpacket-size-for-ep0-in.patch b/queue-4.14/usb-dwc3-gadget-set-maxpacket-size-for-ep0-in.patch new file mode 100644 index 00000000000..5611f9783e9 --- /dev/null +++ b/queue-4.14/usb-dwc3-gadget-set-maxpacket-size-for-ep0-in.patch @@ -0,0 +1,41 @@ +From 6180026341e852a250e1f97ebdcf71684a3c81b9 Mon Sep 17 00:00:00 2001 +From: Thinh Nguyen +Date: Fri, 12 Jan 2018 18:18:05 -0800 +Subject: usb: dwc3: gadget: Set maxpacket size for ep0 IN + +From: Thinh Nguyen + +commit 6180026341e852a250e1f97ebdcf71684a3c81b9 upstream. + +There are 2 control endpoint structures for DWC3. However, the driver +only updates the OUT direction control endpoint structure during +ConnectDone event. DWC3 driver needs to update the endpoint max packet +size for control IN endpoint as well. If the max packet size is not +properly set, then the driver will incorrectly calculate the data +transfer size and fail to send ZLP for HS/FS 3-stage control read +transfer. + +The fix is simply to update the max packet size for the ep0 IN direction +during ConnectDone event. + +Cc: stable@vger.kernel.org +Fixes: 72246da40f37 ("usb: Introduce DesignWare USB3 DRD Driver") +Signed-off-by: Thinh Nguyen +Signed-off-by: Felipe Balbi +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/dwc3/gadget.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/drivers/usb/dwc3/gadget.c ++++ b/drivers/usb/dwc3/gadget.c +@@ -2774,6 +2774,8 @@ static void dwc3_gadget_conndone_interru + break; + } + ++ dwc->eps[1]->endpoint.maxpacket = dwc->gadget.ep0->maxpacket; ++ + /* Enable USB2 LPM Capability */ + + if ((dwc->revision > DWC3_REVISION_194A) && diff --git a/queue-4.14/usb-gadget-f_fs-process-all-descriptors-during-bind.patch b/queue-4.14/usb-gadget-f_fs-process-all-descriptors-during-bind.patch new file mode 100644 index 00000000000..4ad5b85cd24 --- /dev/null +++ b/queue-4.14/usb-gadget-f_fs-process-all-descriptors-during-bind.patch @@ -0,0 +1,55 @@ +From 6cf439e0d37463e42784271179c8a308fd7493c6 Mon Sep 17 00:00:00 2001 +From: Jack Pham +Date: Wed, 24 Jan 2018 00:11:53 -0800 +Subject: usb: gadget: f_fs: Process all descriptors during bind + +From: Jack Pham + +commit 6cf439e0d37463e42784271179c8a308fd7493c6 upstream. + +During _ffs_func_bind(), the received descriptors are evaluated +to prepare for binding with the gadget in order to allocate +endpoints and optionally set up OS descriptors. However, the +high- and super-speed descriptors are only parsed based on +whether the gadget_is_dualspeed() and gadget_is_superspeed() +calls are true, respectively. + +This is a problem in case a userspace program always provides +all of the {full,high,super,OS} descriptors when configuring a +function. Then, for example if a gadget device is not capable +of SuperSpeed, the call to ffs_do_descs() for the SS descriptors +is skipped, resulting in an incorrect offset calculation for +the vla_ptr when moving on to the OS descriptors that follow. +This causes ffs_do_os_descs() to fail as it is now looking at +the SS descriptors' offset within the raw_descs buffer instead. + +_ffs_func_bind() should evaluate the descriptors unconditionally, +so remove the checks for gadget speed. + +Fixes: f0175ab51993 ("usb: gadget: f_fs: OS descriptors support") +Cc: stable@vger.kernel.org +Co-Developed-by: Mayank Rana +Signed-off-by: Mayank Rana +Signed-off-by: Jack Pham +Signed-off-by: Felipe Balbi +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/gadget/function/f_fs.c | 6 ++---- + 1 file changed, 2 insertions(+), 4 deletions(-) + +--- a/drivers/usb/gadget/function/f_fs.c ++++ b/drivers/usb/gadget/function/f_fs.c +@@ -2980,10 +2980,8 @@ static int _ffs_func_bind(struct usb_con + struct ffs_data *ffs = func->ffs; + + const int full = !!func->ffs->fs_descs_count; +- const int high = gadget_is_dualspeed(func->gadget) && +- func->ffs->hs_descs_count; +- const int super = gadget_is_superspeed(func->gadget) && +- func->ffs->ss_descs_count; ++ const int high = !!func->ffs->hs_descs_count; ++ const int super = !!func->ffs->ss_descs_count; + + int fs_len, hs_len, ss_len, ret, i; + struct ffs_ep *eps_ptr; diff --git a/queue-4.14/usb-gadget-f_fs-use-config_ep_by_speed.patch b/queue-4.14/usb-gadget-f_fs-use-config_ep_by_speed.patch new file mode 100644 index 00000000000..69a21959e03 --- /dev/null +++ b/queue-4.14/usb-gadget-f_fs-use-config_ep_by_speed.patch @@ -0,0 +1,95 @@ +From 675272d092e4a5570bace92593776f7348daf4c5 Mon Sep 17 00:00:00 2001 +From: Jack Pham +Date: Wed, 24 Jan 2018 23:58:20 -0800 +Subject: usb: gadget: f_fs: Use config_ep_by_speed() + +From: Jack Pham + +commit 675272d092e4a5570bace92593776f7348daf4c5 upstream. + +In commit 2bfa0719ac2a ("usb: gadget: function: f_fs: pass +companion descriptor along") there is a pointer arithmetic +bug where the comp_desc is obtained as follows: + + comp_desc = (struct usb_ss_ep_comp_descriptor *)(ds + + USB_DT_ENDPOINT_SIZE); + +Since ds is a pointer to usb_endpoint_descriptor, adding +7 to it ends up going out of bounds (7 * sizeof(struct +usb_endpoint_descriptor), which is actually 7*9 bytes) past +the SS descriptor. As a result the maxburst value will be +read incorrectly, and the UDC driver will also get a garbage +comp_desc (assuming it uses it). + +Since Felipe wrote, "Eventually, f_fs.c should be converted +to use config_ep_by_speed() like all other functions, though", +let's finally do it. This allows the other usb_ep fields to +be properly populated, such as maxpacket and mult. It also +eliminates the awkward speed-based descriptor lookup since +config_ep_by_speed() does that already using the ones found +in struct usb_function. + +Fixes: 2bfa0719ac2a ("usb: gadget: function: f_fs: pass companion descriptor along") +Cc: stable@vger.kernel.org +Signed-off-by: Jack Pham +Signed-off-by: Felipe Balbi +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/gadget/function/f_fs.c | 38 ++++++------------------------------- + 1 file changed, 7 insertions(+), 31 deletions(-) + +--- a/drivers/usb/gadget/function/f_fs.c ++++ b/drivers/usb/gadget/function/f_fs.c +@@ -1856,44 +1856,20 @@ static int ffs_func_eps_enable(struct ff + + spin_lock_irqsave(&func->ffs->eps_lock, flags); + while(count--) { +- struct usb_endpoint_descriptor *ds; +- struct usb_ss_ep_comp_descriptor *comp_desc = NULL; +- int needs_comp_desc = false; +- int desc_idx; +- +- if (ffs->gadget->speed == USB_SPEED_SUPER) { +- desc_idx = 2; +- needs_comp_desc = true; +- } else if (ffs->gadget->speed == USB_SPEED_HIGH) +- desc_idx = 1; +- else +- desc_idx = 0; +- +- /* fall-back to lower speed if desc missing for current speed */ +- do { +- ds = ep->descs[desc_idx]; +- } while (!ds && --desc_idx >= 0); +- +- if (!ds) { +- ret = -EINVAL; +- break; +- } +- + ep->ep->driver_data = ep; +- ep->ep->desc = ds; + +- if (needs_comp_desc) { +- comp_desc = (struct usb_ss_ep_comp_descriptor *)(ds + +- USB_DT_ENDPOINT_SIZE); +- ep->ep->maxburst = comp_desc->bMaxBurst + 1; +- ep->ep->comp_desc = comp_desc; ++ ret = config_ep_by_speed(func->gadget, &func->function, ep->ep); ++ if (ret) { ++ pr_err("%s: config_ep_by_speed(%s) returned %d\n", ++ __func__, ep->ep->name, ret); ++ break; + } + + ret = usb_ep_enable(ep->ep); + if (likely(!ret)) { + epfile->ep = ep; +- epfile->in = usb_endpoint_dir_in(ds); +- epfile->isoc = usb_endpoint_xfer_isoc(ds); ++ epfile->in = usb_endpoint_dir_in(ep->ep->desc); ++ epfile->isoc = usb_endpoint_xfer_isoc(ep->ep->desc); + } else { + break; + } diff --git a/queue-4.14/usb-host-ehci-use-correct-device-pointer-for-dma-ops.patch b/queue-4.14/usb-host-ehci-use-correct-device-pointer-for-dma-ops.patch new file mode 100644 index 00000000000..1d2ba329553 --- /dev/null +++ b/queue-4.14/usb-host-ehci-use-correct-device-pointer-for-dma-ops.patch @@ -0,0 +1,41 @@ +From 02a10f061a3f8bca1b37332672f50a107198adbe Mon Sep 17 00:00:00 2001 +From: Peter Chen +Date: Thu, 1 Feb 2018 12:26:43 +0800 +Subject: usb: host: ehci: use correct device pointer for dma ops + +From: Peter Chen + +commit 02a10f061a3f8bca1b37332672f50a107198adbe upstream. + +commit a8c06e407ef9 ("usb: separate out sysdev pointer from usb_bus") +converted to use hcd->self.sysdev for DMA operations instead of +hcd->self.controller, but forgot to do it for hcd test mode. Replace +the correct one in this commit. + +Fixes: a8c06e407ef9 ("usb: separate out sysdev pointer from usb_bus") +Signed-off-by: Peter Chen +Acked-by: Alan Stern +Cc: stable +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/host/ehci-hub.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/usb/host/ehci-hub.c ++++ b/drivers/usb/host/ehci-hub.c +@@ -787,12 +787,12 @@ static struct urb *request_single_step_s + atomic_inc(&urb->use_count); + atomic_inc(&urb->dev->urbnum); + urb->setup_dma = dma_map_single( +- hcd->self.controller, ++ hcd->self.sysdev, + urb->setup_packet, + sizeof(struct usb_ctrlrequest), + DMA_TO_DEVICE); + urb->transfer_dma = dma_map_single( +- hcd->self.controller, ++ hcd->self.sysdev, + urb->transfer_buffer, + urb->transfer_buffer_length, + DMA_FROM_DEVICE); diff --git a/queue-4.14/usb-ldusb-add-pids-for-new-cassy-devices-supported-by-this-driver.patch b/queue-4.14/usb-ldusb-add-pids-for-new-cassy-devices-supported-by-this-driver.patch new file mode 100644 index 00000000000..83c8ceacf77 --- /dev/null +++ b/queue-4.14/usb-ldusb-add-pids-for-new-cassy-devices-supported-by-this-driver.patch @@ -0,0 +1,68 @@ +From 52ad2bd8918158266fc88a05f95429b56b6a33c5 Mon Sep 17 00:00:00 2001 +From: Karsten Koop +Date: Fri, 9 Feb 2018 09:12:06 +0000 +Subject: usb: ldusb: add PIDs for new CASSY devices supported by this driver + +From: Karsten Koop + +commit 52ad2bd8918158266fc88a05f95429b56b6a33c5 upstream. + +This patch adds support for new CASSY devices to the ldusb driver. The +PIDs are also added to the ignore list in hid-quirks. + +Signed-off-by: Karsten Koop +Cc: stable +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/hid/hid-core.c | 3 +++ + drivers/hid/hid-ids.h | 3 +++ + drivers/usb/misc/ldusb.c | 6 ++++++ + 3 files changed, 12 insertions(+) + +--- a/drivers/hid/hid-core.c ++++ b/drivers/hid/hid-core.c +@@ -2716,6 +2716,9 @@ static const struct hid_device_id hid_ig + { HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MICROCASSYTIME) }, + { HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MICROCASSYTEMPERATURE) }, + { HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MICROCASSYPH) }, ++ { HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_POWERANALYSERCASSY) }, ++ { HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_CONVERTERCONTROLLERCASSY) }, ++ { HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MACHINETESTCASSY) }, + { HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_JWM) }, + { HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_DMMP) }, + { HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_UMIP) }, +--- a/drivers/hid/hid-ids.h ++++ b/drivers/hid/hid-ids.h +@@ -634,6 +634,9 @@ + #define USB_DEVICE_ID_LD_MICROCASSYTIME 0x1033 + #define USB_DEVICE_ID_LD_MICROCASSYTEMPERATURE 0x1035 + #define USB_DEVICE_ID_LD_MICROCASSYPH 0x1038 ++#define USB_DEVICE_ID_LD_POWERANALYSERCASSY 0x1040 ++#define USB_DEVICE_ID_LD_CONVERTERCONTROLLERCASSY 0x1042 ++#define USB_DEVICE_ID_LD_MACHINETESTCASSY 0x1043 + #define USB_DEVICE_ID_LD_JWM 0x1080 + #define USB_DEVICE_ID_LD_DMMP 0x1081 + #define USB_DEVICE_ID_LD_UMIP 0x1090 +--- a/drivers/usb/misc/ldusb.c ++++ b/drivers/usb/misc/ldusb.c +@@ -46,6 +46,9 @@ + #define USB_DEVICE_ID_LD_MICROCASSYTIME 0x1033 /* USB Product ID of Micro-CASSY Time (reserved) */ + #define USB_DEVICE_ID_LD_MICROCASSYTEMPERATURE 0x1035 /* USB Product ID of Micro-CASSY Temperature */ + #define USB_DEVICE_ID_LD_MICROCASSYPH 0x1038 /* USB Product ID of Micro-CASSY pH */ ++#define USB_DEVICE_ID_LD_POWERANALYSERCASSY 0x1040 /* USB Product ID of Power Analyser CASSY */ ++#define USB_DEVICE_ID_LD_CONVERTERCONTROLLERCASSY 0x1042 /* USB Product ID of Converter Controller CASSY */ ++#define USB_DEVICE_ID_LD_MACHINETESTCASSY 0x1043 /* USB Product ID of Machine Test CASSY */ + #define USB_DEVICE_ID_LD_JWM 0x1080 /* USB Product ID of Joule and Wattmeter */ + #define USB_DEVICE_ID_LD_DMMP 0x1081 /* USB Product ID of Digital Multimeter P (reserved) */ + #define USB_DEVICE_ID_LD_UMIP 0x1090 /* USB Product ID of UMI P */ +@@ -88,6 +91,9 @@ static const struct usb_device_id ld_usb + { USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MICROCASSYTIME) }, + { USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MICROCASSYTEMPERATURE) }, + { USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MICROCASSYPH) }, ++ { USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_POWERANALYSERCASSY) }, ++ { USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_CONVERTERCONTROLLERCASSY) }, ++ { USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MACHINETESTCASSY) }, + { USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_JWM) }, + { USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_DMMP) }, + { USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_UMIP) }, diff --git a/queue-4.14/usb-ohci-proper-handling-of-ed_rm_list-to-handle-race-condition-between-usb_kill_urb-and-finish_unlinks.patch b/queue-4.14/usb-ohci-proper-handling-of-ed_rm_list-to-handle-race-condition-between-usb_kill_urb-and-finish_unlinks.patch new file mode 100644 index 00000000000..83ff4d10ad4 --- /dev/null +++ b/queue-4.14/usb-ohci-proper-handling-of-ed_rm_list-to-handle-race-condition-between-usb_kill_urb-and-finish_unlinks.patch @@ -0,0 +1,95 @@ +From 46408ea558df13b110e0866b99624384a33bdeba Mon Sep 17 00:00:00 2001 +From: AMAN DEEP +Date: Thu, 8 Feb 2018 11:55:01 +0800 +Subject: usb: ohci: Proper handling of ed_rm_list to handle race condition between usb_kill_urb() and finish_unlinks() + +From: AMAN DEEP + +commit 46408ea558df13b110e0866b99624384a33bdeba upstream. + +There is a race condition between finish_unlinks->finish_urb() function +and usb_kill_urb() in ohci controller case. The finish_urb calls +spin_unlock(&ohci->lock) before usb_hcd_giveback_urb() function call, +then if during this time, usb_kill_urb is called for another endpoint, +then new ed will be added to ed_rm_list at beginning for unlink, and +ed_rm_list will point to newly added. + +When finish_urb() is completed in finish_unlinks() and ed->td_list +becomes empty as in below code (in finish_unlinks() function): + + if (list_empty(&ed->td_list)) { + *last = ed->ed_next; + ed->ed_next = NULL; + } else if (ohci->rh_state == OHCI_RH_RUNNING) { + *last = ed->ed_next; + ed->ed_next = NULL; + ed_schedule(ohci, ed); + } + +The *last = ed->ed_next will make ed_rm_list to point to ed->ed_next +and previously added ed by usb_kill_urb will be left unreferenced by +ed_rm_list. This causes usb_kill_urb() hang forever waiting for +finish_unlink to remove added ed from ed_rm_list. + +The main reason for hang in this race condtion is addition and removal +of ed from ed_rm_list in the beginning during usb_kill_urb and later +last* is modified in finish_unlinks(). + +As suggested by Alan Stern, the solution for proper handling of +ohci->ed_rm_list is to remove ed from the ed_rm_list before finishing +any URBs. Then at the end, we can add ed back to the list if necessary. + +This properly handle the updated ohci->ed_rm_list in usb_kill_urb(). + +Fixes: 977dcfdc6031 ("USB: OHCI: don't lose track of EDs when a controller dies") +Acked-by: Alan Stern +CC: +Signed-off-by: Aman Deep +Signed-off-by: Jeffy Chen +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/host/ohci-q.c | 17 ++++++++++------- + 1 file changed, 10 insertions(+), 7 deletions(-) + +--- a/drivers/usb/host/ohci-q.c ++++ b/drivers/usb/host/ohci-q.c +@@ -1018,6 +1018,8 @@ skip_ed: + * have modified this list. normally it's just prepending + * entries (which we'd ignore), but paranoia won't hurt. + */ ++ *last = ed->ed_next; ++ ed->ed_next = NULL; + modified = 0; + + /* unlink urbs as requested, but rescan the list after +@@ -1076,21 +1078,22 @@ rescan_this: + goto rescan_this; + + /* +- * If no TDs are queued, take ED off the ed_rm_list. ++ * If no TDs are queued, ED is now idle. + * Otherwise, if the HC is running, reschedule. +- * If not, leave it on the list for further dequeues. ++ * If the HC isn't running, add ED back to the ++ * start of the list for later processing. + */ + if (list_empty(&ed->td_list)) { +- *last = ed->ed_next; +- ed->ed_next = NULL; + ed->state = ED_IDLE; + list_del(&ed->in_use_list); + } else if (ohci->rh_state == OHCI_RH_RUNNING) { +- *last = ed->ed_next; +- ed->ed_next = NULL; + ed_schedule(ohci, ed); + } else { +- last = &ed->ed_next; ++ ed->ed_next = ohci->ed_rm_list; ++ ohci->ed_rm_list = ed; ++ /* Don't loop on the same ED */ ++ if (last == &ohci->ed_rm_list) ++ last = &ed->ed_next; + } + + if (modified) diff --git a/queue-4.14/usb-renesas_usbhs-missed-the-running-flag-in-usb_dmac-with-rx-path.patch b/queue-4.14/usb-renesas_usbhs-missed-the-running-flag-in-usb_dmac-with-rx-path.patch new file mode 100644 index 00000000000..07e9ab0c172 --- /dev/null +++ b/queue-4.14/usb-renesas_usbhs-missed-the-running-flag-in-usb_dmac-with-rx-path.patch @@ -0,0 +1,49 @@ +From 17aa31f13cad25daa19d3f923323f552e87bc874 Mon Sep 17 00:00:00 2001 +From: Yoshihiro Shimoda +Date: Mon, 5 Feb 2018 17:12:35 +0900 +Subject: usb: renesas_usbhs: missed the "running" flag in usb_dmac with rx path + +From: Yoshihiro Shimoda + +commit 17aa31f13cad25daa19d3f923323f552e87bc874 upstream. + +This fixes an issue that a gadget driver (usb_f_fs) is possible to +stop rx transactions after the usb-dmac is used because the following +functions missed to set/check the "running" flag. + - usbhsf_dma_prepare_pop_with_usb_dmac() + - usbhsf_dma_pop_done_with_usb_dmac() + +So, if next transaction uses pio, the usbhsf_prepare_pop() can not +start the transaction because the "running" flag is 0. + +Fixes: 8355b2b3082d ("usb: renesas_usbhs: fix the behavior of some usbhs_pkt_handle") +Cc: # v3.19+ +Signed-off-by: Yoshihiro Shimoda +Signed-off-by: Felipe Balbi +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/renesas_usbhs/fifo.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/drivers/usb/renesas_usbhs/fifo.c ++++ b/drivers/usb/renesas_usbhs/fifo.c +@@ -998,6 +998,10 @@ static int usbhsf_dma_prepare_pop_with_u + if ((uintptr_t)pkt->buf & (USBHS_USB_DMAC_XFER_SIZE - 1)) + goto usbhsf_pio_prepare_pop; + ++ /* return at this time if the pipe is running */ ++ if (usbhs_pipe_is_running(pipe)) ++ return 0; ++ + usbhs_pipe_config_change_bfre(pipe, 1); + + ret = usbhsf_fifo_select(pipe, fifo, 0); +@@ -1188,6 +1192,7 @@ static int usbhsf_dma_pop_done_with_usb_ + usbhsf_fifo_clear(pipe, fifo); + pkt->actual = usbhs_dma_calc_received_size(pkt, chan, rcv_len); + ++ usbhs_pipe_running(pipe, 0); + usbhsf_dma_stop(pipe, fifo); + usbhsf_dma_unmap(pkt); + usbhsf_fifo_unselect(pipe, pipe->fifo); diff --git a/queue-4.14/x.509-fix-bug_on-when-hash-algorithm-is-unsupported.patch b/queue-4.14/x.509-fix-bug_on-when-hash-algorithm-is-unsupported.patch new file mode 100644 index 00000000000..8cb7a36a525 --- /dev/null +++ b/queue-4.14/x.509-fix-bug_on-when-hash-algorithm-is-unsupported.patch @@ -0,0 +1,51 @@ +From 437499eea4291ae9621e8763a41df027c110a1ef Mon Sep 17 00:00:00 2001 +From: Eric Biggers +Date: Thu, 22 Feb 2018 14:38:33 +0000 +Subject: X.509: fix BUG_ON() when hash algorithm is unsupported + +From: Eric Biggers + +commit 437499eea4291ae9621e8763a41df027c110a1ef upstream. + +The X.509 parser mishandles the case where the certificate's signature's +hash algorithm is not available in the crypto API. In this case, +x509_get_sig_params() doesn't allocate the cert->sig->digest buffer; +this part seems to be intentional. However, +public_key_verify_signature() is still called via +x509_check_for_self_signed(), which triggers the 'BUG_ON(!sig->digest)'. + +Fix this by making public_key_verify_signature() return -ENOPKG if the +hash buffer has not been allocated. + +Reproducer when all the CONFIG_CRYPTO_SHA512* options are disabled: + + openssl req -new -sha512 -x509 -batch -nodes -outform der \ + | keyctl padd asymmetric desc @s + +Fixes: 6c2dc5ae4ab7 ("X.509: Extract signature digest and make self-signed cert checks earlier") +Reported-by: Paolo Valente +Cc: Paolo Valente +Cc: # v4.7+ +Signed-off-by: Eric Biggers +Signed-off-by: David Howells +Signed-off-by: Greg Kroah-Hartman + +--- + crypto/asymmetric_keys/public_key.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/crypto/asymmetric_keys/public_key.c ++++ b/crypto/asymmetric_keys/public_key.c +@@ -93,9 +93,11 @@ int public_key_verify_signature(const st + + BUG_ON(!pkey); + BUG_ON(!sig); +- BUG_ON(!sig->digest); + BUG_ON(!sig->s); + ++ if (!sig->digest) ++ return -ENOPKG; ++ + alg_name = sig->pkey_algo; + if (strcmp(sig->pkey_algo, "rsa") == 0) { + /* The data wangled by the RSA algorithm is typically padded diff --git a/queue-4.14/x.509-fix-null-dereference-when-restricting-key-with-unsupported_sig.patch b/queue-4.14/x.509-fix-null-dereference-when-restricting-key-with-unsupported_sig.patch new file mode 100644 index 00000000000..7103fc5aaba --- /dev/null +++ b/queue-4.14/x.509-fix-null-dereference-when-restricting-key-with-unsupported_sig.patch @@ -0,0 +1,94 @@ +From 4b34968e77ad09628cfb3c4a7daf2adc2cefc6e8 Mon Sep 17 00:00:00 2001 +From: Eric Biggers +Date: Thu, 22 Feb 2018 14:38:34 +0000 +Subject: X.509: fix NULL dereference when restricting key with unsupported_sig + +From: Eric Biggers + +commit 4b34968e77ad09628cfb3c4a7daf2adc2cefc6e8 upstream. + +The asymmetric key type allows an X.509 certificate to be added even if +its signature's hash algorithm is not available in the crypto API. In +that case 'payload.data[asym_auth]' will be NULL. But the key +restriction code failed to check for this case before trying to use the +signature, resulting in a NULL pointer dereference in +key_or_keyring_common() or in restrict_link_by_signature(). + +Fix this by returning -ENOPKG when the signature is unsupported. + +Reproducer when all the CONFIG_CRYPTO_SHA512* options are disabled and +keyctl has support for the 'restrict_keyring' command: + + keyctl new_session + keyctl restrict_keyring @s asymmetric builtin_trusted + openssl req -new -sha512 -x509 -batch -nodes -outform der \ + | keyctl padd asymmetric desc @s + +Fixes: a511e1af8b12 ("KEYS: Move the point of trust determination to __key_link()") +Cc: # v4.7+ +Signed-off-by: Eric Biggers +Signed-off-by: David Howells +Signed-off-by: Greg Kroah-Hartman + +--- + crypto/asymmetric_keys/restrict.c | 21 +++++++++++++-------- + 1 file changed, 13 insertions(+), 8 deletions(-) + +--- a/crypto/asymmetric_keys/restrict.c ++++ b/crypto/asymmetric_keys/restrict.c +@@ -67,8 +67,9 @@ __setup("ca_keys=", ca_keys_setup); + * + * Returns 0 if the new certificate was accepted, -ENOKEY if we couldn't find a + * matching parent certificate in the trusted list, -EKEYREJECTED if the +- * signature check fails or the key is blacklisted and some other error if +- * there is a matching certificate but the signature check cannot be performed. ++ * signature check fails or the key is blacklisted, -ENOPKG if the signature ++ * uses unsupported crypto, or some other error if there is a matching ++ * certificate but the signature check cannot be performed. + */ + int restrict_link_by_signature(struct key *dest_keyring, + const struct key_type *type, +@@ -88,6 +89,8 @@ int restrict_link_by_signature(struct ke + return -EOPNOTSUPP; + + sig = payload->data[asym_auth]; ++ if (!sig) ++ return -ENOPKG; + if (!sig->auth_ids[0] && !sig->auth_ids[1]) + return -ENOKEY; + +@@ -139,6 +142,8 @@ static int key_or_keyring_common(struct + return -EOPNOTSUPP; + + sig = payload->data[asym_auth]; ++ if (!sig) ++ return -ENOPKG; + if (!sig->auth_ids[0] && !sig->auth_ids[1]) + return -ENOKEY; + +@@ -222,9 +227,9 @@ static int key_or_keyring_common(struct + * + * Returns 0 if the new certificate was accepted, -ENOKEY if we + * couldn't find a matching parent certificate in the trusted list, +- * -EKEYREJECTED if the signature check fails, and some other error if +- * there is a matching certificate but the signature check cannot be +- * performed. ++ * -EKEYREJECTED if the signature check fails, -ENOPKG if the signature uses ++ * unsupported crypto, or some other error if there is a matching certificate ++ * but the signature check cannot be performed. + */ + int restrict_link_by_key_or_keyring(struct key *dest_keyring, + const struct key_type *type, +@@ -249,9 +254,9 @@ int restrict_link_by_key_or_keyring(stru + * + * Returns 0 if the new certificate was accepted, -ENOKEY if we + * couldn't find a matching parent certificate in the trusted list, +- * -EKEYREJECTED if the signature check fails, and some other error if +- * there is a matching certificate but the signature check cannot be +- * performed. ++ * -EKEYREJECTED if the signature check fails, -ENOPKG if the signature uses ++ * unsupported crypto, or some other error if there is a matching certificate ++ * but the signature check cannot be performed. + */ + int restrict_link_by_key_or_keyring_chain(struct key *dest_keyring, + const struct key_type *type, diff --git a/queue-4.14/x86-oprofile-fix-bogus-gcc-8-warning-in-nmi_setup.patch b/queue-4.14/x86-oprofile-fix-bogus-gcc-8-warning-in-nmi_setup.patch new file mode 100644 index 00000000000..7caee1a0c98 --- /dev/null +++ b/queue-4.14/x86-oprofile-fix-bogus-gcc-8-warning-in-nmi_setup.patch @@ -0,0 +1,68 @@ +From 85c615eb52222bc5fab6c7190d146bc59fac289e Mon Sep 17 00:00:00 2001 +From: Arnd Bergmann +Date: Tue, 20 Feb 2018 21:58:21 +0100 +Subject: x86/oprofile: Fix bogus GCC-8 warning in nmi_setup() + +From: Arnd Bergmann + +commit 85c615eb52222bc5fab6c7190d146bc59fac289e upstream. + +GCC-8 shows a warning for the x86 oprofile code that copies per-CPU +data from CPU 0 to all other CPUs, which when building a non-SMP +kernel turns into a memcpy() with identical source and destination +pointers: + + arch/x86/oprofile/nmi_int.c: In function 'mux_clone': + arch/x86/oprofile/nmi_int.c:285:2: error: 'memcpy' source argument is the same as destination [-Werror=restrict] + memcpy(per_cpu(cpu_msrs, cpu).multiplex, + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + per_cpu(cpu_msrs, 0).multiplex, + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + sizeof(struct op_msr) * model->num_virt_counters); + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + arch/x86/oprofile/nmi_int.c: In function 'nmi_setup': + arch/x86/oprofile/nmi_int.c:466:3: error: 'memcpy' source argument is the same as destination [-Werror=restrict] + arch/x86/oprofile/nmi_int.c:470:3: error: 'memcpy' source argument is the same as destination [-Werror=restrict] + +I have analyzed a number of such warnings now: some are valid and the +GCC warning is welcome. Others turned out to be false-positives, and +GCC was changed to not warn about those any more. This is a corner case +that is a false-positive but the GCC developers feel it's better to keep +warning about it. + +In this case, it seems best to work around it by telling GCC +a little more clearly that this code path is never hit with +an IS_ENABLED() configuration check. + +Cc:stable as we also want old kernels to build cleanly with GCC-8. + +Signed-off-by: Arnd Bergmann +Cc: Jessica Yu +Cc: Kees Cook +Cc: Linus Torvalds +Cc: Martin Sebor +Cc: Peter Zijlstra +Cc: Robert Richter +Cc: Thomas Gleixner +Cc: oprofile-list@lists.sf.net +Cc: stable@vger.kernel.org +Link: http://lkml.kernel.org/r/20180220205826.2008875-1-arnd@arndb.de +Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84095 +Signed-off-by: Ingo Molnar +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/oprofile/nmi_int.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/x86/oprofile/nmi_int.c ++++ b/arch/x86/oprofile/nmi_int.c +@@ -460,7 +460,7 @@ static int nmi_setup(void) + goto fail; + + for_each_possible_cpu(cpu) { +- if (!cpu) ++ if (!IS_ENABLED(CONFIG_SMP) || !cpu) + continue; + + memcpy(per_cpu(cpu_msrs, cpu).counters, diff --git a/queue-4.14/xtensa-fix-high-memory-reserved-memory-collision.patch b/queue-4.14/xtensa-fix-high-memory-reserved-memory-collision.patch new file mode 100644 index 00000000000..e55b62a0184 --- /dev/null +++ b/queue-4.14/xtensa-fix-high-memory-reserved-memory-collision.patch @@ -0,0 +1,133 @@ +From 6ac5a11dc674bc5016ea716e8082fff61f524dc1 Mon Sep 17 00:00:00 2001 +From: Max Filippov +Date: Tue, 13 Feb 2018 15:31:05 -0800 +Subject: xtensa: fix high memory/reserved memory collision + +From: Max Filippov + +commit 6ac5a11dc674bc5016ea716e8082fff61f524dc1 upstream. + +Xtensa memory initialization code frees high memory pages without +checking whether they are in the reserved memory regions or not. That +results in invalid value of totalram_pages and duplicate page usage by +CMA and highmem. It produces a bunch of BUGs at startup looking like +this: + +BUG: Bad page state in process swapper pfn:70800 +page:be60c000 count:0 mapcount:-127 mapping: (null) index:0x1 +flags: 0x80000000() +raw: 80000000 00000000 00000001 ffffff80 00000000 be60c014 be60c014 0000000a +page dumped because: nonzero mapcount +Modules linked in: +CPU: 0 PID: 1 Comm: swapper Tainted: G B 4.16.0-rc1-00015-g7928b2cbe55b-dirty #23 +Stack: + bd839d33 00000000 00000018 ba97b64c a106578c bd839d70 be60c000 00000000 + a1378054 bd86a000 00000003 ba97b64c a1066166 bd839da0 be60c000 ffe00000 + a1066b58 bd839dc0 be504000 00000000 000002f4 bd838000 00000000 0000001e +Call Trace: + [] bad_page+0xac/0xd0 + [] free_pages_check_bad+0x34/0x4c + [] __free_pages_ok+0xae/0x14c + [] __free_pages+0x30/0x64 + [] init_cma_reserved_pageblock+0x35/0x44 + [] cma_init_reserved_areas+0xf4/0x148 + [] do_one_initcall+0x80/0xf8 + [] kernel_init_freeable+0xda/0x13c + [] kernel_init+0x9/0xd0 + [] ret_from_kernel_thread+0xc/0x18 + +Only free high memory pages that are not reserved. + +Cc: stable@vger.kernel.org +Signed-off-by: Max Filippov +Signed-off-by: Greg Kroah-Hartman + +--- + arch/xtensa/mm/init.c | 70 +++++++++++++++++++++++++++++++++++++++++++++----- + 1 file changed, 63 insertions(+), 7 deletions(-) + +--- a/arch/xtensa/mm/init.c ++++ b/arch/xtensa/mm/init.c +@@ -79,19 +79,75 @@ void __init zones_init(void) + free_area_init_node(0, zones_size, ARCH_PFN_OFFSET, NULL); + } + ++#ifdef CONFIG_HIGHMEM ++static void __init free_area_high(unsigned long pfn, unsigned long end) ++{ ++ for (; pfn < end; pfn++) ++ free_highmem_page(pfn_to_page(pfn)); ++} ++ ++static void __init free_highpages(void) ++{ ++ unsigned long max_low = max_low_pfn; ++ struct memblock_region *mem, *res; ++ ++ reset_all_zones_managed_pages(); ++ /* set highmem page free */ ++ for_each_memblock(memory, mem) { ++ unsigned long start = memblock_region_memory_base_pfn(mem); ++ unsigned long end = memblock_region_memory_end_pfn(mem); ++ ++ /* Ignore complete lowmem entries */ ++ if (end <= max_low) ++ continue; ++ ++ if (memblock_is_nomap(mem)) ++ continue; ++ ++ /* Truncate partial highmem entries */ ++ if (start < max_low) ++ start = max_low; ++ ++ /* Find and exclude any reserved regions */ ++ for_each_memblock(reserved, res) { ++ unsigned long res_start, res_end; ++ ++ res_start = memblock_region_reserved_base_pfn(res); ++ res_end = memblock_region_reserved_end_pfn(res); ++ ++ if (res_end < start) ++ continue; ++ if (res_start < start) ++ res_start = start; ++ if (res_start > end) ++ res_start = end; ++ if (res_end > end) ++ res_end = end; ++ if (res_start != start) ++ free_area_high(start, res_start); ++ start = res_end; ++ if (start == end) ++ break; ++ } ++ ++ /* And now free anything which remains */ ++ if (start < end) ++ free_area_high(start, end); ++ } ++} ++#else ++static void __init free_highpages(void) ++{ ++} ++#endif ++ + /* + * Initialize memory pages. + */ + + void __init mem_init(void) + { +-#ifdef CONFIG_HIGHMEM +- unsigned long tmp; +- +- reset_all_zones_managed_pages(); +- for (tmp = max_low_pfn; tmp < max_pfn; tmp++) +- free_highmem_page(pfn_to_page(tmp)); +-#endif ++ free_highpages(); + + max_mapnr = max_pfn - ARCH_PFN_OFFSET; + high_memory = (void *)__va(max_low_pfn << PAGE_SHIFT);