4.9-stable patches

added patches:
	fddi-defxx-bail-out-gracefully-with-unassigned-pci-resource-for-csr.patch
	misc-lis3lv02d-fix-false-positive-warn-on-various-hp-models.patch
	misc-vmw_vmci-explicitly-initialize-vmci_datagram-payload.patch
	misc-vmw_vmci-explicitly-initialize-vmci_notify_bm_set_msg-struct.patch

diff --git a/queue-4.9/fddi-defxx-bail-out-gracefully-with-unassigned-pci-resource-for-csr.patch b/queue-4.9/fddi-defxx-bail-out-gracefully-with-unassigned-pci-resource-for-csr.patch
new file mode 100644 (file)
index 0000000..3853982
--- /dev/null
+++ b/queue-4.9/fddi-defxx-bail-out-gracefully-with-unassigned-pci-resource-for-csr.patch
@@ -0,0 +1,193 @@
+From f626ca682912fab55dff15469ce893ae16b65c7e Mon Sep 17 00:00:00 2001
+From: "Maciej W. Rozycki" <macro@orcam.me.uk>
+Date: Wed, 10 Mar 2021 13:03:09 +0100
+Subject: FDDI: defxx: Bail out gracefully with unassigned PCI resource for CSR
+
+From: Maciej W. Rozycki <macro@orcam.me.uk>
+
+commit f626ca682912fab55dff15469ce893ae16b65c7e upstream.
+
+Recent versions of the PCI Express specification have deprecated support
+for I/O transactions and actually some PCIe host bridges, such as Power
+Systems Host Bridge 4 (PHB4), do not implement them.
+
+For those systems the PCI BARs that request a mapping in the I/O space
+have the length recorded in the corresponding PCI resource set to zero,
+which makes it unassigned:
+
+# lspci -s 0031:02:04.0 -v
+0031:02:04.0 FDDI network controller: Digital Equipment Corporation PCI-to-PDQ Interface Chip [PFI] FDDI (DEFPA) (rev 02)
+       Subsystem: Digital Equipment Corporation FDDIcontroller/PCI (DEFPA)
+       Flags: bus master, medium devsel, latency 136, IRQ 57, NUMA node 8
+       Memory at 620c080020000 (32-bit, non-prefetchable) [size=128]
+       I/O ports at <unassigned> [disabled]
+       Memory at 620c080030000 (32-bit, non-prefetchable) [size=64K]
+       Capabilities: [50] Power Management version 2
+       Kernel driver in use: defxx
+       Kernel modules: defxx
+
+#
+
+Regardless the driver goes ahead and requests it (here observed with a
+Raptor Talos II POWER9 system), resulting in an odd /proc/ioport entry:
+
+# cat /proc/ioports
+00000000-ffffffffffffffff : 0031:02:04.0
+#
+
+Furthermore, the system gets confused as the driver actually continues
+and pokes at those locations, causing a flood of messages being output
+to the system console by the underlying system firmware, like:
+
+defxx: v1.11 2014/07/01  Lawrence V. Stefani and others
+defxx 0031:02:04.0: enabling device (0140 -> 0142)
+LPC[000]: Got SYNC no-response error. Error address reg: 0xd0010000
+IPMI: dropping non severe PEL event
+LPC[000]: Got SYNC no-response error. Error address reg: 0xd0010014
+IPMI: dropping non severe PEL event
+LPC[000]: Got SYNC no-response error. Error address reg: 0xd0010014
+IPMI: dropping non severe PEL event
+
+and so on and so on (possibly intermixed actually, as there's no locking
+between the kernel and the firmware in console port access with this
+particular system, but cleaned up above for clarity), and once some 10k
+of such pairs of the latter two messages have been produced an interace
+eventually shows up in a useless state:
+
+0031:02:04.0: DEFPA at I/O addr = 0x0, IRQ = 57, Hardware addr = 00-00-00-00-00-00
+
+This was not expected to happen as resource handling was added to the
+driver a while ago, because it was not known at that time that a PCI
+system would be possible that cannot assign port I/O resources, and
+oddly enough `request_region' does not fail, which would have caught it.
+
+Correct the problem then by checking for the length of zero for the CSR
+resource and bail out gracefully refusing to register an interface if
+that turns out to be the case, producing messages like:
+
+defxx: v1.11 2014/07/01  Lawrence V. Stefani and others
+0031:02:04.0: Cannot use I/O, no address set, aborting
+0031:02:04.0: Recompile driver with "CONFIG_DEFXX_MMIO=y"
+
+Keep the original check for the EISA MMIO resource as implemented,
+because in that case the length is hardwired to 0x400 as a consequence
+of how the compare/mask address decoding works in the ESIC chip and it
+is only the base address that is set to zero if MMIO has been disabled
+for the adapter in EISA configuration, which in turn could be a valid
+bus address in a legacy-free system implementing PCI, especially for
+port I/O.
+
+Where the EISA MMIO resource has been disabled for the adapter in EISA
+configuration this arrangement keeps producing messages like:
+
+eisa 00:05: EISA: slot 5: DEC3002 detected
+defxx: v1.11 2014/07/01  Lawrence V. Stefani and others
+00:05: Cannot use MMIO, no address set, aborting
+00:05: Recompile driver with "CONFIG_DEFXX_MMIO=n"
+00:05: Or run ECU and set adapter's MMIO location
+
+with the last two lines now swapped for easier handling in the driver.
+
+There is no need to check for and catch the case of a port I/O resource
+not having been assigned for EISA as the adapter uses the slot-specific
+I/O space, which gets assigned by how EISA has been specified and maps
+directly to the particular slot an option card has been placed in.  And
+the EISA variant of the adapter has additional registers that are only
+accessible via the port I/O space anyway.
+
+While at it factor out the error message calls into helpers and fix an
+argument order bug with the `pr_err' call now in `dfx_register_res_err'.
+
+Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
+Fixes: 4d0438e56a8f ("defxx: Clean up DEFEA resource management")
+Cc: stable@vger.kernel.org # v3.19+
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/fddi/defxx.c |   47 ++++++++++++++++++++++++++++++-----------------
+ 1 file changed, 30 insertions(+), 17 deletions(-)
+
+--- a/drivers/net/fddi/defxx.c
++++ b/drivers/net/fddi/defxx.c
+@@ -495,6 +495,25 @@ static const struct net_device_ops dfx_n
+       .ndo_set_mac_address    = dfx_ctl_set_mac_address,
+ };
+ 
++static void dfx_register_res_alloc_err(const char *print_name, bool mmio,
++                                     bool eisa)
++{
++      pr_err("%s: Cannot use %s, no address set, aborting\n",
++             print_name, mmio ? "MMIO" : "I/O");
++      pr_err("%s: Recompile driver with \"CONFIG_DEFXX_MMIO=%c\"\n",
++             print_name, mmio ? 'n' : 'y');
++      if (eisa && mmio)
++              pr_err("%s: Or run ECU and set adapter's MMIO location\n",
++                     print_name);
++}
++
++static void dfx_register_res_err(const char *print_name, bool mmio,
++                               unsigned long start, unsigned long len)
++{
++      pr_err("%s: Cannot reserve %s resource 0x%lx @ 0x%lx, aborting\n",
++             print_name, mmio ? "MMIO" : "I/O", len, start);
++}
++
+ /*
+  * ================
+  * = dfx_register =
+@@ -568,15 +587,12 @@ static int dfx_register(struct device *b
+       dev_set_drvdata(bdev, dev);
+ 
+       dfx_get_bars(bdev, bar_start, bar_len);
+-      if (dfx_bus_eisa && dfx_use_mmio && bar_start[0] == 0) {
+-              pr_err("%s: Cannot use MMIO, no address set, aborting\n",
+-                     print_name);
+-              pr_err("%s: Run ECU and set adapter's MMIO location\n",
+-                     print_name);
+-              pr_err("%s: Or recompile driver with \"CONFIG_DEFXX_MMIO=n\""
+-                     "\n", print_name);
++      if (bar_len[0] == 0 ||
++          (dfx_bus_eisa && dfx_use_mmio && bar_start[0] == 0)) {
++              dfx_register_res_alloc_err(print_name, dfx_use_mmio,
++                                         dfx_bus_eisa);
+               err = -ENXIO;
+-              goto err_out;
++              goto err_out_disable;
+       }
+ 
+       if (dfx_use_mmio)
+@@ -585,18 +601,16 @@ static int dfx_register(struct device *b
+       else
+               region = request_region(bar_start[0], bar_len[0], print_name);
+       if (!region) {
+-              pr_err("%s: Cannot reserve %s resource 0x%lx @ 0x%lx, "
+-                     "aborting\n", dfx_use_mmio ? "MMIO" : "I/O", print_name,
+-                     (long)bar_len[0], (long)bar_start[0]);
++              dfx_register_res_err(print_name, dfx_use_mmio,
++                                   bar_start[0], bar_len[0]);
+               err = -EBUSY;
+               goto err_out_disable;
+       }
+       if (bar_start[1] != 0) {
+               region = request_region(bar_start[1], bar_len[1], print_name);
+               if (!region) {
+-                      pr_err("%s: Cannot reserve I/O resource "
+-                             "0x%lx @ 0x%lx, aborting\n", print_name,
+-                             (long)bar_len[1], (long)bar_start[1]);
++                      dfx_register_res_err(print_name, 0,
++                                           bar_start[1], bar_len[1]);
+                       err = -EBUSY;
+                       goto err_out_csr_region;
+               }
+@@ -604,9 +618,8 @@ static int dfx_register(struct device *b
+       if (bar_start[2] != 0) {
+               region = request_region(bar_start[2], bar_len[2], print_name);
+               if (!region) {
+-                      pr_err("%s: Cannot reserve I/O resource "
+-                             "0x%lx @ 0x%lx, aborting\n", print_name,
+-                             (long)bar_len[2], (long)bar_start[2]);
++                      dfx_register_res_err(print_name, 0,
++                                           bar_start[2], bar_len[2]);
+                       err = -EBUSY;
+                       goto err_out_bh_region;
+               }

diff --git a/queue-4.9/misc-lis3lv02d-fix-false-positive-warn-on-various-hp-models.patch b/queue-4.9/misc-lis3lv02d-fix-false-positive-warn-on-various-hp-models.patch
new file mode 100644 (file)
index 0000000..006b7fb
--- /dev/null
+++ b/queue-4.9/misc-lis3lv02d-fix-false-positive-warn-on-various-hp-models.patch
@@ -0,0 +1,101 @@
+From 3641762c1c9c7cfd84a7061a0a73054f09b412e3 Mon Sep 17 00:00:00 2001
+From: Hans de Goede <hdegoede@redhat.com>
+Date: Wed, 17 Feb 2021 11:24:59 +0100
+Subject: misc: lis3lv02d: Fix false-positive WARN on various HP models
+
+From: Hans de Goede <hdegoede@redhat.com>
+
+commit 3641762c1c9c7cfd84a7061a0a73054f09b412e3 upstream.
+
+Before this commit lis3lv02d_get_pwron_wait() had a WARN_ONCE() to catch
+a potential divide by 0. WARN macros should only be used to catch internal
+kernel bugs and that is not the case here. We have been receiving a lot of
+bug reports about kernel backtraces caused by this WARN.
+
+The div value being checked comes from the lis3->odrs[] array. Which
+is sized to be a power-of-2 matching the number of bits in lis3->odr_mask.
+
+The only lis3 model where this array is not entirely filled with non zero
+values. IOW the only model where we can hit the div == 0 check is the
+3dc ("8 bits 3DC sensor") model:
+
+int lis3_3dc_rates[16] = {0, 1, 10, 25, 50, 100, 200, 400, 1600, 5000};
+
+Note the 0 value at index 0, according to the datasheet an odr index of 0
+means "Power-down mode". HP typically uses a lis3 accelerometer for HDD
+fall protection. What I believe is happening here is that on newer
+HP devices, which only contain a SDD, the BIOS is leaving the lis3 device
+powered-down since it is not used for HDD fall protection.
+
+Note that the lis3_3dc_rates array initializer only specifies 10 values,
+which matches the datasheet. So it also contains 6 zero values at the end.
+
+Replace the WARN with a normal check, which treats an odr index of 0
+as power-down and uses a normal dev_err() to report the error in case
+odr index point past the initialized part of the array.
+
+Fixes: 1510dd5954be ("lis3lv02d: avoid divide by zero due to unchecked")
+Cc: stable@vger.kernel.org
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=785814
+BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1817027
+BugLink: https://bugs.centos.org/view.php?id=10720
+Link: https://lore.kernel.org/r/20210217102501.31758-1-hdegoede@redhat.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/misc/lis3lv02d/lis3lv02d.c |   21 ++++++++++++++++-----
+ 1 file changed, 16 insertions(+), 5 deletions(-)
+
+--- a/drivers/misc/lis3lv02d/lis3lv02d.c
++++ b/drivers/misc/lis3lv02d/lis3lv02d.c
+@@ -220,7 +220,7 @@ static int lis3_3dc_rates[16] = {0, 1, 1
+ static int lis3_3dlh_rates[4] = {50, 100, 400, 1000};
+ 
+ /* ODR is Output Data Rate */
+-static int lis3lv02d_get_odr(struct lis3lv02d *lis3)
++static int lis3lv02d_get_odr_index(struct lis3lv02d *lis3)
+ {
+       u8 ctrl;
+       int shift;
+@@ -228,15 +228,23 @@ static int lis3lv02d_get_odr(struct lis3
+       lis3->read(lis3, CTRL_REG1, &ctrl);
+       ctrl &= lis3->odr_mask;
+       shift = ffs(lis3->odr_mask) - 1;
+-      return lis3->odrs[(ctrl >> shift)];
++      return (ctrl >> shift);
+ }
+ 
+ static int lis3lv02d_get_pwron_wait(struct lis3lv02d *lis3)
+ {
+-      int div = lis3lv02d_get_odr(lis3);
++      int odr_idx = lis3lv02d_get_odr_index(lis3);
++      int div = lis3->odrs[odr_idx];
+ 
+-      if (WARN_ONCE(div == 0, "device returned spurious data"))
++      if (div == 0) {
++              if (odr_idx == 0) {
++                      /* Power-down mode, not sampling no need to sleep */
++                      return 0;
++              }
++
++              dev_err(&lis3->pdev->dev, "Error unknown odrs-index: %d\n", odr_idx);
+               return -ENXIO;
++      }
+ 
+       /* LIS3 power on delay is quite long */
+       msleep(lis3->pwron_delay / div);
+@@ -819,9 +827,12 @@ static ssize_t lis3lv02d_rate_show(struc
+                       struct device_attribute *attr, char *buf)
+ {
+       struct lis3lv02d *lis3 = dev_get_drvdata(dev);
++      int odr_idx;
+ 
+       lis3lv02d_sysfs_poweron(lis3);
+-      return sprintf(buf, "%d\n", lis3lv02d_get_odr(lis3));
++
++      odr_idx = lis3lv02d_get_odr_index(lis3);
++      return sprintf(buf, "%d\n", lis3->odrs[odr_idx]);
+ }
+ 
+ static ssize_t lis3lv02d_rate_set(struct device *dev,

diff --git a/queue-4.9/misc-vmw_vmci-explicitly-initialize-vmci_datagram-payload.patch b/queue-4.9/misc-vmw_vmci-explicitly-initialize-vmci_datagram-payload.patch
new file mode 100644 (file)
index 0000000..de582e2
--- /dev/null
+++ b/queue-4.9/misc-vmw_vmci-explicitly-initialize-vmci_datagram-payload.patch
@@ -0,0 +1,92 @@
+From b2192cfeba8481224da0a4ec3b4a7ccd80b1623b Mon Sep 17 00:00:00 2001
+From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
+Date: Fri, 2 Apr 2021 21:17:42 +0900
+Subject: misc: vmw_vmci: explicitly initialize vmci_datagram payload
+
+From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
+
+commit b2192cfeba8481224da0a4ec3b4a7ccd80b1623b upstream.
+
+KMSAN complains that vmci_check_host_caps() left the payload part of
+check_msg uninitialized.
+
+  =====================================================
+  BUG: KMSAN: uninit-value in kmsan_check_memory+0xd/0x10
+  CPU: 1 PID: 1 Comm: swapper/0 Tainted: G    B             5.11.0-rc7+ #4
+  Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 02/27/2020
+  Call Trace:
+   dump_stack+0x21c/0x280
+   kmsan_report+0xfb/0x1e0
+   kmsan_internal_check_memory+0x202/0x520
+   kmsan_check_memory+0xd/0x10
+   iowrite8_rep+0x86/0x380
+   vmci_guest_probe_device+0xf0b/0x1e70
+   pci_device_probe+0xab3/0xe70
+   really_probe+0xd16/0x24d0
+   driver_probe_device+0x29d/0x3a0
+   device_driver_attach+0x25a/0x490
+   __driver_attach+0x78c/0x840
+   bus_for_each_dev+0x210/0x340
+   driver_attach+0x89/0xb0
+   bus_add_driver+0x677/0xc40
+   driver_register+0x485/0x8e0
+   __pci_register_driver+0x1ff/0x350
+   vmci_guest_init+0x3e/0x41
+   vmci_drv_init+0x1d6/0x43f
+   do_one_initcall+0x39c/0x9a0
+   do_initcall_level+0x1d7/0x259
+   do_initcalls+0x127/0x1cb
+   do_basic_setup+0x33/0x36
+   kernel_init_freeable+0x29a/0x3ed
+   kernel_init+0x1f/0x840
+   ret_from_fork+0x1f/0x30
+
+  Uninit was created at:
+   kmsan_internal_poison_shadow+0x5c/0xf0
+   kmsan_slab_alloc+0x8d/0xe0
+   kmem_cache_alloc+0x84f/0xe30
+   vmci_guest_probe_device+0xd11/0x1e70
+   pci_device_probe+0xab3/0xe70
+   really_probe+0xd16/0x24d0
+   driver_probe_device+0x29d/0x3a0
+   device_driver_attach+0x25a/0x490
+   __driver_attach+0x78c/0x840
+   bus_for_each_dev+0x210/0x340
+   driver_attach+0x89/0xb0
+   bus_add_driver+0x677/0xc40
+   driver_register+0x485/0x8e0
+   __pci_register_driver+0x1ff/0x350
+   vmci_guest_init+0x3e/0x41
+   vmci_drv_init+0x1d6/0x43f
+   do_one_initcall+0x39c/0x9a0
+   do_initcall_level+0x1d7/0x259
+   do_initcalls+0x127/0x1cb
+   do_basic_setup+0x33/0x36
+   kernel_init_freeable+0x29a/0x3ed
+   kernel_init+0x1f/0x840
+   ret_from_fork+0x1f/0x30
+
+  Bytes 28-31 of 36 are uninitialized
+  Memory access of size 36 starts at ffff8881675e5f00
+  =====================================================
+
+Fixes: 1f166439917b69d3 ("VMCI: guest side driver implementation.")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
+Link: https://lore.kernel.org/r/20210402121742.3917-2-penguin-kernel@I-love.SAKURA.ne.jp
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/misc/vmw_vmci/vmci_guest.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/misc/vmw_vmci/vmci_guest.c
++++ b/drivers/misc/vmw_vmci/vmci_guest.c
+@@ -172,7 +172,7 @@ static int vmci_check_host_caps(struct p
+                               VMCI_UTIL_NUM_RESOURCES * sizeof(u32);
+       struct vmci_datagram *check_msg;
+ 
+-      check_msg = kmalloc(msg_size, GFP_KERNEL);
++      check_msg = kzalloc(msg_size, GFP_KERNEL);
+       if (!check_msg) {
+               dev_err(&pdev->dev, "%s: Insufficient memory\n", __func__);
+               return -ENOMEM;

diff --git a/queue-4.9/misc-vmw_vmci-explicitly-initialize-vmci_notify_bm_set_msg-struct.patch b/queue-4.9/misc-vmw_vmci-explicitly-initialize-vmci_notify_bm_set_msg-struct.patch
new file mode 100644 (file)
index 0000000..436f061
--- /dev/null
+++ b/queue-4.9/misc-vmw_vmci-explicitly-initialize-vmci_notify_bm_set_msg-struct.patch
@@ -0,0 +1,74 @@
+From 376565b9717c30cd58ad33860fa42697615fa2e4 Mon Sep 17 00:00:00 2001
+From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
+Date: Fri, 2 Apr 2021 21:17:41 +0900
+Subject: misc: vmw_vmci: explicitly initialize vmci_notify_bm_set_msg struct
+
+From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
+
+commit 376565b9717c30cd58ad33860fa42697615fa2e4 upstream.
+
+KMSAN complains that the vmci_use_ppn64() == false path in
+vmci_dbell_register_notification_bitmap() left upper 32bits of
+bitmap_set_msg.bitmap_ppn64 member uninitialized.
+
+  =====================================================
+  BUG: KMSAN: uninit-value in kmsan_check_memory+0xd/0x10
+  CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.11.0-rc7+ #4
+  Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 02/27/2020
+  Call Trace:
+   dump_stack+0x21c/0x280
+   kmsan_report+0xfb/0x1e0
+   kmsan_internal_check_memory+0x484/0x520
+   kmsan_check_memory+0xd/0x10
+   iowrite8_rep+0x86/0x380
+   vmci_send_datagram+0x150/0x280
+   vmci_dbell_register_notification_bitmap+0x133/0x1e0
+   vmci_guest_probe_device+0xcab/0x1e70
+   pci_device_probe+0xab3/0xe70
+   really_probe+0xd16/0x24d0
+   driver_probe_device+0x29d/0x3a0
+   device_driver_attach+0x25a/0x490
+   __driver_attach+0x78c/0x840
+   bus_for_each_dev+0x210/0x340
+   driver_attach+0x89/0xb0
+   bus_add_driver+0x677/0xc40
+   driver_register+0x485/0x8e0
+   __pci_register_driver+0x1ff/0x350
+   vmci_guest_init+0x3e/0x41
+   vmci_drv_init+0x1d6/0x43f
+   do_one_initcall+0x39c/0x9a0
+   do_initcall_level+0x1d7/0x259
+   do_initcalls+0x127/0x1cb
+   do_basic_setup+0x33/0x36
+   kernel_init_freeable+0x29a/0x3ed
+   kernel_init+0x1f/0x840
+   ret_from_fork+0x1f/0x30
+
+  Local variable ----bitmap_set_msg@vmci_dbell_register_notification_bitmap created at:
+   vmci_dbell_register_notification_bitmap+0x50/0x1e0
+   vmci_dbell_register_notification_bitmap+0x50/0x1e0
+
+  Bytes 28-31 of 32 are uninitialized
+  Memory access of size 32 starts at ffff88810098f570
+  =====================================================
+
+Fixes: 83e2ec765be03e8a ("VMCI: doorbell implementation.")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
+Link: https://lore.kernel.org/r/20210402121742.3917-1-penguin-kernel@I-love.SAKURA.ne.jp
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/misc/vmw_vmci/vmci_doorbell.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/misc/vmw_vmci/vmci_doorbell.c
++++ b/drivers/misc/vmw_vmci/vmci_doorbell.c
+@@ -334,7 +334,7 @@ int vmci_dbell_host_context_notify(u32 s
+ bool vmci_dbell_register_notification_bitmap(u32 bitmap_ppn)
+ {
+       int result;
+-      struct vmci_notify_bm_set_msg bitmap_set_msg;
++      struct vmci_notify_bm_set_msg bitmap_set_msg = { };
+ 
+       bitmap_set_msg.hdr.dst = vmci_make_handle(VMCI_HYPERVISOR_CONTEXT_ID,
+                                                 VMCI_SET_NOTIFY_BITMAP);

diff --git a/queue-4.9/series b/queue-4.9/series
index 32abf2491c2a69b52221371c59e0bea9e0fb92a0..c6f1a5180d893e14ef555483484c92bf38e978cc 100644 (file)
--- a/queue-4.9/series
+++ b/queue-4.9/series
@@ -69,3 +69,7 @@ bluetooth-verify-amp-hci_chan-before-amp_destroy.patch
 hsr-use-netdev_err-instead-of-warn_once.patch
 bluetooth-eliminate-the-potential-race-condition-when-removing-the-hci-controller.patch
 net-nfc-fix-use-after-free-llcp_sock_bind-connect.patch
+fddi-defxx-bail-out-gracefully-with-unassigned-pci-resource-for-csr.patch
+misc-lis3lv02d-fix-false-positive-warn-on-various-hp-models.patch
+misc-vmw_vmci-explicitly-initialize-vmci_notify_bm_set_msg-struct.patch
+misc-vmw_vmci-explicitly-initialize-vmci_datagram-payload.patch