--- /dev/null
+From 0a29c57b76624723b6b00c027e0e992d130ace49 Mon Sep 17 00:00:00 2001
+From: Kailang Yang <kailang@realtek.com>
+Date: Wed, 24 Apr 2019 16:34:25 +0800
+Subject: ALSA: hda/realtek - Add new Dell platform for headset mode
+
+From: Kailang Yang <kailang@realtek.com>
+
+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 <kailang@realtek.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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}),
--- /dev/null
+From 3887c26c0e24d50a4d0ce20cf4726737cee1a2fd Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Tue, 30 Apr 2019 15:10:01 +0200
+Subject: ALSA: hda/realtek - Apply the fixup for ASUS Q325UAR
+
+From: Takashi Iwai <tiwai@suse.de>
+
+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: <stable@vger.kernel.org>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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}),
--- /dev/null
+From 0700d3d117a7f110ddddbd83873e13652f69c54b Mon Sep 17 00:00:00 2001
+From: Kailang Yang <kailang@realtek.com>
+Date: Fri, 26 Apr 2019 16:13:54 +0800
+Subject: ALSA: hda/realtek - Fixed Dell AIO speaker noise
+
+From: Kailang Yang <kailang@realtek.com>
+
+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 <kailang@realtek.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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 */
--- /dev/null
+From d386bb9042f4629bf62cdc5952ea8aab225f24a7 Mon Sep 17 00:00:00 2001
+From: Anson Huang <anson.huang@nxp.com>
+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 <anson.huang@nxp.com>
+
+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 <Anson.Huang@nxp.com>
+Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
+Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
+Cc: stable@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
--- /dev/null
+From 72bfcee11cf89509795c56b0e40a3785ab00bbdd Mon Sep 17 00:00:00 2001
+From: Jarkko Nikula <jarkko.nikula@linux.intel.com>
+Date: Tue, 30 Apr 2019 17:23:22 +0300
+Subject: i2c: Prevent runtime suspend of adapter when Host Notify is required
+
+From: Jarkko Nikula <jarkko.nikula@linux.intel.com>
+
+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 <ferdasyn@rocketmail.com>
+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 <jarkko.nikula@linux.intel.com>
+Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Tested-by: Keijo Vaara <ferdasyn@rocketmail.com>
+Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+ }
--- /dev/null
+From 95e0cf3caeb11e1b0398c747b5cfa12828263824 Mon Sep 17 00:00:00 2001
+From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
+Date: Tue, 30 Apr 2019 11:47:34 +0200
+Subject: i2c: synquacer: fix enumeration of slave devices
+
+From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
+
+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: <stable@vger.kernel.org> # v4.19+
+Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
+Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
+
--- /dev/null
+From 5c9adef9789148d382d7d1307c3d6bfaf51d143d Mon Sep 17 00:00:00 2001
+From: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
+Date: Sun, 21 Apr 2019 17:58:11 +0300
+Subject: iwlwifi: fix driver operation for 5350
+
+From: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
+
+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 <emmanuel.grumbach@intel.com>
+Fixes: c8f1b51e506d ("iwlwifi: allow different csr flags for different device families")
+Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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 \
--- /dev/null
+From c3941d9e0ccd48920e4811f133235b3597e5310b Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <sean.j.christopherson@intel.com>
+Date: Wed, 17 Apr 2019 10:15:33 -0700
+Subject: KVM: lapic: Allow user to disable adaptive tuning of timer advancement
+
+From: Sean Christopherson <sean.j.christopherson@intel.com>
+
+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 <liran.alon@oracle.com>
+Cc: Wanpeng Li <wanpengli@tencent.com>
+Reviewed-by: Liran Alon <liran.alon@oracle.com>
+Cc: stable@vger.kernel.org
+Fixes: 3b8a5df6c4dc6 ("KVM: LAPIC: Tune lapic_timer_advance_ns automatically")
+Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
--- /dev/null
+From b6aa57c69cb26ea0160c51f7cf45f1af23542686 Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <sean.j.christopherson@intel.com>
+Date: Wed, 17 Apr 2019 10:15:34 -0700
+Subject: KVM: lapic: Convert guest TSC to host time domain if necessary
+
+From: Sean Christopherson <sean.j.christopherson@intel.com>
+
+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 <liran.alon@oracle.com>
+Cc: Wanpeng Li <wanpengli@tencent.com>
+Cc: stable@vger.kernel.org
+Fixes: 3b8a5df6c4dc6 ("KVM: LAPIC: Tune lapic_timer_advance_ns automatically")
+Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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 */
--- /dev/null
+From 57bf67e73ce9bcce2258890f5abf2adf5f619f1a Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <sean.j.christopherson@intel.com>
+Date: Wed, 17 Apr 2019 10:15:31 -0700
+Subject: KVM: lapic: Disable timer advancement if adaptive tuning goes haywire
+
+From: Sean Christopherson <sean.j.christopherson@intel.com>
+
+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 <liran.alon@oracle.com>
+Cc: Wanpeng Li <wanpengli@tencent.com>
+Cc: stable@vger.kernel.org
+Fixes: 3b8a5df6c4dc6 ("KVM: LAPIC: Tune lapic_timer_advance_ns automatically")
+Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
++ }
+ }
+ }
+
--- /dev/null
+From 39497d7660d9866a47a2dc9055672358da57ad3d Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <sean.j.christopherson@intel.com>
+Date: Wed, 17 Apr 2019 10:15:32 -0700
+Subject: KVM: lapic: Track lapic timer advance per vCPU
+
+From: Sean Christopherson <sean.j.christopherson@intel.com>
+
+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 <liran.alon@oracle.com>
+Cc: Wanpeng Li <wanpengli@tencent.com>
+Reviewed-by: Liran Alon <liran.alon@oracle.com>
+Cc: stable@vger.kernel.org
+Fixes: 3b8a5df6c4dc6 ("KVM: LAPIC: Tune lapic_timer_advance_ns automatically")
+Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
--- /dev/null
+From c09d65d9eab69985c75f98ed64541229f6fa9aa6 Mon Sep 17 00:00:00 2001
+From: Liran Alon <liran.alon@oracle.com>
+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 <liran.alon@oracle.com>
+
+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 <joao.m.martins@oracle.com>
+Signed-off-by: Liran Alon <liran.alon@oracle.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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,
--- /dev/null
+From 517879147493a5e1df6b89a50f708f1133fcaddb Mon Sep 17 00:00:00 2001
+From: Johannes Berg <johannes.berg@intel.com>
+Date: Mon, 15 Apr 2019 11:39:33 +0200
+Subject: mac80211: don't attempt to rename ERR_PTR() debugfs dirs
+
+From: Johannes Berg <johannes.berg@intel.com>
+
+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 <johannes.berg@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
--- /dev/null
+From 9a8f612ca0d6a436e6471c9bed516d34a2cc626f Mon Sep 17 00:00:00 2001
+From: Miquel Raynal <miquel.raynal@bootlin.com>
+Date: Mon, 8 Apr 2019 10:31:45 +0200
+Subject: mtd: rawnand: marvell: Clean the controller state before each operation
+
+From: Miquel Raynal <miquel.raynal@bootlin.com>
+
+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 <daniel@zonque.org>
+Cc: stable@vger.kernel.org
+Fixes: b25251414f6e00 ("mtd: rawnand: marvell: Stop implementing ->select_chip()")
+Suggested-by: Boris Brezillon <boris.brezillon@collabora.com>
+Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
+Tested-by: Daniel Mack <daniel@zonque.org>
+Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
+Signed-off-by: Richard Weinberger <richard@nod.at>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+ }
--- /dev/null
+From b82d6c1f8f8288f744a9dcc16cd3085d535decca Mon Sep 17 00:00:00 2001
+From: Douglas Anderson <dianders@chromium.org>
+Date: Wed, 3 Apr 2019 21:01:06 -0700
+Subject: mwifiex: Make resume actually do something useful again on SDIO cards
+
+From: Douglas Anderson <dianders@chromium.org>
+
+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: <stable@vger.kernel.org>
+Signed-off-by: Douglas Anderson <dianders@chromium.org>
+Reviewed-by: Brian Norris <briannorris@chromium.org>
+Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
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
--- /dev/null
+From c2b71462d294cf517a0bc6e4fd6424d7cee5596f Mon Sep 17 00:00:00 2001
+From: Alan Stern <stern@rowland.harvard.edu>
+Date: Fri, 19 Apr 2019 13:52:38 -0400
+Subject: USB: core: Fix bug caused by duplicate interface PM usage counter
+
+From: Alan Stern <stern@rowland.harvard.edu>
+
+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 <stern@rowland.harvard.edu>
+Reported-and-tested-by: syzbot+7634edaea4d0b341c625@syzkaller.appspotmail.com
+CC: <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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)
--- /dev/null
+From c01c348ecdc66085e44912c97368809612231520 Mon Sep 17 00:00:00 2001
+From: Alan Stern <stern@rowland.harvard.edu>
+Date: Mon, 15 Apr 2019 11:51:38 -0400
+Subject: USB: core: Fix unterminated string returned by usb_string()
+
+From: Alan Stern <stern@rowland.harvard.edu>
+
+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 <stern@rowland.harvard.edu>
+Reported-by: syzbot+b75b85111c10b8d680f1@syzkaller.appspotmail.com
+CC: <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
--- /dev/null
+From fc834e607ae3d18e1a20bca3f9a2d7f52ea7a2be Mon Sep 17 00:00:00 2001
+From: Alan Stern <stern@rowland.harvard.edu>
+Date: Thu, 18 Apr 2019 13:12:07 -0400
+Subject: USB: dummy-hcd: Fix failure to give back unlinked URBs
+
+From: Alan Stern <stern@rowland.harvard.edu>
+
+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 <stern@rowland.harvard.edu>
+Reported-and-tested-by: syzbot+d919b0f29d7b5a4994b9@syzkaller.appspotmail.com
+CC: <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
--- /dev/null
+From c409ca3be3c6ff3a1eeb303b191184e80d412862 Mon Sep 17 00:00:00 2001
+From: Malte Leip <malte@leip.net>
+Date: Sun, 14 Apr 2019 12:00:12 +0200
+Subject: usb: usbip: fix isoc packet num validation in get_pipe
+
+From: Malte Leip <malte@leip.net>
+
+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 <malte@leip.net>
+Cc: stable <stable@vger.kernel.org>
+Acked-by: Shuah Khan <skhan@linuxfoundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
--- /dev/null
+From c114944d7d67f24e71562fcfc18d550ab787e4d4 Mon Sep 17 00:00:00 2001
+From: Alan Stern <stern@rowland.harvard.edu>
+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 <stern@rowland.harvard.edu>
+
+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 <stern@rowland.harvard.edu>
+Reported-and-tested-by: syzbot+d65f673b847a1a96cdba@syzkaller.appspotmail.com
+CC: <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
--- /dev/null
+From ef61eb43ada6c1d6b94668f0f514e4c268093ff3 Mon Sep 17 00:00:00 2001
+From: Alan Stern <stern@rowland.harvard.edu>
+Date: Tue, 23 Apr 2019 14:48:29 -0400
+Subject: USB: yurex: Fix protection fault after device removal
+
+From: Alan Stern <stern@rowland.harvard.edu>
+
+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 <stern@rowland.harvard.edu>
+Reported-and-tested-by: syzbot+2eb9121678bdb36e6d57@syzkaller.appspotmail.com
+CC: <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
projects / thirdparty / kernel / stable-queue.git / commitdiff
