From: Greg Kroah-Hartman Date: Mon, 8 Feb 2021 12:48:17 +0000 (+0100) Subject: 5.4-stable patches X-Git-Tag: v4.4.257~9 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=3f7999b674aed51f8feca93b1a193889fd052eea;p=thirdparty%2Fkernel%2Fstable-queue.git 5.4-stable patches added patches: input-xpad-sync-supported-devices-with-fork-on-github.patch iommu-vt-d-do-not-use-flush-queue-when-caching-mode-is-on.patch iwlwifi-mvm-don-t-send-rfh_queue_config_cmd-with-no-queues.patch md-set-prev_flush_start-and-flush_bio-in-an-atomic-way.patch --- diff --git a/queue-5.4/input-xpad-sync-supported-devices-with-fork-on-github.patch b/queue-5.4/input-xpad-sync-supported-devices-with-fork-on-github.patch new file mode 100644 index 00000000000..4b62d9dfbb3 --- /dev/null +++ b/queue-5.4/input-xpad-sync-supported-devices-with-fork-on-github.patch @@ -0,0 +1,69 @@ +From 9bbd77d5bbc9aff8cb74d805c31751f5f0691ba8 Mon Sep 17 00:00:00 2001 +From: Benjamin Valentin +Date: Thu, 21 Jan 2021 19:24:17 -0800 +Subject: Input: xpad - sync supported devices with fork on GitHub + +From: Benjamin Valentin + +commit 9bbd77d5bbc9aff8cb74d805c31751f5f0691ba8 upstream. + +There is a fork of this driver on GitHub [0] that has been updated +with new device IDs. + +Merge those into the mainline driver, so the out-of-tree fork is not +needed for users of those devices anymore. + +[0] https://github.com/paroj/xpad + +Signed-off-by: Benjamin Valentin +Link: https://lore.kernel.org/r/20210121142523.1b6b050f@rechenknecht2k11 +Signed-off-by: Dmitry Torokhov +Signed-off-by: Greg Kroah-Hartman +--- + drivers/input/joystick/xpad.c | 17 ++++++++++++++++- + 1 file changed, 16 insertions(+), 1 deletion(-) + +--- a/drivers/input/joystick/xpad.c ++++ b/drivers/input/joystick/xpad.c +@@ -215,9 +215,17 @@ static const struct xpad_device { + { 0x0e6f, 0x0213, "Afterglow Gamepad for Xbox 360", 0, XTYPE_XBOX360 }, + { 0x0e6f, 0x021f, "Rock Candy Gamepad for Xbox 360", 0, XTYPE_XBOX360 }, + { 0x0e6f, 0x0246, "Rock Candy Gamepad for Xbox One 2015", 0, XTYPE_XBOXONE }, +- { 0x0e6f, 0x02ab, "PDP Controller for Xbox One", 0, XTYPE_XBOXONE }, ++ { 0x0e6f, 0x02a0, "PDP Xbox One Controller", 0, XTYPE_XBOXONE }, ++ { 0x0e6f, 0x02a1, "PDP Xbox One Controller", 0, XTYPE_XBOXONE }, ++ { 0x0e6f, 0x02a2, "PDP Wired Controller for Xbox One - Crimson Red", 0, XTYPE_XBOXONE }, + { 0x0e6f, 0x02a4, "PDP Wired Controller for Xbox One - Stealth Series", 0, XTYPE_XBOXONE }, + { 0x0e6f, 0x02a6, "PDP Wired Controller for Xbox One - Camo Series", 0, XTYPE_XBOXONE }, ++ { 0x0e6f, 0x02a7, "PDP Xbox One Controller", 0, XTYPE_XBOXONE }, ++ { 0x0e6f, 0x02a8, "PDP Xbox One Controller", 0, XTYPE_XBOXONE }, ++ { 0x0e6f, 0x02ab, "PDP Controller for Xbox One", 0, XTYPE_XBOXONE }, ++ { 0x0e6f, 0x02ad, "PDP Wired Controller for Xbox One - Stealth Series", 0, XTYPE_XBOXONE }, ++ { 0x0e6f, 0x02b3, "Afterglow Prismatic Wired Controller", 0, XTYPE_XBOXONE }, ++ { 0x0e6f, 0x02b8, "Afterglow Prismatic Wired Controller", 0, XTYPE_XBOXONE }, + { 0x0e6f, 0x0301, "Logic3 Controller", 0, XTYPE_XBOX360 }, + { 0x0e6f, 0x0346, "Rock Candy Gamepad for Xbox One 2016", 0, XTYPE_XBOXONE }, + { 0x0e6f, 0x0401, "Logic3 Controller", 0, XTYPE_XBOX360 }, +@@ -296,6 +304,9 @@ static const struct xpad_device { + { 0x1bad, 0xfa01, "MadCatz GamePad", 0, XTYPE_XBOX360 }, + { 0x1bad, 0xfd00, "Razer Onza TE", 0, XTYPE_XBOX360 }, + { 0x1bad, 0xfd01, "Razer Onza", 0, XTYPE_XBOX360 }, ++ { 0x20d6, 0x2001, "BDA Xbox Series X Wired Controller", 0, XTYPE_XBOXONE }, ++ { 0x20d6, 0x281f, "PowerA Wired Controller For Xbox 360", 0, XTYPE_XBOX360 }, ++ { 0x2e24, 0x0652, "Hyperkin Duke X-Box One pad", 0, XTYPE_XBOXONE }, + { 0x24c6, 0x5000, "Razer Atrox Arcade Stick", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOX360 }, + { 0x24c6, 0x5300, "PowerA MINI PROEX Controller", 0, XTYPE_XBOX360 }, + { 0x24c6, 0x5303, "Xbox Airflo wired controller", 0, XTYPE_XBOX360 }, +@@ -429,8 +440,12 @@ static const struct usb_device_id xpad_t + XPAD_XBOX360_VENDOR(0x162e), /* Joytech X-Box 360 controllers */ + XPAD_XBOX360_VENDOR(0x1689), /* Razer Onza */ + XPAD_XBOX360_VENDOR(0x1bad), /* Harminix Rock Band Guitar and Drums */ ++ XPAD_XBOX360_VENDOR(0x20d6), /* PowerA Controllers */ ++ XPAD_XBOXONE_VENDOR(0x20d6), /* PowerA Controllers */ + XPAD_XBOX360_VENDOR(0x24c6), /* PowerA Controllers */ + XPAD_XBOXONE_VENDOR(0x24c6), /* PowerA Controllers */ ++ XPAD_XBOXONE_VENDOR(0x2e24), /* Hyperkin Duke X-Box One pad */ ++ XPAD_XBOX360_VENDOR(0x2f24), /* GameSir Controllers */ + { } + }; + diff --git a/queue-5.4/iommu-vt-d-do-not-use-flush-queue-when-caching-mode-is-on.patch b/queue-5.4/iommu-vt-d-do-not-use-flush-queue-when-caching-mode-is-on.patch new file mode 100644 index 00000000000..8d99ecc6cfa --- /dev/null +++ b/queue-5.4/iommu-vt-d-do-not-use-flush-queue-when-caching-mode-is-on.patch @@ -0,0 +1,76 @@ +From 29b32839725f8c89a41cb6ee054c85f3116ea8b5 Mon Sep 17 00:00:00 2001 +From: Nadav Amit +Date: Wed, 27 Jan 2021 09:53:17 -0800 +Subject: iommu/vt-d: Do not use flush-queue when caching-mode is on + +From: Nadav Amit + +commit 29b32839725f8c89a41cb6ee054c85f3116ea8b5 upstream. + +When an Intel IOMMU is virtualized, and a physical device is +passed-through to the VM, changes of the virtual IOMMU need to be +propagated to the physical IOMMU. The hypervisor therefore needs to +monitor PTE mappings in the IOMMU page-tables. Intel specifications +provide "caching-mode" capability that a virtual IOMMU uses to report +that the IOMMU is virtualized and a TLB flush is needed after mapping to +allow the hypervisor to propagate virtual IOMMU mappings to the physical +IOMMU. To the best of my knowledge no real physical IOMMU reports +"caching-mode" as turned on. + +Synchronizing the virtual and the physical IOMMU tables is expensive if +the hypervisor is unaware which PTEs have changed, as the hypervisor is +required to walk all the virtualized tables and look for changes. +Consequently, domain flushes are much more expensive than page-specific +flushes on virtualized IOMMUs with passthrough devices. The kernel +therefore exploited the "caching-mode" indication to avoid domain +flushing and use page-specific flushing in virtualized environments. See +commit 78d5f0f500e6 ("intel-iommu: Avoid global flushes with caching +mode.") + +This behavior changed after commit 13cf01744608 ("iommu/vt-d: Make use +of iova deferred flushing"). Now, when batched TLB flushing is used (the +default), full TLB domain flushes are performed frequently, requiring +the hypervisor to perform expensive synchronization between the virtual +TLB and the physical one. + +Getting batched TLB flushes to use page-specific invalidations again in +such circumstances is not easy, since the TLB invalidation scheme +assumes that "full" domain TLB flushes are performed for scalability. + +Disable batched TLB flushes when caching-mode is on, as the performance +benefit from using batched TLB invalidations is likely to be much +smaller than the overhead of the virtual-to-physical IOMMU page-tables +synchronization. + +Fixes: 13cf01744608 ("iommu/vt-d: Make use of iova deferred flushing") +Signed-off-by: Nadav Amit +Cc: David Woodhouse +Cc: Lu Baolu +Cc: Joerg Roedel +Cc: Will Deacon +Cc: stable@vger.kernel.org +Acked-by: Lu Baolu +Link: https://lore.kernel.org/r/20210127175317.1600473-1-namit@vmware.com +Signed-off-by: Joerg Roedel +Signed-off-by: Nadav Amit +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/iommu/intel-iommu.c | 6 ++++++ + 1 file changed, 6 insertions(+) + +--- a/drivers/iommu/intel-iommu.c ++++ b/drivers/iommu/intel-iommu.c +@@ -3285,6 +3285,12 @@ static int __init init_dmars(void) + + if (!ecap_pass_through(iommu->ecap)) + hw_pass_through = 0; ++ ++ if (!intel_iommu_strict && cap_caching_mode(iommu->cap)) { ++ pr_info("Disable batched IOTLB flush due to virtualization"); ++ intel_iommu_strict = 1; ++ } ++ + #ifdef CONFIG_INTEL_IOMMU_SVM + if (pasid_supported(iommu)) + intel_svm_init(iommu); diff --git a/queue-5.4/iwlwifi-mvm-don-t-send-rfh_queue_config_cmd-with-no-queues.patch b/queue-5.4/iwlwifi-mvm-don-t-send-rfh_queue_config_cmd-with-no-queues.patch new file mode 100644 index 00000000000..027cedf57e5 --- /dev/null +++ b/queue-5.4/iwlwifi-mvm-don-t-send-rfh_queue_config_cmd-with-no-queues.patch @@ -0,0 +1,43 @@ +From 64f55156f7adedb1ac5bb9cdbcbc9ac05ff5a724 Mon Sep 17 00:00:00 2001 +From: Luca Coelho +Date: Thu, 8 Oct 2020 18:09:43 +0300 +Subject: iwlwifi: mvm: don't send RFH_QUEUE_CONFIG_CMD with no queues + +From: Luca Coelho + +commit 64f55156f7adedb1ac5bb9cdbcbc9ac05ff5a724 upstream. + +If we have only a single RX queue, such as when MSI-X is not +available, we should not send the RFH_QUEUEU_CONFIG_CMD, because our +only queue is the same as the command queue and will be configured as +part of the context info. Our code was actually trying to send the +command with 0 queues, which caused UMAC assert 0x1D04. + +Fix that by not sending the command when we have a single queue. + +Signed-off-by: Luca Coelho +Signed-off-by: Kalle Valo +Link: https://lore.kernel.org/r/iwlwifi.20201008180656.c35eeb3299f8.I08f79a6ebe150a7d180b7005b24504bfdba6d8b5@changeid +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 9 ++++++++- + 1 file changed, 8 insertions(+), 1 deletion(-) + +--- a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c ++++ b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c +@@ -134,7 +134,14 @@ static int iwl_configure_rxq(struct iwl_ + .dataflags[0] = IWL_HCMD_DFL_NOCOPY, + }; + +- /* Do not configure default queue, it is configured via context info */ ++ /* ++ * The default queue is configured via context info, so if we ++ * have a single queue, there's nothing to do here. ++ */ ++ if (mvm->trans->num_rx_queues == 1) ++ return 0; ++ ++ /* skip the default queue */ + num_queues = mvm->trans->num_rx_queues - 1; + + size = struct_size(cmd, data, num_queues); diff --git a/queue-5.4/md-set-prev_flush_start-and-flush_bio-in-an-atomic-way.patch b/queue-5.4/md-set-prev_flush_start-and-flush_bio-in-an-atomic-way.patch new file mode 100644 index 00000000000..d38402c4302 --- /dev/null +++ b/queue-5.4/md-set-prev_flush_start-and-flush_bio-in-an-atomic-way.patch @@ -0,0 +1,65 @@ +From dc5d17a3c39b06aef866afca19245a9cfb533a79 Mon Sep 17 00:00:00 2001 +From: Xiao Ni +Date: Thu, 10 Dec 2020 14:33:32 +0800 +Subject: md: Set prev_flush_start and flush_bio in an atomic way + +From: Xiao Ni + +commit dc5d17a3c39b06aef866afca19245a9cfb533a79 upstream. + +One customer reports a crash problem which causes by flush request. It +triggers a warning before crash. + + /* new request after previous flush is completed */ + if (ktime_after(req_start, mddev->prev_flush_start)) { + WARN_ON(mddev->flush_bio); + mddev->flush_bio = bio; + bio = NULL; + } + +The WARN_ON is triggered. We use spin lock to protect prev_flush_start and +flush_bio in md_flush_request. But there is no lock protection in +md_submit_flush_data. It can set flush_bio to NULL first because of +compiler reordering write instructions. + +For example, flush bio1 sets flush bio to NULL first in +md_submit_flush_data. An interrupt or vmware causing an extended stall +happen between updating flush_bio and prev_flush_start. Because flush_bio +is NULL, flush bio2 can get the lock and submit to underlayer disks. Then +flush bio1 updates prev_flush_start after the interrupt or extended stall. + +Then flush bio3 enters in md_flush_request. The start time req_start is +behind prev_flush_start. The flush_bio is not NULL(flush bio2 hasn't +finished). So it can trigger the WARN_ON now. Then it calls INIT_WORK +again. INIT_WORK() will re-initialize the list pointers in the +work_struct, which then can result in a corrupted work list and the +work_struct queued a second time. With the work list corrupted, it can +lead in invalid work items being used and cause a crash in +process_one_work. + +We need to make sure only one flush bio can be handled at one same time. +So add spin lock in md_submit_flush_data to protect prev_flush_start and +flush_bio in an atomic way. + +Reviewed-by: David Jeffery +Signed-off-by: Xiao Ni +Signed-off-by: Song Liu +Signed-off-by: Jack Wang +Signed-off-by: Greg Kroah-Hartman +--- + drivers/md/md.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/drivers/md/md.c ++++ b/drivers/md/md.c +@@ -538,8 +538,10 @@ static void md_submit_flush_data(struct + * could wait for this and below md_handle_request could wait for those + * bios because of suspend check + */ ++ spin_lock_irq(&mddev->lock); + mddev->last_flush = mddev->start_flush; + mddev->flush_bio = NULL; ++ spin_unlock_irq(&mddev->lock); + wake_up(&mddev->sb_wait); + + if (bio->bi_iter.bi_size == 0) { diff --git a/queue-5.4/series b/queue-5.4/series index 3b08b5542d0..89bb6c91aea 100644 --- a/queue-5.4/series +++ b/queue-5.4/series @@ -53,3 +53,7 @@ mm-compaction-move-high_pfn-to-the-for-loop-scope.patch mm-thp-fix-madv_remove-deadlock-on-shmem-thp.patch x86-build-disable-cet-instrumentation-in-the-kernel.patch x86-apic-add-extra-serialization-for-non-serializing-msrs.patch +iwlwifi-mvm-don-t-send-rfh_queue_config_cmd-with-no-queues.patch +input-xpad-sync-supported-devices-with-fork-on-github.patch +iommu-vt-d-do-not-use-flush-queue-when-caching-mode-is-on.patch +md-set-prev_flush_start-and-flush_bio-in-an-atomic-way.patch