From: Greg Kroah-Hartman Date: Wed, 12 May 2021 08:56:43 +0000 (+0200) Subject: 4.9-stable patches X-Git-Tag: v5.4.119~88 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=9c8f361c69893e8ec47db5ac1309859b1dfb9839;p=thirdparty%2Fkernel%2Fstable-queue.git 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 index 00000000000..3853982c341 --- /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" +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 + +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 [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 +Fixes: 4d0438e56a8f ("defxx: Clean up DEFEA resource management") +Cc: stable@vger.kernel.org # v3.19+ +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + 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 index 00000000000..006b7fbb332 --- /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 +Date: Wed, 17 Feb 2021 11:24:59 +0100 +Subject: misc: lis3lv02d: Fix false-positive WARN on various HP models + +From: Hans de Goede + +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 +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 +Signed-off-by: Greg Kroah-Hartman +--- + 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 index 00000000000..de582e2c675 --- /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 +Date: Fri, 2 Apr 2021 21:17:42 +0900 +Subject: misc: vmw_vmci: explicitly initialize vmci_datagram payload + +From: Tetsuo Handa + +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: +Signed-off-by: Tetsuo Handa +Link: https://lore.kernel.org/r/20210402121742.3917-2-penguin-kernel@I-love.SAKURA.ne.jp +Signed-off-by: Greg Kroah-Hartman +--- + 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 index 00000000000..436f061c64b --- /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 +Date: Fri, 2 Apr 2021 21:17:41 +0900 +Subject: misc: vmw_vmci: explicitly initialize vmci_notify_bm_set_msg struct + +From: Tetsuo Handa + +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: +Signed-off-by: Tetsuo Handa +Link: https://lore.kernel.org/r/20210402121742.3917-1-penguin-kernel@I-love.SAKURA.ne.jp +Signed-off-by: Greg Kroah-Hartman +--- + 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 32abf2491c2..c6f1a5180d8 100644 --- 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