commit 030194a5b292bb7613407668d85af0b987bb9839 Author: Greg Kroah-Hartman Date: Thu Mar 11 14:05:02 2021 +0100 Linux 4.19.180 Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan Tested-by: Guenter Roeck Tested-by: Jason Self Tested-by: Hulk Robot Tested-by: Ross Schmidt Tested-by: Linux Kernel Functional Testing Tested-by: Jon Hunter Link: https://lore.kernel.org/r/20210310132319.708237392@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit c3fbfc3c08fae0e3442541b43c847a6a0d9d5f22 Author: Jisheng Zhang Date: Thu Dec 10 16:55:10 2020 +0800 mmc: sdhci-of-dwcmshc: set SDHCI_QUIRK2_PRESET_VALUE_BROKEN [ Upstream commit 5f7dfda4f2cec580c135fd81d96a05006651c128 ] The SDHCI_PRESET_FOR_* registers are not set(all read as zeros), so set the quirk. Signed-off-by: Jisheng Zhang Link: https://lore.kernel.org/r/20201210165510.76b917e5@xhacker.debian Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit a6ca03e459f8e93cf95cb38269582b399d70be92 Author: AngeloGioacchino Del Regno Date: Wed Jan 13 19:33:33 2021 +0100 drm/msm/a5xx: Remove overwriting A5XX_PC_DBG_ECO_CNTL register [ Upstream commit 8f03c30cb814213e36032084a01f49a9e604a3e3 ] The PC_DBG_ECO_CNTL register on the Adreno A5xx family gets programmed to some different values on a per-model basis. At least, this is what we intend to do here; Unfortunately, though, this register is being overwritten with a static magic number, right after applying the GPU-specific configuration (including the GPU-specific quirks) and that is effectively nullifying the efforts. Let's remove the redundant and wrong write to the PC_DBG_ECO_CNTL register in order to retain the wanted configuration for the target GPU. Signed-off-by: AngeloGioacchino Del Regno Reviewed-by: Jordan Crouse Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 3399db28b4957a3229c67d080225d5203f849b2b Author: Aswath Govindraju Date: Tue Jan 5 16:28:12 2021 +0530 misc: eeprom_93xx46: Add quirk to support Microchip 93LC46B eeprom [ Upstream commit f6f1f8e6e3eea25f539105d48166e91f0ab46dd1 ] A dummy zero bit is sent preceding the data during a read transfer by the Microchip 93LC46B eeprom (section 2.7 of[1]). This results in right shift of data during a read. In order to ignore this bit a quirk can be added to send an extra zero bit after the read address. Add a quirk to ignore the zero bit sent before data by adding a zero bit after the read address. [1] - https://www.mouser.com/datasheet/2/268/20001749K-277859.pdf Signed-off-by: Aswath Govindraju Link: https://lore.kernel.org/r/20210105105817.17644-3-a-govindraju@ti.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 545bb7b5639838d87a31ce4d5bef1a979ed16c83 Author: Bjorn Helgaas Date: Tue Nov 10 16:00:57 2020 -0600 PCI: Add function 1 DMA alias quirk for Marvell 9215 SATA controller [ Upstream commit 059983790a4c963d92943e55a61fca55be427d55 ] Add function 1 DMA alias quirk for Marvell 88SS9215 PCIe SSD Controller. Link: https://bugzilla.kernel.org/show_bug.cgi?id=42679#c135 Link: https://lore.kernel.org/r/20201110220516.697934-1-helgaas@kernel.org Reported-by: John Smith Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit 4de0881b989066a2842baef072125a00723d1c77 Author: Chris Chiu Date: Tue Dec 8 14:04:14 2020 +0800 ASoC: Intel: bytcr_rt5640: Add quirk for ARCHOS Cesium 140 [ Upstream commit 1bea2256aa96a2d7b1b576eb74e29d79edc9bea8 ] Tha ARCHOS Cesium 140 tablet has problem with the jack-sensing, thus the heaset functions are not working. Add quirk for this model to select the correct input map, jack-detect options and channel map to enable jack sensing and headset microphone. This device uses IN1 for its internal MIC and JD2 for jack-detect. Signed-off-by: Chris Chiu Acked-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20201208060414.27646-1-chiu@endlessos.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 2397bcc7cbe8bed08157b697c929e5967d13cb71 Author: Daniel Lee Kruse Date: Wed Sep 30 05:36:35 2020 +0200 media: cx23885: add more quirks for reset DMA on some AMD IOMMU [ Upstream commit dbf0b3a7b719eb3f72cb53c2ce7d34a012a9c261 ] On AMD Family 15h (Models 30h-3fh), I/O Memory Management Unit RiSC engine sometimes stalls, requiring a reset. As result, MythTV and w-scan won't scan channels on the AMD Kaveri APU with the Hauppauge QuadHD TV tuner card. For the solution I added the Input/Output Memory Management Unit's PCI Identity of 0x1423 to the broken_dev_id[] array, which is used by a quirks logic meant to fix similar problems with other AMD chipsets. Signed-off-by: Daniel Lee Kruse Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 46a48d60d3452bedfe56f750efb99172d1301170 Author: Ethan Warth Date: Tue Nov 17 09:48:00 2020 +0100 HID: mf: add support for 0079:1846 Mayflash/Dragonrise USB Gamecube Adapter [ Upstream commit 1008230f2abeb624f6d71b2e1c424fa4eeebbf84 ] Mayflash/Dragonrise seems to have yet another device ID for one of their Gamecube controller adapters. Previous to this commit, the adapter registered only one /dev/input/js* device, and all controller inputs (from any controller) were mapped to this device. This patch defines the 1846 USB device ID and enables the HID_QUIRK_MULTI_INPUT quirk for it, which fixes that (with the patch, four /dev/input/js* devices are created, one for each of the four controller ports). Signed-off-by: Ethan Warth Tested-by: Wladimir J. van der Laan Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 538b7b1d8af955d05e574748b5141c6d06e77148 Author: Hans de Goede Date: Mon Nov 23 16:16:25 2020 +0100 platform/x86: acer-wmi: Add ACER_CAP_KBD_DOCK quirk for the Aspire Switch 10E SW3-016 [ Upstream commit bf753400280d1384abb783efc0b42c491d6deec3 ] Add the Acer Aspire Switch 10E SW3-016 to the list of models which use the Acer Switch WMI interface for reporting SW_TABLET_MODE. Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20201123151625.5530-1-hdegoede@redhat.com Signed-off-by: Sasha Levin commit a51479a20f1df093afc50f5259d781f7f8dceb01 Author: Hans de Goede Date: Mon Oct 19 20:56:28 2020 +0200 platform/x86: acer-wmi: Add support for SW_TABLET_MODE on Switch devices [ Upstream commit 5c54cb6c627e8f50f490e6b5656051a5ac29eab4 ] Add support for SW_TABLET_MODE on the Acer Switch 10 (SW5-012) and the acer Switch 10 (S1003) models. There is no way to detect if this is supported, so this uses DMI based quirks setting force_caps to ACER_CAP_KBD_DOCK (these devices have no other acer-wmi based functionality). The new SW_TABLET_MODE functionality can be tested on devices which are not in the DMI table by passing acer_wmi.force_caps=0x40 on the kernel commandline. Reviewed-by: Andy Shevchenko Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20201019185628.264473-6-hdegoede@redhat.com Signed-off-by: Sasha Levin commit e395a3ff8d8d2068e26b18e3e5e281ab2e85e2c0 Author: Hans de Goede Date: Mon Oct 19 20:56:27 2020 +0200 platform/x86: acer-wmi: Add ACER_CAP_SET_FUNCTION_MODE capability flag [ Upstream commit 82cb8a5c395ea5be20e0fe31a8fe84380a502ca5 ] Not all devices supporting WMID_GUID3 support the wmid3_set_function_mode() call, leading to errors like these: [ 60.138358] acer_wmi: Enabling RF Button failed: 0x1 - 0xff [ 60.140036] acer_wmi: Enabling Launch Manager failed: 0x1 - 0xff Add an ACER_CAP_SET_FUNCTION_MODE capability flag, so that these calls can be disabled through the new force_caps mechanism. Reviewed-by: Andy Shevchenko Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20201019185628.264473-5-hdegoede@redhat.com Signed-off-by: Sasha Levin commit 50fad2dc524d1089cd68b589639e4a8193fd0932 Author: Hans de Goede Date: Mon Oct 19 20:56:26 2020 +0200 platform/x86: acer-wmi: Add new force_caps module parameter [ Upstream commit 39aa009bb66f9d5fbd1e58ca4aa03d6e6f2c9915 ] Add a new force_caps module parameter to allow overriding the drivers builtin capability detection mechanism. This can be used to for example: -Disable rfkill functionality on devices where there is an AA OEM DMI record advertising non functional rfkill switches -Force loading of the driver on devices with a missing AA OEM DMI record Note that force_caps is -1 when unset, this allows forcing the capability field to 0, which results in acer-wmi only providing WMI hotkey handling while disabling all other (led, rfkill, backlight) functionality. Reviewed-by: Andy Shevchenko Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20201019185628.264473-4-hdegoede@redhat.com Signed-off-by: Sasha Levin commit 0ce1d577530a950869b7a25d73280a8561efd5d9 Author: Hans de Goede Date: Mon Oct 19 20:56:25 2020 +0200 platform/x86: acer-wmi: Cleanup accelerometer device handling [ Upstream commit 9feb0763e4985ccfae632de3bb2f029cc8389842 ] Cleanup accelerometer device handling: -Drop acer_wmi_accel_destroy instead directly call input_unregister_device. -The information tracked by the CAP_ACCEL flag mirrors acer_wmi_accel_dev being NULL. Drop the CAP flag, this is a preparation change for allowing users to override the capability flags. Dropping the flag stops users from causing a NULL pointer dereference by forcing the capability. Reviewed-by: Andy Shevchenko Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20201019185628.264473-3-hdegoede@redhat.com Signed-off-by: Sasha Levin commit 626694f7a8c2d5743dd3c06e58f3721d5566091a Author: Hans de Goede Date: Mon Oct 19 20:56:24 2020 +0200 platform/x86: acer-wmi: Cleanup ACER_CAP_FOO defines [ Upstream commit 7c936d8d26afbc74deac0651d613dead2f76e81c ] Cleanup the ACER_CAP_FOO defines: -Switch to using BIT() macro. -The ACER_CAP_RFBTN flag is set, but it is never checked anywhere, drop it. -Drop the unused ACER_CAP_ANY define. Reviewed-by: Andy Shevchenko Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20201019185628.264473-2-hdegoede@redhat.com Signed-off-by: Sasha Levin commit cbb5fa1ed2d3a3bfce8f96d53c9fdc237ffd914c Author: Tsuchiya Yuto Date: Wed Oct 28 23:23:46 2020 +0900 mwifiex: pcie: skip cancel_work_sync() on reset failure path [ Upstream commit 4add4d988f95f47493500a7a19c623827061589b ] If a reset is performed, but even the reset fails for some reasons (e.g., on Surface devices, the fw reset requires another quirks), cancel_work_sync() hangs in mwifiex_cleanup_pcie(). # firmware went into a bad state [...] [ 1608.281690] mwifiex_pcie 0000:03:00.0: info: shutdown mwifiex... [ 1608.282724] mwifiex_pcie 0000:03:00.0: rx_pending=0, tx_pending=1, cmd_pending=0 [ 1608.292400] mwifiex_pcie 0000:03:00.0: PREP_CMD: card is removed [ 1608.292405] mwifiex_pcie 0000:03:00.0: PREP_CMD: card is removed # reset performed after firmware went into a bad state [ 1609.394320] mwifiex_pcie 0000:03:00.0: WLAN FW already running! Skip FW dnld [ 1609.394335] mwifiex_pcie 0000:03:00.0: WLAN FW is active # but even the reset failed [ 1619.499049] mwifiex_pcie 0000:03:00.0: mwifiex_cmd_timeout_func: Timeout cmd id = 0xfa, act = 0xe000 [ 1619.499094] mwifiex_pcie 0000:03:00.0: num_data_h2c_failure = 0 [ 1619.499103] mwifiex_pcie 0000:03:00.0: num_cmd_h2c_failure = 0 [ 1619.499110] mwifiex_pcie 0000:03:00.0: is_cmd_timedout = 1 [ 1619.499117] mwifiex_pcie 0000:03:00.0: num_tx_timeout = 0 [ 1619.499124] mwifiex_pcie 0000:03:00.0: last_cmd_index = 0 [ 1619.499133] mwifiex_pcie 0000:03:00.0: last_cmd_id: fa 00 07 01 07 01 07 01 07 01 [ 1619.499140] mwifiex_pcie 0000:03:00.0: last_cmd_act: 00 e0 00 00 00 00 00 00 00 00 [ 1619.499147] mwifiex_pcie 0000:03:00.0: last_cmd_resp_index = 3 [ 1619.499155] mwifiex_pcie 0000:03:00.0: last_cmd_resp_id: 07 81 07 81 07 81 07 81 07 81 [ 1619.499162] mwifiex_pcie 0000:03:00.0: last_event_index = 2 [ 1619.499169] mwifiex_pcie 0000:03:00.0: last_event: 58 00 58 00 58 00 58 00 58 00 [ 1619.499177] mwifiex_pcie 0000:03:00.0: data_sent=0 cmd_sent=1 [ 1619.499185] mwifiex_pcie 0000:03:00.0: ps_mode=0 ps_state=0 [ 1619.499215] mwifiex_pcie 0000:03:00.0: info: _mwifiex_fw_dpc: unregister device # mwifiex_pcie_work hang happening [ 1823.233923] INFO: task kworker/3:1:44 blocked for more than 122 seconds. [ 1823.233932] Tainted: G WC OE 5.10.0-rc1-1-mainline #1 [ 1823.233935] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 1823.233940] task:kworker/3:1 state:D stack: 0 pid: 44 ppid: 2 flags:0x00004000 [ 1823.233960] Workqueue: events mwifiex_pcie_work [mwifiex_pcie] [ 1823.233965] Call Trace: [ 1823.233981] __schedule+0x292/0x820 [ 1823.233990] schedule+0x45/0xe0 [ 1823.233995] schedule_timeout+0x11c/0x160 [ 1823.234003] wait_for_completion+0x9e/0x100 [ 1823.234012] __flush_work.isra.0+0x156/0x210 [ 1823.234018] ? flush_workqueue_prep_pwqs+0x130/0x130 [ 1823.234026] __cancel_work_timer+0x11e/0x1a0 [ 1823.234035] mwifiex_cleanup_pcie+0x28/0xd0 [mwifiex_pcie] [ 1823.234049] mwifiex_free_adapter+0x24/0xe0 [mwifiex] [ 1823.234060] _mwifiex_fw_dpc+0x294/0x560 [mwifiex] [ 1823.234074] mwifiex_reinit_sw+0x15d/0x300 [mwifiex] [ 1823.234080] mwifiex_pcie_reset_done+0x50/0x80 [mwifiex_pcie] [ 1823.234087] pci_try_reset_function+0x5c/0x90 [ 1823.234094] process_one_work+0x1d6/0x3a0 [ 1823.234100] worker_thread+0x4d/0x3d0 [ 1823.234107] ? rescuer_thread+0x410/0x410 [ 1823.234112] kthread+0x142/0x160 [ 1823.234117] ? __kthread_bind_mask+0x60/0x60 [ 1823.234124] ret_from_fork+0x22/0x30 [...] This is a deadlock caused by calling cancel_work_sync() in mwifiex_cleanup_pcie(): - Device resets are done via mwifiex_pcie_card_reset() - which schedules card->work to call mwifiex_pcie_card_reset_work() - which calls pci_try_reset_function(). - This leads to mwifiex_pcie_reset_done() be called on the same workqueue, which in turn calls - mwifiex_reinit_sw() and that calls - _mwifiex_fw_dpc(). The problem is now that _mwifiex_fw_dpc() calls mwifiex_free_adapter() in case firmware initialization fails. That ends up calling mwifiex_cleanup_pcie(). Note that all those calls are still running on the workqueue. So when mwifiex_cleanup_pcie() now calls cancel_work_sync(), it's really waiting on itself to complete, causing a deadlock. This commit fixes the deadlock by skipping cancel_work_sync() on a reset failure path. After this commit, when reset fails, the following output is expected to be shown: kernel: mwifiex_pcie 0000:03:00.0: info: _mwifiex_fw_dpc: unregister device kernel: mwifiex: Failed to bring up adapter: -5 kernel: mwifiex_pcie 0000:03:00.0: reinit failed: -5 To reproduce this issue, for example, try putting the root port of wifi into D3 (replace "00:1d.3" with your setup). # put into D3 (root port) sudo setpci -v -s 00:1d.3 CAP_PM+4.b=0b Cc: Maximilian Luz Signed-off-by: Tsuchiya Yuto Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20201028142346.18355-1-kitakar@gmail.com Signed-off-by: Sasha Levin commit 4ed2042cb8c2ee90f027c03287b1e1355c3fa077 Author: Andrey Ryabinin Date: Wed Feb 17 17:30:04 2021 +0300 iommu/amd: Fix sleeping in atomic in increase_address_space() commit 140456f994195b568ecd7fc2287a34eadffef3ca upstream. increase_address_space() calls get_zeroed_page(gfp) under spin_lock with disabled interrupts. gfp flags passed to increase_address_space() may allow sleeping, so it comes to this: BUG: sleeping function called from invalid context at mm/page_alloc.c:4342 in_atomic(): 1, irqs_disabled(): 1, pid: 21555, name: epdcbbf1qnhbsd8 Call Trace: dump_stack+0x66/0x8b ___might_sleep+0xec/0x110 __alloc_pages_nodemask+0x104/0x300 get_zeroed_page+0x15/0x40 iommu_map_page+0xdd/0x3e0 amd_iommu_map+0x50/0x70 iommu_map+0x106/0x220 vfio_iommu_type1_ioctl+0x76e/0x950 [vfio_iommu_type1] do_vfs_ioctl+0xa3/0x6f0 ksys_ioctl+0x66/0x70 __x64_sys_ioctl+0x16/0x20 do_syscall_64+0x4e/0x100 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fix this by moving get_zeroed_page() out of spin_lock/unlock section. Fixes: 754265bcab ("iommu/amd: Fix race in increase_address_space()") Signed-off-by: Andrey Ryabinin Acked-by: Will Deacon Cc: Link: https://lore.kernel.org/r/20210217143004.19165-1-arbn@yandex-team.com Signed-off-by: Joerg Roedel Signed-off-by: Andrey Ryabinin Signed-off-by: Greg Kroah-Hartman commit c6547dc1e3753382a58bc339a24ed4ef04b09dd3 Author: Jeffle Xu Date: Tue Mar 9 11:33:44 2021 +0800 dm table: fix zoned iterate_devices based device capability checks commit 24f6b6036c9eec21191646930ad42808e6180510 upstream. Fix dm_table_supports_zoned_model() and invert logic of both iterate_devices_callout_fn so that all devices' zoned capabilities are properly checked. Add one more parameter to dm_table_any_dev_attr(), which is actually used as the @data parameter of iterate_devices_callout_fn, so that dm_table_matches_zone_sectors() can be replaced by dm_table_any_dev_attr(). Fixes: dd88d313bef02 ("dm table: add zoned block devices validation") Cc: stable@vger.kernel.org Signed-off-by: Jeffle Xu Signed-off-by: Mike Snitzer [jeffle: also convert no_sg_merge and partial completion check] Signed-off-by: Greg Kroah-Hartman commit 16ee4c4957e8a92c2d03b8b028e11664d825c167 Author: Jeffle Xu Date: Tue Mar 9 11:33:43 2021 +0800 dm table: fix DAX iterate_devices based device capability checks commit 5b0fab508992c2e120971da658ce80027acbc405 upstream. Fix dm_table_supports_dax() and invert logic of both iterate_devices_callout_fn so that all devices' DAX capabilities are properly checked. Fixes: 545ed20e6df6 ("dm: add infrastructure for DAX support") Cc: stable@vger.kernel.org Signed-off-by: Jeffle Xu Signed-off-by: Mike Snitzer [jeffle: no dax synchronous] Signed-off-by: Greg Kroah-Hartman commit adbe8d9d3d45e02271f28f212375c67c30ced700 Author: Jeffle Xu Date: Tue Mar 9 11:33:42 2021 +0800 dm table: fix iterate_devices based device capability checks commit a4c8dd9c2d0987cf542a2a0c42684c9c6d78a04e upstream. According to the definition of dm_iterate_devices_fn: * This function must iterate through each section of device used by the * target until it encounters a non-zero return code, which it then returns. * Returns zero if no callout returned non-zero. For some target type (e.g. dm-stripe), one call of iterate_devices() may iterate multiple underlying devices internally, in which case a non-zero return code returned by iterate_devices_callout_fn will stop the iteration in advance. No iterate_devices_callout_fn should return non-zero unless device iteration should stop. Rename dm_table_requires_stable_pages() to dm_table_any_dev_attr() and elevate it for reuse to stop iterating (and return non-zero) on the first device that causes iterate_devices_callout_fn to return non-zero. Use dm_table_any_dev_attr() to properly iterate through devices. Rename device_is_nonrot() to device_is_rotational() and invert logic accordingly to fix improper disposition. [jeffle: backport notes] Also convert the no_sg_merge capability check, which is introduced by commit 200612ec33e5 ("dm table: propagate QUEUE_FLAG_NO_SG_MERGE"), and removed since commit 2705c93742e9 ("block: kill QUEUE_FLAG_NO_SG_MERGE") in v5.1. Also convert the partial completion capability check, which is introduced by commit 22c11858e800 ("dm: introduce DM_TYPE_NVME_BIO_BASED"), and removed since commit 9c37de297f65 ("dm: remove special-casing of bio-based immutable singleton target on NVMe") in v5.10. Fixes: c3c4555edd10 ("dm table: clear add_random unless all devices have it set") Fixes: 4693c9668fdc ("dm table: propagate non rotational flag") Cc: stable@vger.kernel.org Signed-off-by: Jeffle Xu Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 6a9a45616bd97030841dc62a92e0e6f443d483d5 Author: Alexander Lobakin Date: Tue Apr 21 16:41:08 2020 +0300 net: dsa: add GRO support via gro_cells commit e131a5634830047923c694b4ce0c3b31745ff01b upstream. gro_cells lib is used by different encapsulating netdevices, such as geneve, macsec, vxlan etc. to speed up decapsulated traffic processing. CPU tag is a sort of "encapsulation", and we can use the same mechs to greatly improve overall DSA performance. skbs are passed to the GRO layer after removing CPU tags, so we don't need any new packet offload types as it was firstly proposed by me in the first GRO-over-DSA variant [1]. The size of struct gro_cells is sizeof(void *), so hot struct dsa_slave_priv becomes only 4/8 bytes bigger, and all critical fields remain in one 32-byte cacheline. The other positive side effect is that drivers for network devices that can be shipped as CPU ports of DSA-driven switches can now use napi_gro_frags() to pass skbs to kernel. Packets built that way are completely non-linear and are likely being dropped without GRO. This was tested on to-be-mainlined-soon Ethernet driver that uses napi_gro_frags(), and the overall performance was on par with the variant from [1], sometimes even better due to minimal overhead. net.core.gro_normal_batch tuning may help to push it to the limit on particular setups and platforms. iperf3 IPoE VLAN NAT TCP forwarding (port1.218 -> port0) setup on 1.2 GHz MIPS board: 5.7-rc2 baseline: [ID] Interval Transfer Bitrate Retr [ 5] 0.00-120.01 sec 9.00 GBytes 644 Mbits/sec 413 sender [ 5] 0.00-120.00 sec 8.99 GBytes 644 Mbits/sec receiver Iface RX packets TX packets eth0 7097731 7097702 port0 426050 6671829 port1 6671681 425862 port1.218 6671677 425851 With this patch: [ID] Interval Transfer Bitrate Retr [ 5] 0.00-120.01 sec 12.2 GBytes 870 Mbits/sec 122 sender [ 5] 0.00-120.00 sec 12.2 GBytes 870 Mbits/sec receiver Iface RX packets TX packets eth0 9474792 9474777 port0 455200 353288 port1 9019592 455035 port1.218 353144 455024 v2: - Add some performance examples in the commit message; - No functional changes. [1] https://lore.kernel.org/netdev/20191230143028.27313-1-alobakin@dlink.ru/ Signed-off-by: Alexander Lobakin Signed-off-by: David S. Miller Cc: Pali Rohár Signed-off-by: Greg Kroah-Hartman commit 310e04f1bad9bcf3b45b4fd3e72b8aad11f5c097 Author: Heiner Kallweit Date: Sun Feb 14 17:38:30 2021 +0100 r8169: fix resuming from suspend on RTL8105e if machine runs on battery commit d2a04370817fc7b0172dad2ef2decf907e1a304e upstream. Armin reported that after referenced commit his RTL8105e is dead when resuming from suspend and machine runs on battery. This patch has been confirmed to fix the issue. Fixes: e80bd76fbf56 ("r8169: work around power-saving bug on some chip versions") Reported-by: Armin Wolf Tested-by: Armin Wolf Signed-off-by: Heiner Kallweit Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 9741874007daa0dcb184b9ed61ccc800fd5640e7 Author: Milan Broz Date: Tue Feb 23 21:21:21 2021 +0100 dm verity: fix FEC for RS roots unaligned to block size commit df7b59ba9245c4a3115ebaa905e3e5719a3810da upstream. Optional Forward Error Correction (FEC) code in dm-verity uses Reed-Solomon code and should support roots from 2 to 24. The error correction parity bytes (of roots lengths per RS block) are stored on a separate device in sequence without any padding. Currently, to access FEC device, the dm-verity-fec code uses dm-bufio client with block size set to verity data block (usually 4096 or 512 bytes). Because this block size is not divisible by some (most!) of the roots supported lengths, data repair cannot work for partially stored parity bytes. This fix changes FEC device dm-bufio block size to "roots << SECTOR_SHIFT" where we can be sure that the full parity data is always available. (There cannot be partial FEC blocks because parity must cover whole sectors.) Because the optional FEC starting offset could be unaligned to this new block size, we have to use dm_bufio_set_sector_offset() to configure it. The problem is easily reproduced using veritysetup, e.g. for roots=13: # create verity device with RS FEC dd if=/dev/urandom of=data.img bs=4096 count=8 status=none veritysetup format data.img hash.img --fec-device=fec.img --fec-roots=13 | awk '/^Root hash/{ print $3 }' >roothash # create an erasure that should be always repairable with this roots setting dd if=/dev/zero of=data.img conv=notrunc bs=1 count=8 seek=4088 status=none # try to read it through dm-verity veritysetup open data.img test hash.img --fec-device=fec.img --fec-roots=13 $(cat roothash) dd if=/dev/mapper/test of=/dev/null bs=4096 status=noxfer # wait for possible recursive recovery in kernel udevadm settle veritysetup close test With this fix, errors are properly repaired. device-mapper: verity-fec: 7:1: FEC 0: corrected 8 errors ... Without it, FEC code usually ends on unrecoverable failure in RS decoder: device-mapper: verity-fec: 7:1: FEC 0: failed to correct: -74 ... This problem is present in all kernels since the FEC code's introduction (kernel 4.5). It is thought that this problem is not visible in Android ecosystem because it always uses a default RS roots=2. Depends-on: a14e5ec66a7a ("dm bufio: subtract the number of initial sectors in dm_bufio_get_device_size") Signed-off-by: Milan Broz Tested-by: Jérôme Carretero Reviewed-by: Sami Tolvanen Cc: stable@vger.kernel.org # 4.5+ Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit c6d6178f539783a8cb1818466776dc9aec3419f5 Author: Dan Carpenter Date: Wed Mar 3 13:59:12 2021 +0300 rsxx: Return -EFAULT if copy_to_user() fails [ Upstream commit 77516d25f54912a7baedeeac1b1b828b6f285152 ] The copy_to_user() function returns the number of bytes remaining but we want to return -EFAULT to the user if it can't complete the copy. The "st" variable only holds zero on success or negative error codes on failure so the type should be int. Fixes: 36f988e978f8 ("rsxx: Adding in debugfs entries.") Signed-off-by: Dan Carpenter Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 65bf32888a140e4de6e14bd19b5dba87e6eaf856 Author: Julian Braha Date: Fri Feb 19 18:32:26 2021 -0500 RDMA/rxe: Fix missing kconfig dependency on CRYPTO [ Upstream commit 475f23b8c66d2892ad6acbf90ed757cafab13de7 ] When RDMA_RXE is enabled and CRYPTO is disabled, Kbuild gives the following warning: WARNING: unmet direct dependencies detected for CRYPTO_CRC32 Depends on [n]: CRYPTO [=n] Selected by [y]: - RDMA_RXE [=y] && (INFINIBAND_USER_ACCESS [=y] || !INFINIBAND_USER_ACCESS [=y]) && INET [=y] && PCI [=y] && INFINIBAND [=y] && INFINIBAND_VIRT_DMA [=y] This is because RDMA_RXE selects CRYPTO_CRC32, without depending on or selecting CRYPTO, despite that config option being subordinate to CRYPTO. Fixes: cee2688e3cd6 ("IB/rxe: Offload CRC calculation when possible") Signed-off-by: Julian Braha Link: https://lore.kernel.org/r/21525878.NYvzQUHefP@ubuntu-mate-laptop Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 4a7cd6082e7c2935ad7f5f3c51d6dbb2a6a9a391 Author: Colin Ian King Date: Sat Feb 27 00:15:27 2021 +0000 ALSA: ctxfi: cthw20k2: fix mask on conf to allow 4 bits [ Upstream commit 26a9630c72ebac7c564db305a6aee54a8edde70e ] Currently the mask operation on variable conf is just 3 bits so the switch statement case value of 8 is unreachable dead code. The function daio_mgr_dao_init can be passed a 4 bit value, function dao_rsc_init calls it with conf set to: conf = (desc->msr & 0x7) | (desc->passthru << 3); so clearly when desc->passthru is set to 1 then conf can be at least 8. Fix this by changing the mask to 0xf. Fixes: 8cc72361481f ("ALSA: SB X-Fi driver merge") Signed-off-by: Colin Ian King Link: https://lore.kernel.org/r/20210227001527.1077484-1-colin.king@canonical.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 1eee7382abc87d537c51d5c20d998112b24174db Author: Hannes Reinecke Date: Tue Feb 23 17:28:59 2021 +0800 virtio-blk: modernize sysfs attribute creation commit e982c4d0a29b1d61fbe7716a8dcf8984936d6730 upstream. Use new-style DEVICE_ATTR_RO/DEVICE_ATTR_RW to create the sysfs attributes and register the disk with default sysfs attribute groups. Signed-off-by: Hannes Reinecke Reviewed-by: Christoph Hellwig Acked-by: Michael S. Tsirkin Reviewed-by: Bart Van Assche Signed-off-by: Jens Axboe Signed-off-by: Jeffle Xu Signed-off-by: Greg Kroah-Hartman commit 70a534ad4a4ee7d528c81ef9b2caf0ae3e302831 Author: Hannes Reinecke Date: Tue Feb 23 17:28:58 2021 +0800 zram: register default groups with device_add_disk() commit 98af4d4df889dcea3bc0ce6b8a04759658ba8826 upstream. Register default sysfs groups during device_add_disk() to avoid a race condition with udev during startup. Signed-off-by: Hannes Reinecke Cc: Minchan Kim Cc: Nitin Gupta Reviewed-by: Christoph Hellwig Reviewed-by: Bart Van Assche Signed-off-by: Jens Axboe Signed-off-by: Jeffle Xu Signed-off-by: Greg Kroah-Hartman commit 4fdc94b476ba89bc712c44adb261e133794eb0f0 Author: Hannes Reinecke Date: Tue Feb 23 17:28:57 2021 +0800 aoe: register default groups with device_add_disk() commit 95cf7809bf9169fec4e4b7bb24b8069d8f354f96 upstream. Register default sysfs groups during device_add_disk() to avoid a race condition with udev during startup. Signed-off-by: Hannes Reinecke Reviewed-by: Christoph Hellwig Acked-by: Ed L. Cachin Reviewed-by: Bart Van Assche Signed-off-by: Jens Axboe Signed-off-by: Jeffle Xu Signed-off-by: Greg Kroah-Hartman commit ea7ac82cf4d8a7085c70fb690ede2d4d6c986bc1 Author: Hannes Reinecke Date: Tue Feb 23 17:28:56 2021 +0800 nvme: register ns_id attributes as default sysfs groups commit 33b14f67a4e1eabd219fd6543da8f15ed86b641c upstream. We should be registering the ns_id attribute as default sysfs attribute groups, otherwise we have a race condition between the uevent and the attributes appearing in sysfs. [Backport Notes] Resolve two context conflicts introduced by following two commits. These two commits are applied after the current commit in upstream, while have been merged into 4.19.y stable tree before the current commit. 1. drivers/nvme/host/core.c:nvme_ns_remove, introduced by commit 2181e455612a ("nvme: fix possible io failures when removing multipathed ns"). 2. drivers/nvme/host/multipath.c:nvme_mpath_set_live, introduced by commit 5e416b11b4a9 ("nvme-multipath: fix possible I/O hang when paths are updated"). Suggested-by: Bart van Assche Reviewed-by: Keith Busch Signed-off-by: Hannes Reinecke Signed-off-by: Jens Axboe Signed-off-by: Jeffle Xu Signed-off-by: Greg Kroah-Hartman commit 1bf6a186c4524e62c4e46d2c9f28a70fb45f9e8b Author: Hannes Reinecke Date: Tue Feb 23 17:28:55 2021 +0800 block: genhd: add 'groups' argument to device_add_disk commit fef912bf860e8e7e48a2bfb978a356bba743a8b7 upstream. Update device_add_disk() to take an 'groups' argument so that individual drivers can register a device with additional sysfs attributes. This avoids race condition the driver would otherwise have if these groups were to be created with sysfs_add_groups(). Signed-off-by: Martin Wilck Signed-off-by: Hannes Reinecke Reviewed-by: Christoph Hellwig Reviewed-by: Bart Van Assche Signed-off-by: Jens Axboe Signed-off-by: Jeffle Xu Signed-off-by: Greg Kroah-Hartman commit e21a0a2a46c61036e460ff2986d2f08c09a6092b Author: Jeffle Xu Date: Tue Feb 23 17:28:54 2021 +0800 Revert "zram: close udev startup race condition as default groups" This reverts commit 9e07f4e243791e00a4086ad86e573705cf7b2c65. The original commit is actually a "merged" fix of [1] and [2], as described in [3]. Since now we have more fixes that rely on [1], revert this commit first, and then get the original [1] and [2] merged. [1] fef912bf860e, block: genhd: add 'groups' argument to device_add_disk [2] 98af4d4df889, zram: register default groups with device_add_disk() [3] https://www.spinics.net/lists/stable/msg442196.html Signed-off-by: Jeffle Xu Signed-off-by: Greg Kroah-Hartman commit cc69244f36b9ee87acc683214574c16f8bffb093 Author: Antonio Borneo Date: Thu Jun 18 02:08:44 2020 +0200 usbip: tools: fix build error for multiple definition commit d5efc2e6b98fe661dbd8dd0d5d5bfb961728e57a upstream. With GCC 10, building usbip triggers error for multiple definition of 'udev_context', in: - libsrc/vhci_driver.c:18 and - libsrc/usbip_host_common.c:27. Declare as extern the definition in libsrc/usbip_host_common.c. Signed-off-by: Antonio Borneo Acked-by: Shuah Khan Link: https://lore.kernel.org/r/20200618000844.1048309-1-borneo.antonio@gmail.com Cc: Petr Štetiar Signed-off-by: Greg Kroah-Hartman commit ef3a3eeaeb3a4a87685d929d298f6127ed8d6d88 Author: Kevin Wang Date: Tue Mar 2 15:54:00 2021 +0800 drm/amdgpu: fix parameter error of RREG32_PCIE() in amdgpu_regs_pcie commit 1aa46901ee51c1c5779b3b239ea0374a50c6d9ff upstream. the register offset isn't needed division by 4 to pass RREG32_PCIE() Signed-off-by: Kevin Wang Reviewed-by: Lijo Lazar Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 85295f08866a6a26d013ae46699104b80699fb4e Author: Mikulas Patocka Date: Tue Feb 23 21:21:20 2021 +0100 dm bufio: subtract the number of initial sectors in dm_bufio_get_device_size commit a14e5ec66a7a66e57b24e2469f9212a78460207e upstream. dm_bufio_get_device_size returns the device size in blocks. Before returning the value, we must subtract the nubmer of starting sectors. The number of starting sectors may not be divisible by block size. Note that currently, no target is using dm_bufio_set_sector_offset and dm_bufio_get_device_size simultaneously, so this change has no effect. However, an upcoming dm-verity-fec fix needs this change. Signed-off-by: Mikulas Patocka Reviewed-by: Milan Broz Cc: stable@vger.kernel.org Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit be0abff9c34659622f564edec20e9cfa9af94120 Author: Rafael J. Wysocki Date: Thu Feb 25 19:23:27 2021 +0100 PM: runtime: Update device status before letting suppliers suspend commit 44cc89f764646b2f1f2ea5d1a08b230131707851 upstream. Because the PM-runtime status of the device is not updated in __rpm_callback(), attempts to suspend the suppliers of the given device triggered by rpm_put_suppliers() called by it may fail. Fix this by making __rpm_callback() update the device's status to RPM_SUSPENDED before calling rpm_put_suppliers() if the current status of the device is RPM_SUSPENDING and the callback just invoked by it has returned 0 (success). While at it, modify the code in __rpm_callback() to always check the device's PM-runtime status under its PM lock. Link: https://lore.kernel.org/linux-pm/CAPDyKFqm06KDw_p8WXsM4dijDbho4bb6T4k50UqqvR1_COsp8g@mail.gmail.com/ Fixes: 21d5c57b3726 ("PM / runtime: Use device links") Reported-by: Elaine Zhang Diagnosed-by: Ulf Hansson Signed-off-by: Rafael J. Wysocki Tested-by: Elaine Zhang Reviewed-by: Ulf Hansson Cc: 4.10+ # 4.10+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit ab28b0886498819816766c1f412443a9eecbd3c3 Author: Nikolay Borisov Date: Tue Feb 23 15:20:42 2021 +0200 btrfs: unlock extents in btrfs_zero_range in case of quota reservation errors commit 4f6a49de64fd1b1dba5229c02047376da7cf24fd upstream. If btrfs_qgroup_reserve_data returns an error (i.e quota limit reached) the handling logic directly goes to the 'out' label without first unlocking the extent range between lockstart, lockend. This results in deadlocks as other processes try to lock the same extent. Fixes: a7f8b1c2ac21 ("btrfs: file: reserve qgroup space after the hole punch range is locked") CC: stable@vger.kernel.org # 5.10+ Reviewed-by: Qu Wenruo Signed-off-by: Nikolay Borisov Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit db1dde1bf1c98aa4a5c80ae453fd9c82fe032926 Author: Nikolay Borisov Date: Mon Feb 22 18:40:42 2021 +0200 btrfs: free correct amount of space in btrfs_delayed_inode_reserve_metadata commit 0f9c03d824f6f522d3bc43629635c9765546ebc5 upstream. Following commit f218ea6c4792 ("btrfs: delayed-inode: Remove wrong qgroup meta reservation calls") this function now reserves num_bytes, rather than the fixed amount of nodesize. As such this requires the same amount to be freed in case of failure. Fix this by adjusting the amount we are freeing. Fixes: f218ea6c4792 ("btrfs: delayed-inode: Remove wrong qgroup meta reservation calls") CC: stable@vger.kernel.org # 4.19+ Reviewed-by: Qu Wenruo Signed-off-by: Nikolay Borisov Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit f27ce3a7c51a8259dca1cb8ad91cbed7beaee892 Author: Dan Carpenter Date: Wed Feb 17 09:04:34 2021 +0300 btrfs: validate qgroup inherit for SNAP_CREATE_V2 ioctl commit 5011c5a663b9c6d6aff3d394f11049b371199627 upstream. The problem is we're copying "inherit" from user space but we don't necessarily know that we're copying enough data for a 64 byte struct. Then the next problem is that 'inherit' has a variable size array at the end, and we have to verify that array is the size we expected. Fixes: 6f72c7e20dba ("Btrfs: add qgroup inheritance") CC: stable@vger.kernel.org # 4.4+ Signed-off-by: Dan Carpenter Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 78abc4fb9eba8e7c7ac0339027df11404ae3bda2 Author: Ira Weiny Date: Wed Jan 27 22:15:03 2021 -0800 btrfs: fix raid6 qstripe kmap commit d70cef0d46729808dc53f145372c02b145c92604 upstream. When a qstripe is required an extra page is allocated and mapped. There were 3 problems: 1) There is no corresponding call of kunmap() for the qstripe page. 2) There is no reason to map the qstripe page more than once if the number of bits set in rbio->dbitmap is greater than one. 3) There is no reason to map the parity page and unmap it each time through the loop. The page memory can continue to be reused with a single mapping on each iteration by raid6_call.gen_syndrome() without remapping. So map the page for the duration of the loop. Similarly, improve the algorithm by mapping the parity page just 1 time. Fixes: 5a6ac9eacb49 ("Btrfs, raid56: support parity scrub on raid56") CC: stable@vger.kernel.org # 4.4.x: c17af96554a8: btrfs: raid56: simplify tracking of Q stripe presence CC: stable@vger.kernel.org # 4.4.x Signed-off-by: Ira Weiny Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit c1a77dbcaa2d7f45fc9cb9f0c525e1c11957bf2a Author: David Sterba Date: Wed Feb 19 15:17:20 2020 +0100 btrfs: raid56: simplify tracking of Q stripe presence commit c17af96554a8a8777cbb0fd53b8497250e548b43 upstream. There are temporary variables tracking the index of P and Q stripes, but none of them is really used as such, merely for determining if the Q stripe is present. This leads to compiler warnings with -Wunused-but-set-variable and has been reported several times. fs/btrfs/raid56.c: In function ‘finish_rmw’: fs/btrfs/raid56.c:1199:6: warning: variable ‘p_stripe’ set but not used [-Wunused-but-set-variable] 1199 | int p_stripe = -1; | ^~~~~~~~ fs/btrfs/raid56.c: In function ‘finish_parity_scrub’: fs/btrfs/raid56.c:2356:6: warning: variable ‘p_stripe’ set but not used [-Wunused-but-set-variable] 2356 | int p_stripe = -1; | ^~~~~~~~ Replace the two variables with one that has a clear meaning and also get rid of the warnings. The logic that verifies that there are only 2 valid cases is unchanged. Reviewed-by: Johannes Thumshirn Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman