From 072eaecbbbe70bab1a9e8c45e78908bb8abdb1f6 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Sun, 29 Dec 2019 15:53:46 +0100 Subject: [PATCH] 5.4-stable patches added patches: cpufreq-avoid-leaving-stale-irq-work-items-during-cpu-offline.patch efi-memreserve-register-reservations-as-reserved-in-proc-iomem.patch intel_th-fix-freeing-irqs.patch intel_th-msu-fix-window-switching-without-windows.patch intel_th-pci-add-comet-lake-pch-v-support.patch intel_th-pci-add-elkhart-lake-soc-support.patch keys-asymmetric-return-enomem-if-akcipher_request_alloc-fails.patch mm-vmscan-protect-shrinker-idr-replace-with-config_memcg.patch platform-x86-hp-wmi-make-buffer-for-hpwmi_feature2_query-128-bytes.patch spi-fsl-don-t-map-irq-during-probe.patch spi-fsl-use-platform_get_irq-instead-of-of_irq_to_resource.patch staging-comedi-gsc_hpdi-check-dma_alloc_coherent-return-value.patch usb-ehci-do-not-return-epipe-when-hub-is-disconnected.patch usbip-fix-error-path-of-vhci_recv_ret_submit.patch usbip-fix-receive-error-in-vhci-hcd-when-using-scatter-gather.patch --- ...le-irq-work-items-during-cpu-offline.patch | 169 ++++++++++++++++++ ...servations-as-reserved-in-proc-iomem.patch | 96 ++++++++++ queue-5.4/intel_th-fix-freeing-irqs.patch | 100 +++++++++++ ...fix-window-switching-without-windows.patch | 94 ++++++++++ ..._th-pci-add-comet-lake-pch-v-support.patch | 35 ++++ ..._th-pci-add-elkhart-lake-soc-support.patch | 35 ++++ ...omem-if-akcipher_request_alloc-fails.patch | 45 +++++ ...rinker-idr-replace-with-config_memcg.patch | 48 +++++ ...r-for-hpwmi_feature2_query-128-bytes.patch | 42 +++++ queue-5.4/series | 15 ++ .../spi-fsl-don-t-map-irq-during-probe.patch | 92 ++++++++++ ...et_irq-instead-of-of_irq_to_resource.patch | 42 +++++ ...heck-dma_alloc_coherent-return-value.patch | 54 ++++++ ...eturn-epipe-when-hub-is-disconnected.patch | 85 +++++++++ ...x-error-path-of-vhci_recv_ret_submit.patch | 70 ++++++++ ...n-vhci-hcd-when-using-scatter-gather.patch | 46 +++++ 16 files changed, 1068 insertions(+) create mode 100644 queue-5.4/cpufreq-avoid-leaving-stale-irq-work-items-during-cpu-offline.patch create mode 100644 queue-5.4/efi-memreserve-register-reservations-as-reserved-in-proc-iomem.patch create mode 100644 queue-5.4/intel_th-fix-freeing-irqs.patch create mode 100644 queue-5.4/intel_th-msu-fix-window-switching-without-windows.patch create mode 100644 queue-5.4/intel_th-pci-add-comet-lake-pch-v-support.patch create mode 100644 queue-5.4/intel_th-pci-add-elkhart-lake-soc-support.patch create mode 100644 queue-5.4/keys-asymmetric-return-enomem-if-akcipher_request_alloc-fails.patch create mode 100644 queue-5.4/mm-vmscan-protect-shrinker-idr-replace-with-config_memcg.patch create mode 100644 queue-5.4/platform-x86-hp-wmi-make-buffer-for-hpwmi_feature2_query-128-bytes.patch create mode 100644 queue-5.4/spi-fsl-don-t-map-irq-during-probe.patch create mode 100644 queue-5.4/spi-fsl-use-platform_get_irq-instead-of-of_irq_to_resource.patch create mode 100644 queue-5.4/staging-comedi-gsc_hpdi-check-dma_alloc_coherent-return-value.patch create mode 100644 queue-5.4/usb-ehci-do-not-return-epipe-when-hub-is-disconnected.patch create mode 100644 queue-5.4/usbip-fix-error-path-of-vhci_recv_ret_submit.patch create mode 100644 queue-5.4/usbip-fix-receive-error-in-vhci-hcd-when-using-scatter-gather.patch diff --git a/queue-5.4/cpufreq-avoid-leaving-stale-irq-work-items-during-cpu-offline.patch b/queue-5.4/cpufreq-avoid-leaving-stale-irq-work-items-during-cpu-offline.patch new file mode 100644 index 00000000000..559f8d95127 --- /dev/null +++ b/queue-5.4/cpufreq-avoid-leaving-stale-irq-work-items-during-cpu-offline.patch @@ -0,0 +1,169 @@ +From 85572c2c4a45a541e880e087b5b17a48198b2416 Mon Sep 17 00:00:00 2001 +From: "Rafael J. Wysocki" +Date: Wed, 11 Dec 2019 11:28:41 +0100 +Subject: cpufreq: Avoid leaving stale IRQ work items during CPU offline + +From: Rafael J. Wysocki + +commit 85572c2c4a45a541e880e087b5b17a48198b2416 upstream. + +The scheduler code calling cpufreq_update_util() may run during CPU +offline on the target CPU after the IRQ work lists have been flushed +for it, so the target CPU should be prevented from running code that +may queue up an IRQ work item on it at that point. + +Unfortunately, that may not be the case if dvfs_possible_from_any_cpu +is set for at least one cpufreq policy in the system, because that +allows the CPU going offline to run the utilization update callback +of the cpufreq governor on behalf of another (online) CPU in some +cases. + +If that happens, the cpufreq governor callback may queue up an IRQ +work on the CPU running it, which is going offline, and the IRQ work +may not be flushed after that point. Moreover, that IRQ work cannot +be flushed until the "offlining" CPU goes back online, so if any +other CPU calls irq_work_sync() to wait for the completion of that +IRQ work, it will have to wait until the "offlining" CPU is back +online and that may not happen forever. In particular, a system-wide +deadlock may occur during CPU online as a result of that. + +The failing scenario is as follows. CPU0 is the boot CPU, so it +creates a cpufreq policy and becomes the "leader" of it +(policy->cpu). It cannot go offline, because it is the boot CPU. +Next, other CPUs join the cpufreq policy as they go online and they +leave it when they go offline. The last CPU to go offline, say CPU3, +may queue up an IRQ work while running the governor callback on +behalf of CPU0 after leaving the cpufreq policy because of the +dvfs_possible_from_any_cpu effect described above. Then, CPU0 is +the only online CPU in the system and the stale IRQ work is still +queued on CPU3. When, say, CPU1 goes back online, it will run +irq_work_sync() to wait for that IRQ work to complete and so it +will wait for CPU3 to go back online (which may never happen even +in principle), but (worse yet) CPU0 is waiting for CPU1 at that +point too and a system-wide deadlock occurs. + +To address this problem notice that CPUs which cannot run cpufreq +utilization update code for themselves (for example, because they +have left the cpufreq policies that they belonged to), should also +be prevented from running that code on behalf of the other CPUs that +belong to a cpufreq policy with dvfs_possible_from_any_cpu set and so +in that case the cpufreq_update_util_data pointer of the CPU running +the code must not be NULL as well as for the CPU which is the target +of the cpufreq utilization update in progress. + +Accordingly, change cpufreq_this_cpu_can_update() into a regular +function in kernel/sched/cpufreq.c (instead of a static inline in a +header file) and make it check the cpufreq_update_util_data pointer +of the local CPU if dvfs_possible_from_any_cpu is set for the target +cpufreq policy. + +Also update the schedutil governor to do the +cpufreq_this_cpu_can_update() check in the non-fast-switch +case too to avoid the stale IRQ work issues. + +Fixes: 99d14d0e16fa ("cpufreq: Process remote callbacks from any CPU if the platform permits") +Link: https://lore.kernel.org/linux-pm/20191121093557.bycvdo4xyinbc5cb@vireshk-i7/ +Reported-by: Anson Huang +Tested-by: Anson Huang +Cc: 4.14+ # 4.14+ +Signed-off-by: Rafael J. Wysocki +Acked-by: Viresh Kumar +Tested-by: Peng Fan (i.MX8QXP-MEK) +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman + +--- + include/linux/cpufreq.h | 11 ----------- + include/linux/sched/cpufreq.h | 3 +++ + kernel/sched/cpufreq.c | 18 ++++++++++++++++++ + kernel/sched/cpufreq_schedutil.c | 8 +++----- + 4 files changed, 24 insertions(+), 16 deletions(-) + +--- a/include/linux/cpufreq.h ++++ b/include/linux/cpufreq.h +@@ -595,17 +595,6 @@ struct governor_attr { + size_t count); + }; + +-static inline bool cpufreq_this_cpu_can_update(struct cpufreq_policy *policy) +-{ +- /* +- * Allow remote callbacks if: +- * - dvfs_possible_from_any_cpu flag is set +- * - the local and remote CPUs share cpufreq policy +- */ +- return policy->dvfs_possible_from_any_cpu || +- cpumask_test_cpu(smp_processor_id(), policy->cpus); +-} +- + /********************************************************************* + * FREQUENCY TABLE HELPERS * + *********************************************************************/ +--- a/include/linux/sched/cpufreq.h ++++ b/include/linux/sched/cpufreq.h +@@ -12,6 +12,8 @@ + #define SCHED_CPUFREQ_MIGRATION (1U << 1) + + #ifdef CONFIG_CPU_FREQ ++struct cpufreq_policy; ++ + struct update_util_data { + void (*func)(struct update_util_data *data, u64 time, unsigned int flags); + }; +@@ -20,6 +22,7 @@ void cpufreq_add_update_util_hook(int cp + void (*func)(struct update_util_data *data, u64 time, + unsigned int flags)); + void cpufreq_remove_update_util_hook(int cpu); ++bool cpufreq_this_cpu_can_update(struct cpufreq_policy *policy); + + static inline unsigned long map_util_freq(unsigned long util, + unsigned long freq, unsigned long cap) +--- a/kernel/sched/cpufreq.c ++++ b/kernel/sched/cpufreq.c +@@ -5,6 +5,8 @@ + * Copyright (C) 2016, Intel Corporation + * Author: Rafael J. Wysocki + */ ++#include ++ + #include "sched.h" + + DEFINE_PER_CPU(struct update_util_data __rcu *, cpufreq_update_util_data); +@@ -57,3 +59,19 @@ void cpufreq_remove_update_util_hook(int + rcu_assign_pointer(per_cpu(cpufreq_update_util_data, cpu), NULL); + } + EXPORT_SYMBOL_GPL(cpufreq_remove_update_util_hook); ++ ++/** ++ * cpufreq_this_cpu_can_update - Check if cpufreq policy can be updated. ++ * @policy: cpufreq policy to check. ++ * ++ * Return 'true' if: ++ * - the local and remote CPUs share @policy, ++ * - dvfs_possible_from_any_cpu is set in @policy and the local CPU is not going ++ * offline (in which case it is not expected to run cpufreq updates any more). ++ */ ++bool cpufreq_this_cpu_can_update(struct cpufreq_policy *policy) ++{ ++ return cpumask_test_cpu(smp_processor_id(), policy->cpus) || ++ (policy->dvfs_possible_from_any_cpu && ++ rcu_dereference_sched(*this_cpu_ptr(&cpufreq_update_util_data))); ++} +--- a/kernel/sched/cpufreq_schedutil.c ++++ b/kernel/sched/cpufreq_schedutil.c +@@ -82,12 +82,10 @@ static bool sugov_should_update_freq(str + * by the hardware, as calculating the frequency is pointless if + * we cannot in fact act on it. + * +- * For the slow switching platforms, the kthread is always scheduled on +- * the right set of CPUs and any CPU can find the next frequency and +- * schedule the kthread. ++ * This is needed on the slow switching platforms too to prevent CPUs ++ * going offline from leaving stale IRQ work items behind. + */ +- if (sg_policy->policy->fast_switch_enabled && +- !cpufreq_this_cpu_can_update(sg_policy->policy)) ++ if (!cpufreq_this_cpu_can_update(sg_policy->policy)) + return false; + + if (unlikely(sg_policy->limits_changed)) { diff --git a/queue-5.4/efi-memreserve-register-reservations-as-reserved-in-proc-iomem.patch b/queue-5.4/efi-memreserve-register-reservations-as-reserved-in-proc-iomem.patch new file mode 100644 index 00000000000..bbd26f1297c --- /dev/null +++ b/queue-5.4/efi-memreserve-register-reservations-as-reserved-in-proc-iomem.patch @@ -0,0 +1,96 @@ +From ab0eb16205b43ece4c78e2259e681ff3d645ea66 Mon Sep 17 00:00:00 2001 +From: Ard Biesheuvel +Date: Fri, 6 Dec 2019 16:55:37 +0000 +Subject: efi/memreserve: Register reservations as 'reserved' in /proc/iomem + +From: Ard Biesheuvel + +commit ab0eb16205b43ece4c78e2259e681ff3d645ea66 upstream. + +Memory regions that are reserved using efi_mem_reserve_persistent() +are recorded in a special EFI config table which survives kexec, +allowing the incoming kernel to honour them as well. However, +such reservations are not visible in /proc/iomem, and so the kexec +tools that load the incoming kernel and its initrd into memory may +overwrite these reserved regions before the incoming kernel has a +chance to reserve them from further use. + +Address this problem by adding these reservations to /proc/iomem as +they are created. Note that reservations that are inherited from a +previous kernel are memblock_reserve()'d early on, so they are already +visible in /proc/iomem. + +Tested-by: Masayoshi Mizuma +Tested-by: Bhupesh Sharma +Signed-off-by: Ard Biesheuvel +Reviewed-by: Bhupesh Sharma +Cc: # v5.4+ +Cc: Andy Shevchenko +Cc: Arvind Sankar +Cc: linux-efi@vger.kernel.org +Link: https://lkml.kernel.org/r/20191206165542.31469-2-ardb@kernel.org +Signed-off-by: Ingo Molnar +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/firmware/efi/efi.c | 28 ++++++++++++++++++++++++++-- + 1 file changed, 26 insertions(+), 2 deletions(-) + +--- a/drivers/firmware/efi/efi.c ++++ b/drivers/firmware/efi/efi.c +@@ -970,6 +970,24 @@ static int __init efi_memreserve_map_roo + return 0; + } + ++static int efi_mem_reserve_iomem(phys_addr_t addr, u64 size) ++{ ++ struct resource *res, *parent; ++ ++ res = kzalloc(sizeof(struct resource), GFP_ATOMIC); ++ if (!res) ++ return -ENOMEM; ++ ++ res->name = "reserved"; ++ res->flags = IORESOURCE_MEM; ++ res->start = addr; ++ res->end = addr + size - 1; ++ ++ /* we expect a conflict with a 'System RAM' region */ ++ parent = request_resource_conflict(&iomem_resource, res); ++ return parent ? request_resource(parent, res) : 0; ++} ++ + int __ref efi_mem_reserve_persistent(phys_addr_t addr, u64 size) + { + struct linux_efi_memreserve *rsv; +@@ -994,7 +1012,7 @@ int __ref efi_mem_reserve_persistent(phy + rsv->entry[index].size = size; + + memunmap(rsv); +- return 0; ++ return efi_mem_reserve_iomem(addr, size); + } + memunmap(rsv); + } +@@ -1004,6 +1022,12 @@ int __ref efi_mem_reserve_persistent(phy + if (!rsv) + return -ENOMEM; + ++ rc = efi_mem_reserve_iomem(__pa(rsv), SZ_4K); ++ if (rc) { ++ free_page((unsigned long)rsv); ++ return rc; ++ } ++ + /* + * The memremap() call above assumes that a linux_efi_memreserve entry + * never crosses a page boundary, so let's ensure that this remains true +@@ -1020,7 +1044,7 @@ int __ref efi_mem_reserve_persistent(phy + efi_memreserve_root->next = __pa(rsv); + spin_unlock(&efi_mem_reserve_persistent_lock); + +- return 0; ++ return efi_mem_reserve_iomem(addr, size); + } + + static int __init efi_memreserve_root_init(void) diff --git a/queue-5.4/intel_th-fix-freeing-irqs.patch b/queue-5.4/intel_th-fix-freeing-irqs.patch new file mode 100644 index 00000000000..99705c7ddfa --- /dev/null +++ b/queue-5.4/intel_th-fix-freeing-irqs.patch @@ -0,0 +1,100 @@ +From ab832e38e4f0f45b16c3633714d868b7ec6b33b4 Mon Sep 17 00:00:00 2001 +From: Alexander Shishkin +Date: Tue, 17 Dec 2019 13:55:26 +0200 +Subject: intel_th: Fix freeing IRQs + +From: Alexander Shishkin + +commit ab832e38e4f0f45b16c3633714d868b7ec6b33b4 upstream. + +Commit aac8da65174a ("intel_th: msu: Start handling IRQs") implicitly +relies on the use of devm_request_irq() to subsequently free the irqs on +device removal, but in case of the pci_free_irq_vectors() API, the +handlers need to be freed before it is called. Therefore, at the moment +the driver's remove path trips a BUG_ON(irq_has_action()): + +> kernel BUG at drivers/pci/msi.c:375! +> invalid opcode: 0000 1 SMP +> CPU: 2 PID: 818 Comm: rmmod Not tainted 5.5.0-rc1+ #1 +> RIP: 0010:free_msi_irqs+0x67/0x1c0 +> pci_disable_msi+0x116/0x150 +> pci_free_irq_vectors+0x1b/0x20 +> intel_th_pci_remove+0x22/0x30 [intel_th_pci] +> pci_device_remove+0x3e/0xb0 +> device_release_driver_internal+0xf0/0x1c0 +> driver_detach+0x4c/0x8f +> bus_remove_driver+0x5c/0xd0 +> driver_unregister+0x31/0x50 +> pci_unregister_driver+0x40/0x90 +> intel_th_pci_driver_exit+0x10/0xad6 [intel_th_pci] +> __x64_sys_delete_module+0x147/0x290 +> ? exit_to_usermode_loop+0xd7/0x120 +> do_syscall_64+0x57/0x1b0 +> entry_SYSCALL_64_after_hwframe+0x44/0xa9 + +Fix this by explicitly freeing irqs before freeing the vectors. We keep +using the devm_* variants because they are still useful in early error +paths. + +Signed-off-by: Alexander Shishkin +Reviewed-by: Andy Shevchenko +Fixes: aac8da65174a ("intel_th: msu: Start handling IRQs") +Reported-by: Ammy Yi +Tested-by: Ammy Yi +Cc: stable@vger.kernel.org # v5.2+ +Link: https://lore.kernel.org/r/20191217115527.74383-4-alexander.shishkin@linux.intel.com +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/hwtracing/intel_th/core.c | 7 ++++--- + drivers/hwtracing/intel_th/intel_th.h | 2 ++ + 2 files changed, 6 insertions(+), 3 deletions(-) + +--- a/drivers/hwtracing/intel_th/core.c ++++ b/drivers/hwtracing/intel_th/core.c +@@ -834,9 +834,6 @@ static irqreturn_t intel_th_irq(int irq, + ret |= d->irq(th->thdev[i]); + } + +- if (ret == IRQ_NONE) +- pr_warn_ratelimited("nobody cared for irq\n"); +- + return ret; + } + +@@ -887,6 +884,7 @@ intel_th_alloc(struct device *dev, struc + + if (th->irq == -1) + th->irq = devres[r].start; ++ th->num_irqs++; + break; + default: + dev_warn(dev, "Unknown resource type %lx\n", +@@ -940,6 +938,9 @@ void intel_th_free(struct intel_th *th) + + th->num_thdevs = 0; + ++ for (i = 0; i < th->num_irqs; i++) ++ devm_free_irq(th->dev, th->irq + i, th); ++ + pm_runtime_get_sync(th->dev); + pm_runtime_forbid(th->dev); + +--- a/drivers/hwtracing/intel_th/intel_th.h ++++ b/drivers/hwtracing/intel_th/intel_th.h +@@ -261,6 +261,7 @@ enum th_mmio_idx { + * @num_thdevs: number of devices in the @thdev array + * @num_resources: number of resources in the @resource array + * @irq: irq number ++ * @num_irqs: number of IRQs is use + * @id: this Intel TH controller's device ID in the system + * @major: device node major for output devices + */ +@@ -277,6 +278,7 @@ struct intel_th { + unsigned int num_thdevs; + unsigned int num_resources; + int irq; ++ int num_irqs; + + int id; + int major; diff --git a/queue-5.4/intel_th-msu-fix-window-switching-without-windows.patch b/queue-5.4/intel_th-msu-fix-window-switching-without-windows.patch new file mode 100644 index 00000000000..b55757d478b --- /dev/null +++ b/queue-5.4/intel_th-msu-fix-window-switching-without-windows.patch @@ -0,0 +1,94 @@ +From 05b686b573cfb35a227c30787083a6631ff0f0c9 Mon Sep 17 00:00:00 2001 +From: Alexander Shishkin +Date: Tue, 17 Dec 2019 13:55:27 +0200 +Subject: intel_th: msu: Fix window switching without windows + +From: Alexander Shishkin + +commit 05b686b573cfb35a227c30787083a6631ff0f0c9 upstream. + +Commit 6cac7866c2741 ("intel_th: msu: Add a sysfs attribute to trigger +window switch") adds a NULL pointer dereference in the case when there are +no windows allocated: + +> BUG: kernel NULL pointer dereference, address: 0000000000000000 +> #PF: supervisor read access in kernel mode +> #PF: error_code(0x0000) - not-present page +> PGD 0 P4D 0 +> Oops: 0000 1 SMP +> CPU: 5 PID: 1110 Comm: bash Not tainted 5.5.0-rc1+ #1 +> RIP: 0010:msc_win_switch+0xa/0x80 [intel_th_msu] +> Call Trace: +> ? win_switch_store+0x9b/0xc0 [intel_th_msu] +> dev_attr_store+0x17/0x30 +> sysfs_kf_write+0x3e/0x50 +> kernfs_fop_write+0xda/0x1b0 +> __vfs_write+0x1b/0x40 +> vfs_write+0xb9/0x1a0 +> ksys_write+0x67/0xe0 +> __x64_sys_write+0x1a/0x20 +> do_syscall_64+0x57/0x1d0 +> entry_SYSCALL_64_after_hwframe+0x44/0xa9 + +Fix that by disallowing window switching with multiwindow buffers without +windows. + +Signed-off-by: Alexander Shishkin +Fixes: 6cac7866c274 ("intel_th: msu: Add a sysfs attribute to trigger window switch") +Reviewed-by: Andy Shevchenko +Reported-by: Ammy Yi +Tested-by: Ammy Yi +Cc: stable@vger.kernel.org # v5.2+ +Link: https://lore.kernel.org/r/20191217115527.74383-5-alexander.shishkin@linux.intel.com +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/hwtracing/intel_th/msu.c | 14 +++++++++----- + 1 file changed, 9 insertions(+), 5 deletions(-) + +--- a/drivers/hwtracing/intel_th/msu.c ++++ b/drivers/hwtracing/intel_th/msu.c +@@ -1676,10 +1676,13 @@ static int intel_th_msc_init(struct msc + return 0; + } + +-static void msc_win_switch(struct msc *msc) ++static int msc_win_switch(struct msc *msc) + { + struct msc_window *first; + ++ if (list_empty(&msc->win_list)) ++ return -EINVAL; ++ + first = list_first_entry(&msc->win_list, struct msc_window, entry); + + if (msc_is_last_win(msc->cur_win)) +@@ -1691,6 +1694,8 @@ static void msc_win_switch(struct msc *m + msc->base_addr = msc_win_base_dma(msc->cur_win); + + intel_th_trace_switch(msc->thdev); ++ ++ return 0; + } + + /** +@@ -2025,16 +2030,15 @@ win_switch_store(struct device *dev, str + if (val != 1) + return -EINVAL; + ++ ret = -EINVAL; + mutex_lock(&msc->buf_mutex); + /* + * Window switch can only happen in the "multi" mode. + * If a external buffer is engaged, they have the full + * control over window switching. + */ +- if (msc->mode != MSC_MODE_MULTI || msc->mbuf) +- ret = -ENOTSUPP; +- else +- msc_win_switch(msc); ++ if (msc->mode == MSC_MODE_MULTI && !msc->mbuf) ++ ret = msc_win_switch(msc); + mutex_unlock(&msc->buf_mutex); + + return ret ? ret : size; diff --git a/queue-5.4/intel_th-pci-add-comet-lake-pch-v-support.patch b/queue-5.4/intel_th-pci-add-comet-lake-pch-v-support.patch new file mode 100644 index 00000000000..ca09a5246df --- /dev/null +++ b/queue-5.4/intel_th-pci-add-comet-lake-pch-v-support.patch @@ -0,0 +1,35 @@ +From e4de2a5d51f97a6e720a1c0911f93e2d8c2f1c08 Mon Sep 17 00:00:00 2001 +From: Alexander Shishkin +Date: Tue, 17 Dec 2019 13:55:24 +0200 +Subject: intel_th: pci: Add Comet Lake PCH-V support + +From: Alexander Shishkin + +commit e4de2a5d51f97a6e720a1c0911f93e2d8c2f1c08 upstream. + +This adds Intel(R) Trace Hub PCI ID for Comet Lake PCH-V. + +Signed-off-by: Alexander Shishkin +Reviewed-by: Andy Shevchenko +Cc: +Link: https://lore.kernel.org/r/20191217115527.74383-2-alexander.shishkin@linux.intel.com +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/hwtracing/intel_th/pci.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/drivers/hwtracing/intel_th/pci.c ++++ b/drivers/hwtracing/intel_th/pci.c +@@ -205,6 +205,11 @@ static const struct pci_device_id intel_ + .driver_data = (kernel_ulong_t)&intel_th_2x, + }, + { ++ /* Comet Lake PCH-V */ ++ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0xa3a6), ++ .driver_data = (kernel_ulong_t)&intel_th_2x, ++ }, ++ { + /* Ice Lake NNPI */ + PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x45c5), + .driver_data = (kernel_ulong_t)&intel_th_2x, diff --git a/queue-5.4/intel_th-pci-add-elkhart-lake-soc-support.patch b/queue-5.4/intel_th-pci-add-elkhart-lake-soc-support.patch new file mode 100644 index 00000000000..cd0931b63e1 --- /dev/null +++ b/queue-5.4/intel_th-pci-add-elkhart-lake-soc-support.patch @@ -0,0 +1,35 @@ +From 88385866bab8d5e18c7f45d1023052c783572e03 Mon Sep 17 00:00:00 2001 +From: Alexander Shishkin +Date: Tue, 17 Dec 2019 13:55:25 +0200 +Subject: intel_th: pci: Add Elkhart Lake SOC support + +From: Alexander Shishkin + +commit 88385866bab8d5e18c7f45d1023052c783572e03 upstream. + +This adds support for Intel Trace Hub in Elkhart Lake. + +Signed-off-by: Alexander Shishkin +Reviewed-by: Andy Shevchenko +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20191217115527.74383-3-alexander.shishkin@linux.intel.com +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/hwtracing/intel_th/pci.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/drivers/hwtracing/intel_th/pci.c ++++ b/drivers/hwtracing/intel_th/pci.c +@@ -234,6 +234,11 @@ static const struct pci_device_id intel_ + PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x4da6), + .driver_data = (kernel_ulong_t)&intel_th_2x, + }, ++ { ++ /* Elkhart Lake */ ++ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x4b26), ++ .driver_data = (kernel_ulong_t)&intel_th_2x, ++ }, + { 0 }, + }; + diff --git a/queue-5.4/keys-asymmetric-return-enomem-if-akcipher_request_alloc-fails.patch b/queue-5.4/keys-asymmetric-return-enomem-if-akcipher_request_alloc-fails.patch new file mode 100644 index 00000000000..243f5d9ca88 --- /dev/null +++ b/queue-5.4/keys-asymmetric-return-enomem-if-akcipher_request_alloc-fails.patch @@ -0,0 +1,45 @@ +From bea37414453eb08d4ceffeb60a9d490dbc930cea Mon Sep 17 00:00:00 2001 +From: Eric Biggers +Date: Wed, 9 Oct 2019 16:03:49 -0700 +Subject: KEYS: asymmetric: return ENOMEM if akcipher_request_alloc() fails + +From: Eric Biggers + +commit bea37414453eb08d4ceffeb60a9d490dbc930cea upstream. + +No error code was being set on this error path. + +Cc: stable@vger.kernel.org +Fixes: ad4b1eb5fb33 ("KEYS: asym_tpm: Implement encryption operation [ver #2]") +Fixes: c08fed737126 ("KEYS: Implement encrypt, decrypt and sign for software asymmetric key [ver #2]") +Reviewed-by: James Morris +Signed-off-by: Eric Biggers +Reviewed-by: Jarkko Sakkinen +Signed-off-by: Jarkko Sakkinen +Signed-off-by: Greg Kroah-Hartman + +--- + crypto/asymmetric_keys/asym_tpm.c | 1 + + crypto/asymmetric_keys/public_key.c | 1 + + 2 files changed, 2 insertions(+) + +--- a/crypto/asymmetric_keys/asym_tpm.c ++++ b/crypto/asymmetric_keys/asym_tpm.c +@@ -486,6 +486,7 @@ static int tpm_key_encrypt(struct tpm_ke + if (ret < 0) + goto error_free_tfm; + ++ ret = -ENOMEM; + req = akcipher_request_alloc(tfm, GFP_KERNEL); + if (!req) + goto error_free_tfm; +--- a/crypto/asymmetric_keys/public_key.c ++++ b/crypto/asymmetric_keys/public_key.c +@@ -184,6 +184,7 @@ static int software_key_eds_op(struct ke + if (IS_ERR(tfm)) + return PTR_ERR(tfm); + ++ ret = -ENOMEM; + req = akcipher_request_alloc(tfm, GFP_KERNEL); + if (!req) + goto error_free_tfm; diff --git a/queue-5.4/mm-vmscan-protect-shrinker-idr-replace-with-config_memcg.patch b/queue-5.4/mm-vmscan-protect-shrinker-idr-replace-with-config_memcg.patch new file mode 100644 index 00000000000..9517ea1991a --- /dev/null +++ b/queue-5.4/mm-vmscan-protect-shrinker-idr-replace-with-config_memcg.patch @@ -0,0 +1,48 @@ +From 42a9a53bb394a1de2247ef78f0b802ae86798122 Mon Sep 17 00:00:00 2001 +From: Yang Shi +Date: Tue, 17 Dec 2019 20:51:52 -0800 +Subject: mm: vmscan: protect shrinker idr replace with CONFIG_MEMCG + +From: Yang Shi + +commit 42a9a53bb394a1de2247ef78f0b802ae86798122 upstream. + +Since commit 0a432dcbeb32 ("mm: shrinker: make shrinker not depend on +memcg kmem"), shrinkers' idr is protected by CONFIG_MEMCG instead of +CONFIG_MEMCG_KMEM, so it makes no sense to protect shrinker idr replace +with CONFIG_MEMCG_KMEM. + +And in the CONFIG_MEMCG && CONFIG_SLOB case, shrinker_idr contains only +shrinker, and it is deferred_split_shrinker. But it is never actually +called, since idr_replace() is never compiled due to the wrong #ifdef. +The deferred_split_shrinker all the time is staying in half-registered +state, and it's never called for subordinate mem cgroups. + +Link: http://lkml.kernel.org/r/1575486978-45249-1-git-send-email-yang.shi@linux.alibaba.com +Fixes: 0a432dcbeb32 ("mm: shrinker: make shrinker not depend on memcg kmem") +Signed-off-by: Yang Shi +Reviewed-by: Kirill Tkhai +Acked-by: Michal Hocko +Cc: Johannes Weiner +Cc: Shakeel Butt +Cc: Roman Gushchin +Cc: [5.4+] +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + mm/vmscan.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/mm/vmscan.c ++++ b/mm/vmscan.c +@@ -422,7 +422,7 @@ void register_shrinker_prepared(struct s + { + down_write(&shrinker_rwsem); + list_add_tail(&shrinker->list, &shrinker_list); +-#ifdef CONFIG_MEMCG_KMEM ++#ifdef CONFIG_MEMCG + if (shrinker->flags & SHRINKER_MEMCG_AWARE) + idr_replace(&shrinker_idr, shrinker, shrinker->id); + #endif diff --git a/queue-5.4/platform-x86-hp-wmi-make-buffer-for-hpwmi_feature2_query-128-bytes.patch b/queue-5.4/platform-x86-hp-wmi-make-buffer-for-hpwmi_feature2_query-128-bytes.patch new file mode 100644 index 00000000000..08ad844e954 --- /dev/null +++ b/queue-5.4/platform-x86-hp-wmi-make-buffer-for-hpwmi_feature2_query-128-bytes.patch @@ -0,0 +1,42 @@ +From 133b2acee3871ae6bf123b8fe34be14464aa3d2c Mon Sep 17 00:00:00 2001 +From: Hans de Goede +Date: Tue, 17 Dec 2019 20:06:04 +0100 +Subject: platform/x86: hp-wmi: Make buffer for HPWMI_FEATURE2_QUERY 128 bytes + +From: Hans de Goede + +commit 133b2acee3871ae6bf123b8fe34be14464aa3d2c upstream. + +At least on the HP Envy x360 15-cp0xxx model the WMI interface +for HPWMI_FEATURE2_QUERY requires an outsize of at least 128 bytes, +otherwise it fails with an error code 5 (HPWMI_RET_INVALID_PARAMETERS): + +Dec 06 00:59:38 kernel: hp_wmi: query 0xd returned error 0x5 + +We do not care about the contents of the buffer, we just want to know +if the HPWMI_FEATURE2_QUERY command is supported. + +This commits bumps the buffer size, fixing the error. + +Fixes: 8a1513b4932 ("hp-wmi: limit hotkey enable") +Cc: stable@vger.kernel.org +BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1520703 +Signed-off-by: Hans de Goede +Signed-off-by: Andy Shevchenko +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/platform/x86/hp-wmi.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/platform/x86/hp-wmi.c ++++ b/drivers/platform/x86/hp-wmi.c +@@ -300,7 +300,7 @@ static int __init hp_wmi_bios_2008_later + + static int __init hp_wmi_bios_2009_later(void) + { +- int state = 0; ++ u8 state[128]; + int ret = hp_wmi_perform_query(HPWMI_FEATURE2_QUERY, HPWMI_READ, &state, + sizeof(state), sizeof(state)); + if (!ret) diff --git a/queue-5.4/series b/queue-5.4/series index ee2eacf0cca..9071c220043 100644 --- a/queue-5.4/series +++ b/queue-5.4/series @@ -391,3 +391,18 @@ md-avoid-invalid-memory-access-for-array-sb-dev_role.patch s390-ftrace-fix-endless-recursion-in-function_graph-.patch arm-dts-fix-vcsi-regulator-to-be-always-on-for-droid.patch can-flexcan-add-low-power-enter-exit-acknowledgment-.patch +usbip-fix-receive-error-in-vhci-hcd-when-using-scatter-gather.patch +usbip-fix-error-path-of-vhci_recv_ret_submit.patch +spi-fsl-don-t-map-irq-during-probe.patch +spi-fsl-use-platform_get_irq-instead-of-of_irq_to_resource.patch +efi-memreserve-register-reservations-as-reserved-in-proc-iomem.patch +cpufreq-avoid-leaving-stale-irq-work-items-during-cpu-offline.patch +keys-asymmetric-return-enomem-if-akcipher_request_alloc-fails.patch +mm-vmscan-protect-shrinker-idr-replace-with-config_memcg.patch +usb-ehci-do-not-return-epipe-when-hub-is-disconnected.patch +intel_th-pci-add-comet-lake-pch-v-support.patch +intel_th-pci-add-elkhart-lake-soc-support.patch +intel_th-fix-freeing-irqs.patch +intel_th-msu-fix-window-switching-without-windows.patch +platform-x86-hp-wmi-make-buffer-for-hpwmi_feature2_query-128-bytes.patch +staging-comedi-gsc_hpdi-check-dma_alloc_coherent-return-value.patch diff --git a/queue-5.4/spi-fsl-don-t-map-irq-during-probe.patch b/queue-5.4/spi-fsl-don-t-map-irq-during-probe.patch new file mode 100644 index 00000000000..5e68c94c129 --- /dev/null +++ b/queue-5.4/spi-fsl-don-t-map-irq-during-probe.patch @@ -0,0 +1,92 @@ +From 3194d2533efffae8b815d84729ecc58b6a9000ab Mon Sep 17 00:00:00 2001 +From: Christophe Leroy +Date: Mon, 9 Dec 2019 15:27:27 +0000 +Subject: spi: fsl: don't map irq during probe + +From: Christophe Leroy + +commit 3194d2533efffae8b815d84729ecc58b6a9000ab upstream. + +With lastest kernel, the following warning is observed at startup: + +[ 1.500609] ------------[ cut here ]------------ +[ 1.505225] remove_proc_entry: removing non-empty directory 'irq/22', leaking at least 'fsl_spi' +[ 1.514234] WARNING: CPU: 0 PID: 1 at fs/proc/generic.c:682 remove_proc_entry+0x198/0x1c0 +[ 1.522403] CPU: 0 PID: 1 Comm: swapper Not tainted 5.4.0-s3k-dev-02248-g93532430a4ff #2564 +[ 1.530724] NIP: c0197694 LR: c0197694 CTR: c0050d80 +[ 1.535762] REGS: df4a5af0 TRAP: 0700 Not tainted (5.4.0-02248-g93532430a4ff) +[ 1.543818] MSR: 00029032 CR: 22028222 XER: 00000000 +[ 1.550524] +[ 1.550524] GPR00: c0197694 df4a5ba8 df4a0000 00000054 00000000 00000000 00004a38 00000010 +[ 1.550524] GPR08: c07c5a30 00000800 00000000 00001032 22000208 00000000 c0004b14 00000000 +[ 1.550524] GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 c0830000 c07fc078 +[ 1.550524] GPR24: c08e8ca0 df665d10 df60ea98 c07c9db8 00000001 df5d5ae3 df5d5a80 df43f8e3 +[ 1.585327] NIP [c0197694] remove_proc_entry+0x198/0x1c0 +[ 1.590628] LR [c0197694] remove_proc_entry+0x198/0x1c0 +[ 1.595829] Call Trace: +[ 1.598280] [df4a5ba8] [c0197694] remove_proc_entry+0x198/0x1c0 (unreliable) +[ 1.605321] [df4a5bd8] [c0067acc] unregister_irq_proc+0x5c/0x70 +[ 1.611238] [df4a5bf8] [c005fbc4] free_desc+0x3c/0x80 +[ 1.616286] [df4a5c18] [c005fe2c] irq_free_descs+0x70/0xa8 +[ 1.621778] [df4a5c38] [c033d3fc] of_fsl_spi_probe+0xdc/0x3cc +[ 1.627525] [df4a5c88] [c02f0f64] platform_drv_probe+0x44/0xa4 +[ 1.633350] [df4a5c98] [c02eee44] really_probe+0x1ac/0x418 +[ 1.638829] [df4a5cc8] [c02ed3e8] bus_for_each_drv+0x64/0xb0 +[ 1.644481] [df4a5cf8] [c02ef950] __device_attach+0xd4/0x128 +[ 1.650132] [df4a5d28] [c02ed61c] bus_probe_device+0xa0/0xbc +[ 1.655783] [df4a5d48] [c02ebbe8] device_add+0x544/0x74c +[ 1.661096] [df4a5d88] [c0382b78] of_platform_device_create_pdata+0xa4/0x100 +[ 1.668131] [df4a5da8] [c0382cf4] of_platform_bus_create+0x120/0x20c +[ 1.674474] [df4a5df8] [c0382d50] of_platform_bus_create+0x17c/0x20c +[ 1.680818] [df4a5e48] [c0382e88] of_platform_bus_probe+0x9c/0xf0 +[ 1.686907] [df4a5e68] [c0751404] __machine_initcall_cmpcpro_cmpcpro_declare_of_platform_devices+0x74/0x1a4 +[ 1.696629] [df4a5e98] [c072a4cc] do_one_initcall+0x8c/0x1d4 +[ 1.702282] [df4a5ef8] [c072a768] kernel_init_freeable+0x154/0x204 +[ 1.708455] [df4a5f28] [c0004b2c] kernel_init+0x18/0x110 +[ 1.713769] [df4a5f38] [c00122ac] ret_from_kernel_thread+0x14/0x1c +[ 1.719926] Instruction dump: +[ 1.722889] 2c030000 4182004c 3863ffb0 3c80c05f 80e3005c 388436a0 3c60c06d 7fa6eb78 +[ 1.730630] 7fe5fb78 38840280 38634178 4be8c611 <0fe00000> 4bffff6c 3c60c071 7fe4fb78 +[ 1.738556] ---[ end trace 05d0720bf2e352e2 ]--- + +The problem comes from the error path which calls +irq_dispose_mapping() while the IRQ has been requested with +devm_request_irq(). + +IRQ doesn't need to be mapped with irq_of_parse_and_map(). The only +need is to get the IRQ virtual number. For that, use +of_irq_to_resource() instead of the +irq_of_parse_and_map()/irq_dispose_mapping() pair. + +Fixes: 500a32abaf81 ("spi: fsl: Call irq_dispose_mapping in err path") +Cc: stable@vger.kernel.org +Signed-off-by: Christophe Leroy +Link: https://lore.kernel.org/r/518cfb83347d5372748e7fe72f94e2e9443d0d4a.1575905123.git.christophe.leroy@c-s.fr +Signed-off-by: Mark Brown +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/spi/spi-fsl-spi.c | 5 ++--- + 1 file changed, 2 insertions(+), 3 deletions(-) + +--- a/drivers/spi/spi-fsl-spi.c ++++ b/drivers/spi/spi-fsl-spi.c +@@ -736,8 +736,8 @@ static int of_fsl_spi_probe(struct platf + if (ret) + goto err; + +- irq = irq_of_parse_and_map(np, 0); +- if (!irq) { ++ irq = of_irq_to_resource(np, 0, NULL); ++ if (irq <= 0) { + ret = -EINVAL; + goto err; + } +@@ -751,7 +751,6 @@ static int of_fsl_spi_probe(struct platf + return 0; + + err: +- irq_dispose_mapping(irq); + return ret; + } + diff --git a/queue-5.4/spi-fsl-use-platform_get_irq-instead-of-of_irq_to_resource.patch b/queue-5.4/spi-fsl-use-platform_get_irq-instead-of-of_irq_to_resource.patch new file mode 100644 index 00000000000..97d4070a626 --- /dev/null +++ b/queue-5.4/spi-fsl-use-platform_get_irq-instead-of-of_irq_to_resource.patch @@ -0,0 +1,42 @@ +From 63aa6a692595d47a0785297b481072086b9272d2 Mon Sep 17 00:00:00 2001 +From: Christophe Leroy +Date: Thu, 12 Dec 2019 17:47:24 +0000 +Subject: spi: fsl: use platform_get_irq() instead of of_irq_to_resource() + +From: Christophe Leroy + +commit 63aa6a692595d47a0785297b481072086b9272d2 upstream. + +Unlike irq_of_parse_and_map() which has a dummy definition on SPARC, +of_irq_to_resource() hasn't. + +But as platform_get_irq() can be used instead and is generic, use it. + +Reported-by: kbuild test robot +Suggested-by: Mark Brown +Fixes: 3194d2533eff ("spi: fsl: don't map irq during probe") +Cc: stable@vger.kernel.org +Signed-off-by: Christophe Leroy +Link: https://lore.kernel.org/r/091a277fd0b3356dca1e29858c1c96983fc9cb25.1576172743.git.christophe.leroy@c-s.fr +Signed-off-by: Mark Brown +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/spi/spi-fsl-spi.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/drivers/spi/spi-fsl-spi.c ++++ b/drivers/spi/spi-fsl-spi.c +@@ -736,9 +736,9 @@ static int of_fsl_spi_probe(struct platf + if (ret) + goto err; + +- irq = of_irq_to_resource(np, 0, NULL); +- if (irq <= 0) { +- ret = -EINVAL; ++ irq = platform_get_irq(ofdev, 0); ++ if (irq < 0) { ++ ret = irq; + goto err; + } + diff --git a/queue-5.4/staging-comedi-gsc_hpdi-check-dma_alloc_coherent-return-value.patch b/queue-5.4/staging-comedi-gsc_hpdi-check-dma_alloc_coherent-return-value.patch new file mode 100644 index 00000000000..50aacfe7125 --- /dev/null +++ b/queue-5.4/staging-comedi-gsc_hpdi-check-dma_alloc_coherent-return-value.patch @@ -0,0 +1,54 @@ +From ab42b48f32d4c766420c3499ee9c0289b7028182 Mon Sep 17 00:00:00 2001 +From: Ian Abbott +Date: Mon, 16 Dec 2019 11:08:23 +0000 +Subject: staging: comedi: gsc_hpdi: check dma_alloc_coherent() return value + +From: Ian Abbott + +commit ab42b48f32d4c766420c3499ee9c0289b7028182 upstream. + +The "auto-attach" handler function `gsc_hpdi_auto_attach()` calls +`dma_alloc_coherent()` in a loop to allocate some DMA data buffers, and +also calls it to allocate a buffer for a DMA descriptor chain. However, +it does not check the return value of any of these calls. Change +`gsc_hpdi_auto_attach()` to return `-ENOMEM` if any of these +`dma_alloc_coherent()` calls fail. This will result in the comedi core +calling the "detach" handler `gsc_hpdi_detach()` as part of the +clean-up, which will call `gsc_hpdi_free_dma()` to free any allocated +DMA coherent memory buffers. + +Cc: #4.6+ +Signed-off-by: Ian Abbott +Link: https://lore.kernel.org/r/20191216110823.216237-1-abbotti@mev.co.uk +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/staging/comedi/drivers/gsc_hpdi.c | 10 ++++++++++ + 1 file changed, 10 insertions(+) + +--- a/drivers/staging/comedi/drivers/gsc_hpdi.c ++++ b/drivers/staging/comedi/drivers/gsc_hpdi.c +@@ -623,6 +623,11 @@ static int gsc_hpdi_auto_attach(struct c + dma_alloc_coherent(&pcidev->dev, DMA_BUFFER_SIZE, + &devpriv->dio_buffer_phys_addr[i], + GFP_KERNEL); ++ if (!devpriv->dio_buffer[i]) { ++ dev_warn(dev->class_dev, ++ "failed to allocate DMA buffer\n"); ++ return -ENOMEM; ++ } + } + /* allocate dma descriptors */ + devpriv->dma_desc = dma_alloc_coherent(&pcidev->dev, +@@ -630,6 +635,11 @@ static int gsc_hpdi_auto_attach(struct c + NUM_DMA_DESCRIPTORS, + &devpriv->dma_desc_phys_addr, + GFP_KERNEL); ++ if (!devpriv->dma_desc) { ++ dev_warn(dev->class_dev, ++ "failed to allocate DMA descriptors\n"); ++ return -ENOMEM; ++ } + if (devpriv->dma_desc_phys_addr & 0xf) { + dev_warn(dev->class_dev, + " dma descriptors not quad-word aligned (bug)\n"); diff --git a/queue-5.4/usb-ehci-do-not-return-epipe-when-hub-is-disconnected.patch b/queue-5.4/usb-ehci-do-not-return-epipe-when-hub-is-disconnected.patch new file mode 100644 index 00000000000..ffcdd2b1a0f --- /dev/null +++ b/queue-5.4/usb-ehci-do-not-return-epipe-when-hub-is-disconnected.patch @@ -0,0 +1,85 @@ +From 64cc3f12d1c7dd054a215bc1ff9cc2abcfe35832 Mon Sep 17 00:00:00 2001 +From: Erkka Talvitie +Date: Wed, 11 Dec 2019 10:08:39 +0200 +Subject: USB: EHCI: Do not return -EPIPE when hub is disconnected + +From: Erkka Talvitie + +commit 64cc3f12d1c7dd054a215bc1ff9cc2abcfe35832 upstream. + +When disconnecting a USB hub that has some child device(s) connected to it +(such as a USB mouse), then the stack tries to clear halt and +reset device(s) which are _already_ physically disconnected. + +The issue has been reproduced with: + +CPU: IMX6D5EYM10AD or MCIMX6D5EYM10AE. +SW: U-Boot 2019.07 and kernel 4.19.40. + +CPU: HP Proliant Microserver Gen8. +SW: Linux version 4.2.3-300.fc23.x86_64 + +In this situation there will be error bit for MMF active yet the +CERR equals EHCI_TUNE_CERR + halt. Existing implementation +interprets this as a stall [1] (chapter 8.4.5). + +The possible conditions when the MMF will be active + halt +can be found from [2] (Table 4-13). + +Fix for the issue is to check whether MMF is active and PID Code is +IN before checking for the stall. If these conditions are true then +it is not a stall. + +What happens after the fix is that when disconnecting a hub with +attached device(s) the situation is not interpret as a stall. + +[1] [https://www.usb.org/document-library/usb-20-specification, usb_20.pdf] +[2] [https://www.intel.com/content/dam/www/public/us/en/documents/ + technical-specifications/ehci-specification-for-usb.pdf] + +Signed-off-by: Erkka Talvitie +Reviewed-by: Alan Stern +Cc: stable +Link: https://lore.kernel.org/r/ef70941d5f349767f19c0ed26b0dd9eed8ad81bb.1576050523.git.erkka.talvitie@vincit.fi +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/host/ehci-q.c | 13 ++++++++++++- + 1 file changed, 12 insertions(+), 1 deletion(-) + +--- a/drivers/usb/host/ehci-q.c ++++ b/drivers/usb/host/ehci-q.c +@@ -27,6 +27,10 @@ + + /*-------------------------------------------------------------------------*/ + ++/* PID Codes that are used here, from EHCI specification, Table 3-16. */ ++#define PID_CODE_IN 1 ++#define PID_CODE_SETUP 2 ++ + /* fill a qtd, returning how much of the buffer we were able to queue up */ + + static int +@@ -190,7 +194,7 @@ static int qtd_copy_status ( + int status = -EINPROGRESS; + + /* count IN/OUT bytes, not SETUP (even short packets) */ +- if (likely (QTD_PID (token) != 2)) ++ if (likely(QTD_PID(token) != PID_CODE_SETUP)) + urb->actual_length += length - QTD_LENGTH (token); + + /* don't modify error codes */ +@@ -206,6 +210,13 @@ static int qtd_copy_status ( + if (token & QTD_STS_BABBLE) { + /* FIXME "must" disable babbling device's port too */ + status = -EOVERFLOW; ++ /* ++ * When MMF is active and PID Code is IN, queue is halted. ++ * EHCI Specification, Table 4-13. ++ */ ++ } else if ((token & QTD_STS_MMF) && ++ (QTD_PID(token) == PID_CODE_IN)) { ++ status = -EPROTO; + /* CERR nonzero + halt --> stall */ + } else if (QTD_CERR(token)) { + status = -EPIPE; diff --git a/queue-5.4/usbip-fix-error-path-of-vhci_recv_ret_submit.patch b/queue-5.4/usbip-fix-error-path-of-vhci_recv_ret_submit.patch new file mode 100644 index 00000000000..57f99c8d8e6 --- /dev/null +++ b/queue-5.4/usbip-fix-error-path-of-vhci_recv_ret_submit.patch @@ -0,0 +1,70 @@ +From aabb5b833872524eaf28f52187e5987984982264 Mon Sep 17 00:00:00 2001 +From: Suwan Kim +Date: Fri, 13 Dec 2019 11:30:55 +0900 +Subject: usbip: Fix error path of vhci_recv_ret_submit() +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Suwan Kim + +commit aabb5b833872524eaf28f52187e5987984982264 upstream. + +If a transaction error happens in vhci_recv_ret_submit(), event +handler closes connection and changes port status to kick hub_event. +Then hub tries to flush the endpoint URBs, but that causes infinite +loop between usb_hub_flush_endpoint() and vhci_urb_dequeue() because +"vhci_priv" in vhci_urb_dequeue() was already released by +vhci_recv_ret_submit() before a transmission error occurred. Thus, +vhci_urb_dequeue() terminates early and usb_hub_flush_endpoint() +continuously calls vhci_urb_dequeue(). + +The root cause of this issue is that vhci_recv_ret_submit() +terminates early without giving back URB when transaction error +occurs in vhci_recv_ret_submit(). That causes the error URB to still +be linked at endpoint list without “vhci_priv". + +So, in the case of transaction error in vhci_recv_ret_submit(), +unlink URB from the endpoint, insert proper error code in +urb->status and give back URB. + +Reported-by: Marek Marczykowski-Górecki +Tested-by: Marek Marczykowski-Górecki +Signed-off-by: Suwan Kim +Cc: stable +Acked-by: Shuah Khan +Link: https://lore.kernel.org/r/20191213023055.19933-3-suwan.kim027@gmail.com +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/usbip/vhci_rx.c | 13 +++++++++---- + 1 file changed, 9 insertions(+), 4 deletions(-) + +--- a/drivers/usb/usbip/vhci_rx.c ++++ b/drivers/usb/usbip/vhci_rx.c +@@ -77,16 +77,21 @@ static void vhci_recv_ret_submit(struct + usbip_pack_pdu(pdu, urb, USBIP_RET_SUBMIT, 0); + + /* recv transfer buffer */ +- if (usbip_recv_xbuff(ud, urb) < 0) +- return; ++ if (usbip_recv_xbuff(ud, urb) < 0) { ++ urb->status = -EPROTO; ++ goto error; ++ } + + /* recv iso_packet_descriptor */ +- if (usbip_recv_iso(ud, urb) < 0) +- return; ++ if (usbip_recv_iso(ud, urb) < 0) { ++ urb->status = -EPROTO; ++ goto error; ++ } + + /* restore the padding in iso packets */ + usbip_pad_iso(ud, urb); + ++error: + if (usbip_dbg_flag_vhci_rx) + usbip_dump_urb(urb); + diff --git a/queue-5.4/usbip-fix-receive-error-in-vhci-hcd-when-using-scatter-gather.patch b/queue-5.4/usbip-fix-receive-error-in-vhci-hcd-when-using-scatter-gather.patch new file mode 100644 index 00000000000..947e9f21e01 --- /dev/null +++ b/queue-5.4/usbip-fix-receive-error-in-vhci-hcd-when-using-scatter-gather.patch @@ -0,0 +1,46 @@ +From d986294ee55d719562b20aabe15a39bf8f863415 Mon Sep 17 00:00:00 2001 +From: Suwan Kim +Date: Fri, 13 Dec 2019 11:30:54 +0900 +Subject: usbip: Fix receive error in vhci-hcd when using scatter-gather +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Suwan Kim + +commit d986294ee55d719562b20aabe15a39bf8f863415 upstream. + +When vhci uses SG and receives data whose size is smaller than SG +buffer size, it tries to receive more data even if it acutally +receives all the data from the server. If then, it erroneously adds +error event and triggers connection shutdown. + +vhci-hcd should check if it received all the data even if there are +more SG entries left. So, check if it receivces all the data from +the server in for_each_sg() loop. + +Fixes: ea44d190764b ("usbip: Implement SG support to vhci-hcd and stub driver") +Reported-by: Marek Marczykowski-Górecki +Tested-by: Marek Marczykowski-Górecki +Signed-off-by: Suwan Kim +Acked-by: Shuah Khan +Cc: stable +Link: https://lore.kernel.org/r/20191213023055.19933-2-suwan.kim027@gmail.com +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/usbip/usbip_common.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/drivers/usb/usbip/usbip_common.c ++++ b/drivers/usb/usbip/usbip_common.c +@@ -727,6 +727,9 @@ int usbip_recv_xbuff(struct usbip_device + + copy -= recv; + ret += recv; ++ ++ if (!copy) ++ break; + } + + if (ret != size) -- 2.47.3