commit bdc3a8f6a8e8b798c46683a98b97d52b3a5708e4 Author: Greg Kroah-Hartman Date: Thu Sep 17 13:47:56 2020 +0200 Linux 5.4.66 Tested-by: Shuah Khan Tested-by: Jon Hunter Tested-by: Linux Kernel Functional Testing Tested-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit d3c2b7d2856cb82bf2166ebc22c06c268b533773 Author: Peter Oberparleiter Date: Thu Sep 10 14:52:01 2020 +0200 gcov: add support for GCC 10.1 [ Upstream commit 40249c6962075c040fd071339acae524f18bfac9 ] Using gcov to collect coverage data for kernels compiled with GCC 10.1 causes random malfunctions and kernel crashes. This is the result of a changed GCOV_COUNTERS value in GCC 10.1 that causes a mismatch between the layout of the gcov_info structure created by GCC profiling code and the related structure used by the kernel. Fix this by updating the in-kernel GCOV_COUNTERS value. Also re-enable config GCOV_KERNEL for use with GCC 10. Reported-by: Colin Ian King Reported-by: Leon Romanovsky Signed-off-by: Peter Oberparleiter Tested-by: Leon Romanovsky Tested-and-Acked-by: Colin Ian King Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit fe79f1cf177afd7804e793c59726d2f008f50b0b Author: Jordan Crouse Date: Thu Sep 3 20:03:13 2020 -0600 drm/msm: Disable the RPTR shadow [ Upstream commit f6828e0c4045f03f9cf2df6c2a768102641183f4 ] Disable the RPTR shadow across all targets. It will be selectively re-enabled later for targets that need it. Cc: stable@vger.kernel.org Signed-off-by: Jordan Crouse Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 8cbe9b765487ef1b3f9ea37a768d4907ca577b56 Author: Rob Clark Date: Mon Aug 17 09:23:09 2020 -0700 drm/msm/gpu: make ringbuffer readonly [ Upstream commit 352c83fb39cae3eff95a8e1ed23006291abb6196 ] The GPU has no business writing into the ringbuffer, let's make it readonly to the GPU. Fixes: 7198e6b03155 ("drm/msm: add a3xx gpu support") Signed-off-by: Rob Clark Reviewed-by: Jordan Crouse Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit ebd9aff7b62ad70fa06ca0cb468a178f6c057fe4 Author: Heikki Krogerus Date: Fri Sep 4 14:09:18 2020 +0300 usb: typec: ucsi: acpi: Check the _DEP dependencies commit 1f3546ff3f0a1000971daef58406954bad3f7061 upstream. Failing probe with -EPROBE_DEFER until all dependencies listed in the _DEP (Operation Region Dependencies) object have been met. This will fix an issue where on some platforms UCSI ACPI driver fails to probe because the address space handler for the operation region that the UCSI ACPI interface uses has not been loaded yet. Fixes: 8243edf44152 ("usb: typec: ucsi: Add ACPI driver") Cc: stable@vger.kernel.org Signed-off-by: Heikki Krogerus Link: https://lore.kernel.org/r/20200904110918.51546-1-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 848eeb75c81daee3c6de9513b0615164871ae2f4 Author: Mathias Nyman Date: Tue Sep 1 11:25:28 2020 +0300 usb: Fix out of sync data toggle if a configured device is reconfigured commit cfd54fa83a5068b61b7eb28d3c117d8354c74c7a upstream. Userspace drivers that use a SetConfiguration() request to "lightweight" reset an already configured usb device might cause data toggles to get out of sync between the device and host, and the device becomes unusable. The xHCI host requires endpoints to be dropped and added back to reset the toggle. If USB core notices the new configuration is the same as the current active configuration it will avoid these extra steps by calling usb_reset_configuration() instead of usb_set_configuration(). A SetConfiguration() request will reset the device side data toggles. Make sure usb_reset_configuration() function also drops and adds back the endpoints to ensure data toggles are in sync. To avoid code duplication split the current usb_disable_device() function and reuse the endpoint specific part. Cc: stable Tested-by: Martin Thierer Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20200901082528.12557-1-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 224fa057d72af8c1262947e8a875640e886980c9 Author: Aleksander Morgado Date: Sat Aug 29 11:05:39 2020 +0200 USB: serial: option: add support for SIM7070/SIM7080/SIM7090 modules commit 1ac698790819b83f39fd7ea4f6cdabee9bdd7b38 upstream. These modules have 2 different USB layouts: The default layout with PID 0x9205 (AT+CUSBSELNV=1) exposes 4 TTYs and an ECM interface: T: Bus=02 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#= 6 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=1e0e ProdID=9205 Rev=00.00 S: Manufacturer=SimTech, Incorporated S: Product=SimTech SIM7080 S: SerialNumber=1234567890ABCDEF C: #Ifs= 6 Cfg#= 1 Atr=e0 MxPwr=500mA I: If#=0x0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#=0x1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#=0x2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#=0x4 Alt= 0 #EPs= 1 Cls=02(commc) Sub=06 Prot=00 Driver=cdc_ether I: If#=0x5 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether The purpose of each TTY is as follows: * ttyUSB0: DIAG/QCDM port. * ttyUSB1: GNSS data. * ttyUSB2: AT-capable port (control). * ttyUSB3: AT-capable port (data). In the secondary layout with PID=0x9206 (AT+CUSBSELNV=86) the module exposes 6 TTY ports: T: Bus=02 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#= 8 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=02(commc) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1e0e ProdID=9206 Rev=00.00 S: Manufacturer=SimTech, Incorporated S: Product=SimTech SIM7080 S: SerialNumber=1234567890ABCDEF C: #Ifs= 6 Cfg#= 1 Atr=e0 MxPwr=500mA I: If#=0x0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#=0x1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#=0x2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#=0x3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#=0x4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#=0x5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option The purpose of each TTY is as follows: * ttyUSB0: DIAG/QCDM port. * ttyUSB1: GNSS data. * ttyUSB2: AT-capable port (control). * ttyUSB3: QFLOG interface. * ttyUSB4: DAM interface. * ttyUSB5: AT-capable port (data). Signed-off-by: Aleksander Morgado Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit dbbb21384fe63266d8b2547077f9404d383c71c9 Author: Bjørn Mork Date: Sat Aug 29 15:42:50 2020 +0200 USB: serial: option: support dynamic Quectel USB compositions commit 2bb70f0a4b238323e4e2f392fc3ddeb5b7208c9e upstream. The USB composition, defining the set of exported functions, is dynamic in newer Quectel modems. Default functions can be disabled and alternative functions can be enabled instead. The alternatives includes class functions using interface pairs, which should be handled by the respective class drivers. Active interfaces are numbered consecutively, so static blacklisting based on interface numbers will fail when the composition changes. An example of such an error, where the option driver has bound to the CDC ECM data interface, preventing cdc_ether from handling this function: T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=2c7c ProdID=0125 Rev= 3.18 S: Manufacturer=Quectel S: Product=EC25-AF C:* #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA A: FirstIf#= 4 IfCount= 2 Cls=02(comm.) Sub=06 Prot=00 I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=87(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=06 Prot=00 Driver=(none) E: Ad=89(I) Atr=03(Int.) MxPS= 16 Ivl=32ms I:* If#= 5 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=00 Driver=option I: If#= 5 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=option E: Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms Another device with the same id gets correct drivers, since the interface of the network function happens to be blacklisted by option: T: Bus=01 Lev=02 Prnt=02 Port=01 Cnt=01 Dev#= 3 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=2c7c ProdID=0125 Rev= 3.18 S: Manufacturer=Android S: Product=Android C:* #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=87(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan E: Ad=89(I) Atr=03(Int.) MxPS= 8 Ivl=32ms E: Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms Change rules for EC21, EC25, BG96 and EG95 to match vendor specific serial functions only, to prevent binding to class functions. Require 2 endpoints on ff/ff/ff functions, avoiding the 3 endpoint QMI/RMNET network functions. Cc: AceLan Kao Cc: Sebastian Sjoholm Cc: Dan Williams Cc: stable@vger.kernel.org Signed-off-by: Bjørn Mork Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 38e75a99b4861bfdc77bd776b30cd684bb5960a3 Author: Patrick Riphagen Date: Thu Aug 6 13:55:47 2020 +0200 USB: serial: ftdi_sio: add IDs for Xsens Mti USB converter commit 6ccc48e0eb2f3a5f3bd39954a21317e5f8874726 upstream. The device added has an FTDI chip inside. The device is used to connect Xsens USB Motion Trackers. Cc: stable@vger.kernel.org Signed-off-by: Patrick Riphagen Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 70a9c0352e219fc87ccdeb54793e457abbef81e3 Author: Zeng Tao Date: Fri Sep 4 14:37:44 2020 +0800 usb: core: fix slab-out-of-bounds Read in read_descriptors commit a18cd6c9b6bc73dc17e8b7e9bd07decaa8833c97 upstream. The USB device descriptor may get changed between two consecutive enumerations on the same device for some reason, such as DFU or malicius device. In that case, we may access the changing descriptor if we don't take the device lock here. The issue is reported: https://syzkaller.appspot.com/bug?id=901a0d9e6519ef8dc7acab25344bd287dd3c7be9 Cc: stable Cc: Alan Stern Reported-by: syzbot+256e56ddde8b8957eabd@syzkaller.appspotmail.com Fixes: 217a9081d8e6 ("USB: add all configs to the "descriptors" attribute") Signed-off-by: Zeng Tao Link: https://lore.kernel.org/r/1599201467-11000-1-git-send-email-prime.zeng@hisilicon.com Signed-off-by: Greg Kroah-Hartman commit 83db8dd32b1d00f77916dba000b02b08f74157df Author: Sivaprakash Murugesan Date: Wed Jul 29 21:00:03 2020 +0530 phy: qcom-qmp: Use correct values for ipq8074 PCIe Gen2 PHY init commit afd55e6d1bd35b4b36847869011447a83a81c8e0 upstream. There were some problem in ipq8074 Gen2 PCIe phy init sequence. 1. Few register values were wrongly updated in the phy init sequence. 2. The register QSERDES_RX_SIGDET_CNTRL is a RX tuning parameter register which is added in serdes table causing the wrong register was getting updated. 3. Clocks and resets were not added in the phy init. Fix these to make Gen2 PCIe port on ipq8074 devices to work. Fixes: eef243d04b2b6 ("phy: qcom-qmp: Add support for IPQ8074") Cc: stable@vger.kernel.org Co-developed-by: Selvam Sathappan Periakaruppan Signed-off-by: Selvam Sathappan Periakaruppan Signed-off-by: Sivaprakash Murugesan Link: https://lore.kernel.org/r/1596036607-11877-4-git-send-email-sivaprak@codeaurora.org Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 524e525fa73ecf7a790b29b7795085a5300631b2 Author: Vaibhav Agarwal Date: Fri Aug 14 18:03:15 2020 +0530 staging: greybus: audio: fix uninitialized value issue commit 1dffeb8b8b4c261c45416d53c75ea51e6ece1770 upstream. The current implementation for gbcodec_mixer_dapm_ctl_put() uses uninitialized gbvalue for comparison with updated value. This was found using static analysis with coverity. Uninitialized scalar variable (UNINIT) 11. uninit_use: Using uninitialized value gbvalue.value.integer_value[0]. 460 if (gbvalue.value.integer_value[0] != val) { This patch fixes the issue with fetching the gbvalue before using it for comparision. Fixes: 6339d2322c47 ("greybus: audio: Add topology parser for GB codec") Reported-by: Colin Ian King Signed-off-by: Vaibhav Agarwal Cc: stable Link: https://lore.kernel.org/r/bc4f29eb502ccf93cd2ffd98db0e319fa7d0f247.1597408126.git.vaibhav.sr@gmail.com Signed-off-by: Greg Kroah-Hartman commit 3aa4c49c8d417798f0c0fb3df3903037f77a6f12 Author: Tetsuo Handa Date: Mon Aug 31 19:37:00 2020 +0900 video: fbdev: fix OOB read in vga_8planes_imageblit() commit bd018a6a75cebb511bb55a0e7690024be975fe93 upstream. syzbot is reporting OOB read at vga_8planes_imageblit() [1], for "cdat[y] >> 4" can become a negative value due to "const char *cdat". [1] https://syzkaller.appspot.com/bug?id=0d7a0da1557dcd1989e00cb3692b26d4173b4132 Reported-by: syzbot Signed-off-by: Tetsuo Handa Cc: stable Link: https://lore.kernel.org/r/90b55ec3-d5b0-3307-9f7c-7ff5c5fd6ad3@i-love.sakura.ne.jp Signed-off-by: Greg Kroah-Hartman commit 9dd48c399a8132e571ea5eb843e130a227a69ad8 Author: Chris Healy Date: Fri Aug 21 14:21:02 2020 -0700 ARM: dts: vfxxx: Add syscon compatible with OCOTP commit 2a6838d54128952ace6f0ca166dd8706abe46649 upstream. Add syscon compatibility with Vybrid OCOTP node. This is required to access the UID. Fixes: fa8d20c8dbb77 ("ARM: dts: vfxxx: Add node corresponding to OCOTP") Cc: stable@vger.kernel.org Reviewed-by: Fabio Estevam Reviewed-by: Stefan Agner Signed-off-by: Chris Healy Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit 323159acb2b5df62d1af831edd5a0db4e0026628 Author: Vladis Dronov Date: Tue Aug 11 17:01:29 2020 +0200 debugfs: Fix module state check condition commit e3b9fc7eec55e6fdc8beeed18f2ed207086341e2 upstream. The '#ifdef MODULE' check in the original commit does not work as intended. The code under the check is not built at all if CONFIG_DEBUG_FS=y. Fix this by using a correct check. Fixes: 275678e7a9be ("debugfs: Check module state before warning in {full/open}_proxy_open()") Signed-off-by: Vladis Dronov Cc: stable Link: https://lore.kernel.org/r/20200811150129.53343-1-vdronov@redhat.com Signed-off-by: Greg Kroah-Hartman commit 41b2ea7a6a11e2b1a7f2c29e1675a709a6b2b98d Author: Rustam Kovhaev Date: Mon Sep 7 11:55:35 2020 -0700 KVM: fix memory leak in kvm_io_bus_unregister_dev() commit f65886606c2d3b562716de030706dfe1bea4ed5e upstream. when kmalloc() fails in kvm_io_bus_unregister_dev(), before removing the bus, we should iterate over all other devices linked to it and call kvm_iodevice_destructor() for them Fixes: 90db10434b16 ("KVM: kvm_io_bus_unregister_dev() should never fail") Cc: stable@vger.kernel.org Reported-and-tested-by: syzbot+f196caa45793d6374707@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?extid=f196caa45793d6374707 Signed-off-by: Rustam Kovhaev Reviewed-by: Vitaly Kuznetsov Message-Id: <20200907185535.233114-1-rkovhaev@gmail.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit d334a67d3ed06cb40f69fbd93efac2e565bebbe9 Author: Marc Zyngier Date: Wed Sep 2 11:18:29 2020 +0100 KVM: arm64: Do not try to map PUDs when they are folded into PMD commit 3fb884ffe921c99483a84b0175f3c03f048e9069 upstream. For the obscure cases where PMD and PUD are the same size (64kB pages with 42bit VA, for example, which results in only two levels of page tables), we can't map anything as a PUD, because there is... erm... no PUD to speak of. Everything is either a PMD or a PTE. So let's only try and map a PUD when its size is different from that of a PMD. Cc: stable@vger.kernel.org Fixes: b8e0ba7c8bea ("KVM: arm64: Add support for creating PUD hugepages at stage 2") Reported-by: Gavin Shan Reported-by: Eric Auger Reviewed-by: Alexandru Elisei Reviewed-by: Gavin Shan Tested-by: Gavin Shan Tested-by: Eric Auger Tested-by: Alexandru Elisei Signed-off-by: Marc Zyngier Signed-off-by: Greg Kroah-Hartman commit a86743ebe680f020454d7d091c82c31ff55372e2 Author: Wanpeng Li Date: Wed Aug 19 16:55:27 2020 +0800 KVM: VMX: Don't freeze guest when event delivery causes an APIC-access exit commit 99b82a1437cb31340dbb2c437a2923b9814a7b15 upstream. According to SDM 27.2.4, Event delivery causes an APIC-access VM exit. Don't report internal error and freeze guest when event delivery causes an APIC-access exit, it is handleable and the event will be re-injected during the next vmentry. Signed-off-by: Wanpeng Li Message-Id: <1597827327-25055-2-git-send-email-wanpengli@tencent.com> Cc: stable@vger.kernel.org Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 087b6cb17df5834d395ab72da3f937380470ba15 Author: Linus Torvalds Date: Wed Sep 9 14:53:50 2020 -0700 vgacon: remove software scrollback support commit 973c096f6a85e5b5f2a295126ba6928d9a6afd45 upstream. Yunhai Zhang recently fixed a VGA software scrollback bug in commit ebfdfeeae8c0 ("vgacon: Fix for missing check in scrollback handling"), but that then made people look more closely at some of this code, and there were more problems on the vgacon side, but also the fbcon software scrollback. We don't really have anybody who maintains this code - probably because nobody actually _uses_ it any more. Sure, people still use both VGA and the framebuffer consoles, but they are no longer the main user interfaces to the kernel, and haven't been for decades, so these kinds of extra features end up bitrotting and not really being used. So rather than try to maintain a likely unused set of code, I'll just aggressively remove it, and see if anybody even notices. Maybe there are people who haven't jumped on the whole GUI badnwagon yet, and think it's just a fad. And maybe those people use the scrollback code. If that turns out to be the case, we can resurrect this again, once we've found the sucker^Wmaintainer for it who actually uses it. Reported-by: NopNop Nop Tested-by: Willy Tarreau Cc: 张云海 Acked-by: Andy Lutomirski Acked-by: Willy Tarreau Reviewed-by: Greg Kroah-Hartman Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 0d123a8c64fde433a9ba07390afb6f2b0d0f5dd0 Author: Linus Torvalds Date: Tue Sep 8 10:56:27 2020 -0700 fbcon: remove now unusued 'softback_lines' cursor() argument commit 06a0df4d1b8b13b551668e47b11fd7629033b7df upstream. Since the softscroll code got removed, this argument is always zero and makes no sense any more. Tested-by: Yuan Ming Tested-by: Willy Tarreau Reviewed-by: Greg Kroah-Hartman Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit cf5a7ded53652c3d63d7243944c6a8ec1f0ef392 Author: Linus Torvalds Date: Mon Sep 7 11:45:27 2020 -0700 fbcon: remove soft scrollback code commit 50145474f6ef4a9c19205b173da6264a644c7489 upstream. This (and the VGA soft scrollback) turns out to have various nasty small special cases that nobody really is willing to fight. The soft scrollback code was really useful a few decades ago when you typically used the console interactively as the main way to interact with the machine, but that just isn't the case any more. So it's not worth dragging along. Tested-by: Yuan Ming Tested-by: Willy Tarreau Acked-by: Bartlomiej Zolnierkiewicz Acked-by: Daniel Vetter Reviewed-by: Greg Kroah-Hartman Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit a0f6bdafaa4c5bb057c8aea5ac2ddfc52a5355f5 Author: Mark Bloch Date: Mon Aug 24 14:02:29 2020 +0300 RDMA/mlx4: Read pkey table length instead of hardcoded value commit ec78b3bd66bc9a015505df0ef0eb153d9e64b03b upstream. If the pkey_table is not available (which is the case when RoCE is not supported), the cited commit caused a regression where mlx4_devices without RoCE are not created. Fix this by returning a pkey table length of zero in procedure eth_link_query_port() if the pkey-table length reported by the device is zero. Link: https://lore.kernel.org/r/20200824110229.1094376-1-leon@kernel.org Cc: Fixes: 1901b91f9982 ("IB/core: Fix potential NULL pointer dereference in pkey cache") Fixes: fa417f7b520e ("IB/mlx4: Add support for IBoE") Signed-off-by: Mark Bloch Reviewed-by: Maor Gottlieb Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 616a0c13e43219a9803c993e256637d3e8117296 Author: Yi Zhang Date: Thu Aug 20 23:36:46 2020 +0800 RDMA/rxe: Fix the parent sysfs read when the interface has 15 chars commit 60b1af64eb35074a4f2d41cc1e503a7671e68963 upstream. 'parent' sysfs reads will yield '\0' bytes when the interface name has 15 chars, and there will no "\n" output. To reproduce, create one interface with 15 chars: [root@test ~]# ip a s enp0s29u1u7u3c2 2: enp0s29u1u7u3c2: mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000 link/ether 02:21:28:57:47:17 brd ff:ff:ff:ff:ff:ff inet6 fe80::ac41:338f:5bcd:c222/64 scope link noprefixroute valid_lft forever preferred_lft forever [root@test ~]# modprobe rdma_rxe [root@test ~]# echo enp0s29u1u7u3c2 > /sys/module/rdma_rxe/parameters/add [root@test ~]# cat /sys/class/infiniband/rxe0/parent enp0s29u1u7u3c2[root@test ~]# [root@test ~]# f="/sys/class/infiniband/rxe0/parent" [root@test ~]# echo "$(<"$f")" -bash: warning: command substitution: ignored null byte in input enp0s29u1u7u3c2 Use scnprintf and PAGE_SIZE to fill the sysfs output buffer. Cc: stable@vger.kernel.org Fixes: 8700e3e7c485 ("Soft RoCE driver") Link: https://lore.kernel.org/r/20200820153646.31316-1-yi.zhang@redhat.com Suggested-by: Jason Gunthorpe Signed-off-by: Yi Zhang Reviewed-by: Bart Van Assche Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit ea3d3bf85669195247ad6a522f4e4209695edca2 Author: Ilya Dryomov Date: Thu Sep 3 13:24:11 2020 +0200 rbd: require global CAP_SYS_ADMIN for mapping and unmapping commit f44d04e696feaf13d192d942c4f14ad2e117065a upstream. It turns out that currently we rely only on sysfs attribute permissions: $ ll /sys/bus/rbd/{add*,remove*} --w------- 1 root root 4096 Sep 3 20:37 /sys/bus/rbd/add --w------- 1 root root 4096 Sep 3 20:37 /sys/bus/rbd/add_single_major --w------- 1 root root 4096 Sep 3 20:37 /sys/bus/rbd/remove --w------- 1 root root 4096 Sep 3 20:38 /sys/bus/rbd/remove_single_major This means that images can be mapped and unmapped (i.e. block devices can be created and deleted) by a UID 0 process even after it drops all privileges or by any process with CAP_DAC_OVERRIDE in its user namespace as long as UID 0 is mapped into that user namespace. Be consistent with other virtual block devices (loop, nbd, dm, md, etc) and require CAP_SYS_ADMIN in the initial user namespace for mapping and unmapping, and also for dumping the configuration string and refreshing the image header. Cc: stable@vger.kernel.org Signed-off-by: Ilya Dryomov Reviewed-by: Jeff Layton Signed-off-by: Greg Kroah-Hartman commit c2fb443bde82c4f6b2390856339bae152a0c0641 Author: Chris Packham Date: Thu Sep 3 13:20:29 2020 +1200 mmc: sdhci-of-esdhc: Don't walk device-tree on every interrupt commit 060522d89705f9d961ef1762dc1468645dd21fbd upstream. Commit b214fe592ab7 ("mmc: sdhci-of-esdhc: add erratum eSDHC7 support") added code to check for a specific compatible string in the device-tree on every esdhc interrupat. Instead of doing this record the quirk in struct sdhci_esdhc and lookup the struct in esdhc_irq. Signed-off-by: Chris Packham Link: https://lore.kernel.org/r/20200903012029.25673-1-chris.packham@alliedtelesis.co.nz Fixes: b214fe592ab7 ("mmc: sdhci-of-esdhc: add erratum eSDHC7 support") Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit c724eb78c1ec61fd579bb62837a7e6f34d60087a Author: Adrian Hunter Date: Thu Sep 3 11:20:07 2020 +0300 mmc: sdio: Use mmc_pre_req() / mmc_post_req() commit f0c393e2104e48c8a881719a8bd37996f71b0aee upstream. SDHCI changed from using a tasklet to finish requests, to using an IRQ thread i.e. commit c07a48c2651965 ("mmc: sdhci: Remove finish_tasklet"). Because this increased the latency to complete requests, a preparatory change was made to complete the request from the IRQ handler if possible i.e. commit 19d2f695f4e827 ("mmc: sdhci: Call mmc_request_done() from IRQ handler if possible"). That alleviated the situation for MMC block devices because the MMC block driver makes use of mmc_pre_req() and mmc_post_req() so that successful requests are completed in the IRQ handler and any DMA unmapping is handled separately in mmc_post_req(). However SDIO was still affected, and an example has been reported with up to 20% degradation in performance. Looking at SDIO I/O helper functions, sdio_io_rw_ext_helper() appeared to be a possible candidate for making use of asynchronous requests within its I/O loops, but analysis revealed that these loops almost never iterate more than once, so the complexity of the change would not be warrented. Instead, mmc_pre_req() and mmc_post_req() are added before and after I/O submission (mmc_wait_for_req) in mmc_io_rw_extended(). This still has the potential benefit of reducing the duration of interrupt handlers, as well as addressing the latency issue for SDHCI. It also seems a more reasonable solution than forcing drivers to do everything in the IRQ handler. Reported-by: Dmitry Osipenko Fixes: c07a48c2651965 ("mmc: sdhci: Remove finish_tasklet") Signed-off-by: Adrian Hunter Tested-by: Dmitry Osipenko Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200903082007.18715-1-adrian.hunter@intel.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit becb3bbb29115d459c7f109c3b4f2d0129bb1443 Author: Jordan Crouse Date: Thu Sep 3 20:03:12 2020 -0600 drm/msm: Disable preemption on all 5xx targets commit 7b3f3948c8b7053d771acc9f79810cc410f5e2e0 upstream. Temporarily disable preemption on a5xx targets pending some improvements to protect the RPTR shadow from being corrupted. Cc: stable@vger.kernel.org Signed-off-by: Jordan Crouse Signed-off-by: Rob Clark Signed-off-by: Greg Kroah-Hartman commit 404ab35baae47b058a09530c962c4f02d78eab47 Author: Linus Walleij Date: Thu Aug 20 22:31:44 2020 +0200 drm/tve200: Stabilize enable/disable commit f71800228dc74711c3df43854ce7089562a3bc2d upstream. The TVE200 will occasionally print a bunch of lost interrupts and similar dmesg messages, sometimes during boot and sometimes after disabling and coming back to enablement. This is probably because the hardware is left in an unknown state by the boot loader that displays a logo. This can be fixed by bringing the controller into a known state by resetting the controller while enabling it. We retry reset 5 times like the vendor driver does. We also put the controller into reset before de-clocking it and clear all interrupts before enabling the vblank IRQ. This makes the video enable/disable/enable cycle rock solid on the D-Link DIR-685. Tested extensively. Signed-off-by: Linus Walleij Acked-by: Daniel Vetter Cc: stable@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20200820203144.271081-1-linus.walleij@linaro.org Signed-off-by: Greg Kroah-Hartman commit 701b385f68774ce1dff25d7f20085a95ac4022cf Author: Yan Zhao Date: Wed Mar 18 13:48:26 2020 +0800 drm/i915/gvt: do not check len & max_len for lri commit dbafc67307ec06036b25b223a251af03fe07969a upstream. lri ususally of variable len and far exceeding 127 dwords. Fixes: 00a33be40634 ("drm/i915/gvt: Add valid length check for MI variable commands") Signed-off-by: Yan Zhao Acked-by: Zhenyu Wang Signed-off-by: Zhenyu Wang Link: http://patchwork.freedesktop.org/patch/msgid/20200304095121.21609-1-yan.y.zhao@intel.com Signed-off-by: Greg Kroah-Hartman commit a5bfcf2455d4249ded2de62480f59ccc1382d81a Author: Hou Pu Date: Wed Jul 29 09:03:43 2020 -0400 scsi: target: iscsi: Fix hang in iscsit_access_np() when getting tpg->np_login_sem commit ed43ffea78dcc97db3f561da834f1a49c8961e33 upstream. The iSCSI target login thread might get stuck with the following stack: cat /proc/`pidof iscsi_np`/stack [<0>] down_interruptible+0x42/0x50 [<0>] iscsit_access_np+0xe3/0x167 [<0>] iscsi_target_locate_portal+0x695/0x8ac [<0>] __iscsi_target_login_thread+0x855/0xb82 [<0>] iscsi_target_login_thread+0x2f/0x5a [<0>] kthread+0xfa/0x130 [<0>] ret_from_fork+0x1f/0x30 This can be reproduced via the following steps: 1. Initiator A tries to log in to iqn1-tpg1 on port 3260. After finishing PDU exchange in the login thread and before the negotiation is finished the the network link goes down. At this point A has not finished login and tpg->np_login_sem is held. 2. Initiator B tries to log in to iqn2-tpg1 on port 3260. After finishing PDU exchange in the login thread the target expects to process remaining login PDUs in workqueue context. 3. Initiator A' tries to log in to iqn1-tpg1 on port 3260 from a new socket. A' will wait for tpg->np_login_sem with np->np_login_timer loaded to wait for at most 15 seconds. The lock is held by A so A' eventually times out. 4. Before A' got timeout initiator B gets negotiation failed and calls iscsi_target_login_drop()->iscsi_target_login_sess_out(). The np->np_login_timer is canceled and initiator A' will hang forever. Because A' is now in the login thread, no new login requests can be serviced. Fix this by moving iscsi_stop_login_thread_timer() out of iscsi_target_login_sess_out(). Also remove iscsi_np parameter from iscsi_target_login_sess_out(). Link: https://lore.kernel.org/r/20200729130343.24976-1-houpu@bytedance.com Cc: stable@vger.kernel.org Reviewed-by: Mike Christie Signed-off-by: Hou Pu Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit fa4372668f581b687294c5a83851353070addcbc Author: Varun Prakash Date: Tue Aug 25 18:05:10 2020 +0530 scsi: target: iscsi: Fix data digest calculation commit 5528d03183fe5243416c706f64b1faa518b05130 upstream. Current code does not consider 'page_off' in data digest calculation. To fix this, add a local variable 'first_sg' and set first_sg.offset to sg->offset + page_off. Link: https://lore.kernel.org/r/1598358910-3052-1-git-send-email-varun@chelsio.com Fixes: e48354ce078c ("iscsi-target: Add iSCSI fabric support for target v4.1") Cc: Reviewed-by: Mike Christie Signed-off-by: Varun Prakash Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit a467624aef02df2a8d7d6dc7b0b3625c8133b6b0 Author: Dmitry Osipenko Date: Mon Aug 31 23:43:35 2020 +0300 regulator: core: Fix slab-out-of-bounds in regulator_unlock_recursive() commit 0a7416f94707c60b9f66b01c0a505b7e41375f3a upstream. The recent commit 7d8196641ee1 ("regulator: Remove pointer table overallocation") changed the size of coupled_rdevs and now KASAN is able to detect slab-out-of-bounds problem in regulator_unlock_recursive(), which is a legit problem caused by a typo in the code. The recursive unlock function uses n_coupled value of a parent regulator for unlocking supply regulator, while supply's n_coupled should be used. In practice problem may only affect platforms that use coupled regulators. Cc: stable@vger.kernel.org # 5.0+ Fixes: f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking") Signed-off-by: Dmitry Osipenko Link: https://lore.kernel.org/r/20200831204335.19489-1-digetx@gmail.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit dfbb9cea5a4b07f6a5445d2f821041aae50b7632 Author: Michał Mirosław Date: Wed Aug 12 03:31:36 2020 +0200 regulator: plug of_node leak in regulator_register()'s error path commit d3c731564e09b6c2ebefcd1344743a91a237d6dc upstream. By calling device_initialize() earlier and noting that kfree(NULL) is ok, we can save a bit of code in error handling and plug of_node leak. Fixed commit already did part of the work. Fixes: 9177514ce349 ("regulator: fix memory leak on error path of regulator_register()") Signed-off-by: Michał Mirosław Reviewed-by: Vladimir Zapolskiy Acked-by: Vladimir Zapolskiy Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/f5035b1b4d40745e66bacd571bbbb5e4644d21a1.1597195321.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 047a71ff5e9d96ec23cfa1b4cab67e512e0edc37 Author: Michał Mirosław Date: Wed Aug 12 03:31:36 2020 +0200 regulator: push allocation in set_consumer_device_supply() out of lock commit 5c06540165d443c6455123eb48e7f1a9b618ab34 upstream. Pull regulator_list_mutex into set_consumer_device_supply() and keep allocations outside of it. Fourth of the fs_reclaim deadlock case. Fixes: 45389c47526d ("regulator: core: Add early supply resolution for regulators") Signed-off-by: Michał Mirosław Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/f0380bdb3d60aeefa9693c4e234d2dcda7e56747.1597195321.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 31d89652c38443f27e386b78a4eb46aed0ccd1c7 Author: Michał Mirosław Date: Wed Aug 12 03:31:35 2020 +0200 regulator: push allocations in create_regulator() outside of lock commit 87fe29b61f9522a3d7b60a4580851f548558186f upstream. Move all allocations outside of the regulator_lock()ed section. ====================================================== WARNING: possible circular locking dependency detected 5.7.13+ #535 Not tainted ------------------------------------------------------ f2fs_discard-179:7/702 is trying to acquire lock: c0e5d920 (regulator_list_mutex){+.+.}-{3:3}, at: regulator_lock_dependent+0x54/0x2c0 but task is already holding lock: cb95b080 (&dcc->cmd_lock){+.+.}-{3:3}, at: __issue_discard_cmd+0xec/0x5f8 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: [...] -> #3 (fs_reclaim){+.+.}-{0:0}: fs_reclaim_acquire.part.11+0x40/0x50 fs_reclaim_acquire+0x24/0x28 __kmalloc_track_caller+0x54/0x218 kstrdup+0x40/0x5c create_regulator+0xf4/0x368 regulator_resolve_supply+0x1a0/0x200 regulator_register+0x9c8/0x163c [...] other info that might help us debug this: Chain exists of: regulator_list_mutex --> &sit_i->sentry_lock --> &dcc->cmd_lock [...] Fixes: f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking") Signed-off-by: Michał Mirosław Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/6eebc99b2474f4ffaa0405b15178ece0e7e4f608.1597195321.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit e7249ceb7ff83d19e1d13df397e67ae228d5b1e8 Author: Michał Mirosław Date: Wed Aug 12 03:31:34 2020 +0200 regulator: push allocation in regulator_init_coupling() outside of lock commit 73a32129f8ccb556704a26b422f54e048bf14bd0 upstream. Allocating memory with regulator_list_mutex held makes lockdep unhappy when memory pressure makes the system do fs_reclaim on eg. eMMC using a regulator. Push the lock inside regulator_init_coupling() after the allocation. ====================================================== WARNING: possible circular locking dependency detected 5.7.13+ #533 Not tainted ------------------------------------------------------ kswapd0/383 is trying to acquire lock: cca78ca4 (&sbi->write_io[i][j].io_rwsem){++++}-{3:3}, at: __submit_merged_write_cond+0x104/0x154 but task is already holding lock: c0e38518 (fs_reclaim){+.+.}-{0:0}, at: __fs_reclaim_acquire+0x0/0x50 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (fs_reclaim){+.+.}-{0:0}: fs_reclaim_acquire.part.11+0x40/0x50 fs_reclaim_acquire+0x24/0x28 __kmalloc+0x54/0x218 regulator_register+0x860/0x1584 dummy_regulator_probe+0x60/0xa8 [...] other info that might help us debug this: Chain exists of: &sbi->write_io[i][j].io_rwsem --> regulator_list_mutex --> fs_reclaim Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(fs_reclaim); lock(regulator_list_mutex); lock(fs_reclaim); lock(&sbi->write_io[i][j].io_rwsem); *** DEADLOCK *** 1 lock held by kswapd0/383: #0: c0e38518 (fs_reclaim){+.+.}-{0:0}, at: __fs_reclaim_acquire+0x0/0x50 [...] Fixes: d8ca7d184b33 ("regulator: core: Introduce API for regulators coupling customization") Signed-off-by: Michał Mirosław Reviewed-by: Dmitry Osipenko Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/1a889cf7f61c6429c9e6b34ddcdde99be77a26b6.1597195321.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit b9fb631f6b03ececf753df24de3c4ab0ced169be Author: Andy Shevchenko Date: Mon Aug 3 11:27:06 2020 +0300 kobject: Restore old behaviour of kobject_del(NULL) commit 40b8b826a6998639dd1c26f0e127f18371e1058d upstream. The commit 079ad2fb4bf9 ("kobject: Avoid premature parent object freeing in kobject_cleanup()") inadvertently dropped a possibility to call kobject_del() with NULL pointer. Restore the old behaviour. Fixes: 079ad2fb4bf9 ("kobject: Avoid premature parent object freeing in kobject_cleanup()") Cc: stable Reported-by: Qu Wenruo Cc: Heikki Krogerus Signed-off-by: Andy Shevchenko Reviewed-by: Qu Wenruo Link: https://lore.kernel.org/r/20200803082706.65347-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit b85c64a7161fa7f42f0be39ffbd2022eee435cae Author: Filipe Manana Date: Mon Sep 14 09:01:04 2020 +0100 btrfs: fix wrong address when faulting in pages in the search ioctl commit 1c78544eaa4660096aeb6a57ec82b42cdb3bfe5a upstream. When faulting in the pages for the user supplied buffer for the search ioctl, we are passing only the base address of the buffer to the function fault_in_pages_writeable(). This means that after the first iteration of the while loop that searches for leaves, when we have a non-zero offset, stored in 'sk_offset', we try to fault in a wrong page range. So fix this by adding the offset in 'sk_offset' to the base address of the user supplied buffer when calling fault_in_pages_writeable(). Several users have reported that the applications compsize and bees have started to operate incorrectly since commit a48b73eca4ceb9 ("btrfs: fix potential deadlock in the search ioctl") was added to stable trees, and these applications make heavy use of the search ioctls. This fixes their issues. Link: https://lore.kernel.org/linux-btrfs/632b888d-a3c3-b085-cdf5-f9bb61017d92@lechevalier.se/ Link: https://github.com/kilobyte/compsize/issues/34 Fixes: a48b73eca4ceb9 ("btrfs: fix potential deadlock in the search ioctl") CC: stable@vger.kernel.org # 4.4+ Tested-by: A L Reviewed-by: Josef Bacik Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 524f3f303079b129622455d32fa778bcf247fbb7 Author: Josef Bacik Date: Mon Aug 31 10:52:42 2020 -0400 btrfs: fix lockdep splat in add_missing_dev commit fccc0007b8dc952c6bc0805cdf842eb8ea06a639 upstream. Nikolay reported a lockdep splat in generic/476 that I could reproduce with btrfs/187. ====================================================== WARNING: possible circular locking dependency detected 5.9.0-rc2+ #1 Tainted: G W ------------------------------------------------------ kswapd0/100 is trying to acquire lock: ffff9e8ef38b6268 (&delayed_node->mutex){+.+.}-{3:3}, at: __btrfs_release_delayed_node.part.0+0x3f/0x330 but task is already holding lock: ffffffffa9d74700 (fs_reclaim){+.+.}-{0:0}, at: __fs_reclaim_acquire+0x5/0x30 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (fs_reclaim){+.+.}-{0:0}: fs_reclaim_acquire+0x65/0x80 slab_pre_alloc_hook.constprop.0+0x20/0x200 kmem_cache_alloc_trace+0x3a/0x1a0 btrfs_alloc_device+0x43/0x210 add_missing_dev+0x20/0x90 read_one_chunk+0x301/0x430 btrfs_read_sys_array+0x17b/0x1b0 open_ctree+0xa62/0x1896 btrfs_mount_root.cold+0x12/0xea legacy_get_tree+0x30/0x50 vfs_get_tree+0x28/0xc0 vfs_kern_mount.part.0+0x71/0xb0 btrfs_mount+0x10d/0x379 legacy_get_tree+0x30/0x50 vfs_get_tree+0x28/0xc0 path_mount+0x434/0xc00 __x64_sys_mount+0xe3/0x120 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 -> #1 (&fs_info->chunk_mutex){+.+.}-{3:3}: __mutex_lock+0x7e/0x7e0 btrfs_chunk_alloc+0x125/0x3a0 find_free_extent+0xdf6/0x1210 btrfs_reserve_extent+0xb3/0x1b0 btrfs_alloc_tree_block+0xb0/0x310 alloc_tree_block_no_bg_flush+0x4a/0x60 __btrfs_cow_block+0x11a/0x530 btrfs_cow_block+0x104/0x220 btrfs_search_slot+0x52e/0x9d0 btrfs_lookup_inode+0x2a/0x8f __btrfs_update_delayed_inode+0x80/0x240 btrfs_commit_inode_delayed_inode+0x119/0x120 btrfs_evict_inode+0x357/0x500 evict+0xcf/0x1f0 vfs_rmdir.part.0+0x149/0x160 do_rmdir+0x136/0x1a0 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 -> #0 (&delayed_node->mutex){+.+.}-{3:3}: __lock_acquire+0x1184/0x1fa0 lock_acquire+0xa4/0x3d0 __mutex_lock+0x7e/0x7e0 __btrfs_release_delayed_node.part.0+0x3f/0x330 btrfs_evict_inode+0x24c/0x500 evict+0xcf/0x1f0 dispose_list+0x48/0x70 prune_icache_sb+0x44/0x50 super_cache_scan+0x161/0x1e0 do_shrink_slab+0x178/0x3c0 shrink_slab+0x17c/0x290 shrink_node+0x2b2/0x6d0 balance_pgdat+0x30a/0x670 kswapd+0x213/0x4c0 kthread+0x138/0x160 ret_from_fork+0x1f/0x30 other info that might help us debug this: Chain exists of: &delayed_node->mutex --> &fs_info->chunk_mutex --> fs_reclaim Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(fs_reclaim); lock(&fs_info->chunk_mutex); lock(fs_reclaim); lock(&delayed_node->mutex); *** DEADLOCK *** 3 locks held by kswapd0/100: #0: ffffffffa9d74700 (fs_reclaim){+.+.}-{0:0}, at: __fs_reclaim_acquire+0x5/0x30 #1: ffffffffa9d65c50 (shrinker_rwsem){++++}-{3:3}, at: shrink_slab+0x115/0x290 #2: ffff9e8e9da260e0 (&type->s_umount_key#48){++++}-{3:3}, at: super_cache_scan+0x38/0x1e0 stack backtrace: CPU: 1 PID: 100 Comm: kswapd0 Tainted: G W 5.9.0-rc2+ #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014 Call Trace: dump_stack+0x92/0xc8 check_noncircular+0x12d/0x150 __lock_acquire+0x1184/0x1fa0 lock_acquire+0xa4/0x3d0 ? __btrfs_release_delayed_node.part.0+0x3f/0x330 __mutex_lock+0x7e/0x7e0 ? __btrfs_release_delayed_node.part.0+0x3f/0x330 ? __btrfs_release_delayed_node.part.0+0x3f/0x330 ? lock_acquire+0xa4/0x3d0 ? btrfs_evict_inode+0x11e/0x500 ? find_held_lock+0x2b/0x80 __btrfs_release_delayed_node.part.0+0x3f/0x330 btrfs_evict_inode+0x24c/0x500 evict+0xcf/0x1f0 dispose_list+0x48/0x70 prune_icache_sb+0x44/0x50 super_cache_scan+0x161/0x1e0 do_shrink_slab+0x178/0x3c0 shrink_slab+0x17c/0x290 shrink_node+0x2b2/0x6d0 balance_pgdat+0x30a/0x670 kswapd+0x213/0x4c0 ? _raw_spin_unlock_irqrestore+0x46/0x60 ? add_wait_queue_exclusive+0x70/0x70 ? balance_pgdat+0x670/0x670 kthread+0x138/0x160 ? kthread_create_worker_on_cpu+0x40/0x40 ret_from_fork+0x1f/0x30 This is because we are holding the chunk_mutex when we call btrfs_alloc_device, which does a GFP_KERNEL allocation. We don't want to switch that to a GFP_NOFS lock because this is the only place where it matters. So instead use memalloc_nofs_save() around the allocation in order to avoid the lockdep splat. Reported-by: Nikolay Borisov CC: stable@vger.kernel.org # 4.4+ Reviewed-by: Anand Jain Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 1aaceffa5ace02d120ce2b62549ec3fa38634dc2 Author: Qu Wenruo Date: Wed Aug 26 17:26:43 2020 +0800 btrfs: require only sector size alignment for parent eb bytenr commit ea57788eb76dc81f6003245427356a1dcd0ac524 upstream. [BUG] A completely sane converted fs will cause kernel warning at balance time: [ 1557.188633] BTRFS info (device sda7): relocating block group 8162107392 flags data [ 1563.358078] BTRFS info (device sda7): found 11722 extents [ 1563.358277] BTRFS info (device sda7): leaf 7989321728 gen 95 total ptrs 213 free space 3458 owner 2 [ 1563.358280] item 0 key (7984947200 169 0) itemoff 16250 itemsize 33 [ 1563.358281] extent refs 1 gen 90 flags 2 [ 1563.358282] ref#0: tree block backref root 4 [ 1563.358285] item 1 key (7985602560 169 0) itemoff 16217 itemsize 33 [ 1563.358286] extent refs 1 gen 93 flags 258 [ 1563.358287] ref#0: shared block backref parent 7985602560 [ 1563.358288] (parent 7985602560 is NOT ALIGNED to nodesize 16384) [ 1563.358290] item 2 key (7985635328 169 0) itemoff 16184 itemsize 33 ... [ 1563.358995] BTRFS error (device sda7): eb 7989321728 invalid extent inline ref type 182 [ 1563.358996] ------------[ cut here ]------------ [ 1563.359005] WARNING: CPU: 14 PID: 2930 at 0xffffffff9f231766 Then with transaction abort, and obviously failed to balance the fs. [CAUSE] That mentioned inline ref type 182 is completely sane, it's BTRFS_SHARED_BLOCK_REF_KEY, it's some extra check making kernel to believe it's invalid. Commit 64ecdb647ddb ("Btrfs: add one more sanity check for shared ref type") introduced extra checks for backref type. One of the requirement is, parent bytenr must be aligned to node size, which is not correct. One example is like this: 0 1G 1G+4K 2G 2G+4K | |///////////////////|//| <- A chunk starts at 1G+4K | | <- A tree block get reserved at bytenr 1G+4K Then we have a valid tree block at bytenr 1G+4K, but not aligned to nodesize (16K). Such chunk is not ideal, but current kernel can handle it pretty well. We may warn about such tree block in the future, but should not reject them. [FIX] Change the alignment requirement from node size alignment to sector size alignment. Also, to make our lives a little easier, also output @iref when btrfs_get_extent_inline_ref_type() failed, so we can locate the item easier. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=205475 Fixes: 64ecdb647ddb ("Btrfs: add one more sanity check for shared ref type") CC: stable@vger.kernel.org # 4.14+ Reviewed-by: Josef Bacik Signed-off-by: Qu Wenruo [ update comments and messages ] Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit c570a3d660a2c5a21d2f3b1212bee0d33b03b215 Author: Rustam Kovhaev Date: Tue Aug 4 07:56:14 2020 -0700 staging: wlan-ng: fix out of bounds read in prism2sta_probe_usb() commit fea22e159d51c766ba70473f473a0ec914cc7e92 upstream. let's use usb_find_common_endpoints() to discover endpoints, it does all necessary checks for type and xfer direction remove memset() in hfa384x_create(), because we now assign endpoints in prism2sta_probe_usb() and because create_wlan() uses kzalloc() to allocate hfa384x struct before calling hfa384x_create() Fixes: faaff9765664 ("staging: wlan-ng: properly check endpoint types") Reported-and-tested-by: syzbot+22794221ab96b0bab53a@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?extid=22794221ab96b0bab53a Signed-off-by: Rustam Kovhaev Cc: stable Link: https://lore.kernel.org/r/20200804145614.104320-1-rkovhaev@gmail.com Signed-off-by: Greg Kroah-Hartman commit e9f7332b00405bb81f3ad258f2c311e4d6e2734c Author: Jonathan Cameron Date: Wed Jul 22 16:50:38 2020 +0100 iio:accel:mma8452: Fix timestamp alignment and prevent data leak. commit 89226a296d816727405d3fea684ef69e7d388bd8 upstream. One of a class of bugs pointed out by Lars in a recent review. iio_push_to_buffers_with_timestamp assumes the buffer used is aligned to the size of the timestamp (8 bytes). This is not guaranteed in this driver which uses a 16 byte u8 array on the stack. As Lars also noted this anti pattern can involve a leak of data to userspace and that indeed can happen here. We close both issues by moving to a suitable structure in the iio_priv() data with alignment ensured by use of an explicit c structure. This data is allocated with kzalloc so no data can leak appart from previous readings. The additional forcing of the 8 byte alignment of the timestamp is not strictly necessary but makes the code less fragile by making this explicit. Fixes: c7eeea93ac60 ("iio: Add Freescale MMA8452Q 3-axis accelerometer driver") Reported-by: Lars-Peter Clausen Cc: Peter Meerwald Signed-off-by: Jonathan Cameron Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Greg Kroah-Hartman commit a6dc50f301295fe0af9abfb2a080be720153a083 Author: Jonathan Cameron Date: Wed Jul 22 16:50:40 2020 +0100 iio:accel:mma7455: Fix timestamp alignment and prevent data leak. commit 7e5ac1f2206eda414f90c698fe1820dee873394d upstream. One of a class of bugs pointed out by Lars in a recent review. iio_push_to_buffers_with_timestamp assumes the buffer used is aligned to the size of the timestamp (8 bytes). This is not guaranteed in this driver which uses a 16 byte u8 array on the stack As Lars also noted this anti pattern can involve a leak of data to userspace and that indeed can happen here. We close both issues by moving to a suitable structure in the iio_priv() data with alignment ensured by use of an explicit c structure. This data is allocated with kzalloc so no data can leak appart from previous readings. The force alignment of ts is not strictly necessary in this particularly case but does make the code less fragile. Fixes: a84ef0d181d9 ("iio: accel: add Freescale MMA7455L/MMA7456L 3-axis accelerometer driver") Reported-by: Lars-Peter Clausen Signed-off-by: Jonathan Cameron Cc: Reviewed-by: Andy Shevchenko Signed-off-by: Greg Kroah-Hartman commit e94ec7f512cf41c50de4ab68e7573c551129db6a Author: Jonathan Cameron Date: Wed Jul 22 16:50:37 2020 +0100 iio: accel: kxsd9: Fix alignment of local buffer. commit 95ad67577de4ea08eb8e441394e698aa4addcc0b upstream. iio_push_to_buffers_with_timestamp assumes 8 byte alignment which is not guaranteed by an array of smaller elements. Note that whilst in this particular case the alignment forcing of the ts element is not strictly necessary it acts as good documentation. Doing this where not necessary should cut down on the number of cut and paste introduced errors elsewhere. Fixes: 0427a106a98a ("iio: accel: kxsd9: Add triggered buffer handling") Reported-by: Lars-Peter Clausen Signed-off-by: Jonathan Cameron Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Greg Kroah-Hartman commit b040ac56b264d307f534e7009489c75f8e6a368b Author: Jonathan Cameron Date: Wed Jul 22 16:50:43 2020 +0100 iio:chemical:ccs811: Fix timestamp alignment and prevent data leak. commit eb1a148ef41d8ae8d9201efc3f1b145976290331 upstream. One of a class of bugs pointed out by Lars in a recent review. iio_push_to_buffers_with_timestamp assumes the buffer used is aligned to the size of the timestamp (8 bytes). This is not guaranteed in this driver which uses an array of smaller elements on the stack. As Lars also noted this anti pattern can involve a leak of data to userspace and that indeed can happen here. We close both issues by moving to a suitable structure in the iio_priv() data with alignment explicitly requested. This data is allocated with kzalloc so no data can leak appart from previous readings. The explicit alignment of ts is necessary to ensure consistent padding for x86_32 in which the ts would otherwise be 4 byte aligned. Fixes: 283d26917ad6 ("iio: chemical: ccs811: Add triggered buffer support") Reported-by: Lars-Peter Clausen Cc: Narcisa Ana Maria Vasile Signed-off-by: Jonathan Cameron Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Greg Kroah-Hartman commit cd1a2517b35e82578abe58578528ef6f1549665b Author: Jonathan Cameron Date: Wed Jul 22 16:50:45 2020 +0100 iio:light:max44000 Fix timestamp alignment and prevent data leak. commit 523628852a5f5f34a15252b2634d0498d3cfb347 upstream. One of a class of bugs pointed out by Lars in a recent review. iio_push_to_buffers_with_timestamp assumes the buffer used is aligned to the size of the timestamp (8 bytes). This is not guaranteed in this driver which uses a 16 byte array of smaller elements on the stack. As Lars also noted this anti pattern can involve a leak of data to userspace and that indeed can happen here. We close both issues by moving to a suitable structure in the iio_priv(). This data is allocated with kzalloc so no data can leak appart from previous readings. It is necessary to force the alignment of ts to avoid the padding on x86_32 being different from 64 bit platorms (it alows for 4 bytes aligned 8 byte types. Fixes: 06ad7ea10e2b ("max44000: Initial triggered buffer support") Reported-by: Lars-Peter Clausen Signed-off-by: Jonathan Cameron Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Greg Kroah-Hartman commit 176fb9423ab8e91ff4776483b81fcc56567f0347 Author: Jonathan Cameron Date: Wed Jul 22 16:50:49 2020 +0100 iio:magnetometer:ak8975 Fix alignment and data leak issues. commit 02ad21cefbac4d89ac443866f25b90449527737b upstream. One of a class of bugs pointed out by Lars in a recent review. iio_push_to_buffers_with_timestamp assumes the buffer used is aligned to the size of the timestamp (8 bytes). This is not guaranteed in this driver which uses an array of smaller elements on the stack. As Lars also noted this anti pattern can involve a leak of data to userspace and that indeed can happen here. We close both issues by moving to a suitable structure in the iio_priv() data. This data is allocated with kzalloc so no data can leak apart from previous readings. The explicit alignment of ts is not necessary in this case as by coincidence the padding will end up the same, however I consider it to make the code less fragile and have included it. Fixes: bc11ca4a0b84 ("iio:magnetometer:ak8975: triggered buffer support") Reported-by: Lars-Peter Clausen Cc: Gregor Boirie Cc: Linus Walleij Signed-off-by: Jonathan Cameron Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Greg Kroah-Hartman commit c4b67a1dcba0e43eb275df8bd7fa5366627bd5b0 Author: Jonathan Cameron Date: Wed Jul 22 16:50:56 2020 +0100 iio:adc:ti-adc081c Fix alignment and data leak issues commit 54f82df2ba86e2a8e9cbf4036d192366e3905c89 upstream. One of a class of bugs pointed out by Lars in a recent review. iio_push_to_buffers_with_timestamp assumes the buffer used is aligned to the size of the timestamp (8 bytes). This is not guaranteed in this driver which uses an array of smaller elements on the stack. As Lars also noted this anti pattern can involve a leak of data to userspace and that indeed can happen here. We close both issues by moving to a suitable structure in the iio_priv(). This data is allocated with kzalloc so no data can leak apart from previous readings. The eplicit alignment of ts is necessary to ensure correct padding on x86_32 where s64 is only aligned to 4 bytes. Fixes: 08e05d1fce5c ("ti-adc081c: Initial triggered buffer support") Reported-by: Lars-Peter Clausen Signed-off-by: Jonathan Cameron Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Greg Kroah-Hartman commit e691d264ddf9382029c81d3ccf3ce3280510cd88 Author: Jonathan Cameron Date: Wed Jul 22 16:51:03 2020 +0100 iio:adc:max1118 Fix alignment of timestamp and data leak issues commit db8f06d97ec284dc018e2e4890d2e5035fde8630 upstream. One of a class of bugs pointed out by Lars in a recent review. iio_push_to_buffers_with_timestamp assumes the buffer used is aligned to the size of the timestamp (8 bytes). This is not guaranteed in this driver which uses an array of smaller elements on the stack. As Lars also noted this anti pattern can involve a leak of data to userspace and that indeed can happen here. We close both issues by moving to a suitable structure in the iio_priv() data. This data is allocated with kzalloc so no data can leak apart from previous readings. The explicit alignment of ts is necessary to ensure correct padding on architectures where s64 is only 4 bytes aligned such as x86_32. Fixes: a9e9c7153e96 ("iio: adc: add max1117/max1118/max1119 ADC driver") Reported-by: Lars-Peter Clausen Cc: Akinobu Mita Signed-off-by: Jonathan Cameron Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Greg Kroah-Hartman commit 24c4430c9b187c05ff0fa33c1bad4dbc72d2fdd2 Author: Jonathan Cameron Date: Wed Jul 22 16:51:02 2020 +0100 iio:adc:ina2xx Fix timestamp alignment issue. commit f8cd222feb82ecd82dcf610fcc15186f55f9c2b5 upstream. One of a class of bugs pointed out by Lars in a recent review. iio_push_to_buffers_with_timestamp assumes the buffer used is aligned to the size of the timestamp (8 bytes). This is not guaranteed in this driver which uses a 32 byte array of smaller elements on the stack. As Lars also noted this anti pattern can involve a leak of data to userspace and that indeed can happen here. We close both issues by moving to a suitable structure in the iio_priv() data with alignment explicitly requested. This data is allocated with kzalloc so no data can leak apart from previous readings. The explicit alignment isn't technically needed here, but it reduced fragility and avoids cut and paste into drivers where it will be needed. If we want this in older stables will need manual backport due to driver reworks. Fixes: c43a102e67db ("iio: ina2xx: add support for TI INA2xx Power Monitors") Reported-by: Lars-Peter Clausen Cc: Stefan Brüns Cc: Marc Titinger Signed-off-by: Jonathan Cameron Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Greg Kroah-Hartman commit de2fa1f48a522a3fc536795a955c4f936f567bb0 Author: Jonathan Cameron Date: Wed Jul 22 16:50:57 2020 +0100 iio:adc:ti-adc084s021 Fix alignment and data leak issues. commit a661b571e3682705cb402a5cd1e970586a3ec00f upstream. One of a class of bugs pointed out by Lars in a recent review. iio_push_to_buffers_with_timestamp assumes the buffer used is aligned to the size of the timestamp (8 bytes). This is not guaranteed in this driver which uses an array of smaller elements on the stack. As Lars also noted this anti pattern can involve a leak of data to userspace and that indeed can happen here. We close both issues by moving to a suitable structure in the iio_priv(). This data is allocated with kzalloc so no data can leak apart from previous readings. The force alignment of ts is not strictly necessary in this case but reduces the fragility of the code. Fixes: 3691e5a69449 ("iio: adc: add driver for the ti-adc084s021 chip") Reported-by: Lars-Peter Clausen Cc: Mårten Lindahl Signed-off-by: Jonathan Cameron Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Greg Kroah-Hartman commit 13a76aae01c742f6746cc5b60167dc1c4338163d Author: Jonathan Cameron Date: Wed Jul 22 16:50:39 2020 +0100 iio:accel:bmc150-accel: Fix timestamp alignment and prevent data leak. commit a6f86f724394de3629da63fe5e1b7a4ab3396efe upstream. One of a class of bugs pointed out by Lars in a recent review. iio_push_to_buffers_with_timestamp assumes the buffer used is aligned to the size of the timestamp (8 bytes). This is not guaranteed in this driver which uses a 16 byte array of smaller elements on the stack. As Lars also noted this anti pattern can involve a leak of data to userspace and that indeed can happen here. We close both issues by moving to a suitable structure in the iio_priv() data with alignment ensured by use of an explicit c structure. This data is allocated with kzalloc so no data can leak appart from previous readings. Fixes tag is beyond some major refactoring so likely manual backporting would be needed to get that far back. Whilst the force alignment of the ts is not strictly necessary, it does make the code less fragile. Fixes: 3bbec9773389 ("iio: bmc150_accel: add support for hardware fifo") Reported-by: Lars-Peter Clausen Signed-off-by: Jonathan Cameron Acked-by: Srinivas Pandruvada Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Greg Kroah-Hartman commit 66b8b8f75e3541d002f3c16f5fabbfafd4552120 Author: Jonathan Cameron Date: Wed Jul 22 16:50:42 2020 +0100 iio:proximity:mb1232: Fix timestamp alignment and prevent data leak. commit f60e8bb84282b8e633956cfe74b4f0d64ca73cec upstream. One of a class of bugs pointed out by Lars in a recent review. iio_push_to_buffers_with_timestamp assumes the buffer used is aligned to the size of the timestamp (8 bytes). This is not guaranteed in this driver which uses a 16 byte s16 array on the stack As Lars also noted this anti pattern can involve a leak of data to userspace and that indeed can happen here. We close both issues by moving to a suitable structure in the iio_priv() data with alignment ensured by use of an explicit c structure. This data is allocated with kzalloc so no data can leak appart from previous readings. In this case the forced alignment of the ts is necessary to ensure correct padding on x86_32 where the s64 would only be 4 byte aligned. Fixes: 16b05261537e ("mb1232.c: add distance iio sensor with i2c") Reported-by: Lars-Peter Clausen Cc: Andreas Klinger Signed-off-by: Jonathan Cameron Cc: Reviewed-by: Andy Shevchenko Signed-off-by: Greg Kroah-Hartman commit 0616d908aef522884608fba3d14431a052ad87f4 Author: Jonathan Cameron Date: Wed Jul 22 16:50:48 2020 +0100 iio:light:ltr501 Fix timestamp alignment issue. commit 2684d5003490df5398aeafe2592ba9d4a4653998 upstream. One of a class of bugs pointed out by Lars in a recent review. iio_push_to_buffers_with_timestamp assumes the buffer used is aligned to the size of the timestamp (8 bytes). This is not guaranteed in this driver which uses an array of smaller elements on the stack. Here we use a structure on the stack. The driver already did an explicit memset so no data leak was possible. Forced alignment of ts is not strictly necessary but probably makes the code slightly less fragile. Note there has been some rework in this driver of the years, so no way this will apply cleanly all the way back. Fixes: 2690be905123 ("iio: Add Lite-On ltr501 ambient light / proximity sensor driver") Reported-by: Lars-Peter Clausen Signed-off-by: Jonathan Cameron Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Greg Kroah-Hartman commit c80210735f31f4030988ca304326024199d064c1 Author: Gwendal Grignou Date: Tue Jul 28 13:48:25 2020 -0700 iio: cros_ec: Set Gyroscope default frequency to 25Hz commit 336306790b2bbf7ce837625fa3b24ba724d05838 upstream. BMI160 Minimium gyroscope frequency in normal mode is 25Hz. When older EC firmware do not report their sensors frequencies, use 25Hz as the minimum for gyroscope to be sure it works on BMI160. Fixes: ae7b02ad2f32d ("iio: common: cros_ec_sensors: Expose cros_ec_sensors frequency range via iio sysfs") Signed-off-by: Gwendal Grignou Reviewed-by: Enric Balletbo i Serra Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit c71e70a85b4b91978b5b92c1918eba9871744d43 Author: Maxim Kochetkov Date: Mon Aug 3 08:04:05 2020 +0300 iio: adc: ti-ads1015: fix conversion when CONFIG_PM is not set commit e71e6dbe96ac80ac2aebe71a6a942e7bd60e7596 upstream. To stop conversion ads1015_set_power_state() function call unimplemented function __pm_runtime_suspend() from pm_runtime_put_autosuspend() if CONFIG_PM is not set. In case of CONFIG_PM is not set: __pm_runtime_suspend() returns -ENOSYS, so ads1015_read_raw() failed because ads1015_set_power_state() returns an error. If CONFIG_PM is disabled, there is no need to start/stop conversion. Fix it by adding return 0 function variant if CONFIG_PM is not set. Signed-off-by: Maxim Kochetkov Fixes: ecc24e72f437 ("iio: adc: Add TI ADS1015 ADC driver support") Tested-by: Maxim Kiselev Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit d4bdcf4f1154fbb4813f6147b0863bc9b2ab8881 Author: Leon Romanovsky Date: Fri Sep 4 18:58:08 2020 +0300 gcov: Disable gcov build with GCC 10 [ Upstream commit cfc905f158eaa099d6258031614d11869e7ef71c ] GCOV built with GCC 10 doesn't initialize n_function variable. This produces different kernel panics as was seen by Colin in Ubuntu and me in FC 32. As a workaround, let's disable GCOV build for broken GCC 10 version. Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1891288 Link: https://lore.kernel.org/lkml/20200827133932.3338519-1-leon@kernel.org Link: https://lore.kernel.org/lkml/CAHk-=whbijeSdSvx-Xcr0DPMj0BiwhJ+uiNnDSVZcr_h_kg7UA@mail.gmail.com/ Cc: Colin Ian King Signed-off-by: Leon Romanovsky Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 104bc6027b27ddde516167df7add650789b06968 Author: Joerg Roedel Date: Mon Aug 24 12:54:15 2020 +0200 iommu/amd: Do not use IOMMUv2 functionality when SME is active [ Upstream commit 2822e582501b65707089b097e773e6fd70774841 ] When memory encryption is active the device is likely not in a direct mapped domain. Forbid using IOMMUv2 functionality for now until finer grained checks for this have been implemented. Signed-off-by: Joerg Roedel Link: https://lore.kernel.org/r/20200824105415.21000-3-joro@8bytes.org Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit cab731c6c873aac2a478659c0880674b44a0e5cb Author: Sandeep Raghuraman Date: Thu Aug 27 18:43:37 2020 +0530 drm/amdgpu: Fix bug in reporting voltage for CIK [ Upstream commit d98299885c9ea140c1108545186593deba36c4ac ] On my R9 390, the voltage was reported as a constant 1000 mV. This was due to a bug in smu7_hwmgr.c, in the smu7_read_sensor() function, where some magic constants were used in a condition, to determine whether the voltage should be read from PLANE2_VID or PLANE1_VID. The VDDC mask was incorrectly used, instead of the VDDGFX mask. This patch changes the code to use the correct defined constants (and apply the correct bitshift), thus resulting in correct voltage reporting. Signed-off-by: Sandeep Raghuraman Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit d6ccea92b1e119d8ec0b47a8548e76b7ff2046f7 Author: Rander Wang Date: Wed Sep 2 18:42:18 2020 +0300 ALSA: hda: fix a runtime pm issue in SOF when integrated GPU is disabled [ Upstream commit 13774d81f38538c5fa2924bdcdfa509155480fa6 ] In snd_hdac_device_init pm_runtime_set_active is called to increase child_count in parent device. But when it is failed to build connection with GPU for one case that integrated graphic gpu is disabled, snd_hdac_ext_bus_device_exit will be invoked to clean up a HD-audio extended codec base device. At this time the child_count of parent is not decreased, which makes parent device can't get suspended. This patch calls pm_runtime_set_suspended to decrease child_count in parent device in snd_hdac_device_exit to match with snd_hdac_device_init. pm_runtime_set_suspended can make sure that it will not decrease child_count if the device is already suspended. Signed-off-by: Rander Wang Reviewed-by: Ranjani Sridharan Reviewed-by: Pierre-Louis Bossart Reviewed-by: Bard Liao Reviewed-by: Guennadi Liakhovetski Signed-off-by: Kai Vehmanen Link: https://lore.kernel.org/r/20200902154218.1440441-1-kai.vehmanen@linux.intel.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 56117aa693016b39e6928f1e0f3ecbaaaa4c2555 Author: Rander Wang Date: Wed Sep 2 18:42:07 2020 +0300 ALSA: hda: hdmi - add Rocketlake support [ Upstream commit f804a324a41a880c1ab43cc5145d8b3e5790430d ] Add Rocketlake HDMI codec support. Rocketlake shares the pin-to-port mapping table with Tigerlake. Signed-off-by: Rander Wang Reviewed-by: Pierre-Louis Bossart Reviewed-by: Ranjani Sridharan Signed-off-by: Kai Vehmanen Link: https://lore.kernel.org/r/20200902154207.1440393-1-kai.vehmanen@linux.intel.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit ff37a2636464e8c4fe320d281b6ad220f14eb46a Author: Jessica Yu Date: Tue Sep 1 18:00:16 2020 +0200 arm64/module: set trampoline section flags regardless of CONFIG_DYNAMIC_FTRACE [ Upstream commit e0328feda79d9681b3e3245e6e180295550c8ee9 ] In the arm64 module linker script, the section .text.ftrace_trampoline is specified unconditionally regardless of whether CONFIG_DYNAMIC_FTRACE is enabled (this is simply due to the limitation that module linker scripts are not preprocessed like the vmlinux one). Normally, for .plt and .text.ftrace_trampoline, the section flags present in the module binary wouldn't matter since module_frob_arch_sections() would assign them manually anyway. However, the arm64 module loader only sets the section flags for .text.ftrace_trampoline when CONFIG_DYNAMIC_FTRACE=y. That's only become problematic recently due to a recent change in binutils-2.35, where the .text.ftrace_trampoline section (along with the .plt section) is now marked writable and executable (WAX). We no longer allow writable and executable sections to be loaded due to commit 5c3a7db0c7ec ("module: Harden STRICT_MODULE_RWX"), so this is causing all modules linked with binutils-2.35 to be rejected under arm64. Drop the IS_ENABLED(CONFIG_DYNAMIC_FTRACE) check in module_frob_arch_sections() so that the section flags for .text.ftrace_trampoline get properly set to SHF_EXECINSTR|SHF_ALLOC, without SHF_WRITE. Signed-off-by: Jessica Yu Acked-by: Will Deacon Acked-by: Ard Biesheuvel Link: http://lore.kernel.org/r/20200831094651.GA16385@linux-8ccs Link: https://lore.kernel.org/r/20200901160016.3646-1-jeyu@kernel.org Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 2423f3a7ef524d04952ddf85affb3f6264a7a6bb Author: Francisco Jerez Date: Mon Aug 31 20:02:50 2020 -0700 cpufreq: intel_pstate: Fix intel_pstate_get_hwp_max() for turbo disabled [ Upstream commit eacc9c5a927e474c173a5d53dd7fb8e306511768 ] This fixes the behavior of the scaling_max_freq and scaling_min_freq sysfs files in systems which had turbo disabled by the BIOS. Caleb noticed that the HWP is programmed to operate in the wrong P-state range on his system when the CPUFREQ policy min/max frequency is set via sysfs. This seems to be because in his system intel_pstate_get_hwp_max() is returning the maximum turbo P-state even though turbo was disabled by the BIOS, which causes intel_pstate to scale kHz frequencies incorrectly e.g. setting the maximum turbo frequency whenever the maximum guaranteed frequency is requested via sysfs. Tested-by: Caleb Callaway Signed-off-by: Francisco Jerez Acked-by: Srinivas Pandruvada [ rjw: Minor subject edits ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 1f1169474803f46fe797eb5c3807c69575db5454 Author: Rafael J. Wysocki Date: Thu Aug 20 17:40:02 2020 +0200 cpufreq: intel_pstate: Refuse to turn off with HWP enabled [ Upstream commit 43298db3009f06fe5c69e1ca8b6cfc2565772fa1 ] After commit f6ebbcf08f37 ("cpufreq: intel_pstate: Implement passive mode with HWP enabled") it is possible to change the driver status to "off" via sysfs with HWP enabled, which effectively causes the driver to unregister itself, but HWP remains active and it forces the minimum performance, so even if another cpufreq driver is loaded, it will not be able to control the CPU frequency. For this reason, make the driver refuse to change the status to "off" with HWP enabled. Signed-off-by: Rafael J. Wysocki Acked-by: Srinivas Pandruvada Signed-off-by: Sasha Levin commit b011e41a8e48d3618332ae81e46581cf39a86142 Author: Evgeniy Didin Date: Tue Jul 7 18:38:58 2020 +0300 ARC: [plat-hsdk]: Switch ethernet phy-mode to rgmii-id [ Upstream commit 26907eb605fbc3ba9dbf888f21d9d8d04471271d ] HSDK board has Micrel KSZ9031, recent commit bcf3440c6dd ("net: phy: micrel: add phy-mode support for the KSZ9031 PHY") caused a breakdown of Ethernet. Using 'phy-mode = "rgmii"' is not correct because accodring RGMII specification it is necessary to have delay on RX (PHY to MAX) which is not generated in case of "rgmii". Using "rgmii-id" adds necessary delay and solves the issue. Also adding name of PHY placed on HSDK board. Signed-off-by: Evgeniy Didin Cc: Eugeniy Paltsev Cc: Alexey Brodkin Signed-off-by: Vineet Gupta Signed-off-by: Sasha Levin commit 82d4cfa185a93456c5c279b79f80af4f1319854c Author: Dinghao Liu Date: Mon Aug 31 17:06:43 2020 +0800 HID: elan: Fix memleak in elan_input_configured [ Upstream commit b7429ea53d6c0936a0f10a5d64164f0aea440143 ] When input_mt_init_slots() fails, input should be freed to prevent memleak. When input_register_device() fails, we should call input_mt_destroy_slots() to free memory allocated by input_mt_init_slots(). Signed-off-by: Dinghao Liu Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit bc818ce2d51ec9bc04a7a4bb8a07cd0893e85cfb Author: Xie He Date: Fri Aug 28 00:07:52 2020 -0700 drivers/net/wan/hdlc_cisco: Add hard_header_len [ Upstream commit 1a545ebe380bf4c1433e3c136e35a77764fda5ad ] This driver didn't set hard_header_len. This patch sets hard_header_len for it according to its header_ops->create function. This driver's header_ops->create function (cisco_hard_header) creates a header of (struct hdlc_header), so hard_header_len should be set to sizeof(struct hdlc_header). Cc: Martin Schiller Signed-off-by: Xie He Acked-by: Krzysztof Halasa Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 052750976d035d279d3d0bbf4ba6b4d7a444dd56 Author: Nicholas Miell Date: Fri Aug 28 21:14:29 2020 -0700 HID: microsoft: Add rumble support for the 8bitdo SN30 Pro+ controller [ Upstream commit 724a419ea28f7514a391e80040230f69cf626707 ] When operating in XInput mode, the 8bitdo SN30 Pro+ requires the same quirk as the official Xbox One Bluetooth controllers for rumble to function. Other controllers like the N30 Pro 2, SF30 Pro, SN30 Pro, etc. probably also need this quirk, but I do not have the hardware to test. Signed-off-by: Nicholas Miell Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 52fa4a63ab146d7aba2c086db0b4c372295fad8e Author: Nirenjan Krishnan Date: Sun Aug 30 17:48:59 2020 -0700 HID: quirks: Set INCREMENT_USAGE_ON_DUPLICATE for all Saitek X52 devices [ Upstream commit 77df710ba633dfb6c65c65cf99ea9e084a1c9933 ] The Saitek X52 family of joysticks has a pair of axes that were originally (by the Windows driver) used as mouse pointer controls. The corresponding usage page is the Game Controls page, which is not recognized by the generic HID driver, and therefore, both axes get mapped to ABS_MISC. The quirk makes the second axis get mapped to ABS_MISC+1, and therefore made available separately. One Saitek X52 device is already fixed. This patch fixes the other two known devices with VID/PID 06a3:0255 and 06a3:0762. Signed-off-by: Nirenjan Krishnan Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 9eef311eb5244fa629fbc32dcad790f3457af008 Author: Tong Zhang Date: Fri Aug 28 10:17:08 2020 -0400 nvme-pci: cancel nvme device request before disabling [ Upstream commit 7ad92f656bddff4cf8f641e0e3b1acd4eb9644cb ] This patch addresses an irq free warning and null pointer dereference error problem when nvme devices got timeout error during initialization. This problem happens when nvme_timeout() function is called while nvme_reset_work() is still in execution. This patch fixed the problem by setting flag of the problematic request to NVME_REQ_CANCELLED before calling nvme_dev_disable() to make sure __nvme_submit_sync_cmd() returns an error code and let nvme_submit_sync_cmd() fail gracefully. The following is console output. [ 62.472097] nvme nvme0: I/O 13 QID 0 timeout, disable controller [ 62.488796] nvme nvme0: could not set timestamp (881) [ 62.494888] ------------[ cut here ]------------ [ 62.495142] Trying to free already-free IRQ 11 [ 62.495366] WARNING: CPU: 0 PID: 7 at kernel/irq/manage.c:1751 free_irq+0x1f7/0x370 [ 62.495742] Modules linked in: [ 62.495902] CPU: 0 PID: 7 Comm: kworker/u4:0 Not tainted 5.8.0+ #8 [ 62.496206] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-48-gd9c812dda519-p4 [ 62.496772] Workqueue: nvme-reset-wq nvme_reset_work [ 62.497019] RIP: 0010:free_irq+0x1f7/0x370 [ 62.497223] Code: e8 ce 49 11 00 48 83 c4 08 4c 89 e0 5b 5d 41 5c 41 5d 41 5e 41 5f c3 44 89 f6 48 c70 [ 62.498133] RSP: 0000:ffffa96800043d40 EFLAGS: 00010086 [ 62.498391] RAX: 0000000000000000 RBX: ffff9b87fc458400 RCX: 0000000000000000 [ 62.498741] RDX: 0000000000000001 RSI: 0000000000000096 RDI: ffffffff9693d72c [ 62.499091] RBP: ffff9b87fd4c8f60 R08: ffffa96800043bfd R09: 0000000000000163 [ 62.499440] R10: ffffa96800043bf8 R11: ffffa96800043bfd R12: ffff9b87fd4c8e00 [ 62.499790] R13: ffff9b87fd4c8ea4 R14: 000000000000000b R15: ffff9b87fd76b000 [ 62.500140] FS: 0000000000000000(0000) GS:ffff9b87fdc00000(0000) knlGS:0000000000000000 [ 62.500534] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 62.500816] CR2: 0000000000000000 CR3: 000000003aa0a000 CR4: 00000000000006f0 [ 62.501165] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 62.501515] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 62.501864] Call Trace: [ 62.501993] pci_free_irq+0x13/0x20 [ 62.502167] nvme_reset_work+0x5d0/0x12a0 [ 62.502369] ? update_load_avg+0x59/0x580 [ 62.502569] ? ttwu_queue_wakelist+0xa8/0xc0 [ 62.502780] ? try_to_wake_up+0x1a2/0x450 [ 62.502979] process_one_work+0x1d2/0x390 [ 62.503179] worker_thread+0x45/0x3b0 [ 62.503361] ? process_one_work+0x390/0x390 [ 62.503568] kthread+0xf9/0x130 [ 62.503726] ? kthread_park+0x80/0x80 [ 62.503911] ret_from_fork+0x22/0x30 [ 62.504090] ---[ end trace de9ed4a70f8d71e2 ]--- [ 123.912275] nvme nvme0: I/O 12 QID 0 timeout, disable controller [ 123.914670] nvme nvme0: 1/0/0 default/read/poll queues [ 123.916310] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 123.917469] #PF: supervisor write access in kernel mode [ 123.917725] #PF: error_code(0x0002) - not-present page [ 123.917976] PGD 0 P4D 0 [ 123.918109] Oops: 0002 [#1] SMP PTI [ 123.918283] CPU: 0 PID: 7 Comm: kworker/u4:0 Tainted: G W 5.8.0+ #8 [ 123.918650] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-48-gd9c812dda519-p4 [ 123.919219] Workqueue: nvme-reset-wq nvme_reset_work [ 123.919469] RIP: 0010:__blk_mq_alloc_map_and_request+0x21/0x80 [ 123.919757] Code: 66 0f 1f 84 00 00 00 00 00 41 55 41 54 55 48 63 ee 53 48 8b 47 68 89 ee 48 89 fb 8b4 [ 123.920657] RSP: 0000:ffffa96800043d40 EFLAGS: 00010286 [ 123.920912] RAX: ffff9b87fc4fee40 RBX: ffff9b87fc8cb008 RCX: 0000000000000000 [ 123.921258] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9b87fc618000 [ 123.921602] RBP: 0000000000000000 R08: ffff9b87fdc2c4a0 R09: ffff9b87fc616000 [ 123.921949] R10: 0000000000000000 R11: ffff9b87fffd1500 R12: 0000000000000000 [ 123.922295] R13: 0000000000000000 R14: ffff9b87fc8cb200 R15: ffff9b87fc8cb000 [ 123.922641] FS: 0000000000000000(0000) GS:ffff9b87fdc00000(0000) knlGS:0000000000000000 [ 123.923032] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 123.923312] CR2: 0000000000000000 CR3: 000000003aa0a000 CR4: 00000000000006f0 [ 123.923660] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 123.924007] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 123.924353] Call Trace: [ 123.924479] blk_mq_alloc_tag_set+0x137/0x2a0 [ 123.924694] nvme_reset_work+0xed6/0x12a0 [ 123.924898] process_one_work+0x1d2/0x390 [ 123.925099] worker_thread+0x45/0x3b0 [ 123.925280] ? process_one_work+0x390/0x390 [ 123.925486] kthread+0xf9/0x130 [ 123.925642] ? kthread_park+0x80/0x80 [ 123.925825] ret_from_fork+0x22/0x30 [ 123.926004] Modules linked in: [ 123.926158] CR2: 0000000000000000 [ 123.926322] ---[ end trace de9ed4a70f8d71e3 ]--- [ 123.926549] RIP: 0010:__blk_mq_alloc_map_and_request+0x21/0x80 [ 123.926832] Code: 66 0f 1f 84 00 00 00 00 00 41 55 41 54 55 48 63 ee 53 48 8b 47 68 89 ee 48 89 fb 8b4 [ 123.927734] RSP: 0000:ffffa96800043d40 EFLAGS: 00010286 [ 123.927989] RAX: ffff9b87fc4fee40 RBX: ffff9b87fc8cb008 RCX: 0000000000000000 [ 123.928336] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9b87fc618000 [ 123.928679] RBP: 0000000000000000 R08: ffff9b87fdc2c4a0 R09: ffff9b87fc616000 [ 123.929025] R10: 0000000000000000 R11: ffff9b87fffd1500 R12: 0000000000000000 [ 123.929370] R13: 0000000000000000 R14: ffff9b87fc8cb200 R15: ffff9b87fc8cb000 [ 123.929715] FS: 0000000000000000(0000) GS:ffff9b87fdc00000(0000) knlGS:0000000000000000 [ 123.930106] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 123.930384] CR2: 0000000000000000 CR3: 000000003aa0a000 CR4: 00000000000006f0 [ 123.930731] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 123.931077] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Co-developed-by: Keith Busch Signed-off-by: Tong Zhang Reviewed-by: Keith Busch Signed-off-by: Sagi Grimberg Signed-off-by: Sasha Levin commit 068f73f767a1ed7f27f1eb48343a7bf2d88c1a58 Author: Sagi Grimberg Date: Thu Jul 30 13:42:42 2020 -0700 nvme-rdma: fix reset hang if controller died in the middle of a reset [ Upstream commit 2362acb6785611eda795bfc12e1ea6b202ecf62c ] If the controller becomes unresponsive in the middle of a reset, we will hang because we are waiting for the freeze to complete, but that cannot happen since we have commands that are inflight holding the q_usage_counter, and we can't blindly fail requests that times out. So give a timeout and if we cannot wait for queue freeze before unfreezing, fail and have the error handling take care how to proceed (either schedule a reconnect of remove the controller). Reviewed-by: Christoph Hellwig Signed-off-by: Sagi Grimberg Signed-off-by: Sasha Levin commit d409ed01923615fe2ede4385a43b80cdc237c549 Author: Sagi Grimberg Date: Wed Jul 29 02:36:03 2020 -0700 nvme-rdma: fix timeout handler [ Upstream commit 0475a8dcbcee92a5d22e40c9c6353829fc6294b8 ] When a request times out in a LIVE state, we simply trigger error recovery and let the error recovery handle the request cancellation, however when a request times out in a non LIVE state, we make sure to complete it immediately as it might block controller setup or teardown and prevent forward progress. However tearing down the entire set of I/O and admin queues causes freeze/unfreeze imbalance (q->mq_freeze_depth) because and is really an overkill to what we actually need, which is to just fence controller teardown that may be running, stop the queue, and cancel the request if it is not already completed. Now that we have the controller teardown_lock, we can safely serialize request cancellation. This addresses a hang caused by calling extra queue freeze on controller namespaces, causing unfreeze to not complete correctly. Reviewed-by: Christoph Hellwig Reviewed-by: James Smart Signed-off-by: Sagi Grimberg Signed-off-by: Sasha Levin commit 9cf1ee492f2370652b49a17bf6cc7c4dfc6256e8 Author: Sagi Grimberg Date: Wed Aug 5 18:13:58 2020 -0700 nvme-rdma: serialize controller teardown sequences [ Upstream commit 5110f40241d08334375eb0495f174b1d2c07657e ] In the timeout handler we may need to complete a request because the request that timed out may be an I/O that is a part of a serial sequence of controller teardown or initialization. In order to complete the request, we need to fence any other context that may compete with us and complete the request that is timing out. In this case, we could have a potential double completion in case a hard-irq or a different competing context triggered error recovery and is running inflight request cancellation concurrently with the timeout handler. Protect using a ctrl teardown_lock to serialize contexts that may complete a cancelled request due to error recovery or a reset. Reviewed-by: Christoph Hellwig Reviewed-by: James Smart Signed-off-by: Sagi Grimberg Signed-off-by: Sasha Levin commit bb018c73500b67362aedaa40e5c8d18da240256d Author: Sagi Grimberg Date: Thu Jul 30 13:25:34 2020 -0700 nvme-tcp: fix reset hang if controller died in the middle of a reset [ Upstream commit e5c01f4f7f623e768e868bcc08d8e7ceb03b75d0 ] If the controller becomes unresponsive in the middle of a reset, we will hang because we are waiting for the freeze to complete, but that cannot happen since we have commands that are inflight holding the q_usage_counter, and we can't blindly fail requests that times out. So give a timeout and if we cannot wait for queue freeze before unfreezing, fail and have the error handling take care how to proceed (either schedule a reconnect of remove the controller). Signed-off-by: Sagi Grimberg Signed-off-by: Sasha Levin commit 34b1b26b2d8fa89d03accd6d1f48e8c346afc047 Author: Sagi Grimberg Date: Tue Jul 28 13:16:36 2020 -0700 nvme-tcp: fix timeout handler [ Upstream commit 236187c4ed195161dfa4237c7beffbba0c5ae45b ] When a request times out in a LIVE state, we simply trigger error recovery and let the error recovery handle the request cancellation, however when a request times out in a non LIVE state, we make sure to complete it immediately as it might block controller setup or teardown and prevent forward progress. However tearing down the entire set of I/O and admin queues causes freeze/unfreeze imbalance (q->mq_freeze_depth) because and is really an overkill to what we actually need, which is to just fence controller teardown that may be running, stop the queue, and cancel the request if it is not already completed. Now that we have the controller teardown_lock, we can safely serialize request cancellation. This addresses a hang caused by calling extra queue freeze on controller namespaces, causing unfreeze to not complete correctly. Signed-off-by: Sagi Grimberg Signed-off-by: Sasha Levin commit 7abff44756fe980bede6aa15d1634b43dfde5ecf Author: Sagi Grimberg Date: Wed Aug 5 18:13:48 2020 -0700 nvme-tcp: serialize controller teardown sequences [ Upstream commit d4d61470ae48838f49e668503e840e1520b97162 ] In the timeout handler we may need to complete a request because the request that timed out may be an I/O that is a part of a serial sequence of controller teardown or initialization. In order to complete the request, we need to fence any other context that may compete with us and complete the request that is timing out. In this case, we could have a potential double completion in case a hard-irq or a different competing context triggered error recovery and is running inflight request cancellation concurrently with the timeout handler. Protect using a ctrl teardown_lock to serialize contexts that may complete a cancelled request due to error recovery or a reset. Signed-off-by: Sagi Grimberg Signed-off-by: Sasha Levin commit 7598a9d0a756af3d94577c6910ca120d1edf71cf Author: Sagi Grimberg Date: Thu Jul 30 13:24:45 2020 -0700 nvme: have nvme_wait_freeze_timeout return if it timed out [ Upstream commit 7cf0d7c0f3c3b0203aaf81c1bc884924d8fdb9bd ] Users can detect if the wait has completed or not and take appropriate actions based on this information (e.g. weather to continue initialization or rather fail and schedule another initialization attempt). Reviewed-by: Christoph Hellwig Signed-off-by: Sagi Grimberg Signed-off-by: Sasha Levin commit 35d841908c0b4807b17083e1353616ee3452e556 Author: Sagi Grimberg Date: Fri Aug 14 11:46:51 2020 -0700 nvme-fabrics: don't check state NVME_CTRL_NEW for request acceptance [ Upstream commit d7144f5c4cf4de95fdc3422943cf51c06aeaf7a7 ] NVME_CTRL_NEW should never see any I/O, because in order to start initialization it has to transition to NVME_CTRL_CONNECTING and from there it will never return to this state. Reviewed-by: Christoph Hellwig Signed-off-by: Sagi Grimberg Signed-off-by: Sasha Levin commit f9af5758b19bb645b412cb6b57913ba778453927 Author: Ziye Yang Date: Sat Aug 22 00:48:10 2020 +0800 nvmet-tcp: Fix NULL dereference when a connect data comes in h2cdata pdu [ Upstream commit a6ce7d7b4adaebc27ee7e78e5ecc378a1cfc221d ] When handling commands without in-capsule data, we assign the ttag assuming we already have the queue commands array allocated (based on the queue size information in the connect data payload). However if the connect itself did not send the connect data in-capsule we have yet to allocate the queue commands,and we will assign a bogus ttag and suffer a NULL dereference when we receive the corresponding h2cdata pdu. Fix this by checking if we already allocated commands before dereferencing it when handling h2cdata, if we didn't, its for sure a connect and we should use the preallocated connect command. Signed-off-by: Ziye Yang Signed-off-by: Sagi Grimberg Signed-off-by: Sasha Levin commit 6ce06caf6b44e47650276c97ab0d1143d1747466 Author: Vineet Gupta Date: Mon Aug 24 12:10:33 2020 -0700 irqchip/eznps: Fix build error for !ARC700 builds [ Upstream commit 89d29997f103d08264b0685796b420d911658b96 ] eznps driver is supposed to be platform independent however it ends up including stuff from inside arch/arc headers leading to rand config build errors. The quick hack to fix this (proper fix is too much chrun for non active user-base) is to add following to nps platform agnostic header. - copy AUX_IENABLE from arch/arc header - move CTOP_AUX_IACK from arch/arc/plat-eznps/*/** Reported-by: kernel test robot Reported-by: Sebastian Andrzej Siewior Link: https://lkml.kernel.org/r/20200824095831.5lpkmkafelnvlpi2@linutronix.de Signed-off-by: Vineet Gupta Signed-off-by: Sasha Levin commit 41ac2e8a6a1f412d236cc2a273e85003e57d5ea8 Author: Darrick J. Wong Date: Wed Aug 26 14:12:18 2020 -0700 xfs: initialize the shortform attr header padding entry [ Upstream commit 125eac243806e021f33a1fdea3687eccbb9f7636 ] Don't leak kernel memory contents into the shortform attr fork. Signed-off-by: Darrick J. Wong Reviewed-by: Eric Sandeen Reviewed-by: Dave Chinner Reviewed-by: Christoph Hellwig Signed-off-by: Sasha Levin commit a33cab0fbd2f5098b5322f362514fbf0d498619e Author: Amar Singhal Date: Fri Jun 19 13:52:01 2020 -0700 cfg80211: Adjust 6 GHz frequency to channel conversion [ Upstream commit 2d9b55508556ccee6410310fb9ea2482fd3328eb ] Adjust the 6 GHz frequency to channel conversion function, the other way around was previously handled. Signed-off-by: Amar Singhal Link: https://lore.kernel.org/r/1592599921-10607-1-git-send-email-asinghal@codeaurora.org [rewrite commit message, hard-code channel 2] Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 0aa356dde967cc78586008bfad23a34b94e666a7 Author: Xie He Date: Tue Aug 25 20:03:53 2020 -0700 drivers/net/wan/lapbether: Set network_header before transmitting [ Upstream commit 91244d108441013b7367b3b4dcc6869998676473 ] Set the skb's network_header before it is passed to the underlying Ethernet device for transmission. This patch fixes the following issue: When we use this driver with AF_PACKET sockets, there would be error messages of: protocol 0805 is buggy, dev (Ethernet interface name) printed in the system "dmesg" log. This is because skbs passed down to the Ethernet device for transmission don't have their network_header properly set, and the dev_queue_xmit_nit function in net/core/dev.c complains about this. Reason of setting the network_header to this place (at the end of the Ethernet header, and at the beginning of the Ethernet payload): Because when this driver receives an skb from the Ethernet device, the network_header is also set at this place. Cc: Martin Schiller Signed-off-by: Xie He Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e91f2ec0bfbde475b8f21f39cfc72c075763580e Author: Brian Foster Date: Wed Aug 26 14:08:27 2020 -0700 xfs: fix off-by-one in inode alloc block reservation calculation [ Upstream commit 657f101930bc6c5b41bd7d6c22565c4302a80d33 ] The inode chunk allocation transaction reserves inobt_maxlevels-1 blocks to accommodate a full split of the inode btree. A full split requires an allocation for every existing level and a new root block, which means inobt_maxlevels is the worst case block requirement for a transaction that inserts to the inobt. This can lead to a transaction block reservation overrun when tmpfile creation allocates an inode chunk and expands the inobt to its maximum depth. This problem has been observed in conjunction with overlayfs, which makes frequent use of tmpfiles internally. The existing reservation code goes back as far as the Linux git repo history (v2.6.12). It was likely never observed as a problem because the traditional file/directory creation transactions also include worst case block reservation for directory modifications, which most likely is able to make up for a single block deficiency in the inode allocation portion of the calculation. tmpfile support is relatively more recent (v3.15), less heavily used, and only includes the inode allocation block reservation as tmpfiles aren't linked into the directory tree on creation. Fix up the inode alloc block reservation macro and a couple of the block allocator minleft parameters that enforce an allocation to leave enough free blocks in the AG for a full inobt split. Signed-off-by: Brian Foster Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Sasha Levin commit 983efe173e37f9b0e5b0243560d6020ddee7a1d9 Author: Yi Li Date: Wed Aug 26 13:11:50 2020 +0800 net: hns3: Fix for geneve tx checksum bug [ Upstream commit a156998fc92d3859c8e820f1583f6d0541d643c3 ] when skb->encapsulation is 0, skb->ip_summed is CHECKSUM_PARTIAL and it is udp packet, which has a dest port as the IANA assigned. the hardware is expected to do the checksum offload, but the hardware will not do the checksum offload when udp dest port is 6081. This patch fixes it by doing the checksum in software. Reported-by: Li Bing Signed-off-by: Yi Li Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit cb54984b79892b015ad766d62af0e5cfa3747fe8 Author: Madhuparna Bhowmik Date: Fri Aug 21 09:14:23 2020 +0530 drivers/dma/dma-jz4780: Fix race condition between probe and irq handler [ Upstream commit 6d6018fc30bee67290dbed2fa51123f7c6f3d691 ] In probe, IRQ is requested before zchan->id is initialized which can be read in the irq handler. Hence, shift request irq after other initializations complete. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Madhuparna Bhowmik Reviewed-by: Paul Cercueil Link: https://lore.kernel.org/r/20200821034423.12713-1-madhuparnabhowmik10@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit bcdbb7c8c7f9ac90eeff07e0e99bc986cd7db5e1 Author: Mohan Kumar Date: Tue Aug 25 10:54:15 2020 +0530 ALSA: hda/tegra: Program WAKEEN register for Tegra [ Upstream commit 23d63a31d9f44d7daeac0d1fb65c6a73c70e5216 ] The WAKEEN bits are used to indicate which bits in the STATESTS register may cause wake event during the codec state change request. Configure the WAKEEN register for the Tegra to detect the wake events. Signed-off-by: Mohan Kumar Acked-by: Sameer Pujar Link: https://lore.kernel.org/r/20200825052415.20626-3-mkumard@nvidia.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit ad360686fcd2739153c5fc7039cd3d307f6c205b Author: Mohan Kumar Date: Tue Aug 25 10:54:14 2020 +0530 ALSA: hda: Fix 2 channel swapping for Tegra [ Upstream commit 216116eae43963c662eb84729507bad95214ca6b ] The Tegra HDA codec HW implementation has an issue related to not swapping the 2 channel Audio Sample Packet(ASP) channel mapping. Whatever the FL and FR mapping specified the left channel always comes out of left speaker and right channel on right speaker. So add condition to disallow the swapping of FL,FR during the playback. Signed-off-by: Mohan Kumar Acked-by: Sameer Pujar Link: https://lore.kernel.org/r/20200825052415.20626-2-mkumard@nvidia.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 1518c24b32652d318c9bf543308e4fb791f163d7 Author: Dinghao Liu Date: Sun Aug 23 19:29:35 2020 +0800 firestream: Fix memleak in fs_open [ Upstream commit 15ac5cdafb9202424206dc5bd376437a358963f9 ] When make_rate() fails, vcc should be freed just like other error paths in fs_open(). Signed-off-by: Dinghao Liu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 818c725c12417b9996011d9e33e4032974b5a38c Author: Dinghao Liu Date: Sun Aug 23 15:23:43 2020 +0800 NFC: st95hf: Fix memleak in st95hf_in_send_cmd [ Upstream commit f97c04c316d8fea16dca449fdfbe101fbdfee6a2 ] When down_killable() fails, skb_resp should be freed just like when st95hf_spi_send() fails. Signed-off-by: Dinghao Liu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 0faee7f8c2366b3536fa32643f70ebe74c52bde2 Author: Xie He Date: Fri Aug 21 14:26:59 2020 -0700 drivers/net/wan/lapbether: Added needed_tailroom [ Upstream commit 1ee39c1448c4e0d480c5b390e2db1987561fb5c2 ] The underlying Ethernet device may request necessary tailroom to be allocated by setting needed_tailroom. This driver should also set needed_tailroom to request the tailroom needed by the underlying Ethernet device to be allocated. Cc: Willem de Bruijn Cc: Martin Schiller Signed-off-by: Xie He Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 59d2b1e5cb058122d53ab140831d69740034f951 Author: Florian Westphal Date: Tue Aug 18 16:15:58 2020 +0200 netfilter: conntrack: allow sctp hearbeat after connection re-use [ Upstream commit cc5453a5b7e90c39f713091a7ebc53c1f87d1700 ] If an sctp connection gets re-used, heartbeats are flagged as invalid because their vtag doesn't match. Handle this in a similar way as TCP conntrack when it suspects that the endpoints and conntrack are out-of-sync. When a HEARTBEAT request fails its vtag validation, flag this in the conntrack state and accept the packet. When a HEARTBEAT_ACK is received with an invalid vtag in the reverse direction after we allowed such a HEARTBEAT through, assume we are out-of-sync and re-set the vtag info. v2: remove left-over snippet from an older incarnation that moved new_state/old_state assignments, thats not needed so keep that as-is. Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 444bf09f2be4afd2a73e4c8ae0a8a700e5bbe5fa Author: Hanjun Guo Date: Wed Jul 22 17:54:21 2020 +0800 dmaengine: acpi: Put the CSRT table after using it [ Upstream commit 7eb48dd094de5fe0e216b550e73aa85257903973 ] The acpi_get_table() should be coupled with acpi_put_table() if the mapped table is not used at runtime to release the table mapping, put the CSRT table buf after using it. Signed-off-by: Hanjun Guo Link: https://lore.kernel.org/r/1595411661-15936-1-git-send-email-guohanjun@huawei.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 89c4339c4d35fa22e355bde1c8b26aa5dbb98e86 Author: Vineet Gupta Date: Thu Jul 9 19:52:32 2020 -0700 ARC: HSDK: wireup perf irq [ Upstream commit fe81d927b78c4f0557836661d32e41ebc957b024 ] Newer version of HSDK aka HSDK-4xD (with dual issue HS48x4 CPU) wired up the perf interrupt, so enable that in DT. This is OK for old HSDK where this irq is ignored because pct irq is not wired up in hardware. Signed-off-by: Vineet Gupta Signed-off-by: Sasha Levin commit 75a81be8fb3e36c7e6267496eff9a196810c6ac6 Author: Florian Fainelli Date: Wed Aug 26 16:49:19 2020 -0700 arm64: dts: ns2: Fixed QSPI compatible string [ Upstream commit 686e0a0c8c61e0e3f55321d0181fece3efd92777 ] The string was incorrectly defined before from least to most specific, swap the compatible strings accordingly. Fixes: ff73917d38a6 ("ARM64: dts: Add QSPI Device Tree node for NS2") Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin commit cd0ffeb0b8795369bcc403109131637c72239976 Author: Florian Fainelli Date: Wed Aug 26 16:45:29 2020 -0700 ARM: dts: BCM5301X: Fixed QSPI compatible string [ Upstream commit b793dab8d811e103665d6bddaaea1c25db3776eb ] The string was incorrectly defined before from least to most specific, swap the compatible strings accordingly. Fixes: 1c8f40650723 ("ARM: dts: BCM5301X: convert to iProc QSPI") Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin commit 8a9383e277e40859a6c3edd4e4236ff365af35a4 Author: Florian Fainelli Date: Wed Aug 26 16:44:25 2020 -0700 ARM: dts: NSP: Fixed QSPI compatible string [ Upstream commit d1ecc40a954fd0f5e3789b91fa80f15e82284e39 ] The string was incorrectly defined before from least to most specific, swap the compatible strings accordingly. Fixes: 329f98c1974e ("ARM: dts: NSP: Add QSPI nodes to NSPI and bcm958625k DTSes") Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin commit 7a1e2c816acced1849ccf3ddab5a530c6e66fdbe Author: Florian Fainelli Date: Wed Aug 26 16:43:41 2020 -0700 ARM: dts: bcm: HR2: Fixed QSPI compatible string [ Upstream commit d663186293a818af97c648624bee6c7a59e8218b ] The string was incorrectly defined before from least to most specific, swap the compatible strings accordingly. Fixes: b9099ec754b5 ("ARM: dts: Add Broadcom Hurricane 2 DTS include file") Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin commit 0f632bc483553fd2203face1384119d49edeff61 Author: Sagi Grimberg Date: Fri Sep 4 12:50:39 2020 -0700 IB/isert: Fix unaligned immediate-data handling [ Upstream commit 0b089c1ef7047652b13b4cdfdb1e0e7dbdb8c9ab ] Currently we allocate rx buffers in a single contiguous buffers for headers (iser and iscsi) and data trailer. This means that most likely the data starting offset is aligned to 76 bytes (size of both headers). This worked fine for years, but at some point this broke, resulting in data corruptions in isert when a command comes with immediate data and the underlying backend device assumes 512 bytes buffer alignment. We assume a hard-requirement for all direct I/O buffers to be 512 bytes aligned. To fix this, we should avoid passing unaligned buffers for I/O. Instead, we allocate our recv buffers with some extra space such that we can have the data portion align to 512 byte boundary. This also means that we cannot reference headers or data using structure but rather accessors (as they may move based on alignment). Also, get rid of the wrong __packed annotation from iser_rx_desc as this has only harmful effects (not aligned to anything). This affects the rx descriptors for iscsi login and data plane. Fixes: 3d75ca0adef4 ("block: introduce multi-page bvec helpers") Link: https://lore.kernel.org/r/20200904195039.31687-1-sagi@grimberg.me Reported-by: Stephen Rust Tested-by: Doug Dumitru Signed-off-by: Sagi Grimberg Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 6736317f350a14a5cfe953f69685b1cb0b3607f7 Author: Ritesh Harjani Date: Wed Sep 9 08:44:25 2020 +0530 block: Set same_page to false in __bio_try_merge_page if ret is false [ Upstream commit 2cd896a5e86fc326bda8614b96c0401dcc145868 ] If we hit the UINT_MAX limit of bio->bi_iter.bi_size and so we are anyway not merging this page in this bio, then it make sense to make same_page also as false before returning. Without this patch, we hit below WARNING in iomap. This mostly happens with very large memory system and / or after tweaking vm dirty threshold params to delay writeback of dirty data. WARNING: CPU: 18 PID: 5130 at fs/iomap/buffered-io.c:74 iomap_page_release+0x120/0x150 CPU: 18 PID: 5130 Comm: fio Kdump: loaded Tainted: G W 5.8.0-rc3 #6 Call Trace: __remove_mapping+0x154/0x320 (unreliable) iomap_releasepage+0x80/0x180 try_to_release_page+0x94/0xe0 invalidate_inode_page+0xc8/0x110 invalidate_mapping_pages+0x1dc/0x540 generic_fadvise+0x3c8/0x450 xfs_file_fadvise+0x2c/0xe0 [xfs] vfs_fadvise+0x3c/0x60 ksys_fadvise64_64+0x68/0xe0 sys_fadvise64+0x28/0x40 system_call_exception+0xf8/0x1c0 system_call_common+0xf0/0x278 Fixes: cc90bc68422 ("block: fix "check bi_size overflow before merge"") Reported-by: Shivaprasad G Bhat Suggested-by: Christoph Hellwig Signed-off-by: Anju T Sudhakar Signed-off-by: Ritesh Harjani Reviewed-by: Ming Lei Reviewed-by: Christoph Hellwig Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 45ffad151baed2e946658da840fd043ff2ef14eb Author: Dan Carpenter Date: Wed Sep 9 12:43:04 2020 +0300 spi: stm32: fix pm_runtime_get_sync() error checking [ Upstream commit c170a5a3b6944ad8e76547c4a1d9fe81c8f23ac8 ] The pm_runtime_get_sync() can return either 0 or 1 on success but this code treats 1 as a failure. Fixes: db96bf976a4f ("spi: stm32: fixes suspend/resume management") Signed-off-by: Dan Carpenter Reviewed-by: Alain Volmat Link: https://lore.kernel.org/r/20200909094304.GA420136@mwanda Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 9ed3ab0c62d491b507bbd55e3b4c5911bc160e88 Author: Sagi Grimberg Date: Tue Sep 8 12:56:08 2020 -0700 nvme-fabrics: allow to queue requests for live queues [ Upstream commit 73a5379937ec89b91e907bb315e2434ee9696a2c ] Right now we are failing requests based on the controller state (which is checked inline in nvmf_check_ready) however we should definitely accept requests if the queue is live. When entering controller reset, we transition the controller into NVME_CTRL_RESETTING, and then return BLK_STS_RESOURCE for non-mpath requests (have blk_noretry_request set). This is also the case for NVME_REQ_USER for the wrong reason. There shouldn't be any reason for us to reject this I/O in a controller reset. We do want to prevent passthru commands on the admin queue because we need the controller to fully initialize first before we let user passthru admin commands to be issued. In a non-mpath setup, this means that the requests will simply be requeued over and over forever not allowing the q_usage_counter to drop its final reference, causing controller reset to hang if running concurrently with heavy I/O. Fixes: 35897b920c8a ("nvme-fabrics: fix and refine state checks in __nvmf_check_ready") Reviewed-by: James Smart Signed-off-by: Sagi Grimberg Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 43b3d09c51425fb680c3cd53f2d7a7b677f09d3b Author: Marek Vasut Date: Sat Sep 5 17:19:13 2020 +0200 spi: stm32: Rate-limit the 'Communication suspended' message [ Upstream commit ea8be08cc9358f811e4175ba7fa7fea23c5d393e ] The 'spi_stm32 44004000.spi: Communication suspended' message means that when using PIO, the kernel did not read the FIFO fast enough and so the SPI controller paused the transfer. Currently, this is printed on every single such event, so if the kernel is busy and the controller is pausing the transfers often, the kernel will be all the more busy scrolling this message into the log buffer every few milliseconds. That is not helpful. Instead, rate-limit the message and print it every once in a while. It is not possible to use the default dev_warn_ratelimited(), because that is still too verbose, as it prints 10 lines (DEFAULT_RATELIMIT_BURST) every 5 seconds (DEFAULT_RATELIMIT_INTERVAL). The policy here is to print 1 line every 50 seconds (DEFAULT_RATELIMIT_INTERVAL * 10), because 1 line is more than enough and the cycles saved on printing are better left to the CPU to handle the SPI. However, dev_warn_once() is also not useful, as the user should be aware that this condition is possibly recurring or ongoing. Thus the custom rate-limit policy. Finally, turn the message from dev_warn() to dev_dbg(), since the system does not suffer any sort of malfunction if this message appears, it is just slowing down. This further reduces the printing into the log buffer and frees the CPU to do useful work. Fixes: dcbe0d84dfa5 ("spi: add driver for STM32 SPI controller") Signed-off-by: Marek Vasut Cc: Alexandre Torgue Cc: Amelie Delaunay Cc: Antonio Borneo Cc: Mark Brown Link: https://lore.kernel.org/r/20200905151913.117775-1-marex@denx.de Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 15dc0695a3b0c1bd5c618e867b0749ce0a2bb53b Author: Douglas Anderson Date: Thu Aug 27 07:58:41 2020 -0700 mmc: sdhci-msm: Add retries when all tuning phases are found valid [ Upstream commit 9d5dcefb7b114d610aeb2371f6a6f119af316e43 ] As the comments in this patch say, if we tune and find all phases are valid it's _almost_ as bad as no phases being found valid. Probably all phases are not really reliable but we didn't detect where the unreliable place is. That means we'll essentially be guessing and hoping we get a good phase. This is not just a problem in theory. It was causing real problems on a real board. On that board, most often phase 10 is found as the only invalid phase, though sometimes 10 and 11 are invalid and sometimes just 11. Some percentage of the time, however, all phases are found to be valid. When this happens, the current logic will decide to use phase 11. Since phase 11 is sometimes found to be invalid, this is a bad choice. Sure enough, when phase 11 is picked we often get mmc errors later in boot. I have seen cases where all phases were found to be valid 3 times in a row, so increase the retry count to 10 just to be extra sure. Fixes: 415b5a75da43 ("mmc: sdhci-msm: Add platform_execute_tuning implementation") Signed-off-by: Douglas Anderson Reviewed-by: Veerabhadrarao Badiganti Acked-by: Adrian Hunter Link: https://lore.kernel.org/r/20200827075809.1.If179abf5ecb67c963494db79c3bc4247d987419b@changeid Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 5bead6811610e5788f078f01aa16fed9905d8764 Author: Raul E Rangel Date: Mon Aug 31 15:10:32 2020 -0600 mmc: sdhci-acpi: Clear amd_sdhci_host on reset [ Upstream commit 2cf9bfe9be75ed3656bbf882fb70c3e3047866e4 ] The commit 61d7437ed1390 ("mmc: sdhci-acpi: Fix HS400 tuning for AMDI0040") broke resume for eMMC HS400. When the system suspends the eMMC controller is powered down. So, on resume we need to reinitialize the controller. Although, amd_sdhci_host was not getting cleared, so the DLL was never re-enabled on resume. This results in HS400 being non-functional. To fix the problem, this change clears the tuned_clock flag, clears the dll_enabled flag and disables the DLL on reset. Fixes: 61d7437ed1390 ("mmc: sdhci-acpi: Fix HS400 tuning for AMDI0040") Signed-off-by: Raul E Rangel Acked-by: Adrian Hunter Link: https://lore.kernel.org/r/20200831150517.1.I93c78bfc6575771bb653c9d3fca5eb018a08417d@changeid Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit c46eabd1e6cc51f5a891b043843f502f4acb87cf Author: Maxime Ripard Date: Tue Jul 28 15:48:10 2020 +0200 drm/sun4i: backend: Disable alpha on the lowest plane on the A20 [ Upstream commit 5e2e2600a3744491a8b49b92597c13b693692082 ] Unlike we previously thought, the per-pixel alpha is just as broken on the A20 as it is on the A10. Remove the quirk that says we can use it. Fixes: dcf496a6a608 ("drm/sun4i: sun4i: Introduce a quirk for lowest plane alpha support") Signed-off-by: Maxime Ripard Reviewed-by: Chen-Yu Tsai Cc: Paul Kocialkowski Link: https://patchwork.freedesktop.org/patch/msgid/20200728134810.883457-2-maxime@cerno.tech Signed-off-by: Sasha Levin commit f3c982d8e60a4f557e754fb425cbff01910710a7 Author: Maxime Ripard Date: Tue Jul 28 15:48:09 2020 +0200 drm/sun4i: backend: Support alpha property on lowest plane [ Upstream commit e359c70462d2a82aae80274d027351d38792dde6 ] Unlike what we previously thought, only the per-pixel alpha is broken on the lowest plane and the per-plane alpha isn't. Remove the check on the alpha property being set on the lowest plane to reject a mode. Fixes: dcf496a6a608 ("drm/sun4i: sun4i: Introduce a quirk for lowest plane alpha support") Signed-off-by: Maxime Ripard Reviewed-by: Chen-Yu Tsai Cc: Paul Kocialkowski Link: https://patchwork.freedesktop.org/patch/msgid/20200728134810.883457-1-maxime@cerno.tech Signed-off-by: Sasha Levin commit fe0278843b64db9df5fd586d79e7cd02464bd413 Author: Tom Rix Date: Wed Sep 2 13:26:50 2020 -0700 soundwire: fix double free of dangling pointer [ Upstream commit 3fbbf2148a406b3e350fe91e6fdd78eb42ecad24 ] clang static analysis flags this problem stream.c:844:9: warning: Use of memory after it is freed kfree(bus->defer_msg.msg->buf); ^~~~~~~~~~~~~~~~~~~~~~~ This happens in an error handler cleaning up memory allocated for elements in a list. list_for_each_entry(m_rt, &stream->master_list, stream_node) { bus = m_rt->bus; kfree(bus->defer_msg.msg->buf); kfree(bus->defer_msg.msg); } And is triggered when the call to sdw_bank_switch() fails. There are a two problems. First, when sdw_bank_switch() fails, though it frees memory it does not clear bus's reference 'defer_msg.msg' to that memory. The second problem is the freeing msg->buf. In some cases msg will be NULL so this will dereference a null pointer. Need to check before freeing. Fixes: 99b8a5d608a6 ("soundwire: Add bank switch routine") Signed-off-by: Tom Rix Reviewed-by: Nick Desaulniers Reviewed-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20200902202650.14189-1-trix@redhat.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 122cdbd5019fd6c74dd234479bc15467afecc252 Author: Tomas Henzl Date: Tue Sep 1 16:50:26 2020 +0200 scsi: mpt3sas: Don't call disable_irq from IRQ poll handler [ Upstream commit b614d55b970d08bcac5b0bc15a5526181b3e4459 ] disable_irq() might sleep, replace it with disable_irq_nosync(). For synchronisation 'irq_poll_scheduled' is sufficient Fixes: 320e77acb3 scsi: mpt3sas: Irq poll to avoid CPU hard lockups Link: https://lore.kernel.org/r/20200901145026.12174-1-thenzl@redhat.com Signed-off-by: Tomas Henzl Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit aa204e20f4d4bbaf42b4a4d3196484eac7621aa6 Author: Tomas Henzl Date: Thu Aug 27 18:53:32 2020 +0200 scsi: megaraid_sas: Don't call disable_irq from process IRQ poll [ Upstream commit d2af39141eea34ef651961e885f49d96781a1016 ] disable_irq() might sleep. Replace it with disable_irq_nosync() which is sufficient as irq_poll_scheduled protects against concurrently running complete_cmd_fusion() from megasas_irqpoll() and megasas_isr_fusion(). Link: https://lore.kernel.org/r/20200827165332.8432-1-thenzl@redhat.com Fixes: a6ffd5bf681 scsi: megaraid_sas: Call disable_irq from process IRQ poll Signed-off-by: Tomas Henzl Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 0b4662709cedf1b1d044bb63e03f64cd3e33f4ce Author: Kamal Heib Date: Wed Sep 2 15:43:04 2020 +0300 RDMA/core: Fix reported speed and width [ Upstream commit 28b0865714b315e318ac45c4fc9156f3d4649646 ] When the returned speed from __ethtool_get_link_ksettings() is SPEED_UNKNOWN this will lead to reporting a wrong speed and width for providers that uses ib_get_eth_speed(), fix that by defaulting the netdev_speed to SPEED_1000 in case the returned value from __ethtool_get_link_ksettings() is SPEED_UNKNOWN. Fixes: d41861942fc5 ("IB/core: Add generic function to extract IB speed from netdev") Link: https://lore.kernel.org/r/20200902124304.170912-1-kamalheib1@gmail.com Signed-off-by: Kamal Heib Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit b3f6c2ca326b14594386610895d4239f284e1f21 Author: Luo Jiaxing Date: Wed Aug 26 15:24:26 2020 +0800 scsi: libsas: Set data_dir as DMA_NONE if libata marks qc as NODATA [ Upstream commit 53de092f47ff40e8d4d78d590d95819d391bf2e0 ] It was discovered that sdparm will fail when attempting to disable write cache on a SATA disk connected via libsas. In the ATA command set the write cache state is controlled through the SET FEATURES operation. This is roughly corresponds to MODE SELECT in SCSI and the latter command is what is used in the SCSI-ATA translation layer. A subtle difference is that a MODE SELECT carries data whereas SET FEATURES is defined as a non-data command in ATA. Set the DMA data direction to DMA_NONE if the requested ATA command is identified as non-data. [mkp: commit desc] Fixes: fa1c1e8f1ece ("[SCSI] Add SATA support to libsas") Link: https://lore.kernel.org/r/1598426666-54544-1-git-send-email-luojiaxing@huawei.com Reviewed-by: John Garry Reviewed-by: Jason Yan Signed-off-by: Luo Jiaxing Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 5571056a58051d85f22265e6ac62da8e7ac727a7 Author: Angelo Compagnucci Date: Wed Aug 19 09:55:25 2020 +0200 iio: adc: mcp3422: fix locking scope commit 3f1093d83d7164e4705e4232ccf76da54adfda85 upstream. Locking should be held for the entire reading sequence involving setting the channel, waiting for the channel switch and reading from the channel. If not, reading from a channel can result mixing with the reading from another channel. Fixes: 07914c84ba30 ("iio: adc: Add driver for Microchip MCP3422/3/4 high resolution ADC") Signed-off-by: Angelo Compagnucci Link: https://lore.kernel.org/r/20200819075525.1395248-1-angelo.compagnucci@gmail.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit f7db02316a003c67ecf8c02037d21c765b992647 Author: Angelo Compagnucci Date: Tue Sep 1 11:32:18 2020 +0200 iio: adc: mcp3422: fix locking on error path [ Upstream commit a139ffa40f0c24b753838b8ef3dcf6ad10eb7854 ] Reading from the chip should be unlocked on error path else the lock could never being released. Fixes: 07914c84ba30 ("iio: adc: Add driver for Microchip MCP3422/3/4 high resolution ADC") Fixes: 3f1093d83d71 ("iio: adc: mcp3422: fix locking scope") Acked-by: Jonathan Cameron Signed-off-by: Angelo Compagnucci Link: https://lore.kernel.org/r/20200901093218.1500845-1-angelo.compagnucci@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 376bc3643eebae10c18f9320a3224d15ef8aeaa5 Author: Ondrej Jirman Date: Fri Aug 28 14:50:32 2020 +0200 drm/sun4i: Fix dsi dcs long write function [ Upstream commit fd90e3808fd2c207560270c39b86b71af2231aa1 ] It's writing too much data. regmap_bulk_write expects number of register sized chunks to write, not a byte sized length of the bounce buffer. Bounce buffer needs to be padded too, so that regmap_bulk_write will not read past the end of the buffer. Fixes: 133add5b5ad4 ("drm/sun4i: Add Allwinner A31 MIPI-DSI controller support") Signed-off-by: Ondrej Jirman Signed-off-by: Maxime Ripard Reviewed-by: Jernej Skrabec Link: https://patchwork.freedesktop.org/patch/msgid/20200828125032.937148-1-megous@megous.com Signed-off-by: Sasha Levin commit af0d9818457599b1e33b20ad2b01c9ef0a80a62a Author: Krzysztof Kozlowski Date: Sat Aug 29 13:12:48 2020 +0200 arm64: dts: imx8mq: Fix TMU interrupt property [ Upstream commit 1f2f98f2703e8134678fe20982886085631eda23 ] "interrupt" is not a valid property. Using proper name fixes dtbs_check warning: arch/arm64/boot/dts/freescale/imx8mq-zii-ultra-zest.dt.yaml: tmu@30260000: 'interrupts' is a required property Fixes: e464fd2ba4d4 ("arm64: dts: imx8mq: enable the multi sensor TMU") Signed-off-by: Krzysztof Kozlowski Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit ddd3698271daf95f488d1faa801009403d7e0a9e Author: Yu Kuai Date: Wed Aug 26 09:08:26 2020 +0800 drm/sun4i: add missing put_device() call in sun8i_r40_tcon_tv_set_mux() [ Upstream commit 07b5b12d97dc9f47ff3dff46c4f944a15bd762e5 ] If sun8i_r40_tcon_tv_set_mux() succeed, sun8i_r40_tcon_tv_set_mux() doesn't have a corresponding put_device(). Thus add put_device() to fix the exception handling for this function implementation. Fixes: 0305189afb32 ("drm/sun4i: tcon: Add support for R40 TCON") Signed-off-by: Yu Kuai Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20200826010826.1785487-1-yukuai3@huawei.com Signed-off-by: Sasha Levin commit 1a2d6e722b49cc67b27b4cbd41ccf783710c2217 Author: Selvin Xavier Date: Mon Aug 24 11:14:32 2020 -0700 RDMA/bnxt_re: Do not report transparent vlan from QP1 [ Upstream commit 2d0e60ee322d512fa6bc62d23a6760b39a380847 ] QP1 Rx CQE reports transparent VLAN ID in the completion and this is used while reporting the completion for received MAD packet. Check if the vlan id is configured before reporting it in the work completion. Fixes: 84511455ac5b ("RDMA/bnxt_re: report vlan_id and sl in qp1 recv completion") Link: https://lore.kernel.org/r/1598292876-26529-3-git-send-email-selvin.xavier@broadcom.com Signed-off-by: Selvin Xavier Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit aaca6867137690c1ed6ccef74d7897784234114a Author: Kamal Heib Date: Tue Aug 25 18:17:25 2020 +0300 RDMA/rxe: Fix panic when calling kmem_cache_create() [ Upstream commit d862060a4b43479887ae8e2c0b74a58c4e27e5f3 ] To avoid the following kernel panic when calling kmem_cache_create() with a NULL pointer from pool_cache(), Block the rxe_param_set_add() from running if the rdma_rxe module is not initialized. BUG: unable to handle kernel NULL pointer dereference at 000000000000000b PGD 0 P4D 0 Oops: 0000 [#1] SMP NOPTI CPU: 4 PID: 8512 Comm: modprobe Kdump: loaded Not tainted 4.18.0-231.el8.x86_64 #1 Hardware name: HPE ProLiant DL385 Gen10/ProLiant DL385 Gen10, BIOS A40 10/02/2018 RIP: 0010:kmem_cache_alloc+0xd1/0x1b0 Code: 8b 57 18 45 8b 77 1c 48 8b 5c 24 30 0f 1f 44 00 00 5b 48 89 e8 5d 41 5c 41 5d 41 5e 41 5f c3 81 e3 00 00 10 00 75 0e 4d 89 fe <41> f6 47 0b 04 0f 84 6c ff ff ff 4c 89 ff e8 cc da 01 00 49 89 c6 RSP: 0018:ffffa2b8c773f9d0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000005 RDX: 0000000000000004 RSI: 00000000006080c0 RDI: 0000000000000000 RBP: ffff8ea0a8634fd0 R08: ffffa2b8c773f988 R09: 00000000006000c0 R10: 0000000000000000 R11: 0000000000000230 R12: 00000000006080c0 R13: ffffffffc0a97fc8 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f9138ed9740(0000) GS:ffff8ea4ae800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000000b CR3: 000000046d59a000 CR4: 00000000003406e0 Call Trace: rxe_alloc+0xc8/0x160 [rdma_rxe] rxe_get_dma_mr+0x25/0xb0 [rdma_rxe] __ib_alloc_pd+0xcb/0x160 [ib_core] ib_mad_init_device+0x296/0x8b0 [ib_core] add_client_context+0x11a/0x160 [ib_core] enable_device_and_get+0xdc/0x1d0 [ib_core] ib_register_device+0x572/0x6b0 [ib_core] ? crypto_create_tfm+0x32/0xe0 ? crypto_create_tfm+0x7a/0xe0 ? crypto_alloc_tfm+0x58/0xf0 rxe_register_device+0x19d/0x1c0 [rdma_rxe] rxe_net_add+0x3d/0x70 [rdma_rxe] ? dev_get_by_name_rcu+0x73/0x90 rxe_param_set_add+0xaf/0xc0 [rdma_rxe] parse_args+0x179/0x370 ? ref_module+0x1b0/0x1b0 load_module+0x135e/0x17e0 ? ref_module+0x1b0/0x1b0 ? __do_sys_init_module+0x13b/0x180 __do_sys_init_module+0x13b/0x180 do_syscall_64+0x5b/0x1a0 entry_SYSCALL_64_after_hwframe+0x65/0xca RIP: 0033:0x7f9137ed296e This can be triggered if a user tries to use the 'module option' which is not actually a real module option but some idiotic (and thankfully no obsolete) sysfs interface. Fixes: 8700e3e7c485 ("Soft RoCE driver") Link: https://lore.kernel.org/r/20200825151725.254046-1-kamalheib1@gmail.com Signed-off-by: Kamal Heib Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit d1878b298fc6b7ca679cfa252db5f955234e03ea Author: Kamal Heib Date: Sun Jul 5 13:43:10 2020 +0300 RDMA/rxe: Drop pointless checks in rxe_init_ports [ Upstream commit 6112ef62826e91afbae5446d5d47b38e25f47e3f ] Both pkey_tbl_len and gid_tbl_len are set in rxe_init_port_param() - so no need to check if they aren't set. Fixes: 8700e3e7c485 ("Soft RoCE driver") Link: https://lore.kernel.org/r/20200705104313.283034-2-kamalheib1@gmail.com Signed-off-by: Kamal Heib Reviewed-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit ca337b53fff3919e99be7256f0a46c73aa8043bc Author: Dinghao Liu Date: Wed Aug 19 15:56:32 2020 +0800 RDMA/rxe: Fix memleak in rxe_mem_init_user [ Upstream commit e3ddd6067ee62f6e76ebcf61ff08b2c729ae412b ] When page_address() fails, umem should be freed just like when rxe_mem_alloc() fails. Fixes: 8700e3e7c485 ("Soft RoCE driver") Link: https://lore.kernel.org/r/20200819075632.22285-1-dinghao.liu@zju.edu.cn Signed-off-by: Dinghao Liu Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit af2e06b02575dcb3934bce0be7f3fd26347f6aa4 Author: Anson Huang Date: Mon Aug 3 16:01:24 2020 +0800 ARM: dts: imx7ulp: Correct gpio ranges [ Upstream commit deb6323b739c54e1a1e83cd3a2bae4901e3eebf6 ] Correct gpio ranges according to i.MX7ULP pinctrl driver: gpio_ptc: ONLY pin 0~19 are available; gpio_ptd: ONLY pin 0~11 are available; gpio_pte: ONLY pin 0~15 are available; gpio_ptf: ONLY pin 0~19 are available; Fixes: 20434dc92c05 ("ARM: dts: imx: add common imx7ulp dtsi support") Signed-off-by: Anson Huang Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit ab56ed56f8c8e9ac74094d42250487b75487d028 Author: Matthias Schiffer Date: Tue Jul 28 12:50:06 2020 +0200 ARM: dts: ls1021a: fix QuadSPI-memory reg range [ Upstream commit 81dbbb417da4d1ac407dca5b434d39d5b6b91ef3 ] According to the Reference Manual, the correct size is 512 MiB. Without this fix, probing the QSPI fails: fsl-quadspi 1550000.spi: ioremap failed for resource [mem 0x40000000-0x7fffffff] fsl-quadspi 1550000.spi: Freescale QuadSPI probe failed fsl-quadspi: probe of 1550000.spi failed with error -12 Fixes: 85f8ee78ab72 ("ARM: dts: ls1021a: Add support for QSPI with ls1021a SoC") Signed-off-by: Matthias Schiffer Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit d5763bbf866431d858f13b43a101fe514f5258d7 Author: Po-Hsu Lin Date: Wed Mar 18 10:42:15 2020 +0800 selftests/timers: Turn off timeout setting [ Upstream commit 5c1e4f7e9e49b6925b1fb5c507d2c614f3edb292 ] The following 4 tests in timers can take longer than the default 45 seconds that added in commit 852c8cbf34d3 ("selftests/kselftest/runner.sh: Add 45 second timeout per test") to run: * nsleep-lat - 2m7.350s * set-timer-lat - 2m0.66s * inconsistency-check - 1m45.074s * raw_skew - 2m0.013s Thus they will be marked as failed with the current 45s setting: not ok 3 selftests: timers: nsleep-lat # TIMEOUT not ok 4 selftests: timers: set-timer-lat # TIMEOUT not ok 6 selftests: timers: inconsistency-check # TIMEOUT not ok 7 selftests: timers: raw_skew # TIMEOUT Disable the timeout setting for timers can make these tests finish properly: ok 3 selftests: timers: nsleep-lat ok 4 selftests: timers: set-timer-lat ok 6 selftests: timers: inconsistency-check ok 7 selftests: timers: raw_skew https://bugs.launchpad.net/bugs/1864626 Fixes: 852c8cbf34d3 ("selftests/kselftest/runner.sh: Add 45 second timeout per test") Signed-off-by: Po-Hsu Lin Acked-by: John Stultz Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 6a2be713c78f0672da5f44ed88abfd42999133cd Author: Dinh Nguyen Date: Fri Jul 31 10:26:40 2020 -0500 ARM: dts: socfpga: fix register entry for timer3 on Arria10 [ Upstream commit 0ff5a4812be4ebd4782bbb555d369636eea164f7 ] Fixes the register address for the timer3 entry on Arria10. Fixes: 475dc86d08de4 ("arm: dts: socfpga: Add a base DTSI for Altera's Arria10 SOC") Signed-off-by: Dinh Nguyen Signed-off-by: Sasha Levin commit 25915590865ceee0d054d648921f553403a004d9 Author: Michał Mirosław Date: Wed Aug 12 03:31:38 2020 +0200 regulator: remove superfluous lock in regulator_resolve_coupling() [ Upstream commit a577f3456c0a2fac3dee037c483753e6e68f3e49 ] The code modifies rdev, but locks c_rdev instead. Remove the lock as this is held together by regulator_list_mutex taken in the caller. Fixes: f9503385b187 ("regulator: core: Mutually resolve regulators coupling") Signed-off-by: Michał Mirosław Reviewed-by: Dmitry Osipenko Link: https://lore.kernel.org/r/25eb81cefb37a646f3e44eaaf1d8ae8881cfde52.1597195321.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 69163464bcd3d843e9152fbe62775719f7021b87 Author: Michał Mirosław Date: Wed Aug 12 03:31:34 2020 +0200 regulator: push allocation in regulator_ena_gpio_request() out of lock [ Upstream commit 467bf30142c64f2eb64e2ac67fa4595126230efd ] Move another allocation out of regulator_list_mutex-protected region, as reclaim might want to take the same lock. WARNING: possible circular locking dependency detected 5.7.13+ #534 Not tainted ------------------------------------------------------ kswapd0/383 is trying to acquire lock: c0e5d920 (regulator_list_mutex){+.+.}-{3:3}, at: regulator_lock_dependent+0x54/0x2c0 but task is already holding lock: c0e38518 (fs_reclaim){+.+.}-{0:0}, at: __fs_reclaim_acquire+0x0/0x50 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (fs_reclaim){+.+.}-{0:0}: fs_reclaim_acquire.part.11+0x40/0x50 fs_reclaim_acquire+0x24/0x28 kmem_cache_alloc_trace+0x40/0x1e8 regulator_register+0x384/0x1630 devm_regulator_register+0x50/0x84 reg_fixed_voltage_probe+0x248/0x35c [...] other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(fs_reclaim); lock(regulator_list_mutex); lock(fs_reclaim); lock(regulator_list_mutex); *** DEADLOCK *** [...] 2 locks held by kswapd0/383: #0: c0e38518 (fs_reclaim){+.+.}-{0:0}, at: __fs_reclaim_acquire+0x0/0x50 #1: cb70e5e0 (hctx->srcu){....}-{0:0}, at: hctx_lock+0x60/0xb8 [...] Fixes: 541d052d7215 ("regulator: core: Only support passing enable GPIO descriptors") [this commit only changes context] Fixes: f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking") [this is when the regulator_list_mutex was introduced in reclaim locking path] Signed-off-by: Michał Mirosław Link: https://lore.kernel.org/r/41fe6a9670335721b48e8f5195038c3d67a3bf92.1597195321.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit e9019af9b0cc954c1229e569e956b2fddf757dbd Author: Adam Ford Date: Fri Aug 14 07:24:41 2020 -0500 ARM: dts: logicpd-som-lv-baseboard: Fix missing video [ Upstream commit d1db7b80a6c8c5f81db0e80664d29b374750e2c6 ] A previous commit removed the panel-dpi driver, which made the SOM-LV video stop working because it relied on the DPI driver for setting video timings. Now that the simple-panel driver is available in omap2plus, this patch migrates the SOM-LV dev kits to use a similar panel and remove the manual timing requirements. A similar patch was already done and applied to the Torpedo family. Fixes: 8bf4b1621178 ("drm/omap: Remove panel-dpi driver") Signed-off-by: Adam Ford Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit 678cde6f4e2b208c31e994b54cb87833ed7b7f7b Author: Adam Ford Date: Fri Aug 14 07:53:38 2020 -0500 ARM: dts: logicpd-som-lv-baseboard: Fix broken audio [ Upstream commit 4d26e9a028e3d88223e06fa133c3d55af7ddbceb ] Older versions of U-Boot would pinmux the whole board, but as the bootloader got updated, it started to only pinmux the pins it needed, and expected Linux to configure what it needed. Unfortunately this caused an issue with the audio, because the mcbsp2 pins were configured in the device tree but never referenced by the driver. When U-Boot stopped muxing the audio pins, the audio died. This patch adds the references to the associate the pin controller with the mcbsp2 driver which makes audio operate again. Fixes: 5cb8b0fa55a9 ("ARM: dts: Move most of logicpd-som-lv-37xx-devkit.dts to logicpd-som-lv-baseboard.dtsi") Signed-off-by: Adam Ford Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit 06fb37a1725d725e94dc81f193905c79dbbf1647 Author: Adam Ford Date: Sat Aug 8 21:56:10 2020 -0500 ARM: dts: logicpd-torpedo-baseboard: Fix broken audio [ Upstream commit d7dfee67688ac7f2dfd4c3bc70c053ee990c40b5 ] Older versions of U-Boot would pinmux the whole board, but as the bootloader got updated, it started to only pinmux the pins it needed, and expected Linux to configure what it needed. Unfortunately this caused an issue with the audio, because the mcbsp2 pins were configured in the device tree, they were never referenced by the driver. When U-Boot stopped muxing the audio pins, the audio died. This patch adds the references to the associate the pin controller with the mcbsp2 driver which makes audio operate again. Fixes: 739f85bba5ab ("ARM: dts: Move most of logicpd-torpedo-37xx-devkit to logicpd-torpedo-baseboard") Signed-off-by: Adam Ford Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin