From: Greg Kroah-Hartman Date: Sun, 5 May 2019 13:19:23 +0000 (+0200) Subject: 5.0-stable patches X-Git-Tag: v4.9.174~40 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=2c26872ce4e9987c94940e43e843bf3d44b9a012;p=thirdparty%2Fkernel%2Fstable-queue.git 5.0-stable patches added patches: alsa-hda-realtek-add-new-dell-platform-for-headset-mode.patch alsa-hda-realtek-apply-the-fixup-for-asus-q325uar.patch alsa-hda-realtek-fixed-dell-aio-speaker-noise.patch i2c-imx-correct-the-method-of-getting-private-data-in-notifier_call.patch i2c-prevent-runtime-suspend-of-adapter-when-host-notify-is-required.patch i2c-synquacer-fix-enumeration-of-slave-devices.patch iwlwifi-fix-driver-operation-for-5350.patch kvm-lapic-allow-user-to-disable-adaptive-tuning-of-timer-advancement.patch kvm-lapic-convert-guest-tsc-to-host-time-domain-if-necessary.patch kvm-lapic-disable-timer-advancement-if-adaptive-tuning-goes-haywire.patch kvm-lapic-track-lapic-timer-advance-per-vcpu.patch kvm-x86-consider-lapic-tsc-deadline-timer-expired-if-deadline-too-short.patch mac80211-don-t-attempt-to-rename-err_ptr-debugfs-dirs.patch mtd-rawnand-marvell-clean-the-controller-state-before-each-operation.patch mwifiex-make-resume-actually-do-something-useful-again-on-sdio-cards.patch usb-core-fix-bug-caused-by-duplicate-interface-pm-usage-counter.patch usb-core-fix-unterminated-string-returned-by-usb_string.patch usb-dummy-hcd-fix-failure-to-give-back-unlinked-urbs.patch usb-usbip-fix-isoc-packet-num-validation-in-get_pipe.patch usb-w1-ds2490-fix-bug-caused-by-improper-use-of-altsetting-array.patch usb-yurex-fix-protection-fault-after-device-removal.patch --- diff --git a/queue-5.0/alsa-hda-realtek-add-new-dell-platform-for-headset-mode.patch b/queue-5.0/alsa-hda-realtek-add-new-dell-platform-for-headset-mode.patch new file mode 100644 index 00000000000..56d0dda4011 --- /dev/null +++ b/queue-5.0/alsa-hda-realtek-add-new-dell-platform-for-headset-mode.patch @@ -0,0 +1,48 @@ +From 0a29c57b76624723b6b00c027e0e992d130ace49 Mon Sep 17 00:00:00 2001 +From: Kailang Yang +Date: Wed, 24 Apr 2019 16:34:25 +0800 +Subject: ALSA: hda/realtek - Add new Dell platform for headset mode + +From: Kailang Yang + +commit 0a29c57b76624723b6b00c027e0e992d130ace49 upstream. + +Add two Dell platform for headset mode. + +[ Note: this is a further correction / addition of the previous + pin-based quirks for Dell machines; another entry for ALC236 with + the d-mic pin 0x12 and an entry for ALC295 -- tiwai ] + +Fixes: b26e36b7ef36 ("ALSA: hda/realtek - add two more pin configuration sets to quirk table") +Signed-off-by: Kailang Yang +Cc: +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman + +--- + sound/pci/hda/patch_realtek.c | 7 +++++++ + 1 file changed, 7 insertions(+) + +--- a/sound/pci/hda/patch_realtek.c ++++ b/sound/pci/hda/patch_realtek.c +@@ -7266,6 +7266,10 @@ static const struct snd_hda_pin_quirk al + {0x21, 0x02211020}), + SND_HDA_PIN_QUIRK(0x10ec0236, 0x1028, "Dell", ALC255_FIXUP_DELL1_MIC_NO_PRESENCE, + {0x21, 0x02211020}), ++ SND_HDA_PIN_QUIRK(0x10ec0236, 0x1028, "Dell", ALC255_FIXUP_DELL1_MIC_NO_PRESENCE, ++ {0x12, 0x40000000}, ++ {0x14, 0x90170110}, ++ {0x21, 0x02211020}), + SND_HDA_PIN_QUIRK(0x10ec0255, 0x1028, "Dell", ALC255_FIXUP_DELL2_MIC_NO_PRESENCE, + {0x14, 0x90170110}, + {0x21, 0x02211020}), +@@ -7540,6 +7544,9 @@ static const struct snd_hda_pin_quirk al + {0x17, 0x90170110}, + {0x21, 0x04211020}), + SND_HDA_PIN_QUIRK(0x10ec0295, 0x1028, "Dell", ALC269_FIXUP_DELL1_MIC_NO_PRESENCE, ++ {0x14, 0x90170110}, ++ {0x21, 0x04211020}), ++ SND_HDA_PIN_QUIRK(0x10ec0295, 0x1028, "Dell", ALC269_FIXUP_DELL1_MIC_NO_PRESENCE, + ALC295_STANDARD_PINS, + {0x17, 0x21014020}, + {0x18, 0x21a19030}), diff --git a/queue-5.0/alsa-hda-realtek-apply-the-fixup-for-asus-q325uar.patch b/queue-5.0/alsa-hda-realtek-apply-the-fixup-for-asus-q325uar.patch new file mode 100644 index 00000000000..b10e4ecc6dc --- /dev/null +++ b/queue-5.0/alsa-hda-realtek-apply-the-fixup-for-asus-q325uar.patch @@ -0,0 +1,35 @@ +From 3887c26c0e24d50a4d0ce20cf4726737cee1a2fd Mon Sep 17 00:00:00 2001 +From: Takashi Iwai +Date: Tue, 30 Apr 2019 15:10:01 +0200 +Subject: ALSA: hda/realtek - Apply the fixup for ASUS Q325UAR + +From: Takashi Iwai + +commit 3887c26c0e24d50a4d0ce20cf4726737cee1a2fd upstream. + +Some ASUS models like Q325UAR with ALC295 codec requires the same +fixup that has been applied to ALC294 codec. Just copy the entry with +the pin matching to cover ALC295 too. + +BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1784485 +Cc: +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman + +--- + sound/pci/hda/patch_realtek.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/sound/pci/hda/patch_realtek.c ++++ b/sound/pci/hda/patch_realtek.c +@@ -7545,6 +7545,10 @@ static const struct snd_hda_pin_quirk al + {0x12, 0x90a60130}, + {0x17, 0x90170110}, + {0x21, 0x04211020}), ++ SND_HDA_PIN_QUIRK(0x10ec0295, 0x1043, "ASUS", ALC294_FIXUP_ASUS_SPK, ++ {0x12, 0x90a60130}, ++ {0x17, 0x90170110}, ++ {0x21, 0x03211020}), + SND_HDA_PIN_QUIRK(0x10ec0295, 0x1028, "Dell", ALC269_FIXUP_DELL1_MIC_NO_PRESENCE, + {0x14, 0x90170110}, + {0x21, 0x04211020}), diff --git a/queue-5.0/alsa-hda-realtek-fixed-dell-aio-speaker-noise.patch b/queue-5.0/alsa-hda-realtek-fixed-dell-aio-speaker-noise.patch new file mode 100644 index 00000000000..a7e82d14e53 --- /dev/null +++ b/queue-5.0/alsa-hda-realtek-fixed-dell-aio-speaker-noise.patch @@ -0,0 +1,36 @@ +From 0700d3d117a7f110ddddbd83873e13652f69c54b Mon Sep 17 00:00:00 2001 +From: Kailang Yang +Date: Fri, 26 Apr 2019 16:13:54 +0800 +Subject: ALSA: hda/realtek - Fixed Dell AIO speaker noise + +From: Kailang Yang + +commit 0700d3d117a7f110ddddbd83873e13652f69c54b upstream. + +Fixed Dell AIO speaker noise. +spec->gen.auto_mute_via_amp = 1, this option was solved speaker white +noise at boot. +codec->power_save_node = 0, this option was solved speaker noise at +resume back. + +Fixes: 9226665159f0 ("ALSA: hda/realtek - Fix Dell AIO LineOut issue") +Signed-off-by: Kailang Yang +Cc: +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman + +--- + sound/pci/hda/patch_realtek.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/sound/pci/hda/patch_realtek.c ++++ b/sound/pci/hda/patch_realtek.c +@@ -5448,6 +5448,8 @@ static void alc274_fixup_bind_dacs(struc + return; + + spec->gen.preferred_dacs = preferred_pairs; ++ spec->gen.auto_mute_via_amp = 1; ++ codec->power_save_node = 0; + } + + /* The DAC of NID 0x3 will introduce click/pop noise on headphones, so invalidate it */ diff --git a/queue-5.0/i2c-imx-correct-the-method-of-getting-private-data-in-notifier_call.patch b/queue-5.0/i2c-imx-correct-the-method-of-getting-private-data-in-notifier_call.patch new file mode 100644 index 00000000000..f84b532b45c --- /dev/null +++ b/queue-5.0/i2c-imx-correct-the-method-of-getting-private-data-in-notifier_call.patch @@ -0,0 +1,84 @@ +From d386bb9042f4629bf62cdc5952ea8aab225f24a7 Mon Sep 17 00:00:00 2001 +From: Anson Huang +Date: Wed, 17 Apr 2019 01:59:34 +0000 +Subject: i2c: imx: correct the method of getting private data in notifier_call + +From: Anson Huang + +commit d386bb9042f4629bf62cdc5952ea8aab225f24a7 upstream. + +The way of getting private imx_i2c_struct in i2c_imx_clk_notifier_call() +is incorrect, should use clk_change_nb element to get correct address +and avoid below kernel dump during POST_RATE_CHANGE notify by clk +framework: + +Unable to handle kernel paging request at virtual address 03ef1488 +pgd = (ptrval) +[03ef1488] *pgd=00000000 +Internal error: Oops: 5 [#1] PREEMPT SMP ARM +Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) +Workqueue: events reduce_bus_freq_handler +PC is at i2c_imx_set_clk+0x10/0xb8 +LR is at i2c_imx_clk_notifier_call+0x20/0x28 +pc : [<806a893c>] lr : [<806a8a04>] psr: a0080013 +sp : bf399dd8 ip : bf3432ac fp : bf7c1dc0 +r10: 00000002 r9 : 00000000 r8 : 00000000 +r7 : 03ef1480 r6 : bf399e50 r5 : ffffffff r4 : 00000000 +r3 : bf025300 r2 : bf399e50 r1 : 00b71b00 r0 : bf399be8 +Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none +Control: 10c5387d Table: 4e03004a DAC: 00000051 +Process kworker/2:1 (pid: 38, stack limit = 0x(ptrval)) +Stack: (0xbf399dd8 to 0xbf39a000) +9dc0: 806a89e4 00000000 +9de0: ffffffff bf399e50 00000002 806a8a04 806a89e4 80142900 ffffffff 00000000 +9e00: bf34ef18 bf34ef04 00000000 ffffffff bf399e50 80142d84 00000000 bf399e6c +9e20: bf34ef00 80f214c4 bf025300 00000002 80f08d08 bf017480 00000000 80142df0 +9e40: 00000000 80166ed8 80c27638 8045de58 bf352340 03ef1480 00b71b00 0f82e242 +9e60: bf025300 00000002 03ef1480 80f60e5c 00000001 8045edf0 00000002 8045eb08 +9e80: bf025300 00000002 03ef1480 8045ee10 03ef1480 8045eb08 bf01be40 00000002 +9ea0: 03ef1480 8045ee10 07de2900 8045eb08 bf01b780 00000002 07de2900 8045ee10 +9ec0: 80c27898 bf399ee4 bf020a80 00000002 1f78a400 8045ee10 80f60e5c 80460514 +9ee0: 80f60e5c bf01b600 bf01b480 80460460 0f82e242 bf383a80 bf383a00 80f60e5c +9f00: 00000000 bf7c1dc0 80f60e70 80460564 80f60df0 80f60d24 80f60df0 8011e72c +9f20: 00000000 80f60df0 80f60e6c bf7c4f00 00000000 8011e7ac bf274000 8013bd84 +9f40: bf7c1dd8 80f03d00 bf274000 bf7c1dc0 bf274014 bf7c1dd8 80f03d00 bf398000 +9f60: 00000008 8013bfb4 00000000 bf25d100 bf25d0c0 00000000 bf274000 8013bf88 +9f80: bf25d11c bf0cfebc 00000000 8014140c bf25d0c0 801412ec 00000000 00000000 +9fa0: 00000000 00000000 00000000 801010e8 00000000 00000000 00000000 00000000 +9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 +9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000 +[<806a893c>] (i2c_imx_set_clk) from [<806a8a04>] (i2c_imx_clk_notifier_call+0x20/0x28) +[<806a8a04>] (i2c_imx_clk_notifier_call) from [<80142900>] (notifier_call_chain+0x44/0x84) +[<80142900>] (notifier_call_chain) from [<80142d84>] (__srcu_notifier_call_chain+0x44/0x98) +[<80142d84>] (__srcu_notifier_call_chain) from [<80142df0>] (srcu_notifier_call_chain+0x18/0x20) +[<80142df0>] (srcu_notifier_call_chain) from [<8045de58>] (__clk_notify+0x78/0xa4) +[<8045de58>] (__clk_notify) from [<8045edf0>] (__clk_recalc_rates+0x60/0xb4) +[<8045edf0>] (__clk_recalc_rates) from [<8045ee10>] (__clk_recalc_rates+0x80/0xb4) +Code: e92d40f8 e5903298 e59072a0 e1530001 (e5975008) +---[ end trace fc7f5514b97b6cbb ]--- + +Fixes: 90ad2cbe88c2 ("i2c: imx: use clk notifier for rate changes") +Signed-off-by: Anson Huang +Reviewed-by: Dong Aisheng +Signed-off-by: Wolfram Sang +Cc: stable@kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/i2c/busses/i2c-imx.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/i2c/busses/i2c-imx.c ++++ b/drivers/i2c/busses/i2c-imx.c +@@ -510,9 +510,9 @@ static int i2c_imx_clk_notifier_call(str + unsigned long action, void *data) + { + struct clk_notifier_data *ndata = data; +- struct imx_i2c_struct *i2c_imx = container_of(&ndata->clk, ++ struct imx_i2c_struct *i2c_imx = container_of(nb, + struct imx_i2c_struct, +- clk); ++ clk_change_nb); + + if (action & POST_RATE_CHANGE) + i2c_imx_set_clk(i2c_imx, ndata->new_rate); diff --git a/queue-5.0/i2c-prevent-runtime-suspend-of-adapter-when-host-notify-is-required.patch b/queue-5.0/i2c-prevent-runtime-suspend-of-adapter-when-host-notify-is-required.patch new file mode 100644 index 00000000000..b579bd51730 --- /dev/null +++ b/queue-5.0/i2c-prevent-runtime-suspend-of-adapter-when-host-notify-is-required.patch @@ -0,0 +1,63 @@ +From 72bfcee11cf89509795c56b0e40a3785ab00bbdd Mon Sep 17 00:00:00 2001 +From: Jarkko Nikula +Date: Tue, 30 Apr 2019 17:23:22 +0300 +Subject: i2c: Prevent runtime suspend of adapter when Host Notify is required + +From: Jarkko Nikula + +commit 72bfcee11cf89509795c56b0e40a3785ab00bbdd upstream. + +Multiple users have reported their Synaptics touchpad has stopped +working between v4.20.1 and v4.20.2 when using SMBus interface. + +The culprit for this appeared to be commit c5eb1190074c ("PCI / PM: Allow +runtime PM without callback functions") that fixed the runtime PM for +i2c-i801 SMBus adapter. Those Synaptics touchpad are using i2c-i801 +for SMBus communication and testing showed they are able to get back +working by preventing the runtime suspend of adapter. + +Normally when i2c-i801 SMBus adapter transmits with the client it resumes +before operation and autosuspends after. + +However, if client requires SMBus Host Notify protocol, what those +Synaptics touchpads do, then the host adapter must not go to runtime +suspend since then it cannot process incoming SMBus Host Notify commands +the client may send. + +Fix this by keeping I2C/SMBus adapter active in case client requires +Host Notify. + +Reported-by: Keijo Vaara +Link: https://bugzilla.kernel.org/show_bug.cgi?id=203297 +Fixes: c5eb1190074c ("PCI / PM: Allow runtime PM without callback functions") +Cc: stable@vger.kernel.org # v4.20+ +Signed-off-by: Jarkko Nikula +Acked-by: Rafael J. Wysocki +Tested-by: Keijo Vaara +Signed-off-by: Wolfram Sang +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/i2c/i2c-core-base.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/drivers/i2c/i2c-core-base.c ++++ b/drivers/i2c/i2c-core-base.c +@@ -327,6 +327,8 @@ static int i2c_device_probe(struct devic + + if (client->flags & I2C_CLIENT_HOST_NOTIFY) { + dev_dbg(dev, "Using Host Notify IRQ\n"); ++ /* Keep adapter active when Host Notify is required */ ++ pm_runtime_get_sync(&client->adapter->dev); + irq = i2c_smbus_host_notify_to_irq(client); + } else if (dev->of_node) { + irq = of_irq_get_byname(dev->of_node, "irq"); +@@ -431,6 +433,8 @@ static int i2c_device_remove(struct devi + device_init_wakeup(&client->dev, false); + + client->irq = client->init_irq; ++ if (client->flags & I2C_CLIENT_HOST_NOTIFY) ++ pm_runtime_put(&client->adapter->dev); + + return status; + } diff --git a/queue-5.0/i2c-synquacer-fix-enumeration-of-slave-devices.patch b/queue-5.0/i2c-synquacer-fix-enumeration-of-slave-devices.patch new file mode 100644 index 00000000000..4d04ae96624 --- /dev/null +++ b/queue-5.0/i2c-synquacer-fix-enumeration-of-slave-devices.patch @@ -0,0 +1,34 @@ +From 95e0cf3caeb11e1b0398c747b5cfa12828263824 Mon Sep 17 00:00:00 2001 +From: Ard Biesheuvel +Date: Tue, 30 Apr 2019 11:47:34 +0200 +Subject: i2c: synquacer: fix enumeration of slave devices + +From: Ard Biesheuvel + +commit 95e0cf3caeb11e1b0398c747b5cfa12828263824 upstream. + +The I2C host driver for SynQuacer fails to populate the of_node and +ACPI companion fields of the struct i2c_adapter it instantiates, +resulting in enumeration of the subordinate I2C bus to fail. + +Fixes: 0d676a6c4390 ("i2c: add support for Socionext SynQuacer I2C controller") +Cc: # v4.19+ +Signed-off-by: Ard Biesheuvel +Signed-off-by: Wolfram Sang +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/i2c/busses/i2c-synquacer.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/drivers/i2c/busses/i2c-synquacer.c ++++ b/drivers/i2c/busses/i2c-synquacer.c +@@ -602,6 +602,8 @@ static int synquacer_i2c_probe(struct pl + i2c->adapter = synquacer_i2c_ops; + i2c_set_adapdata(&i2c->adapter, i2c); + i2c->adapter.dev.parent = &pdev->dev; ++ i2c->adapter.dev.of_node = pdev->dev.of_node; ++ ACPI_COMPANION_SET(&i2c->adapter.dev, ACPI_COMPANION(&pdev->dev)); + i2c->adapter.nr = pdev->id; + init_completion(&i2c->completion); + diff --git a/queue-5.0/iwlwifi-fix-driver-operation-for-5350.patch b/queue-5.0/iwlwifi-fix-driver-operation-for-5350.patch new file mode 100644 index 00000000000..4cb80bc3758 --- /dev/null +++ b/queue-5.0/iwlwifi-fix-driver-operation-for-5350.patch @@ -0,0 +1,47 @@ +From 5c9adef9789148d382d7d1307c3d6bfaf51d143d Mon Sep 17 00:00:00 2001 +From: Emmanuel Grumbach +Date: Sun, 21 Apr 2019 17:58:11 +0300 +Subject: iwlwifi: fix driver operation for 5350 + +From: Emmanuel Grumbach + +commit 5c9adef9789148d382d7d1307c3d6bfaf51d143d upstream. + +We introduced a bug that prevented this old device from +working. The driver would simply not be able to complete +the INIT flow while spewing this warning: + + CSR addresses aren't configured + WARNING: CPU: 0 PID: 819 at drivers/net/wireless/intel/iwlwifi/pcie/drv.c:917 + iwl_pci_probe+0x160/0x1e0 [iwlwifi] + +Cc: stable@vger.kernel.org # v4.18+ +Fixes: a8cbb46f831d ("iwlwifi: allow different csr flags for different device families") +Signed-off-by: Emmanuel Grumbach +Fixes: c8f1b51e506d ("iwlwifi: allow different csr flags for different device families") +Signed-off-by: Luca Coelho +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/wireless/intel/iwlwifi/cfg/5000.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/net/wireless/intel/iwlwifi/cfg/5000.c ++++ b/drivers/net/wireless/intel/iwlwifi/cfg/5000.c +@@ -1,7 +1,7 @@ + /****************************************************************************** + * + * Copyright(c) 2007 - 2014 Intel Corporation. All rights reserved. +- * Copyright(c) 2018 Intel Corporation ++ * Copyright(c) 2018 - 2019 Intel Corporation + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of version 2 of the GNU General Public License as +@@ -136,6 +136,7 @@ const struct iwl_cfg iwl5350_agn_cfg = { + .ht_params = &iwl5000_ht_params, + .led_mode = IWL_LED_BLINK, + .internal_wimax_coex = true, ++ .csr = &iwl_csr_v1, + }; + + #define IWL_DEVICE_5150 \ diff --git a/queue-5.0/kvm-lapic-allow-user-to-disable-adaptive-tuning-of-timer-advancement.patch b/queue-5.0/kvm-lapic-allow-user-to-disable-adaptive-tuning-of-timer-advancement.patch new file mode 100644 index 00000000000..f40535b7981 --- /dev/null +++ b/queue-5.0/kvm-lapic-allow-user-to-disable-adaptive-tuning-of-timer-advancement.patch @@ -0,0 +1,114 @@ +From c3941d9e0ccd48920e4811f133235b3597e5310b Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Wed, 17 Apr 2019 10:15:33 -0700 +Subject: KVM: lapic: Allow user to disable adaptive tuning of timer advancement + +From: Sean Christopherson + +commit c3941d9e0ccd48920e4811f133235b3597e5310b upstream. + +The introduction of adaptive tuning of lapic timer advancement did not +allow for the scenario where userspace would want to disable adaptive +tuning but still employ timer advancement, e.g. for testing purposes or +to handle a use case where adaptive tuning is unable to settle on a +suitable time. This is epecially pertinent now that KVM places a hard +threshold on the maximum advancment time. + +Rework the timer semantics to accept signed values, with a value of '-1' +being interpreted as "use adaptive tuning with KVM's internal default", +and any other value being used as an explicit advancement time, e.g. a +time of '0' effectively disables advancement. + +Note, this does not completely restore the original behavior of +lapic_timer_advance_ns. Prior to tracking the advancement per vCPU, +which is necessary to support autotuning, userspace could adjust +lapic_timer_advance_ns for *running* vCPU. With per-vCPU tracking, the +module params are snapshotted at vCPU creation, i.e. applying a new +advancement effectively requires restarting a VM. + +Dynamically updating a running vCPU is possible, e.g. a helper could be +added to retrieve the desired delay, choosing between the global module +param and the per-VCPU value depending on whether or not auto-tuning is +(globally) enabled, but introduces a great deal of complexity. The +wrapper itself is not complex, but understanding and documenting the +effects of dynamically toggling auto-tuning and/or adjusting the timer +advancement is nigh impossible since the behavior would be dependent on +KVM's implementation as well as compiler optimizations. In other words, +providing stable behavior would require extremely careful consideration +now and in the future. + +Given that the expected use of a manually-tuned timer advancement is to +"tune once, run many", use the vastly simpler approach of recognizing +changes to the module params only when creating a new vCPU. + +Cc: Liran Alon +Cc: Wanpeng Li +Reviewed-by: Liran Alon +Cc: stable@vger.kernel.org +Fixes: 3b8a5df6c4dc6 ("KVM: LAPIC: Tune lapic_timer_advance_ns automatically") +Signed-off-by: Sean Christopherson +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kvm/lapic.c | 11 +++++++++-- + arch/x86/kvm/lapic.h | 2 +- + arch/x86/kvm/x86.c | 9 +++++++-- + 3 files changed, 17 insertions(+), 5 deletions(-) + +--- a/arch/x86/kvm/lapic.c ++++ b/arch/x86/kvm/lapic.c +@@ -2260,7 +2260,7 @@ static enum hrtimer_restart apic_timer_f + return HRTIMER_NORESTART; + } + +-int kvm_create_lapic(struct kvm_vcpu *vcpu, u32 timer_advance_ns) ++int kvm_create_lapic(struct kvm_vcpu *vcpu, int timer_advance_ns) + { + struct kvm_lapic *apic; + +@@ -2284,7 +2284,14 @@ int kvm_create_lapic(struct kvm_vcpu *vc + hrtimer_init(&apic->lapic_timer.timer, CLOCK_MONOTONIC, + HRTIMER_MODE_ABS_PINNED); + apic->lapic_timer.timer.function = apic_timer_fn; +- apic->lapic_timer.timer_advance_ns = timer_advance_ns; ++ if (timer_advance_ns == -1) { ++ apic->lapic_timer.timer_advance_ns = 1000; ++ apic->lapic_timer.timer_advance_adjust_done = false; ++ } else { ++ apic->lapic_timer.timer_advance_ns = timer_advance_ns; ++ apic->lapic_timer.timer_advance_adjust_done = true; ++ } ++ + + /* + * APIC is created enabled. This will prevent kvm_lapic_set_base from +--- a/arch/x86/kvm/lapic.h ++++ b/arch/x86/kvm/lapic.h +@@ -64,7 +64,7 @@ struct kvm_lapic { + + struct dest_map; + +-int kvm_create_lapic(struct kvm_vcpu *vcpu, u32 timer_advance_ns); ++int kvm_create_lapic(struct kvm_vcpu *vcpu, int timer_advance_ns); + void kvm_free_lapic(struct kvm_vcpu *vcpu); + + int kvm_apic_has_interrupt(struct kvm_vcpu *vcpu); +--- a/arch/x86/kvm/x86.c ++++ b/arch/x86/kvm/x86.c +@@ -136,8 +136,13 @@ EXPORT_SYMBOL_GPL(kvm_default_tsc_scalin + static u32 __read_mostly tsc_tolerance_ppm = 250; + module_param(tsc_tolerance_ppm, uint, S_IRUGO | S_IWUSR); + +-/* lapic timer advance (tscdeadline mode only) in nanoseconds */ +-static u32 __read_mostly lapic_timer_advance_ns = 1000; ++/* ++ * lapic timer advance (tscdeadline mode only) in nanoseconds. '-1' enables ++ * adaptive tuning starting from default advancment of 1000ns. '0' disables ++ * advancement entirely. Any other value is used as-is and disables adaptive ++ * tuning, i.e. allows priveleged userspace to set an exact advancement time. ++ */ ++static int __read_mostly lapic_timer_advance_ns = -1; + module_param(lapic_timer_advance_ns, uint, S_IRUGO | S_IWUSR); + + static bool __read_mostly vector_hashing = true; diff --git a/queue-5.0/kvm-lapic-convert-guest-tsc-to-host-time-domain-if-necessary.patch b/queue-5.0/kvm-lapic-convert-guest-tsc-to-host-time-domain-if-necessary.patch new file mode 100644 index 00000000000..02376f8c4b0 --- /dev/null +++ b/queue-5.0/kvm-lapic-convert-guest-tsc-to-host-time-domain-if-necessary.patch @@ -0,0 +1,83 @@ +From b6aa57c69cb26ea0160c51f7cf45f1af23542686 Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Wed, 17 Apr 2019 10:15:34 -0700 +Subject: KVM: lapic: Convert guest TSC to host time domain if necessary + +From: Sean Christopherson + +commit b6aa57c69cb26ea0160c51f7cf45f1af23542686 upstream. + +To minimize the latency of timer interrupts as observed by the guest, +KVM adjusts the values it programs into the host timers to account for +the host's overhead of programming and handling the timer event. In +the event that the adjustments are too aggressive, i.e. the timer fires +earlier than the guest expects, KVM busy waits immediately prior to +entering the guest. + +Currently, KVM manually converts the delay from nanoseconds to clock +cycles. But, the conversion is done in the guest's time domain, while +the delay occurs in the host's time domain. This is perfectly ok when +the guest and host are using the same TSC ratio, but if the guest is +using a different ratio then the delay may not be accurate and could +wait too little or too long. + +When the guest is not using the host's ratio, convert the delay from +guest clock cycles to host nanoseconds and use ndelay() instead of +__delay() to provide more accurate timing. Because converting to +nanoseconds is relatively expensive, e.g. requires division and more +multiplication ops, continue using __delay() directly when guest and +host TSCs are running at the same ratio. + +Cc: Liran Alon +Cc: Wanpeng Li +Cc: stable@vger.kernel.org +Fixes: 3b8a5df6c4dc6 ("KVM: LAPIC: Tune lapic_timer_advance_ns automatically") +Signed-off-by: Sean Christopherson +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kvm/lapic.c | 24 +++++++++++++++++++++--- + 1 file changed, 21 insertions(+), 3 deletions(-) + +--- a/arch/x86/kvm/lapic.c ++++ b/arch/x86/kvm/lapic.c +@@ -1478,6 +1478,26 @@ static bool lapic_timer_int_injected(str + return false; + } + ++static inline void __wait_lapic_expire(struct kvm_vcpu *vcpu, u64 guest_cycles) ++{ ++ u64 timer_advance_ns = vcpu->arch.apic->lapic_timer.timer_advance_ns; ++ ++ /* ++ * If the guest TSC is running at a different ratio than the host, then ++ * convert the delay to nanoseconds to achieve an accurate delay. Note ++ * that __delay() uses delay_tsc whenever the hardware has TSC, thus ++ * always for VMX enabled hardware. ++ */ ++ if (vcpu->arch.tsc_scaling_ratio == kvm_default_tsc_scaling_ratio) { ++ __delay(min(guest_cycles, ++ nsec_to_cycles(vcpu, timer_advance_ns))); ++ } else { ++ u64 delay_ns = guest_cycles * 1000000ULL; ++ do_div(delay_ns, vcpu->arch.virtual_tsc_khz); ++ ndelay(min_t(u32, delay_ns, timer_advance_ns)); ++ } ++} ++ + void wait_lapic_expire(struct kvm_vcpu *vcpu) + { + struct kvm_lapic *apic = vcpu->arch.apic; +@@ -1498,10 +1518,8 @@ void wait_lapic_expire(struct kvm_vcpu * + guest_tsc = kvm_read_l1_tsc(vcpu, rdtsc()); + trace_kvm_wait_lapic_expire(vcpu->vcpu_id, guest_tsc - tsc_deadline); + +- /* __delay is delay_tsc whenever the hardware has TSC, thus always. */ + if (guest_tsc < tsc_deadline) +- __delay(min(tsc_deadline - guest_tsc, +- nsec_to_cycles(vcpu, timer_advance_ns))); ++ __wait_lapic_expire(vcpu, tsc_deadline - guest_tsc); + + if (!apic->lapic_timer.timer_advance_adjust_done) { + /* too early */ diff --git a/queue-5.0/kvm-lapic-disable-timer-advancement-if-adaptive-tuning-goes-haywire.patch b/queue-5.0/kvm-lapic-disable-timer-advancement-if-adaptive-tuning-goes-haywire.patch new file mode 100644 index 00000000000..52b49629ddb --- /dev/null +++ b/queue-5.0/kvm-lapic-disable-timer-advancement-if-adaptive-tuning-goes-haywire.patch @@ -0,0 +1,68 @@ +From 57bf67e73ce9bcce2258890f5abf2adf5f619f1a Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Wed, 17 Apr 2019 10:15:31 -0700 +Subject: KVM: lapic: Disable timer advancement if adaptive tuning goes haywire + +From: Sean Christopherson + +commit 57bf67e73ce9bcce2258890f5abf2adf5f619f1a upstream. + +To minimize the latency of timer interrupts as observed by the guest, +KVM adjusts the values it programs into the host timers to account for +the host's overhead of programming and handling the timer event. Now +that the timer advancement is automatically tuned during runtime, it's +effectively unbounded by default, e.g. if KVM is running as L1 the +advancement can measure in hundreds of milliseconds. + +Disable timer advancement if adaptive tuning yields an advancement of +more than 5000ns, as large advancements can break reasonable assumptions +of the guest, e.g. that a timer configured to fire after 1ms won't +arrive on the next instruction. Although KVM busy waits to mitigate the +case of a timer event arriving too early, complications can arise when +shifting the interrupt too far, e.g. kvm-unit-test's vmx.interrupt test +will fail when its "host" exits on interrupts as KVM may inject the INTR +before the guest executes STI+HLT. Arguably the unit test is "broken" +in the sense that delaying a timer interrupt by 1ms doesn't technically +guarantee the interrupt will arrive after STI+HLT, but it's a reasonable +assumption that KVM should support. + +Furthermore, an unbounded advancement also effectively unbounds the time +spent busy waiting, e.g. if the guest programs a timer with a very large +delay. + +5000ns is a somewhat arbitrary threshold. When running on bare metal, +which is the intended use case, timer advancement is expected to be in +the general vicinity of 1000ns. 5000ns is high enough that false +positives are unlikely, while not being so high as to negatively affect +the host's performance/stability. + +Note, a future patch will enable userspace to disable KVM's adaptive +tuning, which will allow priveleged userspace will to specifying an +advancement value in excess of this arbitrary threshold in order to +satisfy an abnormal use case. + +Cc: Liran Alon +Cc: Wanpeng Li +Cc: stable@vger.kernel.org +Fixes: 3b8a5df6c4dc6 ("KVM: LAPIC: Tune lapic_timer_advance_ns automatically") +Signed-off-by: Sean Christopherson +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kvm/lapic.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/arch/x86/kvm/lapic.c ++++ b/arch/x86/kvm/lapic.c +@@ -1519,6 +1519,10 @@ void wait_lapic_expire(struct kvm_vcpu * + } + if (abs(guest_tsc - tsc_deadline) < LAPIC_TIMER_ADVANCE_ADJUST_DONE) + lapic_timer_advance_adjust_done = true; ++ if (unlikely(lapic_timer_advance_ns > 5000)) { ++ lapic_timer_advance_ns = 0; ++ lapic_timer_advance_adjust_done = true; ++ } + } + } + diff --git a/queue-5.0/kvm-lapic-track-lapic-timer-advance-per-vcpu.patch b/queue-5.0/kvm-lapic-track-lapic-timer-advance-per-vcpu.patch new file mode 100644 index 00000000000..ecddfb6d1da --- /dev/null +++ b/queue-5.0/kvm-lapic-track-lapic-timer-advance-per-vcpu.patch @@ -0,0 +1,227 @@ +From 39497d7660d9866a47a2dc9055672358da57ad3d Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Wed, 17 Apr 2019 10:15:32 -0700 +Subject: KVM: lapic: Track lapic timer advance per vCPU + +From: Sean Christopherson + +commit 39497d7660d9866a47a2dc9055672358da57ad3d upstream. + +Automatically adjusting the globally-shared timer advancement could +corrupt the timer, e.g. if multiple vCPUs are concurrently adjusting +the advancement value. That could be partially fixed by using a local +variable for the arithmetic, but it would still be susceptible to a +race when setting timer_advance_adjust_done. + +And because virtual_tsc_khz and tsc_scaling_ratio are per-vCPU, the +correct calibration for a given vCPU may not apply to all vCPUs. + +Furthermore, lapic_timer_advance_ns is marked __read_mostly, which is +effectively violated when finding a stable advancement takes an extended +amount of timer. + +Opportunistically change the definition of lapic_timer_advance_ns to +a u32 so that it matches the style of struct kvm_timer. Explicitly +pass the param to kvm_create_lapic() so that it doesn't have to be +exposed to lapic.c, thus reducing the probability of unintentionally +using the global value instead of the per-vCPU value. + +Cc: Liran Alon +Cc: Wanpeng Li +Reviewed-by: Liran Alon +Cc: stable@vger.kernel.org +Fixes: 3b8a5df6c4dc6 ("KVM: LAPIC: Tune lapic_timer_advance_ns automatically") +Signed-off-by: Sean Christopherson +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kvm/lapic.c | 36 +++++++++++++++++++----------------- + arch/x86/kvm/lapic.h | 4 +++- + arch/x86/kvm/vmx/vmx.c | 4 +++- + arch/x86/kvm/x86.c | 7 +++---- + arch/x86/kvm/x86.h | 2 -- + 5 files changed, 28 insertions(+), 25 deletions(-) + +--- a/arch/x86/kvm/lapic.c ++++ b/arch/x86/kvm/lapic.c +@@ -70,7 +70,6 @@ + #define APIC_BROADCAST 0xFF + #define X2APIC_BROADCAST 0xFFFFFFFFul + +-static bool lapic_timer_advance_adjust_done = false; + #define LAPIC_TIMER_ADVANCE_ADJUST_DONE 100 + /* step-by-step approximation to mitigate fluctuation */ + #define LAPIC_TIMER_ADVANCE_ADJUST_STEP 8 +@@ -1482,6 +1481,7 @@ static bool lapic_timer_int_injected(str + void wait_lapic_expire(struct kvm_vcpu *vcpu) + { + struct kvm_lapic *apic = vcpu->arch.apic; ++ u32 timer_advance_ns = apic->lapic_timer.timer_advance_ns; + u64 guest_tsc, tsc_deadline, ns; + + if (!lapic_in_kernel(vcpu)) +@@ -1501,34 +1501,36 @@ void wait_lapic_expire(struct kvm_vcpu * + /* __delay is delay_tsc whenever the hardware has TSC, thus always. */ + if (guest_tsc < tsc_deadline) + __delay(min(tsc_deadline - guest_tsc, +- nsec_to_cycles(vcpu, lapic_timer_advance_ns))); ++ nsec_to_cycles(vcpu, timer_advance_ns))); + +- if (!lapic_timer_advance_adjust_done) { ++ if (!apic->lapic_timer.timer_advance_adjust_done) { + /* too early */ + if (guest_tsc < tsc_deadline) { + ns = (tsc_deadline - guest_tsc) * 1000000ULL; + do_div(ns, vcpu->arch.virtual_tsc_khz); +- lapic_timer_advance_ns -= min((unsigned int)ns, +- lapic_timer_advance_ns / LAPIC_TIMER_ADVANCE_ADJUST_STEP); ++ timer_advance_ns -= min((u32)ns, ++ timer_advance_ns / LAPIC_TIMER_ADVANCE_ADJUST_STEP); + } else { + /* too late */ + ns = (guest_tsc - tsc_deadline) * 1000000ULL; + do_div(ns, vcpu->arch.virtual_tsc_khz); +- lapic_timer_advance_ns += min((unsigned int)ns, +- lapic_timer_advance_ns / LAPIC_TIMER_ADVANCE_ADJUST_STEP); ++ timer_advance_ns += min((u32)ns, ++ timer_advance_ns / LAPIC_TIMER_ADVANCE_ADJUST_STEP); + } + if (abs(guest_tsc - tsc_deadline) < LAPIC_TIMER_ADVANCE_ADJUST_DONE) +- lapic_timer_advance_adjust_done = true; +- if (unlikely(lapic_timer_advance_ns > 5000)) { +- lapic_timer_advance_ns = 0; +- lapic_timer_advance_adjust_done = true; ++ apic->lapic_timer.timer_advance_adjust_done = true; ++ if (unlikely(timer_advance_ns > 5000)) { ++ timer_advance_ns = 0; ++ apic->lapic_timer.timer_advance_adjust_done = true; + } ++ apic->lapic_timer.timer_advance_ns = timer_advance_ns; + } + } + + static void start_sw_tscdeadline(struct kvm_lapic *apic) + { +- u64 guest_tsc, tscdeadline = apic->lapic_timer.tscdeadline; ++ struct kvm_timer *ktimer = &apic->lapic_timer; ++ u64 guest_tsc, tscdeadline = ktimer->tscdeadline; + u64 ns = 0; + ktime_t expire; + struct kvm_vcpu *vcpu = apic->vcpu; +@@ -1548,11 +1550,10 @@ static void start_sw_tscdeadline(struct + do_div(ns, this_tsc_khz); + + if (likely(tscdeadline > guest_tsc) && +- likely(ns > lapic_timer_advance_ns)) { ++ likely(ns > apic->lapic_timer.timer_advance_ns)) { + expire = ktime_add_ns(now, ns); +- expire = ktime_sub_ns(expire, lapic_timer_advance_ns); +- hrtimer_start(&apic->lapic_timer.timer, +- expire, HRTIMER_MODE_ABS_PINNED); ++ expire = ktime_sub_ns(expire, ktimer->timer_advance_ns); ++ hrtimer_start(&ktimer->timer, expire, HRTIMER_MODE_ABS_PINNED); + } else + apic_timer_expired(apic); + +@@ -2259,7 +2260,7 @@ static enum hrtimer_restart apic_timer_f + return HRTIMER_NORESTART; + } + +-int kvm_create_lapic(struct kvm_vcpu *vcpu) ++int kvm_create_lapic(struct kvm_vcpu *vcpu, u32 timer_advance_ns) + { + struct kvm_lapic *apic; + +@@ -2283,6 +2284,7 @@ int kvm_create_lapic(struct kvm_vcpu *vc + hrtimer_init(&apic->lapic_timer.timer, CLOCK_MONOTONIC, + HRTIMER_MODE_ABS_PINNED); + apic->lapic_timer.timer.function = apic_timer_fn; ++ apic->lapic_timer.timer_advance_ns = timer_advance_ns; + + /* + * APIC is created enabled. This will prevent kvm_lapic_set_base from +--- a/arch/x86/kvm/lapic.h ++++ b/arch/x86/kvm/lapic.h +@@ -31,8 +31,10 @@ struct kvm_timer { + u32 timer_mode_mask; + u64 tscdeadline; + u64 expired_tscdeadline; ++ u32 timer_advance_ns; + atomic_t pending; /* accumulated triggered timers */ + bool hv_timer_in_use; ++ bool timer_advance_adjust_done; + }; + + struct kvm_lapic { +@@ -62,7 +64,7 @@ struct kvm_lapic { + + struct dest_map; + +-int kvm_create_lapic(struct kvm_vcpu *vcpu); ++int kvm_create_lapic(struct kvm_vcpu *vcpu, u32 timer_advance_ns); + void kvm_free_lapic(struct kvm_vcpu *vcpu); + + int kvm_apic_has_interrupt(struct kvm_vcpu *vcpu); +--- a/arch/x86/kvm/vmx/vmx.c ++++ b/arch/x86/kvm/vmx/vmx.c +@@ -7133,6 +7133,7 @@ static int vmx_set_hv_timer(struct kvm_v + { + struct vcpu_vmx *vmx; + u64 tscl, guest_tscl, delta_tsc, lapic_timer_advance_cycles; ++ struct kvm_timer *ktimer = &vcpu->arch.apic->lapic_timer; + + if (kvm_mwait_in_guest(vcpu->kvm)) + return -EOPNOTSUPP; +@@ -7141,7 +7142,8 @@ static int vmx_set_hv_timer(struct kvm_v + tscl = rdtsc(); + guest_tscl = kvm_read_l1_tsc(vcpu, tscl); + delta_tsc = max(guest_deadline_tsc, guest_tscl) - guest_tscl; +- lapic_timer_advance_cycles = nsec_to_cycles(vcpu, lapic_timer_advance_ns); ++ lapic_timer_advance_cycles = nsec_to_cycles(vcpu, ++ ktimer->timer_advance_ns); + + if (delta_tsc > lapic_timer_advance_cycles) + delta_tsc -= lapic_timer_advance_cycles; +--- a/arch/x86/kvm/x86.c ++++ b/arch/x86/kvm/x86.c +@@ -137,9 +137,8 @@ static u32 __read_mostly tsc_tolerance_p + module_param(tsc_tolerance_ppm, uint, S_IRUGO | S_IWUSR); + + /* lapic timer advance (tscdeadline mode only) in nanoseconds */ +-unsigned int __read_mostly lapic_timer_advance_ns = 1000; ++static u32 __read_mostly lapic_timer_advance_ns = 1000; + module_param(lapic_timer_advance_ns, uint, S_IRUGO | S_IWUSR); +-EXPORT_SYMBOL_GPL(lapic_timer_advance_ns); + + static bool __read_mostly vector_hashing = true; + module_param(vector_hashing, bool, S_IRUGO); +@@ -7882,7 +7881,7 @@ static int vcpu_enter_guest(struct kvm_v + } + + trace_kvm_entry(vcpu->vcpu_id); +- if (lapic_timer_advance_ns) ++ if (vcpu->arch.apic->lapic_timer.timer_advance_ns) + wait_lapic_expire(vcpu); + guest_enter_irqoff(); + +@@ -9070,7 +9069,7 @@ int kvm_arch_vcpu_init(struct kvm_vcpu * + goto fail_free_pio_data; + + if (irqchip_in_kernel(vcpu->kvm)) { +- r = kvm_create_lapic(vcpu); ++ r = kvm_create_lapic(vcpu, lapic_timer_advance_ns); + if (r < 0) + goto fail_mmu_destroy; + } else +--- a/arch/x86/kvm/x86.h ++++ b/arch/x86/kvm/x86.h +@@ -294,8 +294,6 @@ extern u64 kvm_supported_xcr0(void); + + extern unsigned int min_timer_period_us; + +-extern unsigned int lapic_timer_advance_ns; +- + extern bool enable_vmware_backdoor; + + extern struct static_key kvm_no_apic_vcpu; diff --git a/queue-5.0/kvm-x86-consider-lapic-tsc-deadline-timer-expired-if-deadline-too-short.patch b/queue-5.0/kvm-x86-consider-lapic-tsc-deadline-timer-expired-if-deadline-too-short.patch new file mode 100644 index 00000000000..320eb5c375a --- /dev/null +++ b/queue-5.0/kvm-x86-consider-lapic-tsc-deadline-timer-expired-if-deadline-too-short.patch @@ -0,0 +1,52 @@ +From c09d65d9eab69985c75f98ed64541229f6fa9aa6 Mon Sep 17 00:00:00 2001 +From: Liran Alon +Date: Tue, 16 Apr 2019 20:36:34 +0300 +Subject: KVM: x86: Consider LAPIC TSC-Deadline timer expired if deadline too short + +From: Liran Alon + +commit c09d65d9eab69985c75f98ed64541229f6fa9aa6 upstream. + +If guest sets MSR_IA32_TSCDEADLINE to value such that in host +time-domain it's shorter than lapic_timer_advance_ns, we can +reach a case that we call hrtimer_start() with expiration time set at +the past. + +Because lapic_timer.timer is init with HRTIMER_MODE_ABS_PINNED, it +is not allowed to run in softirq and therefore will never expire. + +To avoid such a scenario, verify that deadline expiration time is set on +host time-domain further than (now + lapic_timer_advance_ns). + +A future patch can also consider adding a min_timer_deadline_ns module parameter, +similar to min_timer_period_us to avoid races that amount of ns it takes +to run logic could still call hrtimer_start() with expiration timer set +at the past. + +Reviewed-by: Joao Martins +Signed-off-by: Liran Alon +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kvm/lapic.c | 9 ++++++--- + 1 file changed, 6 insertions(+), 3 deletions(-) + +--- a/arch/x86/kvm/lapic.c ++++ b/arch/x86/kvm/lapic.c +@@ -1543,9 +1543,12 @@ static void start_sw_tscdeadline(struct + + now = ktime_get(); + guest_tsc = kvm_read_l1_tsc(vcpu, rdtsc()); +- if (likely(tscdeadline > guest_tsc)) { +- ns = (tscdeadline - guest_tsc) * 1000000ULL; +- do_div(ns, this_tsc_khz); ++ ++ ns = (tscdeadline - guest_tsc) * 1000000ULL; ++ do_div(ns, this_tsc_khz); ++ ++ if (likely(tscdeadline > guest_tsc) && ++ likely(ns > lapic_timer_advance_ns)) { + expire = ktime_add_ns(now, ns); + expire = ktime_sub_ns(expire, lapic_timer_advance_ns); + hrtimer_start(&apic->lapic_timer.timer, diff --git a/queue-5.0/mac80211-don-t-attempt-to-rename-err_ptr-debugfs-dirs.patch b/queue-5.0/mac80211-don-t-attempt-to-rename-err_ptr-debugfs-dirs.patch new file mode 100644 index 00000000000..fc1b088f2fb --- /dev/null +++ b/queue-5.0/mac80211-don-t-attempt-to-rename-err_ptr-debugfs-dirs.patch @@ -0,0 +1,37 @@ +From 517879147493a5e1df6b89a50f708f1133fcaddb Mon Sep 17 00:00:00 2001 +From: Johannes Berg +Date: Mon, 15 Apr 2019 11:39:33 +0200 +Subject: mac80211: don't attempt to rename ERR_PTR() debugfs dirs + +From: Johannes Berg + +commit 517879147493a5e1df6b89a50f708f1133fcaddb upstream. + +We need to dereference the directory to get its parent to +be able to rename it, so it's clearly not safe to try to +do this with ERR_PTR() pointers. Skip in this case. + +It seems that this is most likely what was causing the +report by syzbot, but I'm not entirely sure as it didn't +come with a reproducer this time. + +Cc: stable@vger.kernel.org +Reported-by: syzbot+4ece1a28b8f4730547c9@syzkaller.appspotmail.com +Signed-off-by: Johannes Berg +Signed-off-by: Greg Kroah-Hartman + +--- + net/mac80211/debugfs_netdev.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/net/mac80211/debugfs_netdev.c ++++ b/net/mac80211/debugfs_netdev.c +@@ -841,7 +841,7 @@ void ieee80211_debugfs_rename_netdev(str + + dir = sdata->vif.debugfs_dir; + +- if (!dir) ++ if (IS_ERR_OR_NULL(dir)) + return; + + sprintf(buf, "netdev:%s", sdata->name); diff --git a/queue-5.0/mtd-rawnand-marvell-clean-the-controller-state-before-each-operation.patch b/queue-5.0/mtd-rawnand-marvell-clean-the-controller-state-before-each-operation.patch new file mode 100644 index 00000000000..53c9f5f4d21 --- /dev/null +++ b/queue-5.0/mtd-rawnand-marvell-clean-the-controller-state-before-each-operation.patch @@ -0,0 +1,56 @@ +From 9a8f612ca0d6a436e6471c9bed516d34a2cc626f Mon Sep 17 00:00:00 2001 +From: Miquel Raynal +Date: Mon, 8 Apr 2019 10:31:45 +0200 +Subject: mtd: rawnand: marvell: Clean the controller state before each operation + +From: Miquel Raynal + +commit 9a8f612ca0d6a436e6471c9bed516d34a2cc626f upstream. + +Since the migration of the driver to stop using the legacy +->select_chip() hook, there is nothing deselecting the target anymore, +thus the selection is not forced at the next access. Ensure the ND_RUN +bit and the interrupts are always in a clean state. + +Cc: Daniel Mack +Cc: stable@vger.kernel.org +Fixes: b25251414f6e00 ("mtd: rawnand: marvell: Stop implementing ->select_chip()") +Suggested-by: Boris Brezillon +Signed-off-by: Miquel Raynal +Tested-by: Daniel Mack +Reviewed-by: Boris Brezillon +Signed-off-by: Richard Weinberger +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/mtd/nand/raw/marvell_nand.c | 12 ++++++------ + 1 file changed, 6 insertions(+), 6 deletions(-) + +--- a/drivers/mtd/nand/raw/marvell_nand.c ++++ b/drivers/mtd/nand/raw/marvell_nand.c +@@ -722,12 +722,6 @@ static void marvell_nfc_select_target(st + struct marvell_nfc *nfc = to_marvell_nfc(chip->controller); + u32 ndcr_generic; + +- if (chip == nfc->selected_chip && die_nr == marvell_nand->selected_die) +- return; +- +- writel_relaxed(marvell_nand->ndtr0, nfc->regs + NDTR0); +- writel_relaxed(marvell_nand->ndtr1, nfc->regs + NDTR1); +- + /* + * Reset the NDCR register to a clean state for this particular chip, + * also clear ND_RUN bit. +@@ -739,6 +733,12 @@ static void marvell_nfc_select_target(st + /* Also reset the interrupt status register */ + marvell_nfc_clear_int(nfc, NDCR_ALL_INT); + ++ if (chip == nfc->selected_chip && die_nr == marvell_nand->selected_die) ++ return; ++ ++ writel_relaxed(marvell_nand->ndtr0, nfc->regs + NDTR0); ++ writel_relaxed(marvell_nand->ndtr1, nfc->regs + NDTR1); ++ + nfc->selected_chip = chip; + marvell_nand->selected_die = die_nr; + } diff --git a/queue-5.0/mwifiex-make-resume-actually-do-something-useful-again-on-sdio-cards.patch b/queue-5.0/mwifiex-make-resume-actually-do-something-useful-again-on-sdio-cards.patch new file mode 100644 index 00000000000..7cb9c2cbb7d --- /dev/null +++ b/queue-5.0/mwifiex-make-resume-actually-do-something-useful-again-on-sdio-cards.patch @@ -0,0 +1,46 @@ +From b82d6c1f8f8288f744a9dcc16cd3085d535decca Mon Sep 17 00:00:00 2001 +From: Douglas Anderson +Date: Wed, 3 Apr 2019 21:01:06 -0700 +Subject: mwifiex: Make resume actually do something useful again on SDIO cards + +From: Douglas Anderson + +commit b82d6c1f8f8288f744a9dcc16cd3085d535decca upstream. + +The commit fc3a2fcaa1ba ("mwifiex: use atomic bitops to represent +adapter status variables") had a fairly straightforward bug in it. It +contained this bit of diff: + + - if (!adapter->is_suspended) { + + if (test_bit(MWIFIEX_IS_SUSPENDED, &adapter->work_flags)) { + +As you can see the patch missed the "!" when converting to the atomic +bitops. This meant that the resume hasn't done anything at all since +that commit landed and suspend/resume for mwifiex SDIO cards has been +totally broken. + +After fixing this mwifiex suspend/resume appears to work again, at +least with the simple testing I've done. + +Fixes: fc3a2fcaa1ba ("mwifiex: use atomic bitops to represent adapter status variables") +Cc: +Signed-off-by: Douglas Anderson +Reviewed-by: Brian Norris +Signed-off-by: Kalle Valo +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/wireless/marvell/mwifiex/sdio.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/net/wireless/marvell/mwifiex/sdio.c ++++ b/drivers/net/wireless/marvell/mwifiex/sdio.c +@@ -181,7 +181,7 @@ static int mwifiex_sdio_resume(struct de + + adapter = card->adapter; + +- if (test_bit(MWIFIEX_IS_SUSPENDED, &adapter->work_flags)) { ++ if (!test_bit(MWIFIEX_IS_SUSPENDED, &adapter->work_flags)) { + mwifiex_dbg(adapter, WARN, + "device already resumed\n"); + return 0; diff --git a/queue-5.0/series b/queue-5.0/series index a9e6687265f..70cd8e07066 100644 --- a/queue-5.0/series +++ b/queue-5.0/series @@ -1,3 +1,24 @@ selftests-seccomp-prepare-for-exclusive-seccomp-flags.patch seccomp-make-new_listener-and-tsync-flags-exclusive.patch arc-memset-fix-build-with-l1_cache_shift-6.patch +iwlwifi-fix-driver-operation-for-5350.patch +mwifiex-make-resume-actually-do-something-useful-again-on-sdio-cards.patch +mtd-rawnand-marvell-clean-the-controller-state-before-each-operation.patch +mac80211-don-t-attempt-to-rename-err_ptr-debugfs-dirs.patch +i2c-synquacer-fix-enumeration-of-slave-devices.patch +i2c-imx-correct-the-method-of-getting-private-data-in-notifier_call.patch +i2c-prevent-runtime-suspend-of-adapter-when-host-notify-is-required.patch +alsa-hda-realtek-add-new-dell-platform-for-headset-mode.patch +alsa-hda-realtek-fixed-dell-aio-speaker-noise.patch +alsa-hda-realtek-apply-the-fixup-for-asus-q325uar.patch +usb-yurex-fix-protection-fault-after-device-removal.patch +usb-w1-ds2490-fix-bug-caused-by-improper-use-of-altsetting-array.patch +usb-dummy-hcd-fix-failure-to-give-back-unlinked-urbs.patch +usb-usbip-fix-isoc-packet-num-validation-in-get_pipe.patch +usb-core-fix-unterminated-string-returned-by-usb_string.patch +usb-core-fix-bug-caused-by-duplicate-interface-pm-usage-counter.patch +kvm-lapic-disable-timer-advancement-if-adaptive-tuning-goes-haywire.patch +kvm-x86-consider-lapic-tsc-deadline-timer-expired-if-deadline-too-short.patch +kvm-lapic-track-lapic-timer-advance-per-vcpu.patch +kvm-lapic-allow-user-to-disable-adaptive-tuning-of-timer-advancement.patch +kvm-lapic-convert-guest-tsc-to-host-time-domain-if-necessary.patch diff --git a/queue-5.0/usb-core-fix-bug-caused-by-duplicate-interface-pm-usage-counter.patch b/queue-5.0/usb-core-fix-bug-caused-by-duplicate-interface-pm-usage-counter.patch new file mode 100644 index 00000000000..e25188955c4 --- /dev/null +++ b/queue-5.0/usb-core-fix-bug-caused-by-duplicate-interface-pm-usage-counter.patch @@ -0,0 +1,211 @@ +From c2b71462d294cf517a0bc6e4fd6424d7cee5596f Mon Sep 17 00:00:00 2001 +From: Alan Stern +Date: Fri, 19 Apr 2019 13:52:38 -0400 +Subject: USB: core: Fix bug caused by duplicate interface PM usage counter + +From: Alan Stern + +commit c2b71462d294cf517a0bc6e4fd6424d7cee5596f upstream. + +The syzkaller fuzzer reported a bug in the USB hub driver which turned +out to be caused by a negative runtime-PM usage counter. This allowed +a hub to be runtime suspended at a time when the driver did not expect +it. The symptom is a WARNING issued because the hub's status URB is +submitted while it is already active: + + URB 0000000031fb463e submitted while active + WARNING: CPU: 0 PID: 2917 at drivers/usb/core/urb.c:363 + +The negative runtime-PM usage count was caused by an unfortunate +design decision made when runtime PM was first implemented for USB. +At that time, USB class drivers were allowed to unbind from their +interfaces without balancing the usage counter (i.e., leaving it with +a positive count). The core code would take care of setting the +counter back to 0 before allowing another driver to bind to the +interface. + +Later on when runtime PM was implemented for the entire kernel, the +opposite decision was made: Drivers were required to balance their +runtime-PM get and put calls. In order to maintain backward +compatibility, however, the USB subsystem adapted to the new +implementation by keeping an independent usage counter for each +interface and using it to automatically adjust the normal usage +counter back to 0 whenever a driver was unbound. + +This approach involves duplicating information, but what is worse, it +doesn't work properly in cases where a USB class driver delays +decrementing the usage counter until after the driver's disconnect() +routine has returned and the counter has been adjusted back to 0. +Doing so would cause the usage counter to become negative. There's +even a warning about this in the USB power management documentation! + +As it happens, this is exactly what the hub driver does. The +kick_hub_wq() routine increments the runtime-PM usage counter, and the +corresponding decrement is carried out by hub_event() in the context +of the hub_wq work-queue thread. This work routine may sometimes run +after the driver has been unbound from its interface, and when it does +it causes the usage counter to go negative. + +It is not possible for hub_disconnect() to wait for a pending +hub_event() call to finish, because hub_disconnect() is called with +the device lock held and hub_event() acquires that lock. The only +feasible fix is to reverse the original design decision: remove the +duplicate interface-specific usage counter and require USB drivers to +balance their runtime PM gets and puts. As far as I know, all +existing drivers currently do this. + +Signed-off-by: Alan Stern +Reported-and-tested-by: syzbot+7634edaea4d0b341c625@syzkaller.appspotmail.com +CC: +Signed-off-by: Greg Kroah-Hartman + +--- + Documentation/driver-api/usb/power-management.rst | 14 +++++++++----- + drivers/usb/core/driver.c | 13 ------------- + drivers/usb/storage/realtek_cr.c | 13 +++++-------- + include/linux/usb.h | 2 -- + 4 files changed, 14 insertions(+), 28 deletions(-) + +--- a/Documentation/driver-api/usb/power-management.rst ++++ b/Documentation/driver-api/usb/power-management.rst +@@ -370,11 +370,15 @@ autosuspend the interface's device. Whe + then the interface is considered to be idle, and the kernel may + autosuspend the device. + +-Drivers need not be concerned about balancing changes to the usage +-counter; the USB core will undo any remaining "get"s when a driver +-is unbound from its interface. As a corollary, drivers must not call +-any of the ``usb_autopm_*`` functions after their ``disconnect`` +-routine has returned. ++Drivers must be careful to balance their overall changes to the usage ++counter. Unbalanced "get"s will remain in effect when a driver is ++unbound from its interface, preventing the device from going into ++runtime suspend should the interface be bound to a driver again. On ++the other hand, drivers are allowed to achieve this balance by calling ++the ``usb_autopm_*`` functions even after their ``disconnect`` routine ++has returned -- say from within a work-queue routine -- provided they ++retain an active reference to the interface (via ``usb_get_intf`` and ++``usb_put_intf``). + + Drivers using the async routines are responsible for their own + synchronization and mutual exclusion. +--- a/drivers/usb/core/driver.c ++++ b/drivers/usb/core/driver.c +@@ -473,11 +473,6 @@ static int usb_unbind_interface(struct d + pm_runtime_disable(dev); + pm_runtime_set_suspended(dev); + +- /* Undo any residual pm_autopm_get_interface_* calls */ +- for (r = atomic_read(&intf->pm_usage_cnt); r > 0; --r) +- usb_autopm_put_interface_no_suspend(intf); +- atomic_set(&intf->pm_usage_cnt, 0); +- + if (!error) + usb_autosuspend_device(udev); + +@@ -1633,7 +1628,6 @@ void usb_autopm_put_interface(struct usb + int status; + + usb_mark_last_busy(udev); +- atomic_dec(&intf->pm_usage_cnt); + status = pm_runtime_put_sync(&intf->dev); + dev_vdbg(&intf->dev, "%s: cnt %d -> %d\n", + __func__, atomic_read(&intf->dev.power.usage_count), +@@ -1662,7 +1656,6 @@ void usb_autopm_put_interface_async(stru + int status; + + usb_mark_last_busy(udev); +- atomic_dec(&intf->pm_usage_cnt); + status = pm_runtime_put(&intf->dev); + dev_vdbg(&intf->dev, "%s: cnt %d -> %d\n", + __func__, atomic_read(&intf->dev.power.usage_count), +@@ -1684,7 +1677,6 @@ void usb_autopm_put_interface_no_suspend + struct usb_device *udev = interface_to_usbdev(intf); + + usb_mark_last_busy(udev); +- atomic_dec(&intf->pm_usage_cnt); + pm_runtime_put_noidle(&intf->dev); + } + EXPORT_SYMBOL_GPL(usb_autopm_put_interface_no_suspend); +@@ -1715,8 +1707,6 @@ int usb_autopm_get_interface(struct usb_ + status = pm_runtime_get_sync(&intf->dev); + if (status < 0) + pm_runtime_put_sync(&intf->dev); +- else +- atomic_inc(&intf->pm_usage_cnt); + dev_vdbg(&intf->dev, "%s: cnt %d -> %d\n", + __func__, atomic_read(&intf->dev.power.usage_count), + status); +@@ -1750,8 +1740,6 @@ int usb_autopm_get_interface_async(struc + status = pm_runtime_get(&intf->dev); + if (status < 0 && status != -EINPROGRESS) + pm_runtime_put_noidle(&intf->dev); +- else +- atomic_inc(&intf->pm_usage_cnt); + dev_vdbg(&intf->dev, "%s: cnt %d -> %d\n", + __func__, atomic_read(&intf->dev.power.usage_count), + status); +@@ -1775,7 +1763,6 @@ void usb_autopm_get_interface_no_resume( + struct usb_device *udev = interface_to_usbdev(intf); + + usb_mark_last_busy(udev); +- atomic_inc(&intf->pm_usage_cnt); + pm_runtime_get_noresume(&intf->dev); + } + EXPORT_SYMBOL_GPL(usb_autopm_get_interface_no_resume); +--- a/drivers/usb/storage/realtek_cr.c ++++ b/drivers/usb/storage/realtek_cr.c +@@ -763,18 +763,16 @@ static void rts51x_suspend_timer_fn(stru + break; + case RTS51X_STAT_IDLE: + case RTS51X_STAT_SS: +- usb_stor_dbg(us, "RTS51X_STAT_SS, intf->pm_usage_cnt:%d, power.usage:%d\n", +- atomic_read(&us->pusb_intf->pm_usage_cnt), ++ usb_stor_dbg(us, "RTS51X_STAT_SS, power.usage:%d\n", + atomic_read(&us->pusb_intf->dev.power.usage_count)); + +- if (atomic_read(&us->pusb_intf->pm_usage_cnt) > 0) { ++ if (atomic_read(&us->pusb_intf->dev.power.usage_count) > 0) { + usb_stor_dbg(us, "Ready to enter SS state\n"); + rts51x_set_stat(chip, RTS51X_STAT_SS); + /* ignore mass storage interface's children */ + pm_suspend_ignore_children(&us->pusb_intf->dev, true); + usb_autopm_put_interface_async(us->pusb_intf); +- usb_stor_dbg(us, "RTS51X_STAT_SS 01, intf->pm_usage_cnt:%d, power.usage:%d\n", +- atomic_read(&us->pusb_intf->pm_usage_cnt), ++ usb_stor_dbg(us, "RTS51X_STAT_SS 01, power.usage:%d\n", + atomic_read(&us->pusb_intf->dev.power.usage_count)); + } + break; +@@ -807,11 +805,10 @@ static void rts51x_invoke_transport(stru + int ret; + + if (working_scsi(srb)) { +- usb_stor_dbg(us, "working scsi, intf->pm_usage_cnt:%d, power.usage:%d\n", +- atomic_read(&us->pusb_intf->pm_usage_cnt), ++ usb_stor_dbg(us, "working scsi, power.usage:%d\n", + atomic_read(&us->pusb_intf->dev.power.usage_count)); + +- if (atomic_read(&us->pusb_intf->pm_usage_cnt) <= 0) { ++ if (atomic_read(&us->pusb_intf->dev.power.usage_count) <= 0) { + ret = usb_autopm_get_interface(us->pusb_intf); + usb_stor_dbg(us, "working scsi, ret=%d\n", ret); + } +--- a/include/linux/usb.h ++++ b/include/linux/usb.h +@@ -200,7 +200,6 @@ usb_find_last_int_out_endpoint(struct us + * @dev: driver model's view of this device + * @usb_dev: if an interface is bound to the USB major, this will point + * to the sysfs representation for that device. +- * @pm_usage_cnt: PM usage counter for this interface + * @reset_ws: Used for scheduling resets from atomic context. + * @resetting_device: USB core reset the device, so use alt setting 0 as + * current; needs bandwidth alloc after reset. +@@ -257,7 +256,6 @@ struct usb_interface { + + struct device dev; /* interface specific device info */ + struct device *usb_dev; +- atomic_t pm_usage_cnt; /* usage counter for autosuspend */ + struct work_struct reset_ws; /* for resets in atomic context */ + }; + #define to_usb_interface(d) container_of(d, struct usb_interface, dev) diff --git a/queue-5.0/usb-core-fix-unterminated-string-returned-by-usb_string.patch b/queue-5.0/usb-core-fix-unterminated-string-returned-by-usb_string.patch new file mode 100644 index 00000000000..4f5a5865070 --- /dev/null +++ b/queue-5.0/usb-core-fix-unterminated-string-returned-by-usb_string.patch @@ -0,0 +1,49 @@ +From c01c348ecdc66085e44912c97368809612231520 Mon Sep 17 00:00:00 2001 +From: Alan Stern +Date: Mon, 15 Apr 2019 11:51:38 -0400 +Subject: USB: core: Fix unterminated string returned by usb_string() + +From: Alan Stern + +commit c01c348ecdc66085e44912c97368809612231520 upstream. + +Some drivers (such as the vub300 MMC driver) expect usb_string() to +return a properly NUL-terminated string, even when an error occurs. +(In fact, vub300's probe routine doesn't bother to check the return +code from usb_string().) When the driver goes on to use an +unterminated string, it leads to kernel errors such as +stack-out-of-bounds, as found by the syzkaller USB fuzzer. + +An out-of-range string index argument is not at all unlikely, given +that some devices don't provide string descriptors and therefore list +0 as the value for their string indexes. This patch makes +usb_string() return a properly terminated empty string along with the +-EINVAL error code when an out-of-range index is encountered. + +And since a USB string index is a single-byte value, indexes >= 256 +are just as invalid as values of 0 or below. + +Signed-off-by: Alan Stern +Reported-by: syzbot+b75b85111c10b8d680f1@syzkaller.appspotmail.com +CC: +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/core/message.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/drivers/usb/core/message.c ++++ b/drivers/usb/core/message.c +@@ -820,9 +820,11 @@ int usb_string(struct usb_device *dev, i + + if (dev->state == USB_STATE_SUSPENDED) + return -EHOSTUNREACH; +- if (size <= 0 || !buf || !index) ++ if (size <= 0 || !buf) + return -EINVAL; + buf[0] = 0; ++ if (index <= 0 || index >= 256) ++ return -EINVAL; + tbuf = kmalloc(256, GFP_NOIO); + if (!tbuf) + return -ENOMEM; diff --git a/queue-5.0/usb-dummy-hcd-fix-failure-to-give-back-unlinked-urbs.patch b/queue-5.0/usb-dummy-hcd-fix-failure-to-give-back-unlinked-urbs.patch new file mode 100644 index 00000000000..551c66f4948 --- /dev/null +++ b/queue-5.0/usb-dummy-hcd-fix-failure-to-give-back-unlinked-urbs.patch @@ -0,0 +1,84 @@ +From fc834e607ae3d18e1a20bca3f9a2d7f52ea7a2be Mon Sep 17 00:00:00 2001 +From: Alan Stern +Date: Thu, 18 Apr 2019 13:12:07 -0400 +Subject: USB: dummy-hcd: Fix failure to give back unlinked URBs + +From: Alan Stern + +commit fc834e607ae3d18e1a20bca3f9a2d7f52ea7a2be upstream. + +The syzkaller USB fuzzer identified a failure mode in which dummy-hcd +would never give back an unlinked URB. This causes usb_kill_urb() to +hang, leading to WARNINGs and unkillable threads. + +In dummy-hcd, all URBs are given back by the dummy_timer() routine as +it scans through the list of pending URBS. Failure to give back URBs +can be caused by failure to start or early exit from the scanning +loop. The code currently has two such pathways: One is triggered when +an unsupported bus transfer speed is encountered, and the other by +exhausting the simulated bandwidth for USB transfers during a frame. + +This patch removes those two paths, thereby allowing all unlinked URBs +to be given back in a timely manner. It adds a check for the bus +speed when the gadget first starts running, so that dummy_timer() will +never thereafter encounter an unsupported speed. And it prevents the +loop from exiting as soon as the total bandwidth has been used up (the +scanning loop continues, giving back unlinked URBs as they are found, +but not transferring any more data). + +Thanks to Andrey Konovalov for manually running the syzkaller fuzzer +to help track down the source of the bug. + +Signed-off-by: Alan Stern +Reported-and-tested-by: syzbot+d919b0f29d7b5a4994b9@syzkaller.appspotmail.com +CC: +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/gadget/udc/dummy_hcd.c | 19 +++++++++++++++---- + 1 file changed, 15 insertions(+), 4 deletions(-) + +--- a/drivers/usb/gadget/udc/dummy_hcd.c ++++ b/drivers/usb/gadget/udc/dummy_hcd.c +@@ -979,8 +979,18 @@ static int dummy_udc_start(struct usb_ga + struct dummy_hcd *dum_hcd = gadget_to_dummy_hcd(g); + struct dummy *dum = dum_hcd->dum; + +- if (driver->max_speed == USB_SPEED_UNKNOWN) ++ switch (g->speed) { ++ /* All the speeds we support */ ++ case USB_SPEED_LOW: ++ case USB_SPEED_FULL: ++ case USB_SPEED_HIGH: ++ case USB_SPEED_SUPER: ++ break; ++ default: ++ dev_err(dummy_dev(dum_hcd), "Unsupported driver max speed %d\n", ++ driver->max_speed); + return -EINVAL; ++ } + + /* + * SLAVE side init ... the layer above hardware, which +@@ -1784,9 +1794,10 @@ static void dummy_timer(struct timer_lis + /* Bus speed is 500000 bytes/ms, so use a little less */ + total = 490000; + break; +- default: ++ default: /* Can't happen */ + dev_err(dummy_dev(dum_hcd), "bogus device speed\n"); +- return; ++ total = 0; ++ break; + } + + /* FIXME if HZ != 1000 this will probably misbehave ... */ +@@ -1828,7 +1839,7 @@ restart: + + /* Used up this frame's bandwidth? */ + if (total <= 0) +- break; ++ continue; + + /* find the gadget's ep for this request (if configured) */ + address = usb_pipeendpoint (urb->pipe); diff --git a/queue-5.0/usb-usbip-fix-isoc-packet-num-validation-in-get_pipe.patch b/queue-5.0/usb-usbip-fix-isoc-packet-num-validation-in-get_pipe.patch new file mode 100644 index 00000000000..5b08c9977f2 --- /dev/null +++ b/queue-5.0/usb-usbip-fix-isoc-packet-num-validation-in-get_pipe.patch @@ -0,0 +1,77 @@ +From c409ca3be3c6ff3a1eeb303b191184e80d412862 Mon Sep 17 00:00:00 2001 +From: Malte Leip +Date: Sun, 14 Apr 2019 12:00:12 +0200 +Subject: usb: usbip: fix isoc packet num validation in get_pipe + +From: Malte Leip + +commit c409ca3be3c6ff3a1eeb303b191184e80d412862 upstream. + +Change the validation of number_of_packets in get_pipe to compare the +number of packets to a fixed maximum number of packets allowed, set to +be 1024. This number was chosen due to it being used by other drivers as +well, for example drivers/usb/host/uhci-q.c + +Background/reason: +The get_pipe function in stub_rx.c validates the number of packets in +isochronous mode and aborts with an error if that number is too large, +in order to prevent malicious input from possibly triggering large +memory allocations. This was previously done by checking whether +pdu->u.cmd_submit.number_of_packets is bigger than the number of packets +that would be needed for pdu->u.cmd_submit.transfer_buffer_length bytes +if all except possibly the last packet had maximum length, given by +usb_endpoint_maxp(epd) * usb_endpoint_maxp_mult(epd). This leads to an +error if URBs with packets shorter than the maximum possible length are +submitted, which is allowed according to +Documentation/driver-api/usb/URB.rst and occurs for example with the +snd-usb-audio driver. + +Fixes: c6688ef9f297 ("usbip: fix stub_rx: harden CMD_SUBMIT path to handle malicious input") +Signed-off-by: Malte Leip +Cc: stable +Acked-by: Shuah Khan +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/usbip/stub_rx.c | 12 +++--------- + drivers/usb/usbip/usbip_common.h | 7 +++++++ + 2 files changed, 10 insertions(+), 9 deletions(-) + +--- a/drivers/usb/usbip/stub_rx.c ++++ b/drivers/usb/usbip/stub_rx.c +@@ -361,16 +361,10 @@ static int get_pipe(struct stub_device * + } + + if (usb_endpoint_xfer_isoc(epd)) { +- /* validate packet size and number of packets */ +- unsigned int maxp, packets, bytes; +- +- maxp = usb_endpoint_maxp(epd); +- maxp *= usb_endpoint_maxp_mult(epd); +- bytes = pdu->u.cmd_submit.transfer_buffer_length; +- packets = DIV_ROUND_UP(bytes, maxp); +- ++ /* validate number of packets */ + if (pdu->u.cmd_submit.number_of_packets < 0 || +- pdu->u.cmd_submit.number_of_packets > packets) { ++ pdu->u.cmd_submit.number_of_packets > ++ USBIP_MAX_ISO_PACKETS) { + dev_err(&sdev->udev->dev, + "CMD_SUBMIT: isoc invalid num packets %d\n", + pdu->u.cmd_submit.number_of_packets); +--- a/drivers/usb/usbip/usbip_common.h ++++ b/drivers/usb/usbip/usbip_common.h +@@ -121,6 +121,13 @@ extern struct device_attribute dev_attr_ + #define USBIP_DIR_OUT 0x00 + #define USBIP_DIR_IN 0x01 + ++/* ++ * Arbitrary limit for the maximum number of isochronous packets in an URB, ++ * compare for example the uhci_submit_isochronous function in ++ * drivers/usb/host/uhci-q.c ++ */ ++#define USBIP_MAX_ISO_PACKETS 1024 ++ + /** + * struct usbip_header_basic - data pertinent to every request + * @command: the usbip request type diff --git a/queue-5.0/usb-w1-ds2490-fix-bug-caused-by-improper-use-of-altsetting-array.patch b/queue-5.0/usb-w1-ds2490-fix-bug-caused-by-improper-use-of-altsetting-array.patch new file mode 100644 index 00000000000..889f7fe10a3 --- /dev/null +++ b/queue-5.0/usb-w1-ds2490-fix-bug-caused-by-improper-use-of-altsetting-array.patch @@ -0,0 +1,50 @@ +From c114944d7d67f24e71562fcfc18d550ab787e4d4 Mon Sep 17 00:00:00 2001 +From: Alan Stern +Date: Mon, 22 Apr 2019 11:16:04 -0400 +Subject: USB: w1 ds2490: Fix bug caused by improper use of altsetting array + +From: Alan Stern + +commit c114944d7d67f24e71562fcfc18d550ab787e4d4 upstream. + +The syzkaller USB fuzzer spotted a slab-out-of-bounds bug in the +ds2490 driver. This bug is caused by improper use of the altsetting +array in the usb_interface structure (the array's entries are not +always stored in numerical order), combined with a naive assumption +that all interfaces probed by the driver will have the expected number +of altsettings. + +The bug can be fixed by replacing references to the possibly +non-existent intf->altsetting[alt] entry with the guaranteed-to-exist +intf->cur_altsetting entry. + +Signed-off-by: Alan Stern +Reported-and-tested-by: syzbot+d65f673b847a1a96cdba@syzkaller.appspotmail.com +CC: +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/w1/masters/ds2490.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/drivers/w1/masters/ds2490.c ++++ b/drivers/w1/masters/ds2490.c +@@ -1016,15 +1016,15 @@ static int ds_probe(struct usb_interface + /* alternative 3, 1ms interrupt (greatly speeds search), 64 byte bulk */ + alt = 3; + err = usb_set_interface(dev->udev, +- intf->altsetting[alt].desc.bInterfaceNumber, alt); ++ intf->cur_altsetting->desc.bInterfaceNumber, alt); + if (err) { + dev_err(&dev->udev->dev, "Failed to set alternative setting %d " + "for %d interface: err=%d.\n", alt, +- intf->altsetting[alt].desc.bInterfaceNumber, err); ++ intf->cur_altsetting->desc.bInterfaceNumber, err); + goto err_out_clear; + } + +- iface_desc = &intf->altsetting[alt]; ++ iface_desc = intf->cur_altsetting; + if (iface_desc->desc.bNumEndpoints != NUM_EP-1) { + pr_info("Num endpoints=%d. It is not DS9490R.\n", + iface_desc->desc.bNumEndpoints); diff --git a/queue-5.0/usb-yurex-fix-protection-fault-after-device-removal.patch b/queue-5.0/usb-yurex-fix-protection-fault-after-device-removal.patch new file mode 100644 index 00000000000..c486a9608a1 --- /dev/null +++ b/queue-5.0/usb-yurex-fix-protection-fault-after-device-removal.patch @@ -0,0 +1,40 @@ +From ef61eb43ada6c1d6b94668f0f514e4c268093ff3 Mon Sep 17 00:00:00 2001 +From: Alan Stern +Date: Tue, 23 Apr 2019 14:48:29 -0400 +Subject: USB: yurex: Fix protection fault after device removal + +From: Alan Stern + +commit ef61eb43ada6c1d6b94668f0f514e4c268093ff3 upstream. + +The syzkaller USB fuzzer found a general-protection-fault bug in the +yurex driver. The fault occurs when a device has been unplugged; the +driver's interrupt-URB handler logs an error message referring to the +device by name, after the device has been unregistered and its name +deallocated. + +This problem is caused by the fact that the interrupt URB isn't +cancelled until the driver's private data structure is released, which +can happen long after the device is gone. The cure is to make sure +that the interrupt URB is killed before yurex_disconnect() returns; +this is exactly the sort of thing that usb_poison_urb() was meant for. + +Signed-off-by: Alan Stern +Reported-and-tested-by: syzbot+2eb9121678bdb36e6d57@syzkaller.appspotmail.com +CC: +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/misc/yurex.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/usb/misc/yurex.c ++++ b/drivers/usb/misc/yurex.c +@@ -314,6 +314,7 @@ static void yurex_disconnect(struct usb_ + usb_deregister_dev(interface, &yurex_class); + + /* prevent more I/O from starting */ ++ usb_poison_urb(dev->urb); + mutex_lock(&dev->io_mutex); + dev->interface = NULL; + mutex_unlock(&dev->io_mutex);