MISC:https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.15.17
Download: text/plain
Original: cdn.kernel.org archive.org
commit e8a2995c6076721d496d9458e13142caa7ba8753 Author: Greg Kroah-Hartman <[email protected]> Date: Thu Jan 27 11:05:44 2022 +0100 Linux 5.15.17 Link: https://lore.kernel.org/r/[email protected] Tested-by: Shuah Khan <[email protected]> Tested-by: Ron Economos <[email protected]> Link: https://lore.kernel.org/r/[email protected] Tested-by: Florian Fainelli <[email protected]> Tested-by: Jon Hunter <[email protected]> Tested-by: Shuah Khan <[email protected]> Tested-by: Justin M. Forbes <[email protected]> Tested-by: Ron Economos <[email protected]> Tested-by: Linux Kernel Functional Testing <[email protected]> Tested-by: Sudip Mukherjee <[email protected]> Tested-by: Alan Maguire <[email protected]> Reviewed-by: Tom Saeger <[email protected]> Tested-by: Guenter Roeck <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 4ea9b8ed6459db9c55d303d1709551e3d8fdf539 Author: Mauro Carvalho Chehab <[email protected]> Date: Thu Jan 6 01:41:02 2022 +0100 scripts: sphinx-pre-install: Fix ctex support on Debian commit 87d6576ddf8ac25f36597bc93ca17f6628289c16 upstream. The name of the package with ctexhook.sty is different on Debian/Ubuntu. Reported-by: Akira Yokosawa <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Tested-by: Akira Yokosawa <[email protected]> Link: https://lore.kernel.org/r/63882425609a2820fac78f5e94620abeb7ed5f6f.1641429634.git.mchehab@kernel.org Signed-off-by: Jonathan Corbet <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 21c9a4d2cdd4a20946e1ac925f9be6e23ded6ab6 Author: Mauro Carvalho Chehab <[email protected]> Date: Mon Jan 3 22:01:57 2022 +0100 scripts: sphinx-pre-install: add required ctex dependency commit 7baab965896eaeea60a54b8fe742feea2f79060f upstream. After a change meant to fix support for oriental characters (Chinese, Japanese, Korean), ctex stylesheet is now a requirement for PDF output. Reported-by: Christoph Hellwig <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Link: https://lore.kernel.org/r/165aa6167f21e3892a6e308688c93c756e94f4e0.1641243581.git.mchehab@kernel.org Signed-off-by: Jonathan Corbet <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit ffd8fd2faf4725ac94895494a4d67f13756a9438 Author: Andrey Konovalov <[email protected]> Date: Wed Jan 19 18:09:28 2022 -0800 lib/test_meminit: destroy cache in kmem_cache_alloc_bulk() test commit e073e5ef90298d2d6e5e7f04b545a0815e92110c upstream. Make do_kmem_cache_size_bulk() destroy the cache it creates. Link: https://lkml.kernel.org/r/aced20a94bf04159a139f0846e41d38a1537debb.1640018297.git.andreyknvl@google.com Fixes: 03a9349ac0e0 ("lib/test_meminit: add a kmem_cache_alloc_bulk() test") Signed-off-by: Andrey Konovalov <[email protected]> Reviewed-by: Marco Elver <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Dmitry Vyukov <[email protected]> Cc: Andrey Ryabinin <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 8d8f479e08a36672d3d36b79caee55e04ec3f065 Author: Moshe Tal <[email protected]> Date: Sun Jan 16 19:39:29 2022 +0200 bonding: Fix extraction of ports from the packet headers commit 429e3d123d9a50cc9882402e40e0ac912d88cfcf upstream. Wrong hash sends single stream to multiple output interfaces. The offset calculation was relative to skb->head, fix it to be relative to skb->data. Fixes: a815bde56b15 ("net, bonding: Refactor bond_xmit_hash for use with xdp_buff") Reviewed-by: Jussi Maki <[email protected]> Reviewed-by: Saeed Mahameed <[email protected]> Reviewed-by: Gal Pressman <[email protected]> Signed-off-by: Moshe Tal <[email protected]> Acked-by: Jay Vosburgh <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 52b66f818916600098c7ea954d749f2307770d9f Author: Alistair Popple <[email protected]> Date: Fri Jan 14 14:09:31 2022 -0800 mm/hmm.c: allow VM_MIXEDMAP to work with hmm_range_fault commit 87c01d57fa23de82fff593a7d070933d08755801 upstream. hmm_range_fault() can be used instead of get_user_pages() for devices which allow faulting however unlike get_user_pages() it will return an error when used on a VM_MIXEDMAP range. To make hmm_range_fault() more closely match get_user_pages() remove this restriction. This requires dealing with the !ARCH_HAS_PTE_SPECIAL case in hmm_vma_handle_pte(). Rather than replicating the logic of vm_normal_page() call it directly and do a check for the zero pfn similar to what get_user_pages() currently does. Also add a test to hmm selftest to verify functionality. Link: https://lkml.kernel.org/r/[email protected] Fixes: da4c3c735ea4 ("mm/hmm/mirror: helper to snapshot CPU page table") Signed-off-by: Alistair Popple <[email protected]> Reviewed-by: Jason Gunthorpe <[email protected]> Cc: Jerome Glisse <[email protected]> Cc: John Hubbard <[email protected]> Cc: Zi Yan <[email protected]> Cc: Ralph Campbell <[email protected]> Cc: Felix Kuehling <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 42de0446a142354f98caa3cdf8f930ca1cac7b14 Author: Miaoqian Lin <[email protected]> Date: Fri Jan 14 06:57:24 2022 +0000 lib82596: Fix IRQ check in sni_82596_probe commit 99218cbf81bf21355a3de61cd46a706d36e900e6 upstream. platform_get_irq() returns negative error number instead 0 on failure. And the doc of platform_get_irq() provides a usage example: int irq = platform_get_irq(pdev, 0); if (irq < 0) return irq; Fix the check of return value to catch errors correctly. Fixes: 115978859272 ("i825xx: Move the Intel 82586/82593/82596 based drivers") Signed-off-by: Miaoqian Lin <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 8d1e3f319160363d9d77af51cbe2765d187587fc Author: Matthias Schiffer <[email protected]> Date: Thu Jan 13 09:19:18 2022 +0100 scripts/dtc: dtx_diff: remove broken example from help text commit d8adf5b92a9d2205620874d498c39923ecea8749 upstream. dtx_diff suggests to use <(...) syntax to pipe two inputs into it, but this has never worked: The /proc/self/fds/... paths passed by the shell will fail the `[ -f "${dtx}" ] && [ -r "${dtx}" ]` check in compile_to_dts, but even with this check removed, the function cannot work: hexdump will eat up the DTB magic, making the subsequent dtc call fail, as a pipe cannot be rewound. Simply remove this broken example, as there is already an alternative one that works fine. Fixes: 10eadc253ddf ("dtc: create tool to diff device trees") Signed-off-by: Matthias Schiffer <[email protected]> Reviewed-by: Frank Rowand <[email protected]> Signed-off-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 46210f5051898d02e87b3bd0ae87aafa9b4180d5 Author: Maxim Mikityanskiy <[email protected]> Date: Wed Jan 12 12:28:05 2022 +0200 sch_api: Don't skip qdisc attach on ingress commit de2d807b294d3d2ce5e59043ae2634016765d076 upstream. The attach callback of struct Qdisc_ops is used by only a few qdiscs: mq, mqprio and htb. qdisc_graft() contains the following logic (pseudocode): if (!qdisc->ops->attach) { if (ingress) do ingress stuff; else do egress stuff; } if (!ingress) { ... if (qdisc->ops->attach) qdisc->ops->attach(qdisc); } else { ... } As we see, the attach callback is not called if the qdisc is being attached to ingress (TC_H_INGRESS). That wasn't a problem for mq and mqprio, since they contain a check that they are attached to TC_H_ROOT, and they can't be attached to TC_H_INGRESS anyway. However, the commit cited below added the attach callback to htb. It is needed for the hardware offload, but in the non-offload mode it simulates the "do egress stuff" part of the pseudocode above. The problem is that when htb is attached to ingress, neither "do ingress stuff" nor attach() is called. It results in an inconsistency, and the following message is printed to dmesg: unregister_netdevice: waiting for lo to become free. Usage count = 2 This commit addresses the issue by running "do ingress stuff" in the ingress flow even in the attach callback is present, which is fine, because attach isn't going to be called afterwards. The bug was found by syzbot and reported by Eric. Fixes: d03b195b5aa0 ("sch_htb: Hierarchical QoS hardware offload") Signed-off-by: Maxim Mikityanskiy <[email protected]> Reported-by: Eric Dumazet <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 814527dbc101590b05bf7335cf762eaeb8ada4c2 Author: Sam Protsenko <[email protected]> Date: Sun Nov 21 18:56:36 2021 +0200 dt-bindings: watchdog: Require samsung,syscon-phandle for Exynos7 commit 33950f9a36aca55c2b1e6062d9b29f3e97f91c40 upstream. Exynos7 watchdog driver is clearly indicating that its dts node must define syscon phandle property. That was probably forgotten, so add it. Signed-off-by: Sam Protsenko <[email protected]> Fixes: 2b9366b66967 ("watchdog: s3c2410_wdt: Add support for Watchdog device on Exynos7") Reviewed-by: Krzysztof Kozlowski <[email protected]> Reviewed-by: Rob Herring <[email protected]> Reviewed-by: Guenter Roeck <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Wim Van Sebroeck <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 34aa30c8ff902b672b3ae9551f5b7479828ffd7a Author: Alexander Stein <[email protected]> Date: Sun Dec 19 10:41:55 2021 +0100 dt-bindings: display: meson-vpu: Add missing amlogic,canvas property commit 640f35b871d29cd685ce0ea0762636381beeb98a upstream. This property was already mentioned in the old textual bindings amlogic,meson-vpu.txt, but got dropped during conversion. Adding it back similar to amlogic,gx-vdec.yaml. Fixes: 6b9ebf1e0e67 ("dt-bindings: display: amlogic, meson-vpu: convert to yaml") Signed-off-by: Alexander Stein <[email protected]> Acked-by: Rob Herring <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Reviewed-by: Martin Blumenstingl <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 3f219ebc9f63c70eb4097cbb8059d1fe0330ed93 Author: Alexander Stein <[email protected]> Date: Thu Dec 23 13:24:32 2021 +0100 dt-bindings: display: meson-dw-hdmi: add missing sound-name-prefix property commit 22bf4047d26980807611b7e2030803db375afd87 upstream. This is used in meson-gx and meson-g12. Add the property to the binding. This fixes the dtschema warning: hdmi-tx@c883a000: 'sound-name-prefix' does not match any of the regexes: 'pinctrl-[0-9]+' Signed-off-by: Alexander Stein <[email protected]> Fixes: 376bf52deef5 ("dt-bindings: display: amlogic, meson-dw-hdmi: convert to yaml") Acked-by: Neil Armstrong <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit e829e487f193559f61dfdb5ccbcab3769251d921 Author: Tom Rix <[email protected]> Date: Tue Jan 18 05:41:10 2022 -0800 net: mscc: ocelot: fix using match before it is set commit baa59504c1cd0cca7d41954a45ee0b3dc78e41a0 upstream. Clang static analysis reports this issue ocelot_flower.c:563:8: warning: 1st function call argument is an uninitialized value !is_zero_ether_addr(match.mask->dst)) { ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The variable match is used before it is set. So move the block. Fixes: 75944fda1dfe ("net: mscc: ocelot: offload ingress skbedit and vlan actions to VCAP IS1") Signed-off-by: Tom Rix <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit f864b6130498e6c688bcb2a41fa3afbae6b12fa3 Author: Claudiu Beznea <[email protected]> Date: Tue Jan 18 13:08:12 2022 +0200 net: phy: micrel: use kszphy_suspend()/kszphy_resume for irq aware devices commit f1131b9c23fb4a3540a774828ff49f421619f902 upstream. On a setup with KSZ9131 and MACB drivers it happens on suspend path, from time to time, that the PHY interrupt arrives after PHY and MACB were suspended (PHY via genphy_suspend(), MACB via macb_suspend()). In this case the phy_read() at the beginning of kszphy_handle_interrupt() will fail (as MACB driver is suspended at this time) leading to phy_error() being called and a stack trace being displayed on console. To solve this .suspend/.resume functions for all KSZ devices implementing .handle_interrupt were replaced with kszphy_suspend()/kszphy_resume() which disable/enable interrupt before/after calling genphy_suspend()/genphy_resume(). The fix has been adapted for all KSZ devices which implements .handle_interrupt but it has been tested only on KSZ9131. Fixes: 59ca4e58b917 ("net: phy: micrel: implement generic .handle_interrupt() callback") Signed-off-by: Claudiu Beznea <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit ed27539e5a4b1ab255b9d73b4ca8c12716c0d817 Author: Ard Biesheuvel <[email protected]> Date: Tue Jan 18 11:22:04 2022 +0100 net: cpsw: avoid alignment faults by taking NET_IP_ALIGN into account commit 1771afd47430f5e95c9c3a2e3a8a63e67402d3fe upstream. Both versions of the CPSW driver declare a CPSW_HEADROOM_NA macro that takes NET_IP_ALIGN into account, but fail to use it appropriately when storing incoming packets in memory. This results in the IPv4 source and destination addresses to appear misaligned in memory, which causes aligment faults that need to be fixed up in software. So let's switch from CPSW_HEADROOM to CPSW_HEADROOM_NA where needed. This gets rid of any alignment faults on the RX path on a Beaglebone White. Fixes: 9ed4050c0d75 ("net: ethernet: ti: cpsw: add XDP support") Cc: Grygorii Strashko <[email protected]> Cc: Ilias Apalodimas <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit d1a29a4e334b82c5a95cfe24d9480ee44f19c83f Author: Russell King (Oracle) <[email protected]> Date: Mon Jan 17 14:52:33 2022 +0000 net: sfp: fix high power modules without diagnostic monitoring commit 5765cee119bf5a36c94d20eceb37c445508934be upstream. Commit 7cfa9c92d0a3 ("net: sfp: avoid power switch on address-change modules") unintetionally changed the semantics for high power modules without the digital diagnostics monitoring. We repeatedly attempt to read the power status from the non-existing 0xa2 address in a futile hope this failure is temporary: [ 8.856051] sfp sfp-eth3: module NTT 0000000000000000 rev 0000 sn 0000000000000000 dc 160408 [ 8.865843] mvpp2 f4000000.ethernet eth3: switched to inband/1000base-x link mode [ 8.873469] sfp sfp-eth3: Failed to read EEPROM: -5 [ 8.983251] sfp sfp-eth3: Failed to read EEPROM: -5 [ 9.103250] sfp sfp-eth3: Failed to read EEPROM: -5 We previosuly assumed such modules were powered up in the correct mode, continuing without further configuration as long as the required power class was supported by the host. Restore this behaviour, while preserving the intent of subsequent patches to avoid the "Address Change Sequence not supported" warning if we are not going to be accessing the DDM address. Fixes: 7cfa9c92d0a3 ("net: sfp: avoid power switch on address-change modules") Reported-by: 照山周一郎 <[email protected]> Tested-by: 照山周一郎 <[email protected]> Signed-off-by: Russell King (Oracle) <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit a2faa4a272621a92ab82f69936443ac8af5c9ddc Author: Horatiu Vultur <[email protected]> Date: Mon Jan 17 13:53:00 2022 +0100 net: ocelot: Fix the call to switchdev_bridge_port_offload commit c0b7f7d7e0ad44f35745c01964b3fa2833e298cb upstream. In the blamed commit, the call to the function switchdev_bridge_port_offload was passing the wrong argument for atomic_nb. It was ocelot_netdevice_nb instead of ocelot_swtchdev_nb. This patch fixes this issue. Fixes: 4e51bf44a03af6 ("net: bridge: move the switchdev object replay helpers to "push" mode") Signed-off-by: Horatiu Vultur <[email protected]> Reviewed-by: Vladimir Oltean <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit f8df88d6d10cdc728c6c9a5036a91e0339638188 Author: Tom Rix <[email protected]> Date: Sat Jan 15 09:49:18 2022 -0800 net: ethernet: mtk_eth_soc: fix error checking in mtk_mac_config() commit 214b3369ab9b0a6f28d6c970220c209417edbc65 upstream. Clang static analysis reports this problem mtk_eth_soc.c:394:7: warning: Branch condition evaluates to a garbage value if (err) ^~~ err is not initialized and only conditionally set. So intitialize err. Fixes: 7e538372694b ("net: ethernet: mediatek: Re-add support SGMII") Signed-off-by: Tom Rix <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit c2d55304dba82b4852883012b785c97d1a884c9b Author: Slark Xiao <[email protected]> Date: Sat Jan 15 10:34:30 2022 +0800 net: wwan: Fix MRU mismatch issue which may lead to data connection lost commit f542cdfa3083a309e3caafbbdf41490c4935492a upstream. In pci_generic.c there is a 'mru_default' in struct mhi_pci_dev_info. This value shall be used for whole mhi if it's given a value for a specific product. But in function mhi_net_rx_refill_work(), it's still using hard code value MHI_DEFAULT_MRU. 'mru_default' shall have higher priority than MHI_DEFAULT_MRU. And after checking, this change could help fix a data connection lost issue. Fixes: 5c2c85315948 ("bus: mhi: pci-generic: configurable network interface MRU") Signed-off-by: Shujun Wang <[email protected]> Signed-off-by: Slark Xiao <[email protected]> Reviewed-by: Loic Poulain <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 5715614a9da8c3daa48273c63682000839f6cadb Author: Sergey Shtylyov <[email protected]> Date: Thu Jan 13 22:46:07 2022 +0300 bcmgenet: add WOL IRQ check commit 9deb48b53e7f4056c2eaa2dc2ee3338df619e4f6 upstream. The driver neglects to check the result of platform_get_irq_optional()'s call and blithely passes the negative error codes to devm_request_irq() (which takes *unsigned* IRQ #), causing it to fail with -EINVAL. Stop calling devm_request_irq() with the invalid IRQ #s. Fixes: 8562056f267d ("net: bcmgenet: request Wake-on-LAN interrupt") Signed-off-by: Sergey Shtylyov <[email protected]> Acked-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 784ea1478f4dd8d86d07f45dfb0bd57f7ff9ed18 Author: Vladimir Oltean <[email protected]> Date: Wed Jan 12 22:21:27 2022 +0200 net: mscc: ocelot: don't let phylink re-enable TX PAUSE on the NPI port commit 33cb0ff30cff104e753f7882c99e54cf67ea7903 upstream. Since commit b39648079db4 ("net: mscc: ocelot: disable flow control on NPI interface"), flow control should be disabled on the DSA CPU port when used in NPI mode. However, the commit blamed in the Fixes: tag below broke this, because it allowed felix_phylink_mac_link_up() to overwrite SYS_PAUSE_CFG_PAUSE_ENA for the DSA CPU port. This issue became noticeable since the device tree update from commit 8fcea7be5736 ("arm64: dts: ls1028a: mark internal links between Felix and ENETC as capable of flow control"). The solution is to check whether this is the currently configured NPI port from ocelot_phylink_mac_link_up(), and to not modify the statically disabled PAUSE frame transmission if it is. When the port is configured for lossless mode as opposed to tail drop mode, but the link partner (DSA master) doesn't observe the transmitted PAUSE frames, the switch termination throughput is much worse, as can be seen below. Before: root@debian:~# iperf3 -c 192.168.100.2 Connecting to host 192.168.100.2, port 5201 [ 5] local 192.168.100.1 port 37504 connected to 192.168.100.2 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 28.4 MBytes 238 Mbits/sec 357 22.6 KBytes [ 5] 1.00-2.00 sec 33.6 MBytes 282 Mbits/sec 426 19.8 KBytes [ 5] 2.00-3.00 sec 34.0 MBytes 285 Mbits/sec 343 21.2 KBytes [ 5] 3.00-4.00 sec 32.9 MBytes 276 Mbits/sec 354 22.6 KBytes [ 5] 4.00-5.00 sec 32.3 MBytes 271 Mbits/sec 297 18.4 KBytes ^C[ 5] 5.00-5.06 sec 2.05 MBytes 270 Mbits/sec 45 19.8 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-5.06 sec 163 MBytes 271 Mbits/sec 1822 sender [ 5] 0.00-5.06 sec 0.00 Bytes 0.00 bits/sec receiver After: root@debian:~# iperf3 -c 192.168.100.2 Connecting to host 192.168.100.2, port 5201 [ 5] local 192.168.100.1 port 49470 connected to 192.168.100.2 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 112 MBytes 941 Mbits/sec 259 143 KBytes [ 5] 1.00-2.00 sec 110 MBytes 920 Mbits/sec 329 144 KBytes [ 5] 2.00-3.00 sec 112 MBytes 936 Mbits/sec 255 144 KBytes [ 5] 3.00-4.00 sec 110 MBytes 927 Mbits/sec 355 105 KBytes [ 5] 4.00-5.00 sec 110 MBytes 926 Mbits/sec 350 156 KBytes [ 5] 5.00-6.00 sec 110 MBytes 925 Mbits/sec 305 148 KBytes [ 5] 6.00-7.00 sec 110 MBytes 924 Mbits/sec 320 143 KBytes [ 5] 7.00-8.00 sec 110 MBytes 925 Mbits/sec 273 97.6 KBytes [ 5] 8.00-9.00 sec 109 MBytes 913 Mbits/sec 299 141 KBytes [ 5] 9.00-10.00 sec 110 MBytes 922 Mbits/sec 287 146 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 1.08 GBytes 926 Mbits/sec 3032 sender [ 5] 0.00-10.00 sec 1.08 GBytes 925 Mbits/sec receiver Fixes: de274be32cb2 ("net: dsa: felix: set TX flow control according to the phylink_mac_link_up resolution") Reported-by: Xiaoliang Yang <[email protected]> Signed-off-by: Vladimir Oltean <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit b4e6455d7ffc60a2803b4794f01631c9d27e0b1e Author: Kevin Bracey <[email protected]> Date: Wed Jan 12 19:02:10 2022 +0200 net_sched: restore "mpu xxx" handling commit fb80445c438c78b40b547d12b8d56596ce4ccfeb upstream. commit 56b765b79e9a ("htb: improved accuracy at high rates") broke "overhead X", "linklayer atm" and "mpu X" attributes. "overhead X" and "linklayer atm" have already been fixed. This restores the "mpu X" handling, as might be used by DOCSIS or Ethernet shaping: tc class add ... htb rate X overhead 4 mpu 64 The code being fixed is used by htb, tbf and act_police. Cake has its own mpu handling. qdisc_calculate_pkt_len still uses the size table containing values adjusted for mpu by user space. iproute2 tc has always passed mpu into the kernel via a tc_ratespec structure, but the kernel never directly acted on it, merely stored it so that it could be read back by `tc class show`. Rather, tc would generate length-to-time tables that included the mpu (and linklayer) in their construction, and the kernel used those tables. Since v3.7, the tables were no longer used. Along with "mpu", this also broke "overhead" and "linklayer" which were fixed in 01cb71d2d47b ("net_sched: restore "overhead xxx" handling", v3.10) and 8a8e3d84b171 ("net_sched: restore "linklayer atm" handling", v3.11). "overhead" was fixed by simply restoring use of tc_ratespec::overhead - this had originally been used by the kernel but was initially omitted from the new non-table-based calculations. "linklayer" had been handled in the table like "mpu", but the mode was not originally passed in tc_ratespec. The new implementation was made to handle it by getting new versions of tc to pass the mode in an extended tc_ratespec, and for older versions of tc the table contents were analysed at load time to deduce linklayer. As "mpu" has always been given to the kernel in tc_ratespec, accompanying the mpu-based table, we can restore system functionality with no userspace change by making the kernel act on the tc_ratespec value. Fixes: 56b765b79e9a ("htb: improved accuracy at high rates") Signed-off-by: Kevin Bracey <[email protected]> Cc: Eric Dumazet <[email protected]> Cc: Jiri Pirko <[email protected]> Cc: Vimalkumar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 75a09b8d02084edf325f24c24a7c08338831b5a4 Author: Alex Elder <[email protected]> Date: Wed Jan 12 07:30:10 2022 -0600 net: ipa: fix atomic update in ipa_endpoint_replenish() commit 6c0e3b5ce94947b311348c367db9e11dcb2ccc93 upstream. In ipa_endpoint_replenish(), if an error occurs when attempting to replenish a receive buffer, we just quit and try again later. In that case we increment the backlog count to reflect that the attempt was unsuccessful. Then, if the add_one flag was true we increment the backlog again. This second increment is not included in the backlog local variable though, and its value determines whether delayed work should be scheduled. This is a bug. Fix this by determining whether 1 or 2 should be added to the backlog before adding it in a atomic_add_return() call. Reviewed-by: Matthias Kaehlcke <[email protected]> Fixes: 84f9bd12d46db ("soc: qcom: ipa: IPA endpoints") Signed-off-by: Alex Elder <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit f1d206181f19b00b275b258fea1418718a2f4173 Author: Jie Wang <[email protected]> Date: Wed Jan 12 20:54:18 2022 +0800 net: bonding: fix bond_xmit_broadcast return value error bug commit 4e5bd03ae34652cd932ab4c91c71c511793df75c upstream. In Linux bonding scenario, one packet is copied to several copies and sent by all slave device of bond0 in mode 3(broadcast mode). The mode 3 xmit function bond_xmit_broadcast() only ueses the last slave device's tx result as the final result. In this case, if the last slave device is down, then it always return NET_XMIT_DROP, even though the other slave devices xmit success. It may cause the tx statistics error, and cause the application (e.g. scp) consider the network is unreachable. For example, use the following command to configure server A. echo 3 > /sys/class/net/bond0/bonding/mode ifconfig bond0 up ifenslave bond0 eth0 eth1 ifconfig bond0 192.168.1.125 ifconfig eth0 up ifconfig eth1 down The slave device eth0 and eth1 are connected to server B(192.168.1.107). Run the ping 192.168.1.107 -c 3 -i 0.2 command, the following information is displayed. PING 192.168.1.107 (192.168.1.107) 56(84) bytes of data. 64 bytes from 192.168.1.107: icmp_seq=1 ttl=64 time=0.077 ms 64 bytes from 192.168.1.107: icmp_seq=2 ttl=64 time=0.056 ms 64 bytes from 192.168.1.107: icmp_seq=3 ttl=64 time=0.051 ms 192.168.1.107 ping statistics 0 packets transmitted, 3 received Actually, the slave device eth0 of the bond successfully sends three ICMP packets, but the result shows that 0 packets are transmitted. Also if we use scp command to get remote files, the command end with the following printings. ssh_exchange_identification: read: Connection timed out So this patch modifies the bond_xmit_broadcast to return NET_XMIT_SUCCESS if one slave device in the bond sends packets successfully. If all slave devices send packets fail, the discarded packets stats is increased. The skb is released when there is no slave device in the bond or the last slave device is down. Fixes: ae46f184bc1f ("bonding: propagate transmit status") Signed-off-by: Jie Wang <[email protected]> Signed-off-by: Guangbin Huang <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 62009fa50c1a70a291f8f72a66b08449a03ea50e Author: Miroslav Lichvar <[email protected]> Date: Tue Jan 11 16:10:53 2022 +0100 net: fix sock_timestamping_bind_phc() to release device commit 2a4d75bfe41232608f5596a6d1369f92ccb20817 upstream. Don't forget to release the device in sock_timestamping_bind_phc() after it was used to get the vclock indices. Fixes: d463126e23f1 ("net: sock: extend SO_TIMESTAMPING for PHC binding") Signed-off-by: Miroslav Lichvar <[email protected]> Cc: Yangbo Lu <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 55d613f5d4c26ac8e5c5addc4d2dd4e876016750 Author: David Heidelberg <[email protected]> Date: Sat Oct 30 12:04:12 2021 +0200 arm64: dts: qcom: msm8996: drop not documented adreno properties commit c41910f257a22dc406c60d8826b4a3b5398003a3 upstream. These properties aren't documented nor implemented in the driver. Drop them. Fixes warnings as: $ make dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/msm/gpu.yaml ... arch/arm64/boot/dts/qcom/msm8996-mtp.dt.yaml: gpu@b00000: 'qcom,gpu-quirk-fault-detect-mask', 'qcom,gpu-quirk-two-pass-use-wfi' do not match any of the regexes: 'pinctrl-[0-9]+' From schema: Documentation/devicetree/bindings/display/msm/gpu.yaml ... Fixes: 69cc3114ab0f ("arm64: dts: Add Adreno GPU definitions") Signed-off-by: David Heidelberg <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 795ad139ed915f7ef726490a3be86cd559f3ee05 Author: Leon Romanovsky <[email protected]> Date: Sun Nov 28 14:14:46 2021 +0200 devlink: Remove misleading internal_flags from health reporter dump commit e9538f8270db24d272659e15841854c7ea11119e upstream. DEVLINK_CMD_HEALTH_REPORTER_DUMP_GET command doesn't have .doit callback and has no use in internal_flags at all. Remove this misleading assignment. Fixes: e44ef4e4516c ("devlink: Hang reporter's dump method on a dumpit cb") Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 228a7024ed8a9e269b45ea12171c2265baaf50cc Author: Zechuan Chen <[email protected]> Date: Tue Dec 28 19:13:38 2021 +0800 perf probe: Fix ppc64 'perf probe add events failed' case commit 4624f199327a704dd1069aca1c3cadb8f2a28c6f upstream. Because of commit bf794bf52a80c627 ("powerpc/kprobes: Fix kallsyms lookup across powerpc ABIv1 and ABIv2"), in ppc64 ABIv1, our perf command eliminates the need to use the prefix "." at the symbol name. But when the command "perf probe -a schedule" is executed on ppc64 ABIv1, it obtains two symbol address information through /proc/kallsyms, for example: cat /proc/kallsyms | grep -w schedule c000000000657020 T .schedule c000000000d4fdb8 D schedule The symbol "D schedule" is not a function symbol, and perf will print: "p:probe/schedule _text+13958584"Failed to write event: Invalid argument Therefore, when searching symbols from map and adding probe point for them, a symbol type check is added. If the type of symbol is not a function, skip it. Fixes: bf794bf52a80c627 ("powerpc/kprobes: Fix kallsyms lookup across powerpc ABIv1 and ABIv2") Signed-off-by: Zechuan Chen <[email protected]> Acked-by: Masami Hiramatsu <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jianlin Lv <[email protected]> Cc: Jin Yao <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Michael Ellerman <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Naveen N. Rao <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Ravi Bangoria <[email protected]> Cc: Yang Jihong <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 115b85125624457bfc859ea2b6d9a9366535ff53 Author: Uwe Kleine-König <[email protected]> Date: Fri Dec 3 22:05:44 2021 +0100 perf tools: Drop requirement for libstdc++.so for libopencsd check commit ed17b1914978eddb2b01f2d34577f1c82518c650 upstream. It's possible to link against libopencsd_c_api without having libstdc++.so available, only libstdc++.so.6.0.28 (or whatever version is in use) needs to be available. The same holds true for libopencsd.so. When -lstdc++ (or -lopencsd) is explicitly passed to the linker however the .so file must be available. So wrap adding the dependencies into a check for static linking that actually requires adding them all. The same construct is already used for some other tests in the same file to reduce dependencies in the dynamic linking case. Fixes: 573cf5c9a152 ("perf build: Add missing -lstdc++ when linking with libopencsd") Reviewed-by: James Clark <[email protected]> Signed-off-by: Uwe Kleine-König <[email protected]> Cc: Adrian Bunk <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Branislav Rankov <[email protected]> Cc: Diederik de Haas <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit e73f737a6e71e863dc46dff5061b2ca4543ba84b Author: Tudor Ambarus <[email protected]> Date: Wed Dec 15 13:01:13 2021 +0200 dmaengine: at_xdmac: Fix at_xdmac_lld struct definition commit 912f7c6f7fac273f40e621447cf17d14b50d6e5b upstream. The hardware channel next descriptor view structure contains just fields of 32 bits, while dma_addr_t can be of type u64 or u32 depending on CONFIG_ARCH_DMA_ADDR_T_64BIT. Force u32 to comply with what the hardware expects. Fixes: e1f7c9eee707 ("dmaengine: at_xdmac: creation of the atmel eXtended DMA Controller driver") Signed-off-by: Tudor Ambarus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit b81e898073c24cb4fb9a5946d44d605197df92a2 Author: Tudor Ambarus <[email protected]> Date: Wed Dec 15 13:01:12 2021 +0200 dmaengine: at_xdmac: Fix lld view setting commit 1385eb4d14d447cc5d744bc2ac34f43be66c9963 upstream. AT_XDMAC_CNDC_NDVIEW_NDV3 was set even for AT_XDMAC_MBR_UBC_NDV2, because of the wrong bit handling. Fix it. Fixes: ee0fe35c8dcd ("dmaengine: xdmac: Handle descriptor's view 3 registers") Signed-off-by: Tudor Ambarus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit fb8f0e827af24f8abf503fa6a0cb4917e95ca04c Author: Tudor Ambarus <[email protected]> Date: Wed Dec 15 13:01:10 2021 +0200 dmaengine: at_xdmac: Fix concurrency over xfers_list commit 18deddea9184b62941395889ff7659529c877326 upstream. Since tx_submit can be called from a hard IRQ, xfers_list must be protected with a lock to avoid concurency on the list's elements. Since at_xdmac_handle_cyclic() is called from a tasklet, spin_lock_irq is enough to protect from a hard IRQ. Fixes: e1f7c9eee707 ("dmaengine: at_xdmac: creation of the atmel eXtended DMA Controller driver") Signed-off-by: Tudor Ambarus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 5a8547fc3c215c0efa7c24c09da5dea1288f14a1 Author: Tudor Ambarus <[email protected]> Date: Wed Dec 15 13:01:06 2021 +0200 dmaengine: at_xdmac: Print debug message after realeasing the lock commit 5edc24ac876a928f36f407a0fcdb33b94a3a210f upstream. It is desirable to do the prints without the lock held if possible, so move the print after the lock is released. Fixes: e1f7c9eee707 ("dmaengine: at_xdmac: creation of the atmel eXtended DMA Controller driver") Signed-off-by: Tudor Ambarus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit da1875fd4c255a7b3313b2f9cc3befd33cb84a3f Author: Tudor Ambarus <[email protected]> Date: Wed Dec 15 13:01:05 2021 +0200 dmaengine: at_xdmac: Start transfer for cyclic channels in issue_pending commit e6af9b05bec63cd4d1de2a33968cd0be2a91282a upstream. Cyclic channels must too call issue_pending in order to start a transfer. Start the transfer in issue_pending regardless of the type of channel. This wrongly worked before, because in the past the transfer was started at tx_submit level when only a desc in the transfer list. Fixes: e1f7c9eee707 ("dmaengine: at_xdmac: creation of the atmel eXtended DMA Controller driver") Signed-off-by: Tudor Ambarus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 45e0d51850313f769436552a2ff65e613b70db1d Author: Tudor Ambarus <[email protected]> Date: Wed Dec 15 13:01:04 2021 +0200 dmaengine: at_xdmac: Don't start transactions at tx_submit level commit bccfb96b59179d4f96cbbd1ddff8fac6d335eae4 upstream. tx_submit is supposed to push the current transaction descriptor to a pending queue, waiting for issue_pending() to be called. issue_pending() must start the transfer, not tx_submit(), thus remove at_xdmac_start_xfer() from at_xdmac_tx_submit(). Clients of at_xdmac that assume that tx_submit() starts the transfer must be updated and call dma_async_issue_pending() if they miss to call it (one example is atmel_serial). As the at_xdmac_start_xfer() is now called only from at_xdmac_advance_work() when !at_xdmac_chan_is_enabled(), the at_xdmac_chan_is_enabled() check is no longer needed in at_xdmac_start_xfer(), thus remove it. Fixes: e1f7c9eee707 ("dmaengine: at_xdmac: creation of the atmel eXtended DMA Controller driver") Signed-off-by: Tudor Ambarus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit e127c17af30ec7cf57e6bcf2fc33974b5ef9480f Author: Adrian Hunter <[email protected]> Date: Wed Jan 12 10:50:57 2022 +0200 perf script: Fix hex dump character output commit 62942e9fda9fd1def10ffcbd5e1c025b3c9eec17 upstream. Using grep -C with perf script -D can give erroneous results as grep loses lines due to non-printable characters, for example, below the 0020, 0060 and 0070 lines are missing: $ perf script -D | grep -C10 AUX | head . 0010: 08 00 00 00 00 00 00 00 1f 00 00 00 00 00 00 00 ................ . 0030: 01 00 00 00 00 00 00 00 00 04 00 00 00 00 00 00 ................ . 0040: 00 08 00 00 00 00 00 00 02 00 00 00 00 00 00 00 ................ . 0050: 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 ................ . 0080: 02 00 00 00 00 00 00 00 1b 00 00 00 00 00 00 00 ................ . 0090: 00 00 00 00 00 00 00 00 ........ 0 0 0x450 [0x98]: PERF_RECORD_AUXTRACE_INFO type: 1 PMU Type 8 Time Shift 31 perf's isprint() is a custom implementation from the kernel, but the kernel's _ctype appears to include characters from Latin-1 Supplement which is not compatible with, for example, UTF-8. Fix by checking also isascii(). After: $ tools/perf/perf script -D | grep -C10 AUX | head . 0010: 08 00 00 00 00 00 00 00 1f 00 00 00 00 00 00 00 ................ . 0020: 03 84 32 2f 00 00 00 00 63 7c 4f d2 fa ff ff ff ..2/....c|O..... . 0030: 01 00 00 00 00 00 00 00 00 04 00 00 00 00 00 00 ................ . 0040: 00 08 00 00 00 00 00 00 02 00 00 00 00 00 00 00 ................ . 0050: 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 ................ . 0060: 00 02 00 00 00 00 00 00 00 c0 03 00 00 00 00 00 ................ . 0070: e2 00 00 00 00 00 00 00 02 00 00 00 00 00 00 00 ................ . 0080: 02 00 00 00 00 00 00 00 1b 00 00 00 00 00 00 00 ................ . 0090: 00 00 00 00 00 00 00 00 ........ Fixes: 3052ba56bcb58904 ("tools perf: Move from sane_ctype.h obtained from git to the Linux's original") Signed-off-by: Adrian Hunter <[email protected]> Cc: Jiri Olsa <[email protected]> Link: http://lore.kernel.org/lkml/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 48a46df6d5428898c9a7abe618168fea185d3bd3 Author: Guillaume Nault <[email protected]> Date: Mon Jan 10 14:43:11 2022 +0100 libcxgb: Don't accidentally set RTO_ONLINK in cxgb_find_route() commit a915deaa9abe4fb3a440312c954253a6a733608e upstream. Mask the ECN bits before calling ip_route_output_ports(). The tos variable might be passed directly from an IPv4 header, so it may have the last ECN bit set. This interferes with the route lookup process as ip_route_output_key_hash() interpretes this bit specially (to restrict the route scope). Found by code inspection, compile tested only. Fixes: 804c2f3e36ef ("libcxgb,iw_cxgb4,cxgbit: add cxgb_find_route()") Signed-off-by: Guillaume Nault <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 09c0535c768de9429a15c522007dfc8e96a428f8 Author: Guillaume Nault <[email protected]> Date: Mon Jan 10 14:43:09 2022 +0100 gre: Don't accidentally set RTO_ONLINK in gre_fill_metadata_dst() commit f7716b318568b22fbf0e3be99279a979e217cf71 upstream. Mask the ECN bits before initialising ->flowi4_tos. The tunnel key may have the last ECN bit set, which will interfere with the route lookup process as ip_route_output_key_hash() interpretes this bit specially (to restrict the route scope). Found by code inspection, compile tested only. Fixes: 962924fa2b7a ("ip_gre: Refactor collect metatdata mode tunnel xmit to ip_md_tunnel_xmit") Signed-off-by: Guillaume Nault <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 63bc14d6e2615e9f89f7110c97ad6e6433379007 Author: Eli Cohen <[email protected]> Date: Wed Jan 5 13:46:41 2022 +0200 vdpa/mlx5: Restore cur_num_vqs in case of failure in change_num_qps() commit 37e07e705888e4c3502f204e9c6785c9c2d6d86a upstream. Restore ndev->cur_num_vqs to the original value in case change_num_qps() fails. Fixes: 52893733f2c5 ("vdpa/mlx5: Add multiqueue support") Reviewed-by: Si-Wei Liu<[email protected]> Acked-by: Jason Wang <[email protected]> Signed-off-by: Eli Cohen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Michael S. Tsirkin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 786e608e97b91227b069517fac6118dfc1ad2c95 Author: Guillaume Nault <[email protected]> Date: Mon Jan 10 14:43:06 2022 +0100 xfrm: Don't accidentally set RTO_ONLINK in decode_session4() commit 23e7b1bfed61e301853b5e35472820d919498278 upstream. Similar to commit 94e2238969e8 ("xfrm4: strip ECN bits from tos field"), clear the ECN bits from iph->tos when setting ->flowi4_tos. This ensures that the last bit of ->flowi4_tos is cleared, so ip_route_output_key_hash() isn't going to restrict the scope of the route lookup. Use ~INET_ECN_MASK instead of IPTOS_RT_MASK, because we have no reason to clear the high order bits. Found by code inspection, compile tested only. Fixes: 4da3089f2b58 ("[IPSEC]: Use TOS when doing tunnel lookups") Signed-off-by: Guillaume Nault <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 6dc6e9f9d94de22f021491c8cf83d8ca9f63a046 Author: Johannes Berg <[email protected]> Date: Fri Dec 10 09:06:11 2021 +0200 iwlwifi: fix Bz NMI behaviour commit fdfde0cb79264f88992e72b5a056a3a3284fcaad upstream. Contrary to what was stated before, the hardware hasn't changed the bits here yet. In any case, the new CSR is also directly (lower 16 bits) connected to UREG_DOORBELL_TO_ISR6, so if it still changes the changes would be there. Adjust the code and comments accordingly. Signed-off-by: Johannes Berg <[email protected]> Fixes: 6c0795f1a524 ("iwlwifi: implement Bz NMI behaviour") Signed-off-by: Luca Coelho <[email protected]> Link: https://lore.kernel.org/r/iwlwifi.20211210090244.75b6207536e3.I7d170a48a9096e6b7269c3a9f447c326f929b171@changeid Signed-off-by: Luca Coelho <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 31428796ca4b00cc10fda059ac24eb0be61778d5 Author: Eric Dumazet <[email protected]> Date: Tue Jan 18 03:43:40 2022 -0800 netns: add schedule point in ops_exit_list() commit 2836615aa22de55b8fca5e32fe1b27a67cda625e upstream. When under stress, cleanup_net() can have to dismantle netns in big numbers. ops_exit_list() currently calls many helpers [1] that have no schedule point, and we can end up with soft lockups, particularly on hosts with many cpus. Even for moderate amount of netns processed by cleanup_net() this patch avoids latency spikes. [1] Some of these helpers like fib_sync_up() and fib_sync_down_dev() are very slow because net/ipv4/fib_semantics.c uses host-wide hash tables, and ifindex is used as the only input of two hash functions. ifindexes tend to be the same for all netns (lo.ifindex==1 per instance) This will be fixed in a separate patch. Fixes: 72ad937abd0a ("net: Add support for batching network namespace cleanups") Signed-off-by: Eric Dumazet <[email protected]> Cc: Eric W. Biederman <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 958cbb139ec4a58cc2a9652e72e9c54882da0682 Author: Eric Dumazet <[email protected]> Date: Thu Jan 13 01:22:29 2022 -0800 inet: frags: annotate races around fqdir->dead and fqdir->high_thresh commit 91341fa0003befd097e190ec2a4bf63ad957c49a upstream. Both fields can be read/written without synchronization, add proper accessors and documentation. Fixes: d5dd88794a13 ("inet: fix various use-after-free in defrags units") Signed-off-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 0288b85d750e9466c0ab295c25e1c903f21d924f Author: Eric W. Biederman <[email protected]> Date: Mon Jan 3 11:32:36 2022 -0600 taskstats: Cleanup the use of task->exit_code commit 1b5a42d9c85f0e731f01c8d1129001fd8531a8a0 upstream. In the function bacct_add_task the code reading task->exit_code was introduced in commit f3cef7a99469 ("[PATCH] csa: basic accounting over taskstats"), and it is not entirely clear what the taskstats interface is trying to return as only returning the exit_code of the first task in a process doesn't make a lot of sense. As best as I can figure the intent is to return task->exit_code after a task exits. The field is returned with per task fields, so the exit_code of the entire process is not wanted. Only the value of the first task is returned so this is not a useful way to get the per task ptrace stop code. The ordinary case of returning this value is returning after a task exits, which also precludes use for getting a ptrace value. It is common to for the first task of a process to also be the last task of a process so this field may have done something reasonable by accident in testing. Make ac_exitcode a reliable per task value by always returning it for every exited task. Setting ac_exitcode in a sensible mannter makes it possible to continue to provide this value going forward. Cc: Balbir Singh <[email protected]> Fixes: f3cef7a99469 ("[PATCH] csa: basic accounting over taskstats") Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: "Eric W. Biederman" <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit be82a92c46bc9b80781f6bcfba7ffcc527c1bfee Author: Michael S. Tsirkin <[email protected]> Date: Thu Jan 6 07:57:46 2022 -0500 virtio_ring: mark ring unused on error commit 1861ba626ae9b98136f3e504208cdef6b29cd3ec upstream. A recently added error path does not mark ring unused when exiting on OOM, which will lead to BUG on the next entry in debug builds. TODO: refactor code so we have START_USE and END_USE in the same function. Fixes: fc6d70f40b3d ("virtio_ring: check desc == NULL when using indirect with packed") Cc: "Xuan Zhuo" <[email protected]> Cc: Jiasheng Jiang <[email protected]> Reviewed-by: Xuan Zhuo <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 0d3334c47a2eb0088432e38f91b8689b2c2762e2 Author: Eli Cohen <[email protected]> Date: Thu Dec 30 16:20:24 2021 +0200 vdpa/mlx5: Fix wrong configuration of virtio_version_1_0 commit 97143b70aa847f2b0a1f959dde126b76ff7b5376 upstream. Remove overriding of virtio_version_1_0 which forced the virtqueue object to version 1. Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5 devices") Signed-off-by: Eli Cohen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Michael S. Tsirkin <[email protected]> Reviewed-by: Parav Pandit <[email protected]> Acked-by: Jason Wang <[email protected]> Reviewed-by: Si-Wei Liu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 087d45cd0f1a53b06cc41d9d3cd48ed0bbae43ab Author: Laurence de Bruxelles <[email protected]> Date: Sat Jan 1 15:41:49 2022 +0000 rtc: pxa: fix null pointer dereference commit 34127b3632b21e5c391756e724b1198eb9917981 upstream. With the latest stable kernel versions the rtc on the PXA based Zaurus does not work, when booting I see the following kernel messages: pxa-rtc pxa-rtc: failed to find rtc clock source pxa-rtc pxa-rtc: Unable to init SA1100 RTC sub-device pxa-rtc: probe of pxa-rtc failed with error -2 hctosys: unable to open rtc device (rtc0) I think this is because commit f2997775b111 ("rtc: sa1100: fix possible race condition") moved the allocation of the rtc_device struct out of sa1100_rtc_init and into sa1100_rtc_probe. This means that pxa_rtc_probe also needs to do allocation for the rtc_device struct, otherwise sa1100_rtc_init will try to dereference a null pointer. This patch adds that allocation by copying how sa1100_rtc_probe in drivers/rtc/rtc-sa1100.c does it; after the IRQs are set up a managed rtc_device is allocated. I've tested this patch with `qemu-system-arm -machine akita` and with a real Zaurus SL-C1000 applied to 4.19, 5.4, and 5.10. Signed-off-by: Laurence de Bruxelles <[email protected]> Fixes: f2997775b111 ("rtc: sa1100: fix possible race condition") Signed-off-by: Alexandre Belloni <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 4c979e88b658aba2a08433a8043c685672b5c915 Author: Dmitry Torokhov <[email protected]> Date: Fri Jan 7 12:09:36 2022 -0800 HID: vivaldi: fix handling devices not using numbered reports commit 3fe6acd4dc922237b30e55473c9349c6ce0690f3 upstream. Unfortunately details of USB HID transport bled into HID core and handling of numbered/unnumbered reports is quite a mess, with hid_report_len() calculating the length according to USB rules, and hid_hw_raw_request() adding report ID to the buffer for both numbered and unnumbered reports. Untangling it all requres a lot of changes in HID, so for now let's handle this in the driver. [[email protected]: microoptimize field->report->id to report->id] Fixes: 14c9c014babe ("HID: add vivaldi HID driver") Signed-off-by: Dmitry Torokhov <[email protected]> Tested-by: Stephen Boyd <[email protected]> # CoachZ Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit b81f33f1fc3819a10d96c71dcb37d838d781bb21 Author: Johannes Berg <[email protected]> Date: Mon Sep 13 10:17:29 2021 +0200 um: gitignore: Add kernel/capflags.c commit 4b86366fdfbedec42f8f7ee037775f2839921d34 upstream. This file is generated, we should ignore it. Fixes: d8fb32f4790f ("um: Add support for host CPU flags and alignment") Signed-off-by: Johannes Berg <[email protected]> Acked-By: [email protected] Signed-off-by: Richard Weinberger <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit fe17064738ad7d4b547388e29ad7553ec9e254d8 Author: Yury Norov <[email protected]> Date: Sat Aug 14 14:16:57 2021 -0700 bitops: protect find_first_{,zero}_bit properly commit b7ec62d7ee0f0b8af6ba190501dff7f9ee6545ca upstream. find_first_bit() and find_first_zero_bit() are not protected with ifdefs as other functions in find.h. It causes build errors on some platforms if CONFIG_GENERIC_FIND_FIRST_BIT is enabled. Signed-off-by: Yury Norov <[email protected]> Fixes: 2cc7b6a44ac2 ("lib: add fast path for find_first_*_bit() and find_last_bit()") Reported-by: kernel test robot <[email protected]> Tested-by: Wolfram Sang <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 6ad2daa516deafc6d6527d7f6450499340cf4064 Author: Robert Hancock <[email protected]> Date: Tue Jan 18 15:41:32 2022 -0600 net: axienet: increase default TX ring size to 128 commit 2d19c3fd80178160dd505ccd7fed1643831227a5 upstream. With previous changes to make the driver handle the TX ring size more correctly, the default TX ring size of 64 appears to significantly bottleneck TX performance to around 600 Mbps on a 1 Gbps link on ZynqMP. Increasing this to 128 seems to bring performance up to near line rate and shouldn't cause excess bufferbloat (this driver doesn't yet support modern byte-based queue management). Fixes: 8a3b7a252dca9 ("drivers/net/ethernet/xilinx: added Xilinx AXI Ethernet driver") Signed-off-by: Robert Hancock <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 4928dd5990ea0ec8c9ffdb66663303862aca33c7 Author: Robert Hancock <[email protected]> Date: Tue Jan 18 15:41:31 2022 -0600 net: axienet: fix for TX busy handling commit bb193e3db8b86a63f26889c99e14fd30c9ebd72a upstream. Network driver documentation indicates we should be avoiding returning NETDEV_TX_BUSY from ndo_start_xmit in normal cases, since it requires the packets to be requeued. Instead the queue should be stopped after a packet is added to the TX ring when there may not be enough room for an additional one. Also, when TX ring entries are completed, we should only wake the queue if we know there is room for another full maximally fragmented packet. Print a warning if there is insufficient space at the start of start_xmit, since this should no longer happen. Combined with increasing the default TX ring size (in a subsequent patch), this appears to recover the TX performance lost by previous changes to actually manage the TX ring state properly. Fixes: 8a3b7a252dca9 ("drivers/net/ethernet/xilinx: added Xilinx AXI Ethernet driver") Signed-off-by: Robert Hancock <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit a530eb5ac606d21ca4908ab95ec4c29812ff5865 Author: Robert Hancock <[email protected]> Date: Tue Jan 18 15:41:30 2022 -0600 net: axienet: fix number of TX ring slots for available check commit aba57a823d2985a2cc8c74a2535f3a88e68d9424 upstream. The check for the number of available TX ring slots was off by 1 since a slot is required for the skb header as well as each fragment. This could result in overwriting a TX ring slot that was still in use. Fixes: 8a3b7a252dca9 ("drivers/net/ethernet/xilinx: added Xilinx AXI Ethernet driver") Signed-off-by: Robert Hancock <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 6342bde86b5af9744a63fe6165e34454c1eb400b Author: Robert Hancock <[email protected]> Date: Tue Jan 18 15:41:29 2022 -0600 net: axienet: Fix TX ring slot available check commit 996defd7f8b5dafc1d480b7585c7c62437f80c3c upstream. The check for whether a TX ring slot was available was incorrect, since a slot which had been loaded with transmit data but the device had not started transmitting would be treated as available, potentially causing non-transmitted slots to be overwritten. The control field in the descriptor should be checked, rather than the status field (which may only be updated when the device completes the entry). Fixes: 8a3b7a252dca9 ("drivers/net/ethernet/xilinx: added Xilinx AXI Ethernet driver") Signed-off-by: Robert Hancock <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit b9d67f0a6dc06be8a93e673c5c88a3d51006e42f Author: Robert Hancock <[email protected]> Date: Tue Jan 18 15:41:28 2022 -0600 net: axienet: limit minimum TX ring size commit 70f5817deddbc6ef3faa35841cab83c280cc653a upstream. The driver will not work properly if the TX ring size is set to below MAX_SKB_FRAGS + 1 since it needs to hold at least one full maximally fragmented packet in the TX ring. Limit setting the ring size to below this value. Fixes: 8b09ca823ffb4 ("net: axienet: Make RX/TX ring sizes configurable") Signed-off-by: Robert Hancock <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit e8893b1f8899b6fa161b83ee93e8cc04e17df1e6 Author: Robert Hancock <[email protected]> Date: Tue Jan 18 15:41:27 2022 -0600 net: axienet: add missing memory barriers commit 95978df6fa328df619c15312e65ece469c2be2d2 upstream. This driver was missing some required memory barriers: Use dma_rmb to ensure we see all updates to the descriptor after we see that an entry has been completed. Use wmb and rmb to avoid stale descriptor status between the TX path and TX complete IRQ path. Fixes: 8a3b7a252dca9 ("drivers/net/ethernet/xilinx: added Xilinx AXI Ethernet driver") Signed-off-by: Robert Hancock <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 07a6ec97c1ef56c4ef1e5187af2edcfe7afec8f8 Author: Robert Hancock <[email protected]> Date: Tue Jan 18 15:41:26 2022 -0600 net: axienet: reset core on initialization prior to MDIO access commit 04cc2da39698efd7eb2e30c112538922d26f848e upstream. In some cases where the Xilinx Ethernet core was used in 1000Base-X or SGMII modes, which use the internal PCS/PMA PHY, and the MGT transceiver clock source for the PCS was not running at the time the FPGA logic was loaded, the core would come up in a state where the PCS could not be found on the MDIO bus. To fix this, the Ethernet core (including the PCS) should be reset after enabling the clocks, prior to attempting to access the PCS using of_mdio_find_device. Fixes: 1a02556086fc (net: axienet: Properly handle PCS/PMA PHY for 1000BaseX mode) Signed-off-by: Robert Hancock <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 9b7f3e6adc157aa10ac5ca1fa6d3c85f400b43b2 Author: Robert Hancock <[email protected]> Date: Tue Jan 18 15:41:25 2022 -0600 net: axienet: Wait for PhyRstCmplt after core reset commit b400c2f4f4c53c86594dd57098970d97d488bfde upstream. When resetting the device, wait for the PhyRstCmplt bit to be set in the interrupt status register before continuing initialization, to ensure that the core is actually ready. When using an external PHY, this also ensures we do not start trying to access the PHY while it is still in reset. The PHY reset is initiated by the core reset which is triggered just above, but remains asserted for 5ms after the core is reset according to the documentation. The MgtRdy bit could also be waited for, but unfortunately when using 7-series devices, the bit does not appear to work as documented (it seems to behave as some sort of link state indication and not just an indication the transceiver is ready) so it can't really be relied on for this purpose. Fixes: 8a3b7a252dca9 ("drivers/net/ethernet/xilinx: added Xilinx AXI Ethernet driver") Signed-off-by: Robert Hancock <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 712224b86247f84e6f3922fd206c5e5943ac077d Author: Robert Hancock <[email protected]> Date: Tue Jan 18 15:41:24 2022 -0600 net: axienet: increase reset timeout commit 2e5644b1bab2ccea9cfc7a9520af95b94eb0dbf1 upstream. The previous timeout of 1ms was too short to handle some cases where the core is reset just after the input clocks were started, which will be introduced in an upcoming patch. Increase the timeout to 50ms. Also simplify the reset timeout checking to use read_poll_timeout. Fixes: 8a3b7a252dca9 ("drivers/net/ethernet/xilinx: added Xilinx AXI Ethernet driver") Signed-off-by: Robert Hancock <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 25b1d0df9483fb25b732c6b75caf2a60371ffb5f Author: Wen Gu <[email protected]> Date: Sun Jan 16 15:43:42 2022 +0800 net/smc: Fix hung_task when removing SMC-R devices commit 56d99e81ecbc997a5f984684d0eeb583992b2072 upstream. A hung_task is observed when removing SMC-R devices. Suppose that a link group has two active links(lnk_A, lnk_B) associated with two different SMC-R devices(dev_A, dev_B). When dev_A is removed, the link group will be removed from smc_lgr_list and added into lgr_linkdown_list. lnk_A will be cleared and smcibdev(A)->lnk_cnt will reach to zero. However, when dev_B is removed then, the link group can't be found in smc_lgr_list and lnk_B won't be cleared, making smcibdev->lnk_cnt never reaches zero, which causes a hung_task. This patch fixes this issue by restoring the implementation of smc_smcr_terminate_all() to what it was before commit 349d43127dac ("net/smc: fix kernel panic caused by race of smc_sock"). The original implementation also satisfies the intention that make sure QP destroy earlier than CQ destroy because we will always wait for smcibdev->lnk_cnt reaches zero, which guarantees QP has been destroyed. Fixes: 349d43127dac ("net/smc: fix kernel panic caused by race of smc_sock") Signed-off-by: Wen Gu <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 405d639ac41103e5637c3de129195fb10562639a Author: Miaoqian Lin <[email protected]> Date: Fri Jan 14 06:51:24 2022 +0000 gpio: idt3243x: Fix IRQ check in idt_gpio_probe commit 30fee1d7462a446ade399c0819717a830cbdca69 upstream. platform_get_irq() returns negative error number instead 0 on failure. And the doc of platform_get_irq() provides a usage example: int irq = platform_get_irq(pdev, 0); if (irq < 0) return irq; Fix the check of return value to catch errors correctly. Fixes: 4195926aedca ("gpio: Add support for IDT 79RC3243x GPIO controller") Signed-off-by: Miaoqian Lin <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 4928241698e168794448e49c5d114f1534c46d39 Author: Miaoqian Lin <[email protected]> Date: Fri Jan 14 06:48:20 2022 +0000 gpio: mpc8xxx: Fix IRQ check in mpc8xxx_probe commit 0b39536cc699db6850c426db7f9cb45923de40c5 upstream. platform_get_irq() returns negative error number instead 0 on failure. And the doc of platform_get_irq() provides a usage example: int irq = platform_get_irq(pdev, 0); if (irq < 0) return irq; Fix the check of return value to catch errors correctly. Fixes: 76c47d1449fc ("gpio: mpc8xxx: Add ACPI support") Signed-off-by: Miaoqian Lin <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit e7525b3b9edaa6b5b8fdc84a9daf16d704011200 Author: John Keeping <[email protected]> Date: Fri Nov 26 15:13:52 2021 +0000 pinctrl/rockchip: fix gpio device creation commit bceb6732f3fd2a55d8f2e518cced1c7555e216b6 upstream. GPIO nodes are not themselves busses, so passing rockchip_bank_match here is wrong. Passing NULL instead uses the standard bus match table which is more appropriate. devm_of_platform_populate() shows that this is the normal way to call of_platform_populate() from a device driver, so in order to match that more closely also add the pinctrl device as the parent for the newly created GPIO controllers. Specifically, using the wrong match here can break dynamic GPIO hogs as marking the GPIO bank as a bus means that of_platform_notify() will set OF_POPULATED on new child nodes and if this happens before of_gpio_notify() is called then the new hog will be skipped as OF_POPULATED is already set. Fixes: 9ce9a02039de ("pinctrl/rockchip: drop the gpio related codes") Signed-off-by: John Keeping <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 8fc3bd2c347ba23fa9dbc25be4f82c0b761e9399 Author: Robert Hancock <[email protected]> Date: Wed Jan 12 14:38:16 2022 -0600 clk: si5341: Fix clock HW provider cleanup commit 49a8f2bc8d88702783c7e163ec84374e9a022f71 upstream. The call to of_clk_add_hw_provider was not undone on remove or on probe failure, which could cause an oops on a subsequent attempt to retrieve clocks for the removed device. Switch to the devm version of the function to avoid this issue. Fixes: 3044a860fd09 ("clk: Add Si5341/Si5340 driver") Signed-off-by: Robert Hancock <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Stephen Boyd <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 4919c073780614df6f996ac33309fbbf2f67b199 Author: Stephen Boyd <[email protected]> Date: Thu Dec 9 17:34:05 2021 -0800 clk: Emit a stern warning with writable debugfs enabled commit 489a71964f9d74e697a12cd0ace20ed829eb1f93 upstream. We don't want vendors to be enabling this part of the clk code and shipping it to customers. Exposing the ability to change clk frequencies and parents via debugfs is potentially damaging to the system if folks don't know what they're doing. Emit a strong warning so that the message is clear: don't enable this outside of development systems. Fixes: 37215da5553e ("clk: Add support for setting clk_rate via debugfs") Cc: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Stephen Boyd <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 3872d146f2b093982e62c6f1f2c4e8f71eed4050 Author: Eric Dumazet <[email protected]> Date: Fri Jan 14 08:43:28 2022 -0800 af_unix: annote lockless accesses to unix_tot_inflight & gc_in_progress commit 9d6d7f1cb67cdee15f1a0e85aacfb924e0e02435 upstream. wait_for_unix_gc() reads unix_tot_inflight & gc_in_progress without synchronization. Adds READ_ONCE()/WRITE_ONCE() and their associated comments to better document the intent. BUG: KCSAN: data-race in unix_inflight / wait_for_unix_gc write to 0xffffffff86e2b7c0 of 4 bytes by task 9380 on cpu 0: unix_inflight+0x1e8/0x260 net/unix/scm.c:63 unix_attach_fds+0x10c/0x1e0 net/unix/scm.c:121 unix_scm_to_skb net/unix/af_unix.c:1674 [inline] unix_dgram_sendmsg+0x679/0x16b0 net/unix/af_unix.c:1817 unix_seqpacket_sendmsg+0xcc/0x110 net/unix/af_unix.c:2258 sock_sendmsg_nosec net/socket.c:704 [inline] sock_sendmsg net/socket.c:724 [inline] ____sys_sendmsg+0x39a/0x510 net/socket.c:2409 ___sys_sendmsg net/socket.c:2463 [inline] __sys_sendmmsg+0x267/0x4c0 net/socket.c:2549 __do_sys_sendmmsg net/socket.c:2578 [inline] __se_sys_sendmmsg net/socket.c:2575 [inline] __x64_sys_sendmmsg+0x53/0x60 net/socket.c:2575 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae read to 0xffffffff86e2b7c0 of 4 bytes by task 9375 on cpu 1: wait_for_unix_gc+0x24/0x160 net/unix/garbage.c:196 unix_dgram_sendmsg+0x8e/0x16b0 net/unix/af_unix.c:1772 unix_seqpacket_sendmsg+0xcc/0x110 net/unix/af_unix.c:2258 sock_sendmsg_nosec net/socket.c:704 [inline] sock_sendmsg net/socket.c:724 [inline] ____sys_sendmsg+0x39a/0x510 net/socket.c:2409 ___sys_sendmsg net/socket.c:2463 [inline] __sys_sendmmsg+0x267/0x4c0 net/socket.c:2549 __do_sys_sendmmsg net/socket.c:2578 [inline] __se_sys_sendmmsg net/socket.c:2575 [inline] __x64_sys_sendmmsg+0x53/0x60 net/socket.c:2575 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae value changed: 0x00000002 -> 0x00000004 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 9375 Comm: syz-executor.1 Not tainted 5.16.0-rc7-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Fixes: 9915672d4127 ("af_unix: limit unix_tot_inflight") Signed-off-by: Eric Dumazet <[email protected]> Reported-by: syzbot <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit cb697a36f41550f4401e3a575684e205fa94169f Author: Dan Carpenter <[email protected]> Date: Sat Nov 27 17:10:27 2021 +0300 crypto: octeontx2 - uninitialized variable in kvf_limits_store() commit 0ea275df84c389e910a3575a9233075118c173ee upstream. If kstrtoint() fails then "lfs_num" is uninitialized and the warning doesn't make any sense. Just delete it. Fixes: 8ec8015a3168 ("crypto: octeontx2 - add support to process the crypto request") Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 2d7d3b6da85e219abed247a63a4754f04376e2fa Author: Chao Yu <[email protected]> Date: Sun Dec 12 20:28:12 2021 +0800 f2fs: fix to check available space of CP area correctly in update_ckpt_flags() commit b702c83e2eaa2fa2d72e957c55c0321535cc8b9f upstream. Otherwise, nat_bit area may be persisted across boundary of CP area during nat_bit rebuilding. Fixes: 94c821fb286b ("f2fs: rebuild nat_bits during umount") Signed-off-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 0789b9b3492264e4bbe212b688866117d14df0c8 Author: Chao Yu <[email protected]> Date: Sat Dec 11 21:27:36 2021 +0800 f2fs: fix to reserve space for IO align feature commit 300a842937fbcfb5a189cea9ba15374fdb0b5c6b upstream. https://bugzilla.kernel.org/show_bug.cgi?id=204137 With below script, we will hit panic during new segment allocation: DISK=bingo.img MOUNT_DIR=/mnt/f2fs dd if=/dev/zero of=$DISK bs=1M count=105 mkfs.f2fe -a 1 -o 19 -t 1 -z 1 -f -q $DISK mount -t f2fs $DISK $MOUNT_DIR -o "noinline_dentry,flush_merge,noextent_cache,mode=lfs,io_bits=7,fsync_mode=strict" for (( i = 0; i < 4096; i++ )); do name=`head /dev/urandom | tr -dc A-Za-z0-9 | head -c 10` mkdir $MOUNT_DIR/$name done umount $MOUNT_DIR rm $DISK commit 56dabe87c4aadb58d4855ad734d74787cdca10d8 Author: Hyeong-Jun Kim <[email protected]> Date: Fri Dec 10 13:30:12 2021 +0900 f2fs: compress: fix potential deadlock of compress file commit 7377e853967ba45bf409e3b5536624d2cbc99f21 upstream. There is a potential deadlock between writeback process and a process performing write_begin() or write_cache_pages() while trying to write same compress file, but not compressable, as below: [Process A] - doing checkpoint [Process B] [Process C] f2fs_write_cache_pages() - lock_page() [all pages in cluster, 0-31] - f2fs_write_multi_pages() - f2fs_write_raw_pages() - f2fs_write_single_data_page() - f2fs_do_write_data_page() - return -EAGAIN [f2fs_trylock_op() failed] - unlock_page(page) [e.g., page 0] - generic_perform_write() - f2fs_write_begin() - f2fs_prepare_compress_overwrite() - prepare_compress_overwrite() - lock_page() [e.g., page 0] - lock_page() [e.g., page 1] - lock_page(page) [e.g., page 0] Since there is no compress process, it is no longer necessary to hold locks on every pages in cluster within f2fs_write_raw_pages(). This patch changes f2fs_write_raw_pages() to release all locks first and then perform write same as the non-compress file in f2fs_write_cache_pages(). Fixes: 4c8ff7095bef ("f2fs: support data compression") Signed-off-by: Hyeong-Jun Kim <[email protected]> Signed-off-by: Sungjong Seo <[email protected]> Signed-off-by: Youngjin Gil <[email protected]> Reviewed-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit b653ee5c4136e74ad083d93eaa7cf9d633fdf8ea Author: Chao Yu <[email protected]> Date: Mon Dec 6 22:44:20 2021 +0800 f2fs: fix to avoid panic in is_alive() if metadata is inconsistent commit f6db43076d190d9bf75559dec28e18b9d12e4ce5 upstream. As report by Wenqing Liu in bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215231 If we enable CONFIG_F2FS_CHECK_FS config, and with fuzzed image attached in above link, we will encounter panic when executing below script: 1. mkdir mnt 2. mount -t f2fs tmp1.img mnt 3. touch tmp F2FS-fs (loop11): mismatched blkaddr 5765 (source_blkaddr 1) in seg 3 kernel BUG at fs/f2fs/gc.c:1042! do_garbage_collect+0x90f/0xa80 [f2fs] f2fs_gc+0x294/0x12a0 [f2fs] f2fs_balance_fs+0x2c5/0x7d0 [f2fs] f2fs_create+0x239/0xd90 [f2fs] lookup_open+0x45e/0xa90 open_last_lookups+0x203/0x670 path_openat+0xae/0x490 do_filp_open+0xbc/0x160 do_sys_openat2+0x2f1/0x500 do_sys_open+0x5e/0xa0 __x64_sys_openat+0x28/0x40 Previously, f2fs tries to catch data inconcistency exception in between SSA and SIT table during GC, however once the exception is caught, it will call f2fs_bug_on to hang kernel, it's not needed, instead, let's set SBI_NEED_FSCK flag and skip migrating current block. Fixes: bbf9f7d90f21 ("f2fs: Fix indefinite loop in f2fs_gc()") Signed-off-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 92804f969524346dabcc2d061022e58850e5714c Author: Fengnan Chang <[email protected]> Date: Fri Nov 26 18:19:19 2021 +0800 f2fs: fix remove page failed in invalidate compress pages commit d1917865a7906baf6b687e15e8e6195a295a3992 upstream. Since compress inode not a regular file, generic_error_remove_page in f2fs_invalidate_compress_pages will always be failed, set compress inode as a regular file to fix it. Fixes: 6ce19aff0b8c ("f2fs: compress: add compress_inode to cache compressed blocks") Signed-off-by: Fengnan Chang <[email protected]> Reviewed-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 28e36db0617c7b52c6a1138a1c8560a1f28151d5 Author: Zack Rusin <[email protected]> Date: Wed Dec 15 13:41:47 2021 -0500 drm/vmwgfx: Remove unused compile options commit 50ca8cc7c0fdd9ab16b8b66ffb301fface101fac upstream. Before the driver had screen targets support we had to disable explicit bringup of its infrastructure because it was breaking screen objects support. Since the implementation of screen targets landed there hasn't been a reason to explicitly disable it and the options were never used. Remove of all that unused code. Signed-off-by: Zack Rusin <[email protected]> Fixes: d80efd5cb3de ("drm/vmwgfx: Initial DX support") Reviewed-by: Martin Krastev <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 11343099d5ae6c7411da1425b6b162c89fb5bf10) Signed-off-by: Thomas Zimmermann <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit f468282f3de0679c17b1c53622731c31826fdbe9 Author: Zack Rusin <[email protected]> Date: Wed Dec 15 13:41:46 2021 -0500 drm/vmwgfx: Remove explicit transparent hugepages support commit bc701a28c74e78d7b5aa2b8628cb3608d4785d14 upstream. Old versions of the svga device used to export virtual vram, handling of which was optimized on top of transparent hugepages support. Only very old devices (OpenGL 2.1 support and earlier) used this code and at this point performance differences are negligible. Because the code requires very old hardware versions to run it has been largely untested and unused for a long time. Furthermore removal of the ttm hugepages support in: commit 0d979509539e ("drm/ttm: remove ttm_bo_vm_insert_huge()") broke the coherency mode in vmwgfx when running with hugepages. Fixes: 0d979509539e ("drm/ttm: remove ttm_bo_vm_insert_huge()") Signed-off-by: Zack Rusin <[email protected]> Cc: Jason Gunthorpe <[email protected]> Cc: Thomas Hellström <[email protected]> Cc: Christian König <[email protected]> Cc: Daniel Vetter <[email protected]> Reviewed-by: Martin Krastev <[email protected]> Reviewed-by: Maaz Mombasawala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 49d535d64d52945e2c874f380705675e20a02b6a) Signed-off-by: Thomas Zimmermann <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 42b777c6aef95bc0e053e4fd3686b4b041851010 Author: Geert Uytterhoeven <[email protected]> Date: Fri Dec 17 13:49:24 2021 +0100 riscv: dts: microchip: mpfs: Drop empty chosen node commit 53ef07326ad0d6ae7fefded22bc53b427d542761 upstream. It does not make sense to have an (empty) chosen node in an SoC-specific .dtsi, as chosen is meant for system-specific configuration. It is already provided in microchip-mpfs-icicle-kit.dts anyway. Fixes: 0fa6107eca4186ad ("RISC-V: Initial DTS for Microchip ICICLE board") Signed-off-by: Geert Uytterhoeven <[email protected]> Reviewed-by: Conor Dooley <[email protected]> Tested-by: Conor Dooley <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Palmer Dabbelt <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit fc1d427d15aac401c4940f07f152885cb74ca3bc Author: Miaoqian Lin <[email protected]> Date: Thu Jan 20 12:18:12 2022 +0000 parisc: pdc_stable: Fix memory leak in pdcs_register_pathentries commit d24846a4246b6e61ecbd036880a4adf61681d241 upstream. kobject_init_and_add() takes reference even when it fails. According to the doc of kobject_init_and_add()： If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object. Fix memory leak by calling kobject_put(). Fixes: 73f368cf679b ("Kobject: change drivers/parisc/pdc_stable.c to use kobject_init_and_add") Signed-off-by: Miaoqian Lin <[email protected]> Signed-off-by: Helge Deller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 911b5ba7c54fd8195d2e969ff3ba14715331f1c7 Author: Tobias Waldekranz <[email protected]> Date: Tue Jan 18 22:50:53 2022 +0100 net/fsl: xgmac_mdio: Fix incorrect iounmap when removing module commit 3f7c239c7844d2044ed399399d97a5f1c6008e1b upstream. As reported by sparse: In the remove path, the driver would attempt to unmap its own priv pointer - instead of the io memory that it mapped in probe. Fixes: 9f35a7342cff ("net/fsl: introduce Freescale 10G MDIO driver") Signed-off-by: Tobias Waldekranz <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit fa456d92c4b72d8e440bf920fd1ece53a0be4905 Author: Tobias Waldekranz <[email protected]> Date: Tue Jan 18 22:50:50 2022 +0100 net/fsl: xgmac_mdio: Add workaround for erratum A-009885 commit 6198c722019774d38018457a8bfb9ba3ed8c931e upstream. Once an MDIO read transaction is initiated, we must read back the data register within 16 MDC cycles after the transaction completes. Outside of this window, reads may return corrupt data. Therefore, disable local interrupts in the critical section, to maximize the probability that we can satisfy this requirement. Fixes: d55ad2967d89 ("powerpc/mpc85xx: Create dts components for the FSL QorIQ DPAA FMan") Signed-off-by: Tobias Waldekranz <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 0cba6beb9645f482521192740aeed90367a21cf4 Author: Guillaume Nault <[email protected]> Date: Mon Jan 10 14:43:14 2022 +0100 mlx5: Don't accidentally set RTO_ONLINK before mlx5e_route_lookup_ipv4_get() commit 48d67543e01d73292e0bb66d3f10fc422e79e031 upstream. Mask the ECN bits before calling mlx5e_route_lookup_ipv4_get(). The tunnel key might have the last ECN bit set. This interferes with the route lookup process as ip_route_output_key_hash() interpretes this bit specially (to restrict the route scope). Found by code inspection, compile tested only. Fixes: c7b9038d8af6 ("net/mlx5e: TC preparation refactoring for routing update event") Fixes: 9a941117fb76 ("net/mlx5e: Maximize ip tunnel key usage on the TC offloading path") Signed-off-by: Guillaume Nault <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 6c923b0f74ae737ebc2e9d45c543b1babcde9212 Author: Eric Dumazet <[email protected]> Date: Wed Jan 19 02:04:12 2022 -0800 ipv4: avoid quadratic behavior in netns dismantle commit d07418afea8f1d9896aaf9dc5ae47ac4f45b220c upstream. net/ipv4/fib_semantics.c uses an hash table of 256 slots, keyed by device ifindexes: fib_info_devhash[DEVINDEX_HASHSIZE] Problem is that with network namespaces, devices tend to use the same ifindex. lo device for instance has a fixed ifindex of one, for all network namespaces. This means that hosts with thousands of netns spend a lot of time looking at some hash buckets with thousands of elements, notably at netns dismantle. Simply add a per netns perturbation (net_hash_mix()) to spread elements more uniformely. Also change fib_devindex_hashfn() to use more entropy. Fixes: aa79e66eee5d ("net: Make ifindex generation per-net namespace") Signed-off-by: Eric Dumazet <[email protected]> Reviewed-by: David Ahern <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 4bcc304e4255952eb92c1cd2ad8761248dd6263c Author: Eric Dumazet <[email protected]> Date: Sun Jan 16 01:02:20 2022 -0800 ipv4: update fib_info_cnt under spinlock protection commit 0a6e6b3c7db6c34e3d149f09cd714972f8753e3f upstream. In the past, free_fib_info() was supposed to be called under RTNL protection. This eventually was no longer the case. Instead of enforcing RTNL it seems we simply can move fib_info_cnt changes to occur when fib_info_lock is held. v2: David Laight suggested to update fib_info_cnt only when an entry is added/deleted to/from the hash table, as fib_info_cnt is used to make sure hash table size is optimal. BUG: KCSAN: data-race in fib_create_info / free_fib_info write to 0xffffffff86e243a0 of 4 bytes by task 26429 on cpu 0: fib_create_info+0xe78/0x3440 net/ipv4/fib_semantics.c:1428 fib_table_insert+0x148/0x10c0 net/ipv4/fib_trie.c:1224 fib_magic+0x195/0x1e0 net/ipv4/fib_frontend.c:1087 fib_add_ifaddr+0xd0/0x2e0 net/ipv4/fib_frontend.c:1109 fib_netdev_event+0x178/0x510 net/ipv4/fib_frontend.c:1466 notifier_call_chain kernel/notifier.c:83 [inline] raw_notifier_call_chain+0x53/0xb0 kernel/notifier.c:391 __dev_notify_flags+0x1d3/0x3b0 dev_change_flags+0xa2/0xc0 net/core/dev.c:8872 do_setlink+0x810/0x2410 net/core/rtnetlink.c:2719 rtnl_group_changelink net/core/rtnetlink.c:3242 [inline] __rtnl_newlink net/core/rtnetlink.c:3396 [inline] rtnl_newlink+0xb10/0x13b0 net/core/rtnetlink.c:3506 rtnetlink_rcv_msg+0x745/0x7e0 net/core/rtnetlink.c:5571 netlink_rcv_skb+0x14e/0x250 net/netlink/af_netlink.c:2496 rtnetlink_rcv+0x18/0x20 net/core/rtnetlink.c:5589 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] netlink_unicast+0x5fc/0x6c0 net/netlink/af_netlink.c:1345 netlink_sendmsg+0x726/0x840 net/netlink/af_netlink.c:1921 sock_sendmsg_nosec net/socket.c:704 [inline] sock_sendmsg net/socket.c:724 [inline] ____sys_sendmsg+0x39a/0x510 net/socket.c:2409 ___sys_sendmsg net/socket.c:2463 [inline] __sys_sendmsg+0x195/0x230 net/socket.c:2492 __do_sys_sendmsg net/socket.c:2501 [inline] __se_sys_sendmsg net/socket.c:2499 [inline] __x64_sys_sendmsg+0x42/0x50 net/socket.c:2499 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae read to 0xffffffff86e243a0 of 4 bytes by task 31505 on cpu 1: free_fib_info+0x35/0x80 net/ipv4/fib_semantics.c:252 fib_info_put include/net/ip_fib.h:575 [inline] nsim_fib4_rt_destroy drivers/net/netdevsim/fib.c:294 [inline] nsim_fib4_rt_replace drivers/net/netdevsim/fib.c:403 [inline] nsim_fib4_rt_insert drivers/net/netdevsim/fib.c:431 [inline] nsim_fib4_event drivers/net/netdevsim/fib.c:461 [inline] nsim_fib_event drivers/net/netdevsim/fib.c:881 [inline] nsim_fib_event_work+0x15ca/0x2cf0 drivers/net/netdevsim/fib.c:1477 process_one_work+0x3fc/0x980 kernel/workqueue.c:2298 process_scheduled_works kernel/workqueue.c:2361 [inline] worker_thread+0x7df/0xa70 kernel/workqueue.c:2447 kthread+0x2c7/0x2e0 kernel/kthread.c:327 ret_from_fork+0x1f/0x30 value changed: 0x00000d2d -> 0x00000d2e Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 31505 Comm: kworker/1:21 Not tainted 5.16.0-rc6-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: events nsim_fib_event_work Fixes: 48bb9eb47b27 ("netdevsim: fib: Add dummy implementation for FIB offload") Signed-off-by: Eric Dumazet <[email protected]> Reported-by: syzbot <[email protected]> Cc: David Laight <[email protected]> Cc: Ido Schimmel <[email protected]> Cc: Jiri Pirko <[email protected]> Reviewed-by: Ido Schimmel <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit c2a957a6f25242ff03a5b5039e0468450aae4896 Author: German Gomez <[email protected]> Date: Tue Jan 18 14:40:54 2022 +0000 perf evsel: Override attr->sample_period for non-libpfm4 events commit 3606c0e1a1050d397ad759a62607e419fd8b0ccb upstream. A previous patch preventing "attr->sample_period" values from being overridden in pfm events changed a related behaviour in arm-spe. Before said patch: perf record -c 10000 -e arm_spe_0// -- sleep 1 Would yield an SPE event with period=10000. After the patch, the period in "-c 10000" was being ignored because the arm-spe code initializes sample_period to a non-zero value. This patch restores the previous behaviour for non-libpfm4 events. Fixes: ae5dcc8abe31 (“perf record: Prevent override of attr->sample_period for libpfm4 events”) Reported-by: Chase Conklin <[email protected]> Signed-off-by: German Gomez <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Ian Rogers <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: John Fastabend <[email protected]> Cc: KP Singh <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Martin KaFai Lau <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Song Liu <[email protected]> Cc: Stephane Eranian <[email protected]> Cc: Yonghong Song <[email protected]> Cc: [email protected] Cc: [email protected] Link: http://lore.kernel.org/lkml/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 95429d6b64b1f6ed5fff4b91b9f8eb5fbf337c0d Author: Daniel Borkmann <[email protected]> Date: Fri Jan 14 13:58:36 2022 +0000 bpf: Mark PTR_TO_FUNC register initially with zero offset commit d400a6cf1c8a57cdf10f35220ead3284320d85ff upstream. Similar as with other pointer types where we use ldimm64, clear the register content to zero first, and then populate the PTR_TO_FUNC type and subprogno number. Currently this is not done, and leads to reuse of stale register tracking data. Given for special ldimm64 cases we always clear the register offset, make it common for all cases, so it won't be forgotten in future. Fixes: 69c087ba6225 ("bpf: Add bpf_for_each_map_elem() helper") Signed-off-by: Daniel Borkmann <[email protected]> Acked-by: John Fastabend <[email protected]> Acked-by: Alexei Starovoitov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 20ceec871b66f8d9fec11ee8bc6b98755049c760 Author: Yafang Shao <[email protected]> Date: Sat Jan 8 13:46:23 2022 +0000 bpf: Fix mount source show for bpffs commit 1e9d74660d4df625b0889e77018f9e94727ceacd upstream. We noticed our tc ebpf tools can't start after we upgrade our in-house kernel version from 4.19 to 5.10. That is because of the behaviour change in bpffs caused by commit d2935de7e4fd ("vfs: Convert bpf to use the new mount API"). In our tc ebpf tools, we do strict environment check. If the environment is not matched, we won't allow to start the ebpf progs. One of the check is whether bpffs is properly mounted. The mount information of bpffs in kernel-4.19 and kernel-5.10 are as follows: - kernel 4.19 $ mount -t bpf bpffs /sys/fs/bpf $ mount -t bpf bpffs on /sys/fs/bpf type bpf (rw,relatime) - kernel 5.10 $ mount -t bpf bpffs /sys/fs/bpf $ mount -t bpf none on /sys/fs/bpf type bpf (rw,relatime) The device name in kernel-5.10 is displayed as none instead of bpffs, then our environment check fails. Currently we modify the tools to adopt to the kernel behaviour change, but I think we'd better change the kernel code to keep the behavior consistent. After this change, the mount information will be displayed the same with the behavior in kernel-4.19, for example: $ mount -t bpf bpffs /sys/fs/bpf $ mount -t bpf bpffs on /sys/fs/bpf type bpf (rw,relatime) Fixes: d2935de7e4fd ("vfs: Convert bpf to use the new mount API") Suggested-by: Daniel Borkmann <[email protected]> Signed-off-by: Yafang Shao <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Acked-by: Christian Brauner <[email protected]> Cc: David Howells <[email protected]> Cc: Al Viro <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit b87b59633e358f15e782df96f41733b228c06023 Author: Toke Høiland-Jørgensen <[email protected]> Date: Fri Jan 7 23:11:13 2022 +0100 xdp: check prog type before updating BPF link commit 382778edc8262b7535f00523e9eb22edba1b9816 upstream. The bpf_xdp_link_update() function didn't check the program type before updating the program, which made it possible to install any program type as an XDP program, which is obviously not good. Syzbot managed to trigger this by swapping in an LWT program on the XDP hook which would crash in a helper call. Fix this by adding a check and bailing out if the types don't match. Fixes: 026a4c28e1db ("bpf, xdp: Implement LINK_UPDATE for BPF XDP link") Reported-by: [email protected] Acked-by: Andrii Nakryiko <[email protected]> Signed-off-by: Toke Høiland-Jørgensen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit b46b0ef69d07b17d084c1fee14a738354201b0f0 Author: Quentin Monnet <[email protected]> Date: Wed Nov 10 11:46:30 2021 +0000 bpftool: Fix indent in option lists in the documentation commit 986dec18bbf41f50edc2e0aa4ac5ef8e0f64f328 upstream. Mixed indentation levels in the lists of options in bpftool's documentation produces some unexpected results. For the "bpftool" man page, it prints a warning: $ make -C bpftool.8 GEN bpftool.8 <stdin>:26: (ERROR/3) Unexpected indentation. For other pages, there is no warning, but it results in a line break appearing in the option lists in the generated man pages. RST paragraphs should have a uniform indentation level. Let's fix it. Fixes: c07ba629df97 ("tools: bpftool: Update and synchronise option list in doc and help msg") Fixes: 8cc8c6357c8f ("tools: bpftool: Document and add bash completion for -L, -B options") Signed-off-by: Quentin Monnet <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 220ee6f3b4608f16777a6ac190ed084100d8bfda Author: Quentin Monnet <[email protected]> Date: Wed Nov 10 11:46:28 2021 +0000 bpftool: Remove inclusion of utilities.mak from Makefiles commit 48f5aef4c458c19ab337eed8c95a6486cc014aa3 upstream. Bpftool's Makefile, and the Makefile for its documentation, both include scripts/utilities.mak, but they use none of the items defined in this file. Remove the includes. Fixes: 71bb428fe2c1 ("tools: bpf: add bpftool") Signed-off-by: Quentin Monnet <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit adb344f551d6607c79de030c140e582ad4c917af Author: Maxime Ripard <[email protected]> Date: Mon Oct 25 16:11:07 2021 +0200 drm/vc4: crtc: Copy assigned channel to the CRTC commit eeb6ab4639590130d25670204ab7b6011333d685 upstream. Accessing the crtc->state pointer from outside the modesetting context is not allowed. We thus need to copy whatever we need from the KMS state to our structure in order to access it. In VC4, a number of users of that pointers have crept in over the years, and the previous commits removed them all but the HVS channel a CRTC has been assigned. Let's move this channel in struct vc4_crtc at atomic_begin() time, drop it from our private state structure, and remove our use of crtc->state from our vblank handler entirely. Link: https://lore.kernel.org/all/[email protected]/ Link: https://lore.kernel.org/r/[email protected] Fixes: 87ebcd42fb7b ("drm/vc4: crtc: Assign output to channel automatically") Acked-by: Daniel Vetter <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit d26a90d362d966a66fec4a0c3da7545426bbc783 Author: Maxime Ripard <[email protected]> Date: Mon Oct 25 16:11:06 2021 +0200 drm/vc4: Fix non-blocking commit getting stuck forever commit 0c250c150c74a90db298bf2a8bcd0a1dabed2e2f upstream. In some situation, we can end up being stuck on a non-blocking that went through properly. The situation that seems to trigger it reliably is to first start a non-blocking commit, and then right after, and before we had any vblank interrupt), start a blocking commit. This will lead to the first commit workqueue to be scheduled, setup the display, while the second commit is waiting for the first one to be completed. The vblank interrupt will then be raised, vc4_crtc_handle_vblank() will run and will compare the active dlist in the HVS channel to the one associated with the crtc->state. However, at that point, the second commit is waiting using drm_atomic_helper_wait_for_dependencies that occurs after drm_atomic_helper_swap_state has been called, so crtc->state points to the second commit state. vc4_crtc_handle_vblank() will compare the two dlist addresses and since they don't match will ignore the interrupt. The vblank event will never be reported, and the first and second commit will wait for the first commit completion until they timeout. The underlying reason is that it was never safe to do so. Indeed, accessing the ->state pointer access synchronization is based on ownership guarantees that can only occur within the functions and hooks defined as part of the KMS framework, and obviously the irq handler isn't one of them. The rework to move to generic helpers only uncovered the underlying issue. However, since the code path between drm_atomic_helper_wait_for_dependencies() and drm_atomic_helper_wait_for_vblanks() is serialised and we can't get two commits in that path at the same time, we can work around this issue by setting a variable associated to struct drm_crtc to the dlist we expect, and then using it from the vc4_crtc_handle_vblank() function. Since that state is shared with the modesetting path, we also need to introduce a spinlock to protect the code shared between the interrupt handler and the modesetting path, protecting only our new variable for now. Link: https://lore.kernel.org/all/[email protected]/ Link: https://lore.kernel.org/r/[email protected] Fixes: 56d1fe0979dc ("drm/vc4: Make pageflip completion handling more robust.") Acked-by: Daniel Vetter <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit d2cbb24cf66e15835496645741fb842e088ceaaa Author: Maxime Ripard <[email protected]> Date: Mon Oct 25 16:11:05 2021 +0200 drm/vc4: crtc: Drop feed_txp from state commit a16c66401fd831f70a02d33e9bcaac585637c29f upstream. Accessing the crtc->state pointer from outside the modesetting context is not allowed. We thus need to copy whatever we need from the KMS state to our structure in order to access it. In VC4, a number of users of that pointers have crept in over the years, the first one being whether or not the downstream controller of the pixelvalve is our writeback controller. Fortunately for us, Since commit 39fcb2808376 ("drm/vc4: txp: Turn the TXP into a CRTC of its own") this is no longer something that can change from one commit to the other and is hardcoded. Let's set this flag in struct vc4_crtc if we happen to be the TXP, and drop the flag from our private state structure. Link: https://lore.kernel.org/all/[email protected]/ Link: https://lore.kernel.org/r/[email protected] Fixes: 008095e065a8 ("drm/vc4: Add support for the transposer block") Acked-by: Daniel Vetter <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit b157f4bf1fc63e99be3a79d683959884a20faf2f Author: Ye Bin <[email protected]> Date: Mon Nov 29 09:26:59 2021 +0800 block: Fix fsync always failed if once failed commit 8a7518931baa8ea023700987f3db31cb0a80610b upstream. We do test with inject error fault base on v4.19, after test some time we found sync /dev/sda always failed. [root@localhost] sync /dev/sda sync: error syncing '/dev/sda': Input/output error scsi log as follows: [19069.812296] sd 0:0:0:0: [sda] tag#64 Send: scmd 0x00000000d03a0b6b [19069.812302] sd 0:0:0:0: [sda] tag#64 CDB: Synchronize Cache(10) 35 00 00 00 00 00 00 00 00 00 [19069.812533] sd 0:0:0:0: [sda] tag#64 Done: SUCCESS Result: hostbyte=DID_OK driverbyte=DRIVER_OK [19069.812536] sd 0:0:0:0: [sda] tag#64 CDB: Synchronize Cache(10) 35 00 00 00 00 00 00 00 00 00 [19069.812539] sd 0:0:0:0: [sda] tag#64 scsi host busy 1 failed 0 [19069.812542] sd 0:0:0:0: Notifying upper driver of completion (result 0) [19069.812546] sd 0:0:0:0: [sda] tag#64 sd_done: completed 0 of 0 bytes [19069.812549] sd 0:0:0:0: [sda] tag#64 0 sectors total, 0 bytes done. [19069.812564] print_req_error: I/O error, dev sda, sector 0 ftrace log as follows: rep-306069 [007] .... 19654.923315: block_bio_queue: 8,0 FWS 0 + 0 [rep] rep-306069 [007] .... 19654.923333: block_getrq: 8,0 FWS 0 + 0 [rep] kworker/7:1H-250 [007] .... 19654.923352: block_rq_issue: 8,0 FF 0 () 0 + 0 [kworker/7:1H] <idle>-0 [007] ..s. 19654.923562: block_rq_complete: 8,0 FF () 18446744073709551615 + 0 [0] <idle>-0 [007] d.s. 19654.923576: block_rq_complete: 8,0 WS () 0 + 0 [-5] As 8d6996630c03 introduce 'fq->rq_status', this data only update when 'flush_rq' reference count isn't zero. If flush request once failed and record error code in 'fq->rq_status'. If there is no chance to update 'fq->rq_status',then do fsync will always failed. To address this issue reset 'fq->rq_status' after return error code to upper layer. Fixes: 8d6996630c03("block: fix null pointer dereference in blk_mq_rq_timed_out()") Signed-off-by: Ye Bin <[email protected]> Reviewed-by: Ming Lei <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 269fbc268633c1ee7da992dd9c58890d9906d120 Author: Jens Axboe <[email protected]> Date: Thu Jan 20 10:28:13 2022 -0700 block: fix async_depth sysfs interface for mq-deadline commit 46cdc45acb089c811d9a54fd50af33b96e5fae9d upstream. A previous commit added this feature, but it inadvertently used the wrong variable to show/store the setting from/to, victimized by copy/paste. Fix it up so that the async_depth sysfs interface reads and writes from the right setting. Fixes: 07757588e507 ("block/mq-deadline: Reserve 25% of scheduler tags for synchronous requests") Link: https://bugzilla.kernel.org/show_bug.cgi?id=215485 Reviewed-by: Bart Van Assche <[email protected]> Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 1e95e6dab0d17826631b37f3c3bdb62d57d43b4f Author: Tobias Waldekranz <[email protected]> Date: Tue Jan 18 22:50:52 2022 +0100 powerpc/fsl/dts: Enable WA for erratum A-009885 on fman3l MDIO buses commit 0d375d610fa96524e2ee2b46830a46a7bfa92a9f upstream. This block is used in (at least) T1024 and T1040, including their variants like T1023 etc. Fixes: d55ad2967d89 ("powerpc/mpc85xx: Create dts components for the FSL QorIQ DPAA FMan") Signed-off-by: Tobias Waldekranz <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 696733774b2f03ed7c774735416bb343a86041e9 Author: Anders Roxell <[email protected]> Date: Tue Dec 7 12:02:28 2021 +0100 powerpc/cell: Fix clang -Wimplicit-fallthrough warning commit e89257e28e844f5d1d39081bb901d9f1183a7705 upstream. Clang warns: arch/powerpc/platforms/cell/pervasive.c:81:2: error: unannotated fall-through between switch labels case SRR1_WAKEEE: ^ arch/powerpc/platforms/cell/pervasive.c:81:2: note: insert 'break;' to avoid fall-through case SRR1_WAKEEE: ^ break; 1 error generated. Clang is more pedantic than GCC, which does not warn when failing through to a case that is just break or return. Clang's version is more in line with the kernel's own stance in deprecated.rst. Add athe missing break to silence the warning. Fixes: 6e83985b0f6e ("powerpc/cbe: Do not process external or decremeter interrupts from sreset") Reported-by: Naresh Kamboju <[email protected]> Signed-off-by: Anders Roxell <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Reviewed-by: Arnd Bergmann <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 3feb292a03d157ec2f04b47793a92db7a8a391ae Author: Moshe Shemesh <[email protected]> Date: Sun Dec 5 11:20:59 2021 +0200 Revert "net/mlx5: Add retry mechanism to the command entry index allocation" commit 4f6626b0e140867fd6d5a2e9d4ceaef97f10f46a upstream. This reverts commit 410bd754cd73c4a2ac3856d9a03d7b08f9c906bf. The reverted commit had added a retry mechanism to the command entry index allocation. The previous patch ensures that there is a free command entry index once the command work handler holds the command semaphore. Thus the retry mechanism is not needed. Fixes: 410bd754cd73 ("net/mlx5: Add retry mechanism to the command entry index allocation") Signed-off-by: Moshe Shemesh <[email protected]> Reviewed-by: Eran Ben Elisha <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit b8b4a083ab94bfadc742bbc2f023534b602a01c2 Author: Amelie Delaunay <[email protected]> Date: Mon Dec 20 17:58:27 2021 +0100 dmaengine: stm32-mdma: fix STM32_MDMA_CTBR_TSEL_MASK commit e7f110889a87307fb0fed408a5dee1707796ca04 upstream. This patch fixes STM32_MDMA_CTBR_TSEL_MASK, which is [5:0], not [7:0]. Fixes: a4ffb13c8946 ("dmaengine: Add STM32 MDMA driver") Signed-off-by: Amelie Delaunay <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 7de812fc6be4c191dadc4a4b4c3a070413a281c6 Author: Chengguang Xu <[email protected]> Date: Sat Dec 18 19:23:20 2021 +0800 RDMA/rxe: Fix a typo in opcode name commit 8d1cfb884e881efd69a3be4ef10772c71cb22216 upstream. There is a redundant ']' in the name of opcode IB_OPCODE_RC_SEND_MIDDLE, so just fix it. Fixes: 8700e3e7c485 ("Soft RoCE driver") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Chengguang Xu <[email protected]> Acked-by: Zhu Yanjun <[email protected]> Reviewed-by: Bob Pearson <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 779ff1e23450b37c164dabe80ed070cf2e388927 Author: Yixing Liu <[email protected]> Date: Mon Dec 6 21:36:52 2021 +0800 RDMA/hns: Modify the mapping attribute of doorbell to device commit 39d5534b1302189c809e90641ffae8cbdc42a8fc upstream. It is more general for ARM device drivers to use the device attribute to map PCI BAR spaces. Fixes: 9a4435375cd1 ("IB/hns: Add driver files for hns RoCE driver") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Yixing Liu <[email protected]> Signed-off-by: Wenpeng Liang <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit dcb7718a80736bfffed7362493a931040c8a78da Author: Dave Jiang <[email protected]> Date: Tue Dec 14 13:15:17 2021 -0700 dmaengine: idxd: fix wq settings post wq disable commit 0f225705cf6536826318180831e18a74595efc8d upstream. By the spec, wq size and group association is not changeable unless device is disabled. Exclude clearing the shadow copy on wq disable/reset. This allows wq type to be changed after disable to be re-enabled. Move the size and group association to its own cleanup and only call it during device disable. Fixes: 0dcfe41e9a4c ("dmanegine: idxd: cleanup all device related bits after disabling device") Reported-by: Lucas Van <[email protected]> Tested-by: Lucas Van <[email protected]> Signed-off-by: Dave Jiang <[email protected]> Link: https://lore.kernel.org/r/163951291732.2987775.13576571320501115257.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit d87eb22b94f6068b159412c4e7a3e446f3da7953 Author: Kunihiko Hayashi <[email protected]> Date: Tue Dec 14 13:42:43 2021 +0900 dmaengine: uniphier-xdmac: Fix type of address variables commit 105a8c525675bb7d4d64871f9b2edf39460de881 upstream. The variables src_addr and dst_addr handle DMA addresses, so these should be declared as dma_addr_t. Fixes: 667b9251440b ("dmaengine: uniphier-xdmac: Add UniPhier external DMA controller driver") Signed-off-by: Kunihiko Hayashi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 60390c2242d6c70c7004f3261f86242742167ad2 Author: Håkon Bugge <[email protected]> Date: Tue Nov 23 11:06:18 2021 +0100 RDMA/cma: Remove open coding of overflow checking for private_data_len commit 8d0d2b0f41b1b2add8a30dbd816051a964efa497 upstream. The existing tests are a little hard to comprehend. Use check_add_overflow() instead. Fixes: 04ded1672402 ("RDMA/cma: Verify private data length") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Håkon Bugge <[email protected]> Reviewed-by: Leon Romanovsky <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 0dc4db8abccf266390b81b72064191f876e55876 Author: Miaoqian Lin <[email protected]> Date: Wed Dec 22 07:09:30 2021 +0000 scsi: ufs: ufs-mediatek: Fix error checking in ufs_mtk_init_va09_pwr_ctrl() commit 3ba880a12df5aa4488c18281701b5b1bc3d4531a upstream. The function regulator_get() returns an error pointer. Use IS_ERR() to validate the return value. Link: https://lore.kernel.org/r/[email protected] Fixes: cf137b3ea49a ("scsi: ufs-mediatek: Support VA09 regulator operations") Signed-off-by: Miaoqian Lin <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 46f6dda2a6fc46339832a71036dff6f36b368597 Author: Bart Van Assche <[email protected]> Date: Mon Nov 29 11:46:00 2021 -0800 scsi: core: Show SCMD_LAST in text form commit 3369046e54ca8f82e0cb17740643da2d80d3cfa8 upstream. The SCSI debugfs code supports showing information about pending commands, including translating SCSI command flags from numeric into text format. Also convert the SCMD_LAST flag from numeric into text form. Link: https://lore.kernel.org/r/[email protected] Fixes: 8930a6c20791 ("scsi: core: add support for request batching") Signed-off-by: Bart Van Assche <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 53b2ad98d2bb6c2d020cb4bd7e2d406bb310b0e7 Author: Luiz Augusto von Dentz <[email protected]> Date: Mon Nov 1 15:14:41 2021 -0700 Bluetooth: hci_sync: Fix not setting adv set duration commit f16a491c65d9eb19398b25aefc10c2d3313d17b3 upstream. 10bbffa3e88e attempted to fix the use of rotation duration as advertising duration but it didn't change the if condition which still uses the duration instead of the timeout. Fixes: 10bbffa3e88e ("Bluetooth: Fix using advertising instance duration as timeout") Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 7055782bc72217c9f6662e592f99e4b318bc0b88 Author: Markus Reichl <[email protected]> Date: Thu Jan 13 21:01:11 2022 +0100 net: usb: Correct reset handling of smsc95xx commit 0bf3885324a8599e3af4c7379b8d4f621c9bbffa upstream. On boards with LAN9514 and no preconfigured MAC address we don't get an ip address from DHCP after commit a049a30fc27c ("net: usb: Correct PHY handling of smsc95xx") anymore. Adding an explicit reset before starting the phy fixes the issue. [1] https://lore.kernel.org/netdev/[email protected]/ From: Gabriel Hojda <[email protected]> Fixes: a049a30fc27c ("net: usb: Correct PHY handling of smsc95xx") Signed-off-by: Gabriel Hojda <[email protected]> Signed-off-by: Markus Reichl <[email protected]> Tested-by: Alexander Stein <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit a15a5eabae418ff91ebce8de3f6815433b49ad1d Author: Mark Chen <[email protected]> Date: Tue Dec 7 01:33:43 2021 +0800 Bluetooth: btusb: Return error code when getting patch status failed commit 995d948cf2e45834275f07afc1c9881a9902e73c upstream. If there are failure cases in getting patch status, it should return the error code (-EIO). Fixes: fc342c4dc4087 ("Bluetooth: btusb: Add protocol support for MediaTek MT7921U USB devices") Co-developed-by: Sean Wang <[email protected]> Signed-off-by: Sean Wang <[email protected]> Signed-off-by: Mark Chen <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 9e2d8d9c0e330f3af0c43c8362bf0e5d9f5f1137 Author: Randy Dunlap <[email protected]> Date: Tue Jan 18 19:39:05 2022 -0800 Documentation: fix firewire.rst ABI file path error commit b0ac702f3329cdc8a06dcaac73183d4b5a2b942d upstream. Adjust the path of the ABI files for firewire.rst to prevent a documentation build error. Prevents this problem: Sphinx parallel build error: docutils.utils.SystemMessage: Documentation/driver-api/firewire.rst:22: (SEVERE/4) Problems with "include" directive path: InputError: [Errno 2] No such file or directory: '../Documentation/driver-api/ABI/stable/firewire-cdev'. Fixes: 2f4830ef96d2 ("FireWire: add driver-api Introduction section") Signed-off-by: Randy Dunlap <[email protected]> Tested-by: Akira Yokosawa <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Corbet <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit b791ffcb23c90285140fd3aba7e04ac850183487 Author: Lukas Bulwahn <[email protected]> Date: Thu Dec 30 18:19:40 2021 +0100 Documentation: refer to config RANDOMIZE_BASE for kernel address-space randomization commit 82ca67321f55a8d1da6ac3ed611da3c32818bb37 upstream. The config RANDOMIZE_SLAB does not exist, the authors probably intended to refer to the config RANDOMIZE_BASE, which provides kernel address-space randomization. They probably just confused SLAB with BASE (these two four-letter words coincidentally share three common letters), as they also point out the config SLAB_FREELIST_RANDOM as further randomization within the same sentence. Fix the reference of the config for kernel address-space randomization to the config that provides that. Fixes: 6e88559470f5 ("Documentation: Add section about CPU vulnerabilities for Spectre") Signed-off-by: Lukas Bulwahn <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Corbet <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 63e9fdd76ccae77466ca306acb981bd4d701dc93 Author: Alexandre Ghiti <[email protected]> Date: Thu Dec 16 10:44:23 2021 +0100 Documentation, arch: Remove leftovers from CIFS_WEAK_PW_HASH commit 2ac7069ad7647cd1d9ca5b08765a1e116e13cdc4 upstream. This config was removed so remove all references to it. Fixes: 76a3c92ec9e0 ("cifs: remove support for NTLM and weaker authentication algorithms") Signed-off-by: Alexandre Ghiti <[email protected]> Reviewed-by: Steve French <[email protected]> Acked-by: Arnd Bergmann <[email protected]> [arch/arm/configs] Acked-by: Thomas Bogendoerfer <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 2644d43268da13adad2a7ec3ea2d303db62a4082 Author: Alexandre Ghiti <[email protected]> Date: Thu Dec 16 10:44:22 2021 +0100 Documentation, arch: Remove leftovers from raw device commit 473dcf0ffc31ce1135cd10578e7e06698cf51f4a upstream. Raw device interface was removed so remove all references to configs related to it. Fixes: 603e4922f1c8 ("remove the raw driver") Signed-off-by: Alexandre Ghiti <[email protected]> Acked-by: Arnd Bergmann <[email protected]> [arch/arm/configs] Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 6bcac3149e9449883e9cbaa3b40cffe8896fdaf3 Author: Sakari Ailus <[email protected]> Date: Wed Dec 1 14:59:31 2021 +0200 Documentation: ACPI: Fix data node reference documentation commit a11174952205d082f1658fab4314f0caf706e0a8 upstream. The data node reference documentation was missing a package that must contain the property values, instead property name and multiple values being present in a single package. This is not aligned with the _DSD spec. Fix it by adding the package for the values. Also add the missing "reg" properties to two numbered nodes. Fixes: b10134a3643d ("ACPI: property: Document hierarchical data extension references") Signed-off-by: Sakari Ailus <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit d4aa8cd70b3fd9fe9565feff5a4a746bf515d6d9 Author: Daniel Thompson <[email protected]> Date: Thu Nov 18 10:09:52 2021 +0000 Documentation: dmaengine: Correctly describe dmatest with channel unset commit c61d7b2ef141abf81140756b45860a2306f395a2 upstream. Currently the documentation states that channels must be configured before running the dmatest. This has not been true since commit 6b41030fdc79 ("dmaengine: dmatest: Restore default for channel"). Fix accordingly. Fixes: 6b41030fdc79 ("dmaengine: dmatest: Restore default for channel") Signed-off-by: Daniel Thompson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 1d4f0d707d35f3e1779a4e95cbc79b24320c9ab9 Author: Mike Leach <[email protected]> Date: Wed Nov 17 16:42:20 2021 +0000 Documentation: coresight: Fix documentation issue commit 66bd1333abd7fa191f13b929c9119d6cd3df27b0 upstream. Fix the description of the directories and attributes used in cs_etm as used by perf. Drop the references to the 'configurations' sub-directory which had been removed in an earlier version of the patchset. Fixes: f71cd93d5ea4 ("Documentation: coresight: Add documentation for CoreSight config") Reported-by: German Gomex <[email protected]> Signed-off-by: Mike Leach <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mathieu Poirier <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit aceb8d70f7aa351c1bbf49f24f29d25e11d0aa47 Author: Randy Dunlap <[email protected]> Date: Sun Nov 7 18:19:23 2021 +0000 media: correct MEDIA_TEST_SUPPORT help text commit 09f4d1513267d0ab712f5d29e7bd136535748709 upstream. Fix grammar/wording in the help text for MEDIA_TEST_SUPPORT. Fixes: 4b32216adb01 ("media: split test drivers from platform directory") Signed-off-by: Randy Dunlap <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit fbe1e801bc1fa0a4c34a5284abf6ad0ef887cdfc Author: Maxime Ripard <[email protected]> Date: Thu Aug 19 15:59:30 2021 +0200 drm/vc4: hdmi: Make sure the device is powered with CEC commit 20b0dfa86bef0e80b41b0e5ac38b92f23b6f27f9 upstream. Similarly to what we encountered with the detect hook with DRM, nothing actually prevents any of the CEC callback from being run while the HDMI output is disabled. However, this is an issue since any register access to the controller when it's powered down will result in a silent hang. Let's make sure we run the runtime_pm hooks when the CEC adapter is opened and closed by the userspace to avoid that issue. Fixes: 15b4511a4af6 ("drm/vc4: add HDMI CEC support") Reviewed-by: Dave Stevenson <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 31a5bdbe4a68e7d1e9dba536d5ff64c08cb7d57d Author: Suresh Udipi <[email protected]> Date: Fri Aug 13 17:07:56 2021 +0200 media: rcar-csi2: Optimize the selection PHTW register commit 549cc89cd09a85aaa16dc07ef3db811d5cf9bcb1 upstream. PHTW register is selected based on default bit rate from Table[1]. for the bit rates less than or equal to 250. Currently first value of default bit rate which is greater than or equal to the caculated mbps is selected. This selection can be further improved by selecting the default bit rate which is nearest to the calculated value. [1] specs r19uh0105ej0200-r-car-3rd-generation.pdf [Table 25.12] Fixes: 769afd212b16 ("media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver driver") Signed-off-by: Suresh Udipi <[email protected]> Signed-off-by: Michael Rodin <[email protected]> Reviewed-by: Niklas Söderlund <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit c8e0c2cf2dd42ae2a545a6b42ef883bf3ed7155b Author: Marc Kleine-Budde <[email protected]> Date: Fri Apr 23 11:26:56 2021 +0200 can: mcp251xfd: mcp251xfd_tef_obj_read(): fix typo in error message commit 99e7cc3b3f85d9a583ab83f386315c59443509ae upstream. This patch fixes a typo in the error message in mcp251xfd_tef_obj_read(), if trying to read too many objects. Link: https://lore.kernel.org/all/[email protected] Fixes: 55e5b97f003e ("can: mcp25xxfd: add driver for Microchip MCP25xxFD SPI CAN") Signed-off-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 1844b8ae85ac22563b92cffafaf18f528416a3b0 Author: Ben Hutchings <[email protected]> Date: Mon Jun 18 23:55:40 2018 +0100 firmware: Update Kconfig help text for Google firmware commit d185a3466f0cd5af8f1c5c782c53bc0e6f2e7136 upstream. The help text for GOOGLE_FIRMWARE states that it should only be enabled when building a kernel for Google's own servers. However, many of the drivers dependent on it are also useful on Chromebooks or on any platform using coreboot. Update the help text to reflect this double duty. Fixes: d384d6f43d1e ("firmware: google memconsole: Add coreboot support") Reviewed-by: Julius Werner <[email protected]> Signed-off-by: Ben Hutchings <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 3252ca8b667396aef16e856ba9cf32a04cdbb2d6 Author: Baruch Siach <[email protected]> Date: Thu Dec 30 18:31:53 2021 +0200 of: base: Improve argument length mismatch error commit 5d05b811b5acb92fc581a7b328b36646c86f5ab9 upstream. The cells_name field of of_phandle_iterator might be NULL. Use the phandle name instead. With this change instead of: OF: /soc/pinctrl@1000000: (null) = 3 found 2 We get: OF: /soc/pinctrl@1000000: phandle pinctrl@1000000 needs 3, found 2 Which is a more helpful messages making DT debugging easier. In this particular example the phandle name looks like duplicate of the same node name. But note that the first node is the parent node (it->parent), while the second is the phandle target (it->node). They happen to be the same in the case that triggered this improvement. See commit 72cb4c48a46a ("arm64: dts: qcom: ipq6018: Fix gpio-ranges property"). Signed-off-by: Baruch Siach <[email protected]> Signed-off-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/f6a68e0088a552ea9dfd4d8e3b5b586d92594738.1640881913.git.baruch@tkos.co.il Signed-off-by: Greg Kroah-Hartman <[email protected]> commit f22f67b43775fffb09f371ea861779cdbbb763ec Author: Christian König <[email protected]> Date: Mon Jan 17 10:31:26 2022 +0100 drm/radeon: fix error handling in radeon_driver_open_kms commit 4722f463896cc0ef1a6f1c3cb2e171e949831249 upstream. The return value was never initialized so the cleanup code executed when it isn't even necessary. Just add proper error handling. Fixes: ab50cb9df889 ("drm/radeon/radeon_kms: Fix a NULL pointer dereference in radeon_driver_open_kms()") Signed-off-by: Christian König <[email protected]> Tested-by: Jan Stancek <[email protected]> Tested-by: Borislav Petkov <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 16c436fa4f748c6d5a65acf749e6054801784a2f Author: Aaron Ma <[email protected]> Date: Tue Sep 28 12:05:43 2021 +0300 ath11k: qmi: avoid error messages when dma allocation fails commit b9b5948cdd7bc8d9fa31c78cbbb04382c815587f upstream. qmi tries to allocate a large contiguous dma memory at first, on the AMD Ryzen platform it fails, then retries with small slices. So set flag GFP_NOWARN to avoid flooding dmesg. Signed-off-by: Aaron Ma <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Cc: "Limonciello, Mario" <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit cb77c81d347980f029e2e1ccdb80eb550d50eaf1 Author: Nikita Yushchenko <[email protected]> Date: Sun Jan 9 18:34:59 2022 +0300 tracing/osnoise: Properly unhook events if start_per_cpu_kthreads() fails commit 0878355b51f5f26632e652c848a8e174bb02d22d upstream. If start_per_cpu_kthreads() called from osnoise_workload_start() returns error, event hooks are left in broken state: unhook_irq_events() called but unhook_thread_events() and unhook_softirq_events() not called, and trace_osnoise_callback_enabled flag not cleared. On the next tracer enable, hooks get not installed due to trace_osnoise_callback_enabled flag. And on the further tracer disable an attempt to remove non-installed hooks happened, hitting a WARN_ON_ONCE() in tracepoint_remove_func(). Fix the error path by adding the missing part of cleanup. While at this, introduce osnoise_unhook_events() to avoid code duplication between this error path and normal tracer disable. Link: https://lkml.kernel.org/r/[email protected] Cc: [email protected] Fixes: bce29ac9ce0b ("trace: Add osnoise tracer") Acked-by: Daniel Bristot de Oliveira <[email protected]> Signed-off-by: Nikita Yushchenko <[email protected]> Signed-off-by: Steven Rostedt <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 0d99b0a7c329b972d40f8f136576931673d4b261 Author: Theodore Ts'o <[email protected]> Date: Wed Jan 5 23:59:56 2022 -0500 ext4: don't use the orphan list when migrating an inode commit 6eeaf88fd586f05aaf1d48cb3a139d2a5c6eb055 upstream. We probably want to remove the indirect block to extents migration feature after a deprecation window, but until then, let's fix a potential data loss problem caused by the fact that we put the tmp_inode on the orphan list. In the unlikely case where we crash and do a journal recovery, the data blocks belonging to the inode being migrated are also represented in the tmp_inode on the orphan list --- and so its data blocks will get marked unallocated, and available for reuse. Instead, stop putting the tmp_inode on the oprhan list. So in the case where we crash while migrating the inode, we'll leak an inode, which is not a disaster. It will be easily fixed the next time we run fsck, and it's better than potentially having blocks getting claimed by two different files, and losing data as a result. Signed-off-by: Theodore Ts'o <[email protected]> Reviewed-by: Lukas Czerner <[email protected]> Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit e58742f46afc5d89f1f9b122627b4d81a31be9bd Author: Zhang Yi <[email protected]> Date: Sat Dec 25 17:09:37 2021 +0800 ext4: fix an use-after-free issue about data=journal writeback mode commit 5c48a7df91499e371ef725895b2e2d21a126e227 upstream. Our syzkaller report an use-after-free issue that accessing the freed buffer_head on the writeback page in __ext4_journalled_writepage(). The problem is that if there was a truncate racing with the data=journalled writeback procedure, the writeback length could become zero and bget_one() refuse to get buffer_head's refcount, then the truncate procedure release buffer once we drop page lock, finally, the last ext4_walk_page_buffers() trigger the use-after-free problem. sync truncate ext4_sync_file() file_write_and_wait_range() ext4_setattr(0) inode->i_size = 0 ext4_writepage() len = 0 __ext4_journalled_writepage() page_bufs = page_buffers(page) ext4_walk_page_buffers(bget_one) <- does not get refcount do_invalidatepage() free_buffer_head() ext4_walk_page_buffers(page_bufs) <- trigger use-after-free After commit bdf96838aea6 ("ext4: fix race between truncate and __ext4_journalled_writepage()"), we have already handled the racing case, so the bget_one() and bput_one() are not needed. So this patch simply remove these hunk, and recheck the i_size to make it safe. Fixes: bdf96838aea6 ("ext4: fix race between truncate and __ext4_journalled_writepage()") Signed-off-by: Zhang Yi <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 0a3624bfdc00b4886e82a4acdab6738d974f739d Author: Ye Bin <[email protected]> Date: Fri Dec 24 18:03:41 2021 +0800 ext4: fix null-ptr-deref in '__ext4_journal_ensure_credits' commit 298b5c521746d69c07beb2757292fb5ccc1b0f85 upstream. We got issue as follows when run syzkaller test: [ 1901.130043] EXT4-fs error (device vda): ext4_remount:5624: comm syz-executor.5: Abort forced by user [ 1901.130901] Aborting journal on device vda-8. [ 1901.131437] EXT4-fs error (device vda): ext4_journal_check_start:61: comm syz-executor.16: Detected aborted journal [ 1901.131566] EXT4-fs error (device vda): ext4_journal_check_start:61: comm syz-executor.11: Detected aborted journal [ 1901.132586] EXT4-fs error (device vda): ext4_journal_check_start:61: comm syz-executor.18: Detected aborted journal [ 1901.132751] EXT4-fs error (device vda): ext4_journal_check_start:61: comm syz-executor.9: Detected aborted journal [ 1901.136149] EXT4-fs error (device vda) in ext4_reserve_inode_write:6035: Journal has aborted [ 1901.136837] EXT4-fs error (device vda): ext4_journal_check_start:61: comm syz-fuzzer: Detected aborted journal [ 1901.136915] ================================================================== [ 1901.138175] BUG: KASAN: null-ptr-deref in __ext4_journal_ensure_credits+0x74/0x140 [ext4] [ 1901.138343] EXT4-fs error (device vda): ext4_journal_check_start:61: comm syz-executor.13: Detected aborted journal [ 1901.138398] EXT4-fs error (device vda): ext4_journal_check_start:61: comm syz-executor.1: Detected aborted journal [ 1901.138808] Read of size 8 at addr 0000000000000000 by task syz-executor.17/968 [ 1901.138817] [ 1901.138852] EXT4-fs error (device vda): ext4_journal_check_start:61: comm syz-executor.30: Detected aborted journal [ 1901.144779] CPU: 1 PID: 968 Comm: syz-executor.17 Not tainted 4.19.90-vhulk2111.1.0.h893.eulerosv2r10.aarch64+ #1 [ 1901.146479] Hardware name: linux,dummy-virt (DT) [ 1901.147317] Call trace: [ 1901.147552] dump_backtrace+0x0/0x2d8 [ 1901.147898] show_stack+0x28/0x38 [ 1901.148215] dump_stack+0xec/0x15c [ 1901.148746] kasan_report+0x108/0x338 [ 1901.149207] __asan_load8+0x58/0xb0 [ 1901.149753] __ext4_journal_ensure_credits+0x74/0x140 [ext4] [ 1901.150579] ext4_xattr_delete_inode+0xe4/0x700 [ext4] [ 1901.151316] ext4_evict_inode+0x524/0xba8 [ext4] [ 1901.151985] evict+0x1a4/0x378 [ 1901.152353] iput+0x310/0x428 [ 1901.152733] do_unlinkat+0x260/0x428 [ 1901.153056] __arm64_sys_unlinkat+0x6c/0xc0 [ 1901.153455] el0_svc_common+0xc8/0x320 [ 1901.153799] el0_svc_handler+0xf8/0x160 [ 1901.154265] el0_svc+0x10/0x218 [ 1901.154682] ================================================================== This issue may happens like this: Process1 Process2 ext4_evict_inode ext4_journal_start ext4_truncate ext4_ind_truncate ext4_free_branches ext4_ind_truncate_ensure_credits ext4_journal_ensure_credits_fn ext4_journal_restart handle->h_transaction = NULL; mount -o remount,abort /mnt -> trigger JBD abort start_this_handle -> will return failed ext4_xattr_delete_inode ext4_journal_ensure_credits ext4_journal_ensure_credits_fn __ext4_journal_ensure_credits jbd2_handle_buffer_credits journal = handle->h_transaction->t_journal; ->null-ptr-deref Now, indirect truncate process didn't handle error. To solve this issue maybe simply add check handle is abort in '__ext4_journal_ensure_credits' is enough, and i also think this is necessary. Cc: [email protected] Signed-off-by: Ye Bin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit c857769622f3647f973bb75a8a040e694f498a93 Author: Sebastian Andrzej Siewior <[email protected]> Date: Thu Dec 23 17:44:36 2021 +0100 ext4: destroy ext4_fc_dentry_cachep kmemcache on module removal commit ab047d516dea72f011c15c04a929851e4d053109 upstream. The kmemcache for ext4_fc_dentry_cachep remains registered after module removal. Destroy ext4_fc_dentry_cachep kmemcache on module removal. Fixes: aa75f4d3daaeb ("ext4: main fast-commit commit path") Signed-off-by: Sebastian Andrzej Siewior <[email protected]> Reviewed-by: Lukas Czerner <[email protected]> Reviewed-by: Harshad Shirwadkar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 95fb4c496a7abebb50ba49b0bbba9de6d8466fa7 Author: Xin Yin <[email protected]> Date: Thu Dec 23 11:23:37 2021 +0800 ext4: fast commit may miss tracking unwritten range during ftruncate commit 9725958bb75cdfa10f2ec11526fdb23e7485e8e4 upstream. If use FALLOC_FL_KEEP_SIZE to alloc unwritten range at bottom, the inode->i_size will not include the unwritten range. When call ftruncate with fast commit enabled, it will miss to track the unwritten range. Change to trace the full range during ftruncate. Signed-off-by: Xin Yin <[email protected]> Reviewed-by: Harshad Shirwadkar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 82034851e93bfb1407129b09ad1d1f3392be486e Author: Xin Yin <[email protected]> Date: Thu Dec 23 11:23:36 2021 +0800 ext4: use ext4_ext_remove_space() for fast commit replay delete range commit 0b5b5a62b945a141e64011b2f90ee7e46f14be98 upstream. For now ,we use ext4_punch_hole() during fast commit replay delete range procedure. But it will be affected by inode->i_size, which may not correct during fast commit replay procedure. The following test will failed. -create & write foo (len 1000K) -falloc FALLOC_FL_ZERO_RANGE foo (range 400K - 600K) -create & fsync bar -falloc FALLOC_FL_PUNCH_HOLE foo (range 300K-500K) -fsync foo -crash before a full commit After the fast_commit reply procedure, the range 400K-500K will not be removed. Because in this case, when calling ext4_punch_hole() the inode->i_size is 0, and it just retruns with doing nothing. Change to use ext4_ext_remove_space() instead of ext4_punch_hole() to remove blocks of inode directly. Signed-off-by: Xin Yin <[email protected]> Reviewed-by: Harshad Shirwadkar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit efbb6fcced2d0cb9b8dc604fd13ccdd76d50bbfb Author: Ye Bin <[email protected]> Date: Thu Dec 23 09:55:06 2021 +0800 ext4: Fix BUG_ON in ext4_bread when write quota data commit 380a0091cab482489e9b19e07f2a166ad2b76d5c upstream. We got issue as follows when run syzkaller: [ 167.936972] EXT4-fs error (device loop0): __ext4_remount:6314: comm rep: Abort forced by user [ 167.938306] EXT4-fs (loop0): Remounting filesystem read-only [ 167.981637] Assertion failure in ext4_getblk() at fs/ext4/inode.c:847: '(EXT4_SB(inode->i_sb)->s_mount_state & EXT4_FC_REPLAY) || handle != NULL || create == 0' [ 167.983601] ------------[ cut here ]------------ [ 167.984245] kernel BUG at fs/ext4/inode.c:847! [ 167.984882] invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI [ 167.985624] CPU: 7 PID: 2290 Comm: rep Tainted: G B 5.16.0-rc5-next-20211217+ #123 [ 167.986823] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ 167.988590] RIP: 0010:ext4_getblk+0x17e/0x504 [ 167.989189] Code: c6 01 74 28 49 c7 c0 a0 a3 5c 9b b9 4f 03 00 00 48 c7 c2 80 9c 5c 9b 48 c7 c6 40 b6 5c 9b 48 c7 c7 20 a4 5c 9b e8 77 e3 fd ff <0f> 0b 8b 04 244 [ 167.991679] RSP: 0018:ffff8881736f7398 EFLAGS: 00010282 [ 167.992385] RAX: 0000000000000094 RBX: 1ffff1102e6dee75 RCX: 0000000000000000 [ 167.993337] RDX: 0000000000000001 RSI: ffffffff9b6e29e0 RDI: ffffed102e6dee66 [ 167.994292] RBP: ffff88816a076210 R08: 0000000000000094 R09: ffffed107363fa09 [ 167.995252] R10: ffff88839b1fd047 R11: ffffed107363fa08 R12: ffff88816a0761e8 [ 167.996205] R13: 0000000000000000 R14: 0000000000000021 R15: 0000000000000001 [ 167.997158] FS: 00007f6a1428c740(0000) GS:ffff88839b000000(0000) knlGS:0000000000000000 [ 167.998238] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 167.999025] CR2: 00007f6a140716c8 CR3: 0000000133216000 CR4: 00000000000006e0 [ 167.999987] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 168.000944] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 168.001899] Call Trace: [ 168.002235] <TASK> [ 168.007167] ext4_bread+0xd/0x53 [ 168.007612] ext4_quota_write+0x20c/0x5c0 [ 168.010457] write_blk+0x100/0x220 [ 168.010944] remove_free_dqentry+0x1c6/0x440 [ 168.011525] free_dqentry.isra.0+0x565/0x830 [ 168.012133] remove_tree+0x318/0x6d0 [ 168.014744] remove_tree+0x1eb/0x6d0 [ 168.017346] remove_tree+0x1eb/0x6d0 [ 168.019969] remove_tree+0x1eb/0x6d0 [ 168.022128] qtree_release_dquot+0x291/0x340 [ 168.023297] v2_release_dquot+0xce/0x120 [ 168.023847] dquot_release+0x197/0x3e0 [ 168.024358] ext4_release_dquot+0x22a/0x2d0 [ 168.024932] dqput.part.0+0x1c9/0x900 [ 168.025430] __dquot_drop+0x120/0x190 [ 168.025942] ext4_clear_inode+0x86/0x220 [ 168.026472] ext4_evict_inode+0x9e8/0xa22 [ 168.028200] evict+0x29e/0x4f0 [ 168.028625] dispose_list+0x102/0x1f0 [ 168.029148] evict_inodes+0x2c1/0x3e0 [ 168.030188] generic_shutdown_super+0xa4/0x3b0 [ 168.030817] kill_block_super+0x95/0xd0 [ 168.031360] deactivate_locked_super+0x85/0xd0 [ 168.031977] cleanup_mnt+0x2bc/0x480 [ 168.033062] task_work_run+0xd1/0x170 [ 168.033565] do_exit+0xa4f/0x2b50 [ 168.037155] do_group_exit+0xef/0x2d0 [ 168.037666] __x64_sys_exit_group+0x3a/0x50 [ 168.038237] do_syscall_64+0x3b/0x90 [ 168.038751] entry_SYSCALL_64_after_hwframe+0x44/0xae In order to reproduce this problem, the following conditions need to be met: 1. Ext4 filesystem with no journal; 2. Filesystem image with incorrect quota data; 3. Abort filesystem forced by user; 4. umount filesystem; As in ext4_quota_write: ... if (EXT4_SB(sb)->s_journal && !handle) { ext4_msg(sb, KERN_WARNING, "Quota write (off=%llu, len=%llu)" " cancelled because transaction is not started", (unsigned long long)off, (unsigned long long)len); return -EIO; } ... We only check handle if NULL when filesystem has journal. There is need check handle if NULL even when filesystem has no journal. Signed-off-by: Ye Bin <[email protected]> Reviewed-by: Jan Kara <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit fd86fd7119fbcd430ef8ad0a19255e72f2e16683 Author: Luís Henriques <[email protected]> Date: Tue Dec 14 17:50:58 2021 +0000 ext4: set csum seed in tmp inode while migrating to extents commit e81c9302a6c3c008f5c30beb73b38adb0170ff2d upstream. When migrating to extents, the temporary inode will have it's own checksum seed. This means that, when swapping the inodes data, the inode checksums will be incorrect. This can be fixed by recalculating the extents checksums again. Or simply by copying the seed into the temporary inode. Link: https://bugzilla.kernel.org/show_bug.cgi?id=213357 Reported-by: Jeroen van Wolffelaar <[email protected]> Signed-off-by: Luís Henriques <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 50bc43bc1ce0821e7042ab5ffb7a943e0ef854ba Author: Xin Yin <[email protected]> Date: Tue Dec 21 10:28:39 2021 +0800 ext4: fix fast commit may miss tracking range for FALLOC_FL_ZERO_RANGE commit 5e4d0eba1ccaf19f93222abdeda5a368be141785 upstream. when call falloc with FALLOC_FL_ZERO_RANGE, to set an range to unwritten, which has been already initialized. If the range is align to blocksize, fast commit will not track range for this change. Also track range for unwritten range in ext4_map_blocks(). Signed-off-by: Xin Yin <[email protected]> Reviewed-by: Harshad Shirwadkar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 85cc4554eea845ae0a1b06f43df6b566ff6776d2 Author: Harshad Shirwadkar <[email protected]> Date: Wed Dec 1 08:34:21 2021 -0800 ext4: initialize err_blk before calling __ext4_get_inode_loc commit c27c29c6af4f3f4ce925a2111c256733c5a5b430 upstream. It is not guaranteed that __ext4_get_inode_loc will definitely set err_blk pointer when it returns EIO. To avoid using uninitialized variables, let's first set err_blk to 0. Reported-by: Dan Carpenter <[email protected]> Signed-off-by: Harshad Shirwadkar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 2d221d9b17fa3065ba7c3afd8ff0a8e1f2818497 Author: Chunguang Xu <[email protected]> Date: Tue Nov 23 09:17:57 2021 +0800 ext4: fix a possible ABBA deadlock due to busy PA commit 8c80fb312d7abf8bcd66cca1d843a80318a2c522 upstream. We found on older kernel (3.10) that in the scenario of insufficient disk space, system may trigger an ABBA deadlock problem, it seems that this problem still exists in latest kernel, try to fix it here. The main process triggered by this problem is that task A occupies the PA and waits for the jbd2 transaction finish, the jbd2 transaction waits for the completion of task B's IO (plug_list), but task B waits for the release of PA by task A to finish discard, which indirectly forms an ABBA deadlock. The related calltrace is as follows: Task A vfs_write ext4_mb_new_blocks() ext4_mb_mark_diskspace_used() JBD2 jbd2_journal_get_write_access() -> jbd2_journal_commit_transaction() ->schedule() filemap_fdatawait() | | | Task B | | do_unlinkat() | | ext4_evict_inode() | | jbd2_journal_begin_ordered_truncate() | | filemap_fdatawrite_range() | | ext4_mb_new_blocks() | -ext4_mb_discard_group_preallocations() <----- Here, try to cancel ext4_mb_discard_group_preallocations() internal retry due to PA busy, and do a limited number of retries inside ext4_mb_discard_preallocations(), which can circumvent the above problems, but also has some advantages: 1. Since the PA is in a busy state, if other groups have free PAs, keeping the current PA may help to reduce fragmentation. 2. Continue to traverse forward instead of waiting for the current group PA to be released. In most scenarios, the PA discard time can be reduced. However, in the case of smaller free space, if only a few groups have space, then due to multiple traversals of the group, it may increase CPU overhead. But in contrast, I feel that the overall benefit is better than the cost. Signed-off-by: Chunguang Xu <[email protected]> Reported-by: kernel test robot <[email protected]> Reviewed-by: Jan Kara <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit bca8a2bfbdd0ebf13828d48c6e1acc2f658e04e1 Author: Jan Kara <[email protected]> Date: Thu Oct 7 17:53:35 2021 +0200 ext4: make sure quota gets properly shutdown on error commit 15fc69bbbbbc8c72e5f6cc4e1be0f51283c5448e upstream. When we hit an error when enabling quotas and setting inode flags, we do not properly shutdown quota subsystem despite returning error from Q_QUOTAON quotactl. This can lead to some odd situations like kernel using quota file while it is still writeable for userspace. Make sure we properly cleanup the quota subsystem in case of error. Signed-off-by: Jan Kara <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 8ffe9ad9f5efc14a0d7a706ba3b8ee616b682872 Author: Jan Kara <[email protected]> Date: Thu Oct 7 17:53:36 2021 +0200 ext4: make sure to reset inode lockdep class when quota enabling fails commit 4013d47a5307fdb5c13370b5392498b00fedd274 upstream. When we succeed in enabling some quota type but fail to enable another one with quota feature, we correctly disable all enabled quota types. However we forget to reset i_data_sem lockdep class. When the inode gets freed and reused, it will inherit this lockdep class (i_data_sem is initialized only when a slab is created) and thus eventually lockdep barfs about possible deadlocks. Reported-and-tested-by: [email protected] Signed-off-by: Jan Kara <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 5237c93d58c3723e99a03f2d3305145d67dfebe0 Author: Filipe Manana <[email protected]> Date: Thu Dec 16 15:00:32 2021 +0000 btrfs: respect the max size in the header when activating swap file commit c2f822635df873c510bda6fb7fd1b10b7c31be2d upstream. If we extended the size of a swapfile after its header was created (by the mkswap utility) and then try to activate it, we will map the entire file when activating the swap file, instead of limiting to the max size defined in the swap file's header. Currently test case generic/643 from fstests fails because we do not respect that size limit defined in the swap file's header. So fix this by not mapping file ranges beyond the max size defined in the swap header. This is the same type of bug that iomap used to have, and was fixed in commit 36ca7943ac18ae ("mm/swap: consider max pages in iomap_swapfile_add_extent"). Fixes: ed46ff3d423780 ("Btrfs: support swap files") CC: [email protected] # 5.4+ Reviewed-and-tested-by: Josef Bacik <[email protected] Signed-off-by: Filipe Manana <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 724d9fa55cbea7ed9e61500da0f13a1dd660bd6c Author: Josef Bacik <[email protected]> Date: Wed Nov 24 14:14:24 2021 -0500 btrfs: check the root node for uptodate before returning it commit 120de408e4b97504a2d9b5ca534b383de2c73d49 upstream. Now that we clear the extent buffer uptodate if we fail to write it out we need to check to see if our root node is uptodate before we search down it. Otherwise we could return stale data (or potentially corrupt data that was caught by the write verification step) and think that the path is OK to search down. CC: [email protected] # 5.4+ Reviewed-by: Nikolay Borisov <[email protected]> Signed-off-by: Josef Bacik <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit ef383621b12512b241dc0d01ecdb2285d2437fbc Author: Filipe Manana <[email protected]> Date: Wed Oct 27 18:30:25 2021 +0100 btrfs: fix deadlock between quota enable and other quota operations commit 232796df8c1437c41d308d161007f0715bac0a54 upstream. When enabling quotas, we attempt to commit a transaction while holding the mutex fs_info->qgroup_ioctl_lock. This can result on a deadlock with other quota operations such as: - qgroup creation and deletion, ioctl BTRFS_IOC_QGROUP_CREATE; - adding and removing qgroup relations, ioctl BTRFS_IOC_QGROUP_ASSIGN. This is because these operations join a transaction and after that they attempt to lock the mutex fs_info->qgroup_ioctl_lock. Acquiring that mutex after joining or starting a transaction is a pattern followed everywhere in qgroups, so the quota enablement operation is the one at fault here, and should not commit a transaction while holding that mutex. Fix this by making the transaction commit while not holding the mutex. We are safe from two concurrent tasks trying to enable quotas because we are serialized by the rw semaphore fs_info->subvol_sem at btrfs_ioctl_quota_ctl(), which is the only call site for enabling quotas. When this deadlock happens, it produces a trace like the following: INFO: task syz-executor:25604 blocked for more than 143 seconds. Not tainted 5.15.0-rc6 #4 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:syz-executor state:D stack:24800 pid:25604 ppid: 24873 flags:0x00004004 Call Trace: context_switch kernel/sched/core.c:4940 [inline] __schedule+0xcd9/0x2530 kernel/sched/core.c:6287 schedule+0xd3/0x270 kernel/sched/core.c:6366 btrfs_commit_transaction+0x994/0x2e90 fs/btrfs/transaction.c:2201 btrfs_quota_enable+0x95c/0x1790 fs/btrfs/qgroup.c:1120 btrfs_ioctl_quota_ctl fs/btrfs/ioctl.c:4229 [inline] btrfs_ioctl+0x637e/0x7b70 fs/btrfs/ioctl.c:5010 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:874 [inline] __se_sys_ioctl fs/ioctl.c:860 [inline] __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:860 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f86920b2c4d RSP: 002b:00007f868f61ac58 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007f86921d90a0 RCX: 00007f86920b2c4d RDX: 0000000020005e40 RSI: 00000000c0109428 RDI: 0000000000000008 RBP: 00007f869212bd80 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f86921d90a0 R13: 00007fff6d233e4f R14: 00007fff6d233ff0 R15: 00007f868f61adc0 INFO: task syz-executor:25628 blocked for more than 143 seconds. Not tainted 5.15.0-rc6 #4 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:syz-executor state:D stack:29080 pid:25628 ppid: 24873 flags:0x00004004 Call Trace: context_switch kernel/sched/core.c:4940 [inline] __schedule+0xcd9/0x2530 kernel/sched/core.c:6287 schedule+0xd3/0x270 kernel/sched/core.c:6366 schedule_preempt_disabled+0xf/0x20 kernel/sched/core.c:6425 __mutex_lock_common kernel/locking/mutex.c:669 [inline] __mutex_lock+0xc96/0x1680 kernel/locking/mutex.c:729 btrfs_remove_qgroup+0xb7/0x7d0 fs/btrfs/qgroup.c:1548 btrfs_ioctl_qgroup_create fs/btrfs/ioctl.c:4333 [inline] btrfs_ioctl+0x683c/0x7b70 fs/btrfs/ioctl.c:5014 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:874 [inline] __se_sys_ioctl fs/ioctl.c:860 [inline] __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:860 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae Reported-by: Hao Sun <[email protected]> Link: https://lore.kernel.org/linux-btrfs/CACkBjsZQF19bQ1C6=yetF3BvL10OSORpFUcWXTP6HErshDB4dQ@mail.gmail.com/ Fixes: 340f1aa27f36 ("btrfs: qgroups: Move transaction management inside btrfs_quota_enable/disable") CC: [email protected] # 4.19 Reviewed-by: Qu Wenruo <[email protected]> Signed-off-by: Filipe Manana <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 9c1154f395cb4c24996829b0dfafa78754702729 Author: Nicolas Dichtel <[email protected]> Date: Mon Nov 22 11:33:13 2021 +0100 xfrm: fix dflt policy check when there is no policy configured commit ec3bb890817e4398f2d46e12e2e205495b116be9 upstream. When there is no policy configured on the system, the default policy is checked in xfrm_route_forward. However, it was done with the wrong direction (XFRM_POLICY_FWD instead of XFRM_POLICY_OUT). The default policy for XFRM_POLICY_FWD was checked just before, with a call to xfrm[46]_policy_check(). CC: [email protected] Fixes: 2d151d39073a ("xfrm: Add possibility to set the default to block if we have no policy") Signed-off-by: Nicolas Dichtel <[email protected]> Signed-off-by: Steffen Klassert <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 491c3ae9fbb6eecdc880aef608d35f28fc7481d3 Author: Ghalem Boudour <[email protected]> Date: Fri Nov 19 18:20:16 2021 +0100 xfrm: fix policy lookup for ipv6 gre packets commit bcf141b2eb551b3477b24997ebc09c65f117a803 upstream. On egress side, xfrm lookup is called from __gre6_xmit() with the fl6_gre_key field not initialized leading to policies selectors check failure. Consequently, gre packets are sent without encryption. On ingress side, INET6_PROTO_NOPOLICY was set, thus packets were not checked against xfrm policies. Like for egress side, fl6_gre_key should be correctly set, this is now done in decode_session6(). Fixes: c12b395a4664 ("gre: Support GRE over IPv6") Cc: [email protected] Signed-off-by: Ghalem Boudour <[email protected]> Signed-off-by: Nicolas Dichtel <[email protected]> Signed-off-by: Steffen Klassert <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 9473abe5b5bff6c34e8cda352c4b5ce6a7bc82aa Author: Pali Rohár <[email protected]> Date: Wed Nov 24 16:59:44 2021 +0100 PCI: pci-bridge-emul: Set PCI_STATUS_CAP_LIST for PCIe device commit 3be9d243b21724d49b65043d4520d688b6040b36 upstream. Since all PCI Express device Functions are required to implement the PCI Express Capability structure, Capabilities List bit in PCI Status Register must be hardwired to 1b. Capabilities Pointer register (which is already set by pci-bride-emul.c driver) is valid only when Capabilities List is set to 1b. Link: https://lore.kernel.org/r/[email protected] Fixes: 23a5fba4d941 ("PCI: Introduce PCI bridge emulated config space common logic") Signed-off-by: Pali Rohár <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit d4e0d674b42dfb87f556c2a7caf2e9b3defb1477 Author: Pali Rohár <[email protected]> Date: Wed Nov 24 16:59:43 2021 +0100 PCI: pci-bridge-emul: Correctly set PCIe capabilities commit 1f1050c5e1fefb34ac90a506b43e9da803b5f8f7 upstream. Older mvebu hardware provides PCIe Capability structure only in version 1. New mvebu and aardvark hardware provides it in version 2. So do not force version to 2 in pci_bridge_emul_init() and rather allow drivers to set correct version. Drivers need to set version in pcie_conf.cap field without overwriting PCI_CAP_LIST_ID register. Both drivers (mvebu and aardvark) do not provide slot support yet, so do not set PCI_EXP_FLAGS_SLOT flag. Link: https://lore.kernel.org/r/[email protected] Fixes: 23a5fba4d941 ("PCI: Introduce PCI bridge emulated config space common logic") Signed-off-by: Pali Rohár <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 9624d1eb4d1f5136183ee9aed1b3eb075f8fdf6b Author: Pali Rohár <[email protected]> Date: Wed Nov 24 16:59:42 2021 +0100 PCI: pci-bridge-emul: Fix definitions of reserved bits commit 12998087d9f48b66965b97412069c7826502cd7e upstream. Some bits in PCI_EXP registers are reserved for non-root ports. Driver pci-bridge-emul.c implements PCIe Root Port device therefore it should not allow setting reserved bits of registers. Properly define non-reserved bits for all PCI_EXP registers. Link: https://lore.kernel.org/r/[email protected] Fixes: 23a5fba4d941 ("PCI: Introduce PCI bridge emulated config space common logic") Signed-off-by: Pali Rohár <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit b1445d865b054b3de4b1bdcdb2ca8f98c4a32cc6 Author: Pali Rohár <[email protected]> Date: Wed Nov 24 16:59:40 2021 +0100 PCI: pci-bridge-emul: Properly mark reserved PCIe bits in PCI config space commit 7b067ac63a5730d2fae18399fed7e45f23d36912 upstream. Some bits in PCI config space are reserved when device is PCIe. Properly define behavior of PCI registers for PCIe emulated bridge and ensure that it would not be possible change these reserved bits. Link: https://lore.kernel.org/r/[email protected] Fixes: 23a5fba4d941 ("PCI: Introduce PCI bridge emulated config space common logic") Signed-off-by: Pali Rohár <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 15cf508331ef025c55ad5759517584232a6792fc Author: Pali Rohár <[email protected]> Date: Wed Nov 24 16:59:39 2021 +0100 PCI: pci-bridge-emul: Make expansion ROM Base Address register read-only commit 1c1a3b4d3e86b997a313ffb297c1129540882859 upstream. If expansion ROM is unsupported (which is the case of pci-bridge-emul.c driver) then ROM Base Address register must be implemented as read-only register that return 0 when read, same as for unused Base Address registers. Link: https://lore.kernel.org/r/[email protected] Fixes: 23a5fba4d941 ("PCI: Introduce PCI bridge emulated config space common logic") Signed-off-by: Pali Rohár <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit c2451a37174cf3d701f4b0345efbe28179202820 Author: Hans de Goede <[email protected]> Date: Fri Dec 17 15:17:09 2021 +0100 PCI: pciehp: Use down_read/write_nested(reset_lock) to fix lockdep errors commit 085a9f43433f30cbe8a1ade62d9d7827c3217f4d upstream. Use down_read_nested() and down_write_nested() when taking the ctrl->reset_lock rw-sem, passing the number of PCIe hotplug controllers in the path to the PCI root bus as lock subclass parameter. This fixes the following false-positive lockdep report when unplugging a Lenovo X1C8 from a Lenovo 2nd gen TB3 dock: pcieport 0000:06:01.0: pciehp: Slot(1): Link Down pcieport 0000:06:01.0: pciehp: Slot(1): Card not present ============================================ WARNING: possible recursive locking detected 5.16.0-rc2+ #621 Not tainted -------------------------------------------- irq/124-pciehp/86 is trying to acquire lock: ffff8e5ac4299ef8 (&ctrl->reset_lock){.+.+}-{3:3}, at: pciehp_check_presence+0x23/0x80 but task is already holding lock: ffff8e5ac4298af8 (&ctrl->reset_lock){.+.+}-{3:3}, at: pciehp_ist+0xf3/0x180 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&ctrl->reset_lock); lock(&ctrl->reset_lock); *** DEADLOCK *** May be due to missing lock nesting notation 3 locks held by irq/124-pciehp/86: #0: ffff8e5ac4298af8 (&ctrl->reset_lock){.+.+}-{3:3}, at: pciehp_ist+0xf3/0x180 #1: ffffffffa3b024e8 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pciehp_unconfigure_device+0x31/0x110 #2: ffff8e5ac1ee2248 (&dev->mutex){....}-{3:3}, at: device_release_driver+0x1c/0x40 stack backtrace: CPU: 4 PID: 86 Comm: irq/124-pciehp Not tainted 5.16.0-rc2+ #621 Hardware name: LENOVO 20U90SIT19/20U90SIT19, BIOS N2WET30W (1.20 ) 08/26/2021 Call Trace: <TASK> dump_stack_lvl+0x59/0x73 __lock_acquire.cold+0xc5/0x2c6 lock_acquire+0xb5/0x2b0 down_read+0x3e/0x50 pciehp_check_presence+0x23/0x80 pciehp_runtime_resume+0x5c/0xa0 device_for_each_child+0x45/0x70 pcie_port_device_runtime_resume+0x20/0x30 pci_pm_runtime_resume+0xa7/0xc0 __rpm_callback+0x41/0x110 rpm_callback+0x59/0x70 rpm_resume+0x512/0x7b0 __pm_runtime_resume+0x4a/0x90 __device_release_driver+0x28/0x240 device_release_driver+0x26/0x40 pci_stop_bus_device+0x68/0x90 pci_stop_bus_device+0x2c/0x90 pci_stop_and_remove_bus_device+0xe/0x20 pciehp_unconfigure_device+0x6c/0x110 pciehp_disable_slot+0x5b/0xe0 pciehp_handle_presence_or_link_change+0xc3/0x2f0 pciehp_ist+0x179/0x180 This lockdep warning is triggered because with Thunderbolt, hotplug ports are nested. When removing multiple devices in a daisy-chain, each hotplug port's reset_lock may be acquired recursively. It's never the same lock, so the lockdep splat is a false positive. Because locks at the same hierarchy level are never acquired recursively, a per-level lockdep class is sufficient to fix the lockdep warning. The choice to use one lockdep subclass per pcie-hotplug controller in the path to the root-bus was made to conserve class keys because their number is limited and the complexity grows quadratically with number of keys according to Documentation/locking/lockdep-design.rst. Link: https://lore.kernel.org/linux-pci/[email protected]/ Link: https://lore.kernel.org/linux-pci/[email protected]/ Link: https://lore.kernel.org/r/[email protected] Link: https://bugzilla.kernel.org/show_bug.cgi?id=208855 Reported-by: "Theodore Ts'o" <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Lukas Wunner <[email protected]> Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 0a04b6a0f7f41c0361242105cd77f9afab44f59b Author: Rob Herring <[email protected]> Date: Mon Nov 29 11:36:37 2021 -0600 PCI: xgene: Fix IB window setup commit c7a75d07827a1f33d566e18e6098379cc2a0c2b2 upstream. Commit 6dce5aa59e0b ("PCI: xgene: Use inbound resources for setup") broke PCI support on XGene. The cause is the IB resources are now sorted in address order instead of being in DT dma-ranges order. The result is which inbound registers are used for each region are swapped. I don't know the details about this h/w, but it appears that IB region 0 registers can't handle a size greater than 4GB. In any case, limiting the size for region 0 is enough to get back to the original assignment of dma-ranges to regions. Link: https://lore.kernel.org/all/CA+enf=v9rY_xnZML01oEgKLmvY1NGBUUhnSJaETmXtDtXfaczA@mail.gmail.com/ Link: https://lore.kernel.org/r/[email protected] Fixes: 6dce5aa59e0b ("PCI: xgene: Use inbound resources for setup") Reported-by: Stéphane Graber <[email protected]> Tested-by: Stéphane Graber <[email protected]> Signed-off-by: Rob Herring <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Krzysztof Wilczyński <[email protected]> Cc: [email protected] # v5.5+ Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 077fe9d865604fcab3238afeaa7408cc1635bc39 Author: José Roberto de Souza <[email protected]> Date: Thu Jan 13 08:04:37 2022 -0800 drm/i915/display/ehl: Update voltage swing table commit ef3ac01564067a4337bb798b8eddc6ea7b78fd10 upstream. EHL table was recently updated with some minor fixes. BSpec: 21257 Cc: [email protected] Cc: Clint Taylor <[email protected]> Signed-off-by: José Roberto de Souza <[email protected]> Reviewed-by: Clint Taylor <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 5ec7baef52c367cdbda964aa662f7135c25bab1f) Signed-off-by: Tvrtko Ursulin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit c3a9e0e701dfd087b0044c3598bffe880262c066 Author: Alex Deucher <[email protected]> Date: Wed Jan 12 22:38:51 2022 -0500 drm/amdgpu: don't do resets on APUs which don't support it commit e8309d50e97851ff135c4e33325d37b032666b94 upstream. It can cause a hang. This is normally not enabled for GPU hangs on these asics, but was recently enabled for handling aborted suspends. This causes hangs on some platforms on suspend. Fixes: daf8de0874ab5b ("drm/amdgpu: always reset the asic in suspend (v2)") Cc: [email protected] Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1858 Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 99d41076c26099899dedacd690f5d0f3f470565c Author: James Smart <[email protected]> Date: Fri Dec 3 16:26:38 2021 -0800 scsi: lpfc: Fix lpfc_force_rscn ndlp kref imbalance commit 7576d48c64f36f6fea9df2882f710a474fa35f40 upstream. Issuing lpfc_force_rscn twice results in an ndlp kref use-after-free call trace. A prior patch reworked the get/put handling by ensuring nlp_get was done before WQE submission and a put was done in the completion path. Unfortunately, the issue_els_rscn path had a piece of legacy code that did a nlp_put, causing an imbalance on the ref counts. Fixed by removing the unnecessary legacy code snippet. Link: https://lore.kernel.org/r/[email protected] Fixes: 4430f7fd09ec ("scsi: lpfc: Rework locations of ndlp reference taking") Cc: <[email protected]> # v5.11+ Co-developed-by: Justin Tee <[email protected]> Signed-off-by: Justin Tee <[email protected]> Signed-off-by: James Smart <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 56fc6cb5d59a90e926be994e2532df44f6c4349d Author: Nicholas Piggin <[email protected]> Date: Thu Dec 16 20:33:42 2021 +1000 powerpc/64s/radix: Fix huge vmap false positive commit 467ba14e1660b52a2f9338b484704c461bd23019 upstream. pmd_huge() is defined to false when HUGETLB_PAGE is not configured, but the vmap code still installs huge PMDs. This leads to false bad PMD errors when vunmapping because it is not seen as a huge PTE, and the bad PMD check catches it. The end result may not be much more serious than some bad pmd warning messages, because the pmd_none_or_clear_bad() does what we wanted and clears the huge PTE anyway. Fix this by checking pmd_is_leaf(), which checks for a PTE regardless of config options. The whole huge/large/leaf stuff is a tangled mess but that's kernel-wide and not something we can improve much in arch/powerpc code. pmd_page(), pud_page(), etc., called by vmalloc_to_page() on huge vmaps can similarly trigger a false VM_BUG_ON when CONFIG_HUGETLB_PAGE=n, so those checks are adjusted. The checks were added by commit d6eacedd1f0e ("powerpc/book3s: Use config independent helpers for page table walk"), while implementing a similar fix for other page table walking functions. Fixes: d909f9109c30 ("powerpc/64s/radix: Enable HAVE_ARCH_HUGE_VMAP") Cc: [email protected] # v5.3+ Signed-off-by: Nicholas Piggin <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 46df3013a5c2a34b02476fc6840bb6d63868207a Author: John David Anglin <[email protected]> Date: Wed Dec 22 16:01:31 2021 +0000 parisc: Fix lpa and lpa_user defines commit db19c6f1a2a353cc8dec35b4789733a3cf6e2838 upstream. While working on the rewrite to the light-weight syscall and futex code, I experimented with using a hash index based on the user physical address of atomic variable. This exposed two problems with the lpa and lpa_user defines. Because of the copy instruction, the pa argument needs to be an early clobber argument. This prevents gcc from allocating the va and pa arguments to the same register. Secondly, the lpa instruction can cause a page fault so we need to catch exceptions. Signed-off-by: John David Anglin <[email protected]> Fixes: 116d753308cf ("parisc: Use lpa instruction to load physical addresses in driver code") Signed-off-by: Helge Deller <[email protected]> Cc: [email protected] # v5.2+ Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 95df03b471d9061c94340241eb9507bf9493febd Author: Brian Norris <[email protected]> Date: Wed Nov 3 13:52:00 2021 -0700 drm/bridge: analogix_dp: Make PSR-exit block less commit c4c6ef229593366ab593d4d424addc7025b54a76 upstream. Prior to commit 6c836d965bad ("drm/rockchip: Use the helpers for PSR"), "PSR exit" used non-blocking analogix_dp_send_psr_spd(). The refactor started using the blocking variant, for a variety of reasons -- quoting Sean Paul's potentially-faulty memory: """ - To avoid racing a subsequent PSR entry (if exit takes a long time) - To avoid racing disable/modeset - We're not displaying new content while exiting PSR anyways, so there is minimal utility in allowing frames to be submitted - We're lying to userspace telling them frames are on the screen when we're just dropping them on the floor """ However, I'm finding that this blocking transition is causing upwards of 60+ ms of unneeded latency on PSR-exit, to the point that initial cursor movements when leaving PSR are unbearably jumpy. It turns out that we need to meet in the middle somewhere: Sean is right that we were "lying to userspace" with a non-blocking PSR-exit, but the new blocking behavior is also waiting too long: According to the eDP specification, the sink device must support PSR entry transitions from both state 4 (ACTIVE_RESYNC) and state 0 (INACTIVE). It also states that in ACTIVE_RESYNC, "the Sink device must display the incoming active frames from the Source device with no visible glitches and/or artifacts." Thus, for our purposes, we only need to wait for ACTIVE_RESYNC before moving on; we are ready to display video, and subsequent PSR-entry is safe. Tested on a Samsung Chromebook Plus (i.e., Rockchip RK3399 Gru Kevin), where this saves about 60ms of latency, for PSR-exit that used to take about 80ms. Fixes: 6c836d965bad ("drm/rockchip: Use the helpers for PSR") Cc: <[email protected]> Cc: Zain Wang <[email protected]> Cc: Tomasz Figa <[email protected]> Cc: Heiko Stuebner <[email protected]> Cc: Sean Paul <[email protected]> Signed-off-by: Brian Norris <[email protected]> Reviewed-by: Sean Paul <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20211103135112.v3.1.I67612ea073c3306c71b46a87be894f79707082df@changeid Signed-off-by: Greg Kroah-Hartman <[email protected]> commit d2a6d606e6d35e3f53cee13b406c5c7e6a5df86a Author: Ilia Mirkin <[email protected]> Date: Sun Mar 7 12:48:53 2021 -0500 drm/nouveau/kms/nv04: use vzalloc for nv04_display commit bd6e07e72f37f34535bec7eebc807e5fcfe37b43 upstream. The struct is giant, and triggers an order-7 allocation (512K). There is no reason for this to be kmalloc-type memory, so switch to vmalloc. This should help loading nouveau on low-memory and/or long-running systems. Reported-by: Nathan E. Egge <[email protected]> Signed-off-by: Ilia Mirkin <[email protected]> Cc: [email protected] Signed-off-by: Ben Skeggs <[email protected]> Reviewed-by: Karol Herbst <[email protected]> Signed-off-by: Karol Herbst <[email protected]> Link: https://gitlab.freedesktop.org/drm/nouveau/-/merge_requests/10 Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 3bf997ec299cdf7280b2039806e5e1d847df111a Author: Yizhuo Zhai <[email protected]> Date: Fri Dec 17 20:22:23 2021 -0800 drm/amd/display: Fix the uninitialized variable in enable_stream_features() commit 0726ed3065eeb910f9cea0c933bc021a848e00b3 upstream. In function enable_stream_features(), the variable "old_downspread.raw" could be uninitialized if core_link_read_dpcd() fails, however, it is used in the later if statement, and further, core_link_write_dpcd() may write random value, which is potentially unsafe. Fixes: 6016cd9dba0f ("drm/amd/display: add helper for enabling mst stream features") Cc: [email protected] Signed-off-by: Yizhuo Zhai <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 2de6ce5836513f0bfe61d0948d8eb25f1417e7bd Author: Lucas Stach <[email protected]> Date: Fri Dec 17 11:59:28 2021 +0100 drm/etnaviv: limit submit sizes commit 6dfa2fab8ddd46faa771a102672176bee7a065de upstream. Currently we allow rediculous amounts of kernel memory being allocated via the etnaviv GEM_SUBMIT ioctl, which is a pretty easy DoS vector. Put some reasonable limits in to fix this. The commandstream size is limited to 64KB, which was already a soft limit on older kernels after which the kernel only took submits on a best effort base, so there is no userspace that tries to submit commandstreams larger than this. Even if the whole commandstream is a single incrementing address load, the size limit also limits the number of potential relocs and referenced buffers to slightly under 64K, so use the same limit for those arguments. The performance monitoring infrastructure currently supports less than 50 performance counter signals, so limiting them to 128 on a single submit seems like a reasonably future-proof number for now. This number can be bumped if needed without breaking the interface. Cc: [email protected] Reported-by: Dan Carpenter <[email protected]> Signed-off-by: Lucas Stach <[email protected]> Reviewed-by: Christian Gmeiner <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit a04da77f444a3e1945966f403a3007a671ecff9d Author: Dmitry Osipenko <[email protected]> Date: Wed Dec 1 02:23:17 2021 +0300 drm/tegra: submit: Add missing pm_runtime_mark_last_busy() commit a21115dd38c6cf396ba39aefd561e7903ca6149d upstream. Runtime PM auto-suspension doesn't work without pm_runtime_mark_last_busy(), add it. Cc: <[email protected]> Reviewed-by: Ulf Hansson <[email protected]> Signed-off-by: Dmitry Osipenko <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit b8902d5ab431f9ac9a3a787e527bc2ec10e4d02a Author: Sakari Ailus <[email protected]> Date: Wed Dec 1 14:59:29 2021 +0200 device property: Fix fwnode_graph_devcon_match() fwnode leak commit 4a7f4110f79163fd53ea65438041994ed615e3af upstream. For each endpoint it encounters, fwnode_graph_devcon_match() checks whether the endpoint's remote port parent device is available. If it is not, it ignores the endpoint but does not put the reference to the remote endpoint port parent fwnode. For available devices the fwnode handle reference is put as expected. Put the reference for unavailable devices now. Fixes: 637e9e52b185 ("device connection: Find device connections also from device graphs") Cc: 5.1+ <[email protected]> # 5.1+ Signed-off-by: Sakari Ailus <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 9d28671017047af1ca14d00c946f02e0fd871ff4 Author: Alexander Gordeev <[email protected]> Date: Thu Nov 4 07:14:44 2021 +0100 s390/mm: fix 2KB pgtable release race commit c2c224932fd0ee6854d6ebfc8d059c2bcad86606 upstream. There is a race on concurrent 2KB-pgtables release paths when both upper and lower halves of the containing parent page are freed, one via page_table_free_rcu() + __tlb_remove_table(), and the other via page_table_free(). The race might lead to a corruption as result of remove of list item in page_table_free() concurrently with __free_page() in __tlb_remove_table(). Let's assume first the lower and next the upper 2KB-pgtables are freed from a page. Since both halves of the page are allocated the tracking byte (bits 24-31 of the page _refcount) has value of 0x03 initially: CPU0 CPU1 ---- ---- page_table_free_rcu() // lower half { // _refcount[31..24] == 0x03 ... atomic_xor_bits(&page->_refcount, 0x11U << (0 + 24)); // _refcount[31..24] <= 0x12 ... table = table | (1U << 0); tlb_remove_table(tlb, table); } ... __tlb_remove_table() { // _refcount[31..24] == 0x12 mask = _table & 3; // mask <= 0x01 ... page_table_free() // upper half { // _refcount[31..24] == 0x12 ... atomic_xor_bits( &page->_refcount, 1U << (1 + 24)); // _refcount[31..24] <= 0x10 // mask <= 0x10 ... atomic_xor_bits(&page->_refcount, mask << (4 + 24)); // _refcount[31..24] <= 0x00 // mask <= 0x00 ... if (mask != 0) // == false break; fallthrough; ... if (mask & 3) // == false ... else __free_page(page); list_del(&page->lru); ^^^^^^^^^^^^^^^^^^ RACE! ^^^^^^^^^^^^^^^^^^^^^ } ... } The problem is page_table_free() releases the page as result of lower nibble unset and __tlb_remove_table() observing zero too early. With this update page_table_free() will use the similar logic as page_table_free_rcu() + __tlb_remove_table(), and mark the fragment as pending for removal in the upper nibble until after the list_del(). In other words, the parent page is considered as unreferenced and safe to release only when the lower nibble is cleared already and unsetting a bit in upper nibble results in that nibble turned zero. Cc: [email protected] Suggested-by: Vlastimil Babka <[email protected]> Reviewed-by: Gerald Schaefer <[email protected]> Signed-off-by: Alexander Gordeev <[email protected]> Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit b5498bbba0d3072675d0391ebcc28e618944b105 Author: Ilan Peer <[email protected]> Date: Fri Dec 10 09:06:21 2021 +0200 iwlwifi: mvm: Increase the scan timeout guard to 30 seconds commit ced50f1133af12f7521bb777fcf4046ca908fb77 upstream. With the introduction of 6GHz channels the scan guard timeout should be adjusted to account for the following extreme case: - All 6GHz channels are scanned passively: 58 channels. - The scan is fragmented with the following parameters: 3 fragments, 95 TUs suspend time, 44 TUs maximal out of channel time. The above would result with scan time of more than 24 seconds. Thus, set the timeout to 30 seconds. Cc: [email protected] Signed-off-by: Ilan Peer <[email protected]> Signed-off-by: Luca Coelho <[email protected]> Link: https://lore.kernel.org/r/iwlwifi.20211210090244.3c851b93aef5.I346fa2e1d79220a6770496e773c6f87a2ad9e6c4@changeid Signed-off-by: Luca Coelho <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 9e87229ff6514db20f2e0a3902124029efc5f527 Author: Christophe JAILLET <[email protected]> Date: Sat Oct 16 08:44:28 2021 +0200 remoteproc: imx_rproc: Fix a resource leak in the remove function commit 4da96175014be67c846fd274eace08066e525d75 upstream. 'priv->workqueue' is destroyed in the error handling path of the probe but not in the remove function. Add the missing call to release some resources. Cc: stable <[email protected]> Fixes: 2df7062002d0 ("remoteproc: imx_proc: enable virtio/mailbox") Signed-off-by: Christophe JAILLET <[email protected]> Reviewed-by: Peng Fan <[email protected]> Tested-by: Peng Fan <[email protected]> Link: https://lore.kernel.org/r/d28ca94a4031bd7297d47c2164e18885a5a6ec19.1634366546.git.christophe.jaillet@wanadoo.fr Signed-off-by: Mathieu Poirier <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 74c0c6483b63c528b3da39bf689e30fb4f45ae5f Author: Steven Rostedt <[email protected]> Date: Fri Jan 7 17:56:56 2022 -0500 tracing: Have syscall trace events use trace_event_buffer_lock_reserve() commit 3e2a56e6f639492311e0a8533f0a7aed60816308 upstream. Currently, the syscall trace events call trace_buffer_lock_reserve() directly, which means that it misses out on some of the filtering optimizations provided by the helper function trace_event_buffer_lock_reserve(). Have the syscall trace events call that instead, as it was missed when adding the update to use the temp buffer when filtering. Link: https://lkml.kernel.org/r/[email protected] Cc: [email protected] Cc: Ingo Molnar <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Tom Zanussi <[email protected]> Reviewed-by: Masami Hiramatsu <[email protected]> Fixes: 0fc1b09ff1ff4 ("tracing: Use temp buffer when filtering events") Signed-off-by: Steven Rostedt <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 40022b3682d527908946f699df09849d366065bc Author: Xiangyang Zhang <[email protected]> Date: Fri Jan 7 23:02:42 2022 +0800 tracing/kprobes: 'nmissed' not showed correctly for kretprobe commit dfea08a2116fe327f79d8f4d4b2cf6e0c88be11f upstream. The 'nmissed' column of the 'kprobe_profile' file for kretprobe is not showed correctly, kretprobe can be skipped by two reasons, shortage of kretprobe_instance which is counted by tk->rp.nmissed, and kprobe itself is missed by some reason, so to show the sum. Link: https://lkml.kernel.org/r/[email protected] Cc: [email protected] Fixes: 4a846b443b4e ("tracing/kprobes: Cleanup kprobe tracer code") Acked-by: Masami Hiramatsu <[email protected]> Signed-off-by: Xiangyang Zhang <[email protected]> Signed-off-by: Steven Rostedt <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 95c7ba00353f89f81ad94037d69feee2546830c7 Author: Andrey Ryabinin <[email protected]> Date: Mon Nov 15 19:46:06 2021 +0300 sched/cpuacct: Fix user/system in shown cpuacct.usage* commit dd02d4234c9a2214a81c57a16484304a1a51872a upstream. cpuacct has 2 different ways of accounting and showing user and system times. The first one uses cpuacct_account_field() to account times and cpuacct.stat file to expose them. And this one seems to work ok. The second one is uses cpuacct_charge() function for accounting and set of cpuacct.usage* files to show times. Despite some attempts to fix it in the past it still doesn't work. Sometimes while running KVM guest the cpuacct_charge() accounts most of the guest time as system time. This doesn't match with user&system times shown in cpuacct.stat or proc/<pid>/stat. Demonstration: # git clone https://github.com/aryabinin/kvmsample # make # mkdir /sys/fs/cgroup/cpuacct/test # echo $$ > /sys/fs/cgroup/cpuacct/test/tasks # ./kvmsample & # for i in {1..5}; do cat /sys/fs/cgroup/cpuacct/test/cpuacct.usage_sys; sleep 1; done 1976535645 2979839428 3979832704 4983603153 5983604157 Use cpustats accounted in cpuacct_account_field() as the source of user/sys times for cpuacct.usage* files. Make cpuacct_charge() to account only summary execution time. Fixes: d740037fac70 ("sched/cpuacct: Split usage accounting into user_usage and sys_usage") Signed-off-by: Andrey Ryabinin <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Daniel Jordan <[email protected]> Acked-by: Tejun Heo <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit b48450843f57f0ed982d6330dac47c95642a4bfc Author: Andrey Ryabinin <[email protected]> Date: Mon Nov 15 19:46:04 2021 +0300 cputime, cpuacct: Include guest time in user time in cpuacct.stat commit 9731698ecb9c851f353ce2496292ff9fcea39dff upstream. cpuacct.stat in no-root cgroups shows user time without guest time included int it. This doesn't match with user time shown in root cpuacct.stat and /proc/<pid>/stat. This also affects cgroup2's cpu.stat in the same way. Make account_guest_time() to add user time to cgroup's cpustat to fix this. Fixes: ef12fefabf94 ("cpuacct: add per-cgroup utime/stime statistics") Signed-off-by: Andrey Ryabinin <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Daniel Jordan <[email protected]> Acked-by: Tejun Heo <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 6f52d2531f30e838b1c70ccf6b535b220bb98908 Author: Lukas Wunner <[email protected]> Date: Sat Dec 18 10:58:56 2021 +0100 serial: Fix incorrect rs485 polarity on uart open commit d3b3404df318504ec084213ab1065b73f49b0f1d upstream. Commit a6845e1e1b78 ("serial: core: Consider rs485 settings to drive RTS") sought to deassert RTS when opening an rs485-enabled uart port. That way, the transceiver does not occupy the bus until it transmits data. Unfortunately, the commit mixed up the logic and *asserted* RTS instead of *deasserting* it: The commit amended uart_port_dtr_rts(), which raises DTR and RTS when opening an rs232 port. "Raising" actually means lowering the signal that's coming out of the uart, because an rs232 transceiver not only changes a signal's voltage level, it also *inverts* the signal. See the simplified schematic in the MAX232 datasheet for an example: https://www.ti.com/lit/ds/symlink/max232.pdf So, to raise RTS on an rs232 port, TIOCM_RTS is *set* in port->mctrl and that results in the signal being driven low. In contrast to rs232, the signal level for rs485 Transmit Enable is the identity, not the inversion: If the transceiver expects a "high" RTS signal for Transmit Enable, the signal coming out of the uart must also be high, so TIOCM_RTS must be *cleared* in port->mctrl. The commit did the exact opposite, but it's easy to see why given the confusing semantics of rs232 and rs485. Fix it. Fixes: a6845e1e1b78 ("serial: core: Consider rs485 settings to drive RTS") Cc: [email protected] # v4.14+ Cc: Rafael Gago Castano <[email protected]> Cc: Jan Kiszka <[email protected]> Cc: Su Bao Cheng <[email protected]> Signed-off-by: Lukas Wunner <[email protected]> Link: https://lore.kernel.org/r/9395767847833f2f3193c49cde38501eeb3b5669.1639821059.git.lukas@wunner.de Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 3ec632bc0a4aa8c8c909c57ec1785ed02d880c60 Author: Xie Yongji <[email protected]> Date: Mon Nov 22 17:05:31 2021 +0800 fuse: Pass correct lend value to filemap_write_and_wait_range() commit e388164ea385f04666c4633f5dc4f951fca71890 upstream. The acceptable maximum value of lend parameter in filemap_write_and_wait_range() is LLONG_MAX rather than -1. And there is also some logic depending on LLONG_MAX check in write_cache_pages(). So let's pass LLONG_MAX to filemap_write_and_wait_range() in fuse_writeback_range() instead. Fixes: 59bda8ecee2f ("fuse: flush extending writes") Signed-off-by: Xie Yongji <[email protected]> Cc: <[email protected]> # v5.15 Signed-off-by: Miklos Szeredi <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 2884aac078745798419f74cfc13025558e718541 Author: Christophe JAILLET <[email protected]> Date: Tue Dec 28 22:09:17 2021 +0100 HID: magicmouse: Fix an error handling path in magicmouse_probe() commit 33812fc7c8d77a43b7e2bf36a0d5a57c277a4b0c upstream. If the timer introduced by the commit below is started, then it must be deleted in the error handling of the probe. Otherwise it would trigger once the driver is no more. Fixes: 0b91b4e4dae6 ("HID: magicmouse: Report battery level over USB") Signed-off-by: Christophe JAILLET <[email protected]> Tested-by: José Expósito <[email protected]> Reported-by: <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 00e3d58f50a875343124bcf5a9637520a492b0d1 Author: Xiao Ni <[email protected]> Date: Fri Dec 10 17:31:15 2021 +0800 md: Move alloc/free acct bioset in to personality commit 0c031fd37f69deb0cd8c43bbfcfccd62ebd7e952 upstream. bioset acct is only needed for raid0 and raid5. Therefore, md_run only allocates it for raid0 and raid5. However, this does not cover personality takeover, which may cause uninitialized bioset. For example, the following repro steps: mdadm -CR /dev/md0 -l1 -n2 /dev/loop0 /dev/loop1 mdadm --wait /dev/md0 mkfs.xfs /dev/md0 mdadm /dev/md0 --grow -l5 mount /dev/md0 /mnt causes panic like: [ 225.933939] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 225.934903] #PF: supervisor instruction fetch in kernel mode [ 225.935639] #PF: error_code(0x0010) - not-present page [ 225.936361] PGD 0 P4D 0 [ 225.936677] Oops: 0010 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN PTI [ 225.937525] CPU: 27 PID: 1133 Comm: mount Not tainted 5.16.0-rc3+ #706 [ 225.938416] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-2.module_el8.4.0+547+a85d02ba 04/01/2014 [ 225.939922] RIP: 0010:0x0 [ 225.940289] Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6. [ 225.941196] RSP: 0018:ffff88815897eff0 EFLAGS: 00010246 [ 225.941897] RAX: 0000000000000000 RBX: 0000000000092800 RCX: ffffffff81370a39 [ 225.942813] RDX: dffffc0000000000 RSI: 0000000000000000 RDI: 0000000000092800 [ 225.943772] RBP: 1ffff1102b12fe04 R08: fffffbfff0b43c01 R09: fffffbfff0b43c01 [ 225.944807] R10: ffffffff85a1e007 R11: fffffbfff0b43c00 R12: ffff88810eaaaf58 [ 225.945757] R13: 0000000000000000 R14: ffff88810eaaafb8 R15: ffff88815897f040 [ 225.946709] FS: 00007ff3f2505080(0000) GS:ffff888fb5e00000(0000) knlGS:0000000000000000 [ 225.947814] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 225.948556] CR2: ffffffffffffffd6 CR3: 000000015aa5a006 CR4: 0000000000370ee0 [ 225.949537] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 225.950455] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 225.951414] Call Trace: [ 225.951787] <TASK> [ 225.952120] mempool_alloc+0xe5/0x250 [ 225.952625] ? mempool_resize+0x370/0x370 [ 225.953187] ? rcu_read_lock_sched_held+0xa1/0xd0 [ 225.953862] ? rcu_read_lock_bh_held+0xb0/0xb0 [ 225.954464] ? sched_clock_cpu+0x15/0x120 [ 225.955019] ? find_held_lock+0xac/0xd0 [ 225.955564] bio_alloc_bioset+0x1ed/0x2a0 [ 225.956080] ? lock_downgrade+0x3a0/0x3a0 [ 225.956644] ? bvec_alloc+0xc0/0xc0 [ 225.957135] bio_clone_fast+0x19/0x80 [ 225.957651] raid5_make_request+0x1370/0x1b70 [ 225.958286] ? sched_clock_cpu+0x15/0x120 [ 225.958797] ? __lock_acquire+0x8b2/0x3510 [ 225.959339] ? raid5_get_active_stripe+0xce0/0xce0 [ 225.959986] ? lock_is_held_type+0xd8/0x130 [ 225.960528] ? rcu_read_lock_sched_held+0xa1/0xd0 [ 225.961135] ? rcu_read_lock_bh_held+0xb0/0xb0 [ 225.961703] ? sched_clock_cpu+0x15/0x120 [ 225.962232] ? lock_release+0x27a/0x6c0 [ 225.962746] ? do_wait_intr_irq+0x130/0x130 [ 225.963302] ? lock_downgrade+0x3a0/0x3a0 [ 225.963815] ? lock_release+0x6c0/0x6c0 [ 225.964348] md_handle_request+0x342/0x530 [ 225.964888] ? set_in_sync+0x170/0x170 [ 225.965397] ? blk_queue_split+0x133/0x150 [ 225.965988] ? __blk_queue_split+0x8b0/0x8b0 [ 225.966524] ? submit_bio_checks+0x3b2/0x9d0 [ 225.967069] md_submit_bio+0x127/0x1c0 [...] Fix this by moving alloc/free of acct bioset to pers->run and pers->free. While we are on this, properly handle md_integrity_register() error in raid0_run(). Fixes: daee2024715d (md: check level before create and exit io_acct_set) Cc: [email protected] Acked-by: Guoqing Jiang <[email protected]> Signed-off-by: Xiao Ni <[email protected]> Signed-off-by: Song Liu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit c77edcd242b44970fdd3c1dd219617565261fb04 Author: Oleksandr Andrushchenko <[email protected]> Date: Fri Dec 10 11:28:17 2021 +0200 xen/gntdev: fix unmap notification order commit ce2f46f3531a03781181b7f4bd1ff9f8c5086e7e upstream. While working with Xen's libxenvchan library I have faced an issue with unmap notifications sent in wrong order if both UNMAP_NOTIFY_SEND_EVENT and UNMAP_NOTIFY_CLEAR_BYTE were requested: first we send an event channel notification and then clear the notification byte which renders in the below inconsistency (cli_live is the byte which was requested to be cleared on unmap): [ 444.514243] gntdev_put_map UNMAP_NOTIFY_SEND_EVENT map->notify.event 6 libxenvchan_is_open cli_live 1 [ 444.515239] __unmap_grant_pages UNMAP_NOTIFY_CLEAR_BYTE at 14 Thus it is not possible to reliably implement the checks like - wait for the notification (UNMAP_NOTIFY_SEND_EVENT) - check the variable (UNMAP_NOTIFY_CLEAR_BYTE) because it is possible that the variable gets checked before it is cleared by the kernel. To fix that we need to re-order the notifications, so the variable is first gets cleared and then the event channel notification is sent. With this fix I can see the correct order of execution: [ 54.522611] __unmap_grant_pages UNMAP_NOTIFY_CLEAR_BYTE at 14 [ 54.537966] gntdev_put_map UNMAP_NOTIFY_SEND_EVENT map->notify.event 6 libxenvchan_is_open cli_live 0 Cc: [email protected] Signed-off-by: Oleksandr Andrushchenko <[email protected]> Reviewed-by: Boris Ostrovsky <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Juergen Gross <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 0d9b780cb385cc4f7d2f86a575656837030dc9a9 Author: Kunihiko Hayashi <[email protected]> Date: Wed Dec 22 13:48:12 2021 +0900 spi: uniphier: Fix a bug that doesn't point to private data correctly commit 80bb73a9fbcde4ecc55e12f10c73fabbe68a24d1 upstream. In uniphier_spi_remove(), there is a wrong code to get private data from the platform device, so the driver can't be removed properly. The driver should get spi_master from the platform device and retrieve the private data from it. Cc: <[email protected]> Fixes: 5ba155a4d4cc ("spi: add SPI controller driver for UniPhier SoC") Signed-off-by: Kunihiko Hayashi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit e53802534cd25fc1dd6a5391aa9f686f6c73dc2a Author: Dmitry Osipenko <[email protected]> Date: Wed Nov 24 22:01:04 2021 +0300 mfd: tps65910: Set PWR_OFF bit during driver probe commit 7620ad0bdfac1efff4a1228cd36ae62a9d8206b0 upstream. The PWR_OFF bit needs to be set in order to power off properly, without hanging PMIC. This bit needs to be set early in order to allow thermal protection of NVIDIA Terga SoCs to power off hardware properly, otherwise a battery re-plug may be needed on some devices to recover after the hang. Cc: <[email protected]> Signed-off-by: Dmitry Osipenko <[email protected]> Tested-by: Svyatoslav Ryhel <[email protected]> # ASUS TF201 Signed-off-by: Lee Jones <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit e6b11d8fc5481867126cb1ec8d64014e2a56a257 Author: Patrick Williams <[email protected]> Date: Thu Dec 23 09:49:31 2021 -0600 tpm: fix NPE on probe for missing device commit 84cc69589700b90a4c8d27b481a51fce8cca6051 upstream. When using the tpm_tis-spi driver on a system missing the physical TPM, a null pointer exception was observed. [ 0.938677] Unable to handle kernel NULL pointer dereference at virtual address 00000004 [ 0.939020] pgd = 10c753cb [ 0.939237] [00000004] *pgd=00000000 [ 0.939808] Internal error: Oops: 5 [#1] SMP ARM [ 0.940157] CPU: 0 PID: 48 Comm: kworker/u4:1 Not tainted 5.15.10-dd1e40c #1 [ 0.940364] Hardware name: Generic DT based system [ 0.940601] Workqueue: events_unbound async_run_entry_fn [ 0.941048] PC is at tpm_tis_remove+0x28/0xb4 [ 0.941196] LR is at tpm_tis_core_init+0x170/0x6ac This is due to an attempt in 'tpm_tis_remove' to use the drvdata, which was not initialized in 'tpm_tis_core_init' prior to the first error. Move the initialization of drvdata earlier so 'tpm_tis_remove' has access to it. Signed-off-by: Patrick Williams <[email protected]> Fixes: 79ca6f74dae0 ("tpm: fix Atmel TPM crash caused by too frequent queries") Cc: [email protected] Reviewed-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit c90732a58cd1d678487fc62483e98f6f9de2a56c Author: Lino Sanfilippo <[email protected]> Date: Mon Dec 20 16:06:35 2021 +0100 tpm: fix potential NULL pointer access in tpm_del_char_device commit eabad7ba2c752392ae50f24a795093fb115b686d upstream. Some SPI controller drivers unregister the controller in the shutdown handler (e.g. BCM2835). If such a controller is used with a TPM 2 slave chip->ops may be accessed when it is already NULL: At system shutdown the pre-shutdown handler tpm_class_shutdown() shuts down TPM 2 and sets chip->ops to NULL. Then at SPI controller unregistration tpm_tis_spi_remove() is called and eventually calls tpm_del_char_device() which tries to shut down TPM 2 again. Thereby it accesses chip->ops again: (tpm_del_char_device calls tpm_chip_start which calls tpm_clk_enable which calls chip->ops->clk_enable). Avoid the NULL pointer access by testing if chip->ops is valid and skipping the TPM 2 shutdown procedure in case it is NULL. Cc: [email protected] Signed-off-by: Lino Sanfilippo <[email protected]> Fixes: 39d0099f9439 ("powerpc/pseries: Add shutdown() to vio_driver and vio_bus") Reviewed-by: Stefan Berger <[email protected]> Tested-by: Stefan Berger <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 277c60c9e9ebd4e9ad05ef0855be4f876deb1a97 Author: Petr Cvachoucek <[email protected]> Date: Mon Aug 30 21:20:37 2021 +0200 ubifs: Error path in ubifs_remount_rw() seems to wrongly free write buffers commit 3fea4d9d160186617ff40490ae01f4f4f36b28ff upstream. it seems freeing the write buffers in the error path of the ubifs_remount_rw() is wrong. It leads later to a kernel oops like this: [10016.431274] UBIFS (ubi0:0): start fixing up free space [10090.810042] UBIFS (ubi0:0): free space fixup complete [10090.814623] UBIFS error (ubi0:0 pid 512): ubifs_remount_fs: cannot spawn "ubifs_bgt0_0", error -4 [10101.915108] UBIFS (ubi0:0): background thread "ubifs_bgt0_0" started, PID 517 [10105.275498] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000030 [10105.284352] Mem abort info: [10105.287160] ESR = 0x96000006 [10105.290252] EC = 0x25: DABT (current EL), IL = 32 bits [10105.295592] SET = 0, FnV = 0 [10105.298652] EA = 0, S1PTW = 0 [10105.301848] Data abort info: [10105.304723] ISV = 0, ISS = 0x00000006 [10105.308573] CM = 0, WnR = 0 [10105.311564] user pgtable: 4k pages, 48-bit VAs, pgdp=00000000f03d1000 [10105.318034] [0000000000000030] pgd=00000000f6cee003, pud=00000000f4884003, pmd=0000000000000000 [10105.326783] Internal error: Oops: 96000006 [#1] PREEMPT SMP [10105.332355] Modules linked in: ath10k_pci ath10k_core ath mac80211 libarc4 cfg80211 nvme nvme_core cryptodev(O) [10105.342468] CPU: 3 PID: 518 Comm: touch Tainted: G O 5.4.3 #1 [10105.349517] Hardware name: HYPEX CPU (DT) [10105.353525] pstate: 40000005 (nZcv daif -PAN -UAO) [10105.358324] pc : atomic64_try_cmpxchg_acquire.constprop.22+0x8/0x34 [10105.364596] lr : mutex_lock+0x1c/0x34 [10105.368253] sp : ffff000075633aa0 [10105.371563] x29: ffff000075633aa0 x28: 0000000000000001 [10105.376874] x27: ffff000076fa80c8 x26: 0000000000000004 [10105.382185] x25: 0000000000000030 x24: 0000000000000000 [10105.387495] x23: 0000000000000000 x22: 0000000000000038 [10105.392807] x21: 000000000000000c x20: ffff000076fa80c8 [10105.398119] x19: ffff000076fa8000 x18: 0000000000000000 [10105.403429] x17: 0000000000000000 x16: 0000000000000000 [10105.408741] x15: 0000000000000000 x14: fefefefefefefeff [10105.414052] x13: 0000000000000000 x12: 0000000000000fe0 [10105.419364] x11: 0000000000000fe0 x10: ffff000076709020 [10105.424675] x9 : 0000000000000000 x8 : 00000000000000a0 [10105.429986] x7 : ffff000076fa80f4 x6 : 0000000000000030 [10105.435297] x5 : 0000000000000000 x4 : 0000000000000000 [10105.440609] x3 : 0000000000000000 x2 : ffff00006f276040 [10105.445920] x1 : ffff000075633ab8 x0 : 0000000000000030 [10105.451232] Call trace: [10105.453676] atomic64_try_cmpxchg_acquire.constprop.22+0x8/0x34 [10105.459600] ubifs_garbage_collect+0xb4/0x334 [10105.463956] ubifs_budget_space+0x398/0x458 [10105.468139] ubifs_create+0x50/0x180 [10105.471712] path_openat+0x6a0/0x9b0 [10105.475284] do_filp_open+0x34/0x7c [10105.478771] do_sys_open+0x78/0xe4 [10105.482170] __arm64_sys_openat+0x1c/0x24 [10105.486180] el0_svc_handler+0x84/0xc8 [10105.489928] el0_svc+0x8/0xc [10105.492808] Code: 52800013 17fffffb d2800003 f9800011 (c85ffc05) [10105.498903] ---[ end trace 46b721d93267a586 ]--- To reproduce the problem: 1. Filesystem initially mounted read-only, free space fixup flag set. 2. mount -o remount,rw <mountpoint> 3. it takes some time (free space fixup running) ... try to terminate running mount by CTRL-C ... does not respond, only after free space fixup is complete ... then "ubifs_remount_fs: cannot spawn "ubifs_bgt0_0", error -4" 4. mount -o remount,rw <mountpoint> ... now finished instantly (fixup already done). 5. Create file or just unmount the filesystem and we get the oops. Cc: <[email protected]> Fixes: b50b9f408502 ("UBIFS: do not free write-buffers when in R/O mode") Signed-off-by: Petr Cvachoucek <[email protected]> Signed-off-by: Richard Weinberger <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit d6b6324c3c173a1bc33a5534a650dc3b4a8e58f0 Author: Meng Li <[email protected]> Date: Mon Nov 1 11:13:53 2021 +0800 crypto: caam - replace this_cpu_ptr with raw_cpu_ptr commit efd21e10fc3bf4c6da122470a5ae89ec4ed8d180 upstream. When enable the kernel debug config, there is below calltrace detected: BUG: using smp_processor_id() in preemptible [00000000] code: cryptomgr_test/339 caller is debug_smp_processor_id+0x20/0x30 CPU: 9 PID: 339 Comm: cryptomgr_test Not tainted 5.10.63-yocto-standard #1 Hardware name: NXP Layerscape LX2160ARDB (DT) Call trace: dump_backtrace+0x0/0x1a0 show_stack+0x24/0x30 dump_stack+0xf0/0x13c check_preemption_disabled+0x100/0x110 debug_smp_processor_id+0x20/0x30 dpaa2_caam_enqueue+0x10c/0x25c ...... cryptomgr_test+0x38/0x60 kthread+0x158/0x164 ret_from_fork+0x10/0x38 According to the comment in commit ac5d15b4519f("crypto: caam/qi2 - use affine DPIOs "), because preemption is no longer disabled while trying to enqueue an FQID, it might be possible to run the enqueue on a different CPU(due to migration, when in process context), however this wouldn't be a functionality issue. But there will be above calltrace when enable kernel debug config. So, replace this_cpu_ptr with raw_cpu_ptr to avoid above call trace. Fixes: ac5d15b4519f ("crypto: caam/qi2 - use affine DPIOs") Cc: [email protected] Signed-off-by: Meng Li <[email protected]> Reviewed-by: Horia Geantă <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 5c91102702f7f3cb8eb127f04d3c91c666818d2c Author: Marek Vasut <[email protected]> Date: Mon Dec 20 20:50:22 2021 +0100 crypto: stm32/crc32 - Fix kernel BUG triggered in probe() commit 29009604ad4e3ef784fd9b9fef6f23610ddf633d upstream. The include/linux/crypto.h struct crypto_alg field cra_driver_name description states "Unique name of the transformation provider. " ... " this contains the name of the chip or provider and the name of the transformation algorithm." In case of the stm32-crc driver, field cra_driver_name is identical for all registered transformation providers and set to the name of the driver itself, which is incorrect. This patch fixes it by assigning a unique cra_driver_name to each registered transformation provider. The kernel crash is triggered when the driver calls crypto_register_shashes() which calls crypto_register_shash(), which calls crypto_register_alg(), which calls __crypto_register_alg(), which returns -EEXIST, which is propagated back through this call chain. Upon -EEXIST from crypto_register_shash(), the crypto_register_shashes() starts unregistering the providers back, and calls crypto_unregister_shash(), which calls crypto_unregister_alg(), and this is where the BUG() triggers due to incorrect cra_refcnt. Fixes: b51dbe90912a ("crypto: stm32 - Support for STM32 CRC32 crypto module") Signed-off-by: Marek Vasut <[email protected]> Cc: <[email protected]> # 4.12+ Cc: Alexandre Torgue <[email protected]> Cc: Fabien Dessenne <[email protected]> Cc: Herbert Xu <[email protected]> Cc: Lionel Debieve <[email protected]> Cc: Nicolas Toromanoff <[email protected]> Cc: [email protected] Cc: [email protected] To: [email protected] Acked-by: Nicolas Toromanoff <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 7f429ce71edb7a32264520d59ee0930f000c9c9c Author: Heiner Kallweit <[email protected]> Date: Fri Dec 17 10:03:30 2021 +0100 crypto: omap-aes - Fix broken pm_runtime_and_get() usage commit c2aec59be093bd44627bc4f6bc67e4614a93a7b6 upstream. This fix is basically the same as 3d6b661330a7 ("crypto: stm32 - Revert broken pm_runtime_resume_and_get changes"), just for the omap driver. If the return value isn't used, then pm_runtime_get_sync() has to be used for ensuring that the usage count is balanced. Fixes: 1f34cc4a8da3 ("crypto: omap-aes - Fix PM reference leak on omap-aes.c") Cc: [email protected] Signed-off-by: Heiner Kallweit <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 8b6d58859e8fb26a718aba4417a2611a02e4e628 Author: Zhu Lingshan <[email protected]> Date: Wed Dec 1 16:12:55 2021 +0800 ifcvf/vDPA: fix misuse virtio-net device config size for blk dev commit 0f420c383a2bb414ebccedf9289b5b815f1295fe upstream. This commit fixes a misuse of virtio-net device config size issue for virtio-block devices. A new member config_size in struct ifcvf_hw is introduced and would be initialized through vdpa_dev_add() to record correct device config size. To be more generic, rename ifcvf_hw.net_config to ifcvf_hw.dev_config, the helpers ifcvf_read/write_net_config() to ifcvf_read/write_dev_config() Signed-off-by: Zhu Lingshan <[email protected]> Reported-and-suggested-by: Stefano Garzarella <[email protected]> Reviewed-by: Stefano Garzarella <[email protected]> Fixes: 6ad31d162a4e ("vDPA/ifcvf: enable Intel C5000X-PL virtio-block for vDPA") Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Michael S. Tsirkin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit e2b53845a9395d596cbbb31c773cabe9d74fe55e Author: Arnaud Pouliquen <[email protected]> Date: Mon Dec 6 20:07:58 2021 +0100 rpmsg: core: Clean up resources on announce_create failure. commit 8066c615cb69b7da8a94f59379847b037b3a5e46 upstream. During the rpmsg_dev_probe, if rpdev->ops->announce_create returns an error, the rpmsg device and default endpoint should be freed before exiting the function. Fixes: 5e619b48677c ("rpmsg: Split rpmsg core and virtio backend") Suggested-by: Bjorn Andersson <[email protected]> Signed-off-by: Arnaud Pouliquen <[email protected]> Reviewed-by: Bjorn Andersson <[email protected]> Cc: stable <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mathieu Poirier <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 591a1e2ef0f11cb37fb8ebb6479885229425e784 Author: Andrew Lunn <[email protected]> Date: Mon Jan 3 18:11:32 2022 +0100 udp6: Use Segment Routing Header for dest address if present [ Upstream commit 222a011efc839ca1f51bf89fe7a2b3705fa55ccd ] When finding the socket to report an error on, if the invoking packet is using Segment Routing, the IPv6 destination address is that of an intermediate router, not the end destination. Extract the ultimate destination address from the segment address. This change allows traceroute to function in the presence of Segment Routing. Signed-off-by: Andrew Lunn <[email protected]> Reviewed-by: David Ahern <[email protected]> Reviewed-by: Willem de Bruijn <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit af58dbc08ea3e736a47394da75d9c849a18e606c Author: Andrew Lunn <[email protected]> Date: Mon Jan 3 18:11:31 2022 +0100 icmp: ICMPV6: Examine invoking packet for Segment Route Headers. [ Upstream commit e41294408c56c68ea0f269d757527bf33b39118a ] RFC8754 says: ICMP error packets generated within the SR domain are sent to source nodes within the SR domain. The invoking packet in the ICMP error message may contain an SRH. Since the destination address of a packet with an SRH changes as each segment is processed, it may not be the destination used by the socket or application that generated the invoking packet. For the source of an invoking packet to process the ICMP error message, the ultimate destination address of the IPv6 header may be required. The following logic is used to determine the destination address for use by protocol-error handlers. * Walk all extension headers of the invoking IPv6 packet to the routing extension header preceding the upper-layer header. - If routing header is type 4 Segment Routing Header (SRH) o The SID at Segment List[0] may be used as the destination address of the invoking packet. Mangle the skb so the network header points to the invoking packet inside the ICMP packet. The seg6 helpers can then be used on the skb to find any segment routing headers. If found, mark this fact in the IPv6 control block of the skb, and store the offset into the packet of the SRH. Then restore the skb back to its old state. Signed-off-by: Andrew Lunn <[email protected]> Reviewed-by: David Ahern <[email protected]> Reviewed-by: Willem de Bruijn <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 85b3b307471ef1f9fa093ada115a67373952b6ac Author: Andrew Lunn <[email protected]> Date: Mon Jan 3 18:11:30 2022 +0100 seg6: export get_srh() for ICMP handling [ Upstream commit fa55a7d745de2d10489295b0674a403e2a5d490d ] An ICMP error message can contain in its message body part of an IPv6 packet which invoked the error. Such a packet might contain a segment router header. Export get_srh() so the ICMP code can make use of it. Since his changes the scope of the function from local to global, add the seg6_ prefix to keep the namespace clean. And move it into seg6.c so it is always available, not just when IPV6_SEG6_LWTUNNEL is enabled. Signed-off-by: Andrew Lunn <[email protected]> Reviewed-by: David Ahern <[email protected]> Reviewed-by: Willem de Bruijn <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit bcb86df40f96b90fbbd5c96cfbcc744ee4a362d1 Author: Conor Dooley <[email protected]> Date: Fri Dec 17 09:33:12 2021 +0000 mailbox: change mailbox-mpfs compatible string [ Upstream commit f10b1fc0161cd99e54c5687fcc63368aa255e05e ] The Polarfire SoC is currently using two different compatible string prefixes. Fix this by changing "polarfire-soc-*" strings to "mpfs-*" in its system controller in order to match the compatible string used in the soc binding and device tree. Signed-off-by: Conor Dooley <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Jassi Brar <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit d543ba3a61d7788b3c6ba5684364aa5dc89619da Author: Miaoqian Lin <[email protected]> Date: Fri Dec 24 08:21:03 2021 +0000 phy: mediatek: Fix missing check in mtk_mipi_tx_probe [ Upstream commit 399c91c3f30531593e5ff6ca7b53f47092128669 ] The of_device_get_match_data() function may return NULL. Add check to prevent potential null dereference. Signed-off-by: Miaoqian Lin <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 5895474d218265645a24ecaf4afe6413c39bdb82 Author: Ohad Sharabi <[email protected]> Date: Mon Nov 22 12:23:51 2021 +0200 habanalabs: skip read fw errors if dynamic descriptor invalid [ Upstream commit 4fac990f604e6c10538026835a8a30f3c1b6fcf5 ] Reporting FW errors involves reading of the error registers. In case we have a corrupted FW descriptor we cannot do that since the dynamic scratchpad is potentially corrupted as well and may cause kernel crush when attempting access to a corrupted register offset. Signed-off-by: Ohad Sharabi <[email protected]> Reviewed-by: Oded Gabbay <[email protected]> Signed-off-by: Oded Gabbay <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 8f23743e1978162c0925dc718e42fe56d3518614 Author: Tzung-Bi Shih <[email protected]> Date: Fri Dec 24 14:47:17 2021 +0800 ASoC: mediatek: mt8183: fix device_node leak [ Upstream commit cb006006fe6221f092fadaffd3f219288304c9ad ] Fixes the device_node leak. Signed-off-by: Tzung-Bi Shih <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 61274c00d8e8eab6d5bbf7b19f70a44561858e06 Author: Tzung-Bi Shih <[email protected]> Date: Fri Dec 24 14:47:16 2021 +0800 ASoC: mediatek: mt8173: fix device_node leak [ Upstream commit 493433785df0075afc0c106ab65f10a605d0b35d ] Fixes the device_node leak. Signed-off-by: Tzung-Bi Shih <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit ab23ed0a7c8cc2f8175c5818fc37d656130e9c55 Author: Chunfeng Yun <[email protected]> Date: Sat Dec 18 16:27:59 2021 +0800 phy: phy-mtk-tphy: add support efuse setting [ Upstream commit 6f2b033cb883f64ad084a75f13634242c7e179a6 ] Due to some SoCs have a bit shift issue that will drop a bit for usb3 phy or pcie phy, fix it by adding software efuse reading and setting, but only support it optionally for version 2/3. Signed-off-by: Chunfeng Yun <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 286c6f7b28fab19d649c2e1f3bc18fdecdbadfe5 Author: Tzung-Bi Shih <[email protected]> Date: Tue Dec 14 12:00:28 2021 +0800 ASoC: mediatek: mt8192-mt6359: fix device_node leak [ Upstream commit 4e28491a7a198c668437f2be8a91a76aa52f20eb ] The of_parse_phandle() document: >>> Use of_node_put() on it when done. The driver didn't call of_node_put(). Fixes the leak. Signed-off-by: Tzung-Bi Shih <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 5b03322abb61591f9a8a10ff07340f2d9670b813 Author: Sreekanth Reddy <[email protected]> Date: Mon Dec 20 19:41:58 2021 +0530 scsi: mpi3mr: Fixes around reply request queues [ Upstream commit 243bcc8efdb1f44b1a1d415e6821a246714c68ce ] Set reply queue depth of 1K for B0 and 4K for A0. While freeing the segmented request queues use the actual queue depth that is used while creating them. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sreekanth Reddy <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit f325446b5a18da23790bd86f83853a3542d5146e Author: Christoph Hellwig <[email protected]> Date: Wed Dec 22 10:08:42 2021 +0100 scsi: sr: Don't use GFP_DMA [ Upstream commit d94d94969a4ba07a43d62429c60372320519c391 ] The allocated buffers are used as a command payload, for which the block layer and/or DMA API do the proper bounce buffering if needed. Link: https://lore.kernel.org/r/[email protected] Reported-by: Baoquan He <[email protected]> Reviewed-by: Baoquan He <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 6af33b200b7fa4e53431a96a6b405873f6426ae2 Author: Tianjia Zhang <[email protected]> Date: Thu Dec 16 17:50:14 2021 +0800 MIPS: Octeon: Fix build errors using clang [ Upstream commit 95339b70677dc6f9a2d669c4716058e71b8dc1c7 ] A large number of the following errors is reported when compiling with clang: cvmx-bootinfo.h:326:3: error: adding 'int' to a string does not append to the string [-Werror,-Wstring-plus-int] ENUM_BRD_TYPE_CASE(CVMX_BOARD_TYPE_NULL) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cvmx-bootinfo.h:321:20: note: expanded from macro 'ENUM_BRD_TYPE_CASE' case x: return(#x + 16); /* Skip CVMX_BOARD_TYPE_ */ ~~~^~~~ cvmx-bootinfo.h:326:3: note: use array indexing to silence this warning cvmx-bootinfo.h:321:20: note: expanded from macro 'ENUM_BRD_TYPE_CASE' case x: return(#x + 16); /* Skip CVMX_BOARD_TYPE_ */ ^ Follow the prompts to use the address operator '&' to fix this error. Signed-off-by: Tianjia Zhang <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Reviewed-by: Philippe Mathieu-Daudé <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 843fff4287a56b3a20c834bd817f7c9eeaeba605 Author: Michael Ellerman <[email protected]> Date: Thu Dec 9 22:59:44 2021 +1100 selftests/powerpc: Add a test of sigreturning to the kernel [ Upstream commit a8968521cfdc3e339fe69473d6632e0aa8d7202a ] We have a general signal fuzzer, sigfuz, which can modify the MSR & NIP before sigreturn. But the chance of it hitting a kernel address and also clearing MSR_PR is fairly slim. So add a specific test of sigreturn to a kernel address, both with and without attempting to clear MSR_PR (which the kernel must block). Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 845a5a4a8fd9805827e045089f5dca01a573f36c Author: Lakshmi Sowjanya D <[email protected]> Date: Wed Dec 15 17:12:01 2021 +0200 i2c: designware-pci: Fix to change data types of hcnt and lcnt parameters [ Upstream commit d52097010078c1844348dc0e467305e5f90fd317 ] The data type of hcnt and lcnt in the struct dw_i2c_dev is of type u16. It's better to have same data type in struct dw_scl_sda_cfg as well. Reported-by: Wolfram Sang <[email protected]> Signed-off-by: Lakshmi Sowjanya D <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]> Signed-off-by: Jarkko Nikula <[email protected]> Signed-off-by: Wolfram Sang <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 23606176a3b4fe2c63121d098da7fc7180dad4d1 Author: Marc Zyngier <[email protected]> Date: Thu Dec 16 14:32:27 2021 +0000 irqchip/gic-v4: Disable redistributors' view of the VPE table at boot time [ Upstream commit 79a7f77b9b154d572bd9d2f1eecf58c4d018d8e2 ] Jay Chen reported that using a kdump kernel on a GICv4.1 system results in a RAS error being delivered when the secondary kernel configures the ITS's view of the new VPE table. As it turns out, that's because each RD still has a pointer to the previous instance of the VPE table, and that particular implementation is very upset by seeing two bits of the HW that should point to the same table with different values. To solve this, let's invalidate any reference that any RD has to the VPE table when discovering the RDs. The ITS can then be programmed as expected. Reported-by: Jay Chen <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Cc: Lorenzo Pieralisi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit e8ffc355c7d67c63461859242a2aac3aa80ca00b Author: Ye Guojin <[email protected]> Date: Tue Nov 16 08:10:51 2021 +0000 MIPS: OCTEON: add put_device() after of_find_device_by_node() [ Upstream commit 858779df1c0787d3fec827fb705708df9ebdb15b ] This was found by coccicheck: ./arch/mips/cavium-octeon/octeon-platform.c, 332, 1-7, ERROR missing put_device; call of_find_device_by_node on line 324, but without a corresponding object release within this function. ./arch/mips/cavium-octeon/octeon-platform.c, 395, 1-7, ERROR missing put_device; call of_find_device_by_node on line 387, but without a corresponding object release within this function. ./arch/mips/cavium-octeon/octeon-usb.c, 512, 3-9, ERROR missing put_device; call of_find_device_by_node on line 515, but without a corresponding object release within this function. ./arch/mips/cavium-octeon/octeon-usb.c, 543, 1-7, ERROR missing put_device; call of_find_device_by_node on line 515, but without a corresponding object release within this function. Reported-by: Zeal Robot <[email protected]> Signed-off-by: Ye Guojin <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 9de7569942cc7960755d21e61661b7b7ba4757da Author: Jan Kara <[email protected]> Date: Tue Dec 14 11:04:29 2021 +0100 udf: Fix error handling in udf_new_inode() [ Upstream commit f05f2429eec60851b98bdde213de31dab697c01b ] When memory allocation of iinfo or block allocation fails, already allocated struct udf_inode_info gets freed with iput() and udf_evict_inode() may look at inode fields which are not properly initialized. Fix it by marking inode bad before dropping reference to it in udf_new_inode(). Reported-by: [email protected] Signed-off-by: Jan Kara <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 625be247e81249ec92d8bf8db17e6ee724c48099 Author: Hari Bathini <[email protected]> Date: Tue Dec 7 16:07:19 2021 +0530 powerpc/fadump: Fix inaccurate CPU state info in vmcore generated with panic [ Upstream commit 06e629c25daa519be620a8c17359ae8fc7a2e903 ] In panic path, fadump is triggered via a panic notifier function. Before calling panic notifier functions, smp_send_stop() gets called, which stops all CPUs except the panic'ing CPU. Commit 8389b37dffdc ("powerpc: stop_this_cpu: remove the cpu from the online map.") and again commit bab26238bbd4 ("powerpc: Offline CPU in stop_this_cpu()") started marking CPUs as offline while stopping them. So, if a kernel has either of the above commits, vmcore captured with fadump via panic path would not process register data for all CPUs except the panic'ing CPU. Sample output of crash-utility with such vmcore: # crash vmlinux vmcore ... KERNEL: vmlinux DUMPFILE: vmcore [PARTIAL DUMP] CPUS: 1 DATE: Wed Nov 10 09:56:34 EST 2021 UPTIME: 00:00:42 LOAD AVERAGE: 2.27, 0.69, 0.24 TASKS: 183 NODENAME: XXXXXXXXX RELEASE: 5.15.0+ VERSION: #974 SMP Wed Nov 10 04:18:19 CST 2021 MACHINE: ppc64le (2500 Mhz) MEMORY: 8 GB PANIC: "Kernel panic - not syncing: sysrq triggered crash" PID: 3394 COMMAND: "bash" TASK: c0000000150a5f80 [THREAD_INFO: c0000000150a5f80] CPU: 1 STATE: TASK_RUNNING (PANIC) crash> p -x __cpu_online_mask __cpu_online_mask = $1 = { bits = {0x2, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0} } crash> crash> crash> p -x __cpu_active_mask __cpu_active_mask = $2 = { bits = {0xff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0} } crash> While this has been the case since fadump was introduced, the issue was not identified for two probable reasons: - In general, the bulk of the vmcores analyzed were from crash due to exception. - The above did change since commit 8341f2f222d7 ("sysrq: Use panic() to force a crash") started using panic() instead of deferencing NULL pointer to force a kernel crash. But then commit de6e5d38417e ("powerpc: smp_send_stop do not offline stopped CPUs") stopped marking CPUs as offline till kernel commit bab26238bbd4 ("powerpc: Offline CPU in stop_this_cpu()") reverted that change. To ensure post processing register data of all other CPUs happens as intended, let panic() function take the crash friendly path (read crash_smp_send_stop()) with the help of crash_kexec_post_notifiers option. Also, as register data for all CPUs is captured by f/w, skip IPI callbacks here for fadump, to avoid any complications in finding the right backtraces. Signed-off-by: Hari Bathini <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 953cacfaf36af33599a1142cccf799bd13c46c3d Author: Hari Bathini <[email protected]> Date: Tue Dec 7 16:07:18 2021 +0530 powerpc: handle kdump appropriately with crash_kexec_post_notifiers option [ Upstream commit 219572d2fc4135b5ce65c735d881787d48b10e71 ] Kdump can be triggered after panic_notifers since commit f06e5153f4ae2 ("kernel/panic.c: add "crash_kexec_post_notifiers" option for kdump after panic_notifers") introduced crash_kexec_post_notifiers option. But using this option would mean smp_send_stop(), that marks all other CPUs as offline, gets called before kdump is triggered. As a result, kdump routines fail to save other CPUs' registers. To fix this, kdump friendly crash_smp_send_stop() function was introduced with kernel commit 0ee59413c967 ("x86/panic: replace smp_send_stop() with kdump friendly version in panic path"). Override this kdump friendly weak function to handle crash_kexec_post_notifiers option appropriately on powerpc. Reported-by: kernel test robot <[email protected]> Signed-off-by: Hari Bathini <[email protected]> [Fixed signature of crash_stop_this_cpu() - reported by [email protected]] Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 6a0a06c9b1938001cd4ef68575e2e994f676ad53 Author: Thadeu Lima de Souza Cascardo <[email protected]> Date: Tue Dec 7 10:05:57 2021 -0300 selftests/powerpc/spectre_v2: Return skip code when miss_percent is high [ Upstream commit 3c42e9542050d49610077e083c7c3f5fd5e26820 ] A mis-match between reported and actual mitigation is not restricted to the Vulnerable case. The guest might also report the mitigation as "Software count cache flush" and the host will still mitigate with branch cache disabled. So, instead of skipping depending on the detected mitigation, simply skip whenever the detected miss_percent is the expected one for a fully mitigated system, that is, above 95%. Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit e7dd8ba6fc8439bb2c4cebc042a8fdb8ea58eea1 Author: Christophe Leroy <[email protected]> Date: Mon Sep 27 17:12:39 2021 +0200 powerpc/40x: Map 32Mbytes of memory at startup [ Upstream commit 06e7cbc29e97b4713b4ea6def04ae8501a7d1a59 ] As reported by Carlo, 16Mbytes is not enough with modern kernels that tend to be a bit big, so map another 16M page at boot. Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/89b5f974a7fa5011206682cd092e2c905530ff46.1632755552.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin <[email protected]> commit 7e6c8ff5c21cd6d612e934eebfdf5a276f067896 Author: Nathan Chancellor <[email protected]> Date: Wed Dec 8 09:56:17 2021 -0700 MIPS: Loongson64: Use three arguments for slti [ Upstream commit f2c6c22fa83ab2577619009057b3ebcb5305bb03 ] LLVM's integrated assembler does not support 'slti <reg>, <imm>': <instantiation>:16:12: error: invalid operand for instruction slti $12, (0x6300 | 0x0008) ^ arch/mips/kernel/head.S:86:2: note: while in macro instantiation kernel_entry_setup # cpu specific setup ^ <instantiation>:16:12: error: invalid operand for instruction slti $12, (0x6300 | 0x0008) ^ arch/mips/kernel/head.S:150:2: note: while in macro instantiation smp_slave_setup ^ To increase compatibility with LLVM's integrated assembler, use the full form of 'slti <reg>, <reg>, <imm>', which matches the rest of arch/mips/. This does not result in any change for GNU as. Link: https://github.com/ClangBuiltLinux/linux/issues/1526 Reported-by: Ryutaroh Matsumoto <[email protected]> Signed-off-by: Nathan Chancellor <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 8774f9824c2cc35809c6230ccf224e8f665609c1 Author: Takashi Iwai <[email protected]> Date: Tue Dec 7 17:51:46 2021 +0100 ALSA: seq: Set upper limit of processed events [ Upstream commit 6fadb494a638d8b8a55864ecc6ac58194f03f327 ] Currently ALSA sequencer core tries to process the queued events as much as possible when they become dispatchable. If applications try to queue too massive events to be processed at the very same timing, the sequencer core would still try to process such all events, either in the interrupt context or via some notifier; in either away, it might be a cause of RCU stall or such problems. As a potential workaround for those problems, this patch adds the upper limit of the amount of events to be processed. The remaining events are processed in the next batch, so they won't be lost. For the time being, it's limited up to 1000 events per queue, which should be high enough for any normal usages. Reported-by: Zqiang <[email protected]> Reported-by: [email protected] Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit b693e737e080d13b31e4d2d62d6b745542747b7d Author: James Smart <[email protected]> Date: Fri Dec 3 16:26:40 2021 -0800 scsi: lpfc: Trigger SLI4 firmware dump before doing driver cleanup [ Upstream commit 7dd2e2a923173d637c272e483966be8e96a72b64 ] Extraneous teardown routines are present in the firmware dump path causing altered states in firmware captures. When a firmware dump is requested via sysfs, trigger the dump immediately without tearing down structures and changing adapter state. The driver shall rely on pre-existing firmware error state clean up handlers to restore the adapter. Link: https://lore.kernel.org/r/[email protected] Co-developed-by: Justin Tee <[email protected]> Signed-off-by: Justin Tee <[email protected]> Signed-off-by: James Smart <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 5b91e80b631c5ea55abfc6ff89ab26fb2edd9dc3 Author: James Smart <[email protected]> Date: Fri Dec 3 16:26:36 2021 -0800 scsi: lpfc: Fix leaked lpfc_dmabuf mbox allocations with NPIV [ Upstream commit f0d3919697492950f57a26a1093aee53880d669d ] During rmmod testing, messages appeared indicating lpfc_mbuf_pool entries were still busy. This situation was only seen doing rmmod after at least 1 vport (NPIV) instance was created and destroyed. The number of messages scaled with the number of vports created. When a vport is created, it can receive a PLOGI from another initiator Nport. When this happens, the driver prepares to ack the PLOGI and prepares an RPI for registration (via mbx cmd) which includes an mbuf allocation. During the unsolicited PLOGI processing and after the RPI preparation, the driver recognizes it is one of the vport instances and decides to reject the PLOGI. During the LS_RJT preparation for the PLOGI, the mailbox struct allocated for RPI registration is freed, but the mbuf that was also allocated is not released. Fix by freeing the mbuf with the mailbox struct in the LS_RJT path. As part of the code review to figure the issue out a couple of other areas where found that also would not have released the mbuf. Those are cleaned up as well. Link: https://lore.kernel.org/r/[email protected] Co-developed-by: Justin Tee <[email protected]> Signed-off-by: Justin Tee <[email protected]> Signed-off-by: James Smart <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit ef9e3ecacb756857338992ec868478d0ebcdaae9 Author: Bart Van Assche <[email protected]> Date: Fri Dec 3 15:19:47 2021 -0800 scsi: ufs: Fix a kernel crash during shutdown [ Upstream commit 3489c34bd02b73a72646037d673a122a53cee174 ] Fix the following kernel crash: Unable to handle kernel paging request at virtual address ffffffc91e735000 Call trace: __queue_work+0x26c/0x624 queue_work_on+0x6c/0xf0 ufshcd_hold+0x12c/0x210 __ufshcd_wl_suspend+0xc0/0x400 ufshcd_wl_shutdown+0xb8/0xcc device_shutdown+0x184/0x224 kernel_restart+0x4c/0x124 __arm64_sys_reboot+0x194/0x264 el0_svc_common+0xc8/0x1d4 do_el0_svc+0x30/0x8c el0_svc+0x20/0x30 el0_sync_handler+0x84/0xe4 el0_sync+0x1bc/0x1c0 Fix this crash by ungating the clock before destroying the work queue on which clock gating work is queued. Link: https://lore.kernel.org/r/[email protected] Tested-by: Bean Huo <[email protected]> Reviewed-by: Bean Huo <[email protected]> Signed-off-by: Bart Van Assche <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit d90d496a999ed1e7909e8e24f452c0b7b444a636 Author: Stephan Gerhold <[email protected]> Date: Mon Dec 6 12:45:42 2021 +0100 interconnect: qcom: rpm: Prevent integer overflow in rate [ Upstream commit a7d9436a6c85fcb8843c910fd323dcd7f839bf63 ] Using icc-rpm on ARM32 currently results in clk_set_rate() errors during boot, e.g. "bus clk_set_rate error: -22". This is very similar to commit 7381e27b1e56 ("interconnect: qcom: msm8974: Prevent integer overflow in rate") where the u64 is converted to a signed long during clock rate rounding, resulting in an overflow on 32-bit platforms. Let's fix it similarly by making sure that the rate does not exceed LONG_MAX. Such high clock rates will surely result in the maximum frequency of the bus anyway. Signed-off-by: Stephan Gerhold <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit efd507bed1b4ba0f32ece009c34e462392e6de7c Author: Christoph Hellwig <[email protected]> Date: Mon Nov 29 11:21:35 2021 +0100 dm: fix alloc_dax error handling in alloc_dev [ Upstream commit d751939235b9b7bc4af15f90a3e99288a8b844a7 ] Make sure ->dax_dev is NULL on error so that the cleanup path doesn't trip over an ERR_PTR. Reported-by: Dan Williams <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dan Williams <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 78d56d075464315fefa8842c35d34219b5490ae1 Author: Srinivas Kandagatla <[email protected]> Date: Tue Nov 30 13:39:09 2021 +0000 nvmem: core: set size for sysfs bin file [ Upstream commit 86192251033308bb42f1e9813c962989d8ed07ec ] For some reason we never set the size for nvmem sysfs binary file. Set this. Reported-by: Gilles BULOZ <[email protected]> Signed-off-by: Srinivas Kandagatla <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit fea0e4b49dd2bfc28347e20f4e7a41dd2bd872cc Author: Christophe Leroy <[email protected]> Date: Fri Nov 26 18:06:46 2021 +0100 w1: Misuse of get_user()/put_user() reported by sparse [ Upstream commit 33dc3e3e99e626ce51f462d883b05856c6c30b1d ] sparse warnings: (new ones prefixed by >>) >> drivers/w1/slaves/w1_ds28e04.c:342:13: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected char [noderef] __user *_pu_addr @@ got char *buf @@ drivers/w1/slaves/w1_ds28e04.c:342:13: sparse: expected char [noderef] __user *_pu_addr drivers/w1/slaves/w1_ds28e04.c:342:13: sparse: got char *buf >> drivers/w1/slaves/w1_ds28e04.c:356:13: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected char const [noderef] __user *_gu_addr @@ got char const *buf @@ drivers/w1/slaves/w1_ds28e04.c:356:13: sparse: expected char const [noderef] __user *_gu_addr drivers/w1/slaves/w1_ds28e04.c:356:13: sparse: got char const *buf The buffer buf is a failsafe buffer in kernel space, it's not user memory hence doesn't deserve the use of get_user() or put_user(). Access 'buf' content directly. Link: https://lore.kernel.org/lkml/[email protected]/T/ Reported-by: kernel test robot <[email protected]> Signed-off-by: Christophe Leroy <[email protected]> Link: https://lore.kernel.org/r/d14ed8d71ad4372e6839ae427f91441d3ba0e94d.1637946316.git.christophe.leroy@csgroup.eu Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit d58837197d20546e567631d257c585433c72aa77 Author: Alexey Kardashevskiy <[email protected]> Date: Wed Sep 1 18:45:50 2021 +1000 KVM: PPC: Book3S: Suppress failed alloc warning in H_COPY_TOFROM_GUEST [ Upstream commit 792020907b11c6f9246c21977cab3bad985ae4b6 ] H_COPY_TOFROM_GUEST is an hcall for an upper level VM to access its nested VMs memory. The userspace can trigger WARN_ON_ONCE(!(gfp & __GFP_NOWARN)) in __alloc_pages() by constructing a tiny VM which only does H_COPY_TOFROM_GUEST with a too big GPR9 (number of bytes to copy). This silences the warning by adding __GFP_NOWARN. Spotted by syzkaller. Signed-off-by: Alexey Kardashevskiy <[email protected]> Reviewed-by: Fabiano Rosas <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit a0a4d7a23d18c2953d76d26dedf82a74a1943177 Author: Alexey Kardashevskiy <[email protected]> Date: Wed Sep 1 18:45:12 2021 +1000 KVM: PPC: Book3S: Suppress warnings when allocating too big memory slots [ Upstream commit 511d25d6b789fffcb20a3eb71899cf974a31bd9d ] The userspace can trigger "vmalloc size %lu allocation failure: exceeds total pages" via the KVM_SET_USER_MEMORY_REGION ioctl. This silences the warning by checking the limit before calling vzalloc() and returns ENOMEM if failed. This does not call underlying valloc helpers as __vmalloc_node() is only exported when CONFIG_TEST_VMALLOC_MODULE and __vmalloc_node_range() is not exported at all. Spotted by syzkaller. Signed-off-by: Alexey Kardashevskiy <[email protected]> [mpe: Use 'size' for the variable rather than 'cb'] Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 9170beaeffe4bc232042fd7e1cff921a27fde536 Author: Christophe Leroy <[email protected]> Date: Tue Nov 30 10:32:42 2021 +0100 powerpc/powermac: Add missing lockdep_register_key() [ Upstream commit df1f679d19edb9eeb67cc2f96b29375f21991945 ] KeyWest i2c @0xf8001003 irq 42 /uni-n@f8000000/i2c@f8001000 BUG: key c2d00cbc has not been registered! ------------[ cut here ]------------ DEBUG_LOCKS_WARN_ON(1) WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:4801 lockdep_init_map_type+0x4c0/0xb4c Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.5-gentoo-PowerMacG4 #9 NIP: c01a9428 LR: c01a9428 CTR: 00000000 REGS: e1033cf0 TRAP: 0700 Not tainted (5.15.5-gentoo-PowerMacG4) MSR: 00029032 <EE,ME,IR,DR,RI> CR: 24002002 XER: 00000000 GPR00: c01a9428 e1033db0 c2d1cf20 00000016 00000004 00000001 c01c0630 e1033a73 GPR08: 00000000 00000000 00000000 e1033db0 24002004 00000000 f8729377 00000003 GPR16: c1829a9c 00000000 18305357 c1416fc0 c1416f80 c006ac60 c2d00ca8 c1416f00 GPR24: 00000000 c21586f0 c2160000 00000000 c2d00cbc c2170000 c216e1a0 c2160000 NIP [c01a9428] lockdep_init_map_type+0x4c0/0xb4c LR [c01a9428] lockdep_init_map_type+0x4c0/0xb4c Call Trace: [e1033db0] [c01a9428] lockdep_init_map_type+0x4c0/0xb4c (unreliable) [e1033df0] [c1c177b8] kw_i2c_add+0x334/0x424 [e1033e20] [c1c18294] pmac_i2c_init+0x9ec/0xa9c [e1033e80] [c1c1a790] smp_core99_probe+0xbc/0x35c [e1033eb0] [c1c03cb0] kernel_init_freeable+0x190/0x5a4 [e1033f10] [c000946c] kernel_init+0x28/0x154 [e1033f30] [c0035148] ret_from_kernel_thread+0x14/0x1c Add missing lockdep_register_key() Reported-by: Erhard Furtner <[email protected]> Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/69e4f55565bb45ebb0843977801b245af0c666fe.1638264741.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin <[email protected]> commit af0e9677f6e6050343ae381f753e65bd11ecdfb8 Author: Martin Blumenstingl <[email protected]> Date: Sun Oct 31 14:50:06 2021 +0100 clk: meson: gxbb: Fix the SDM_EN bit for MPLL0 on GXBB [ Upstream commit ff54938dd190d85f740b9bf9dde59b550936b621 ] There are reports that 48kHz audio does not work on the WeTek Play 2 (which uses a GXBB SoC), while 44.1kHz audio works fine on the same board. There are also reports of 48kHz audio working fine on GXL and GXM SoCs, which are using an (almost) identical AIU (audio controller). Experimenting has shown that MPLL0 is causing this problem. In the .dts we have by default: assigned-clocks = <&clkc CLKID_MPLL0>, <&clkc CLKID_MPLL1>, <&clkc CLKID_MPLL2>; assigned-clock-rates = <294912000>, <270950400>, <393216000>; The MPLL0 rate is divisible by 48kHz without remainder and the MPLL1 rate is divisible by 44.1kHz without remainder. Swapping these two clock rates "fixes" 48kHz audio but breaks 44.1kHz audio. Everything looks normal when looking at the info provided by the common clock framework while playing 48kHz audio (via I2S with mclk-fs = 256): mpll_prediv 1 1 0 2000000000 mpll0_div 1 1 0 294909641 mpll0 1 1 0 294909641 cts_amclk_sel 1 1 0 294909641 cts_amclk_div 1 1 0 12287902 cts_amclk 1 1 0 12287902 meson-clk-msr however shows that the actual MPLL0 clock is off by more than 38MHz: mp0_out 333322917 +/-10416Hz The rate seen by meson-clk-msr is very close to what we would get when SDM (the fractional part) was ignored: (2000000000Hz * 16384) / ((16384 * 6) = 333.33MHz If SDM was considered the we should get close to: (2000000000Hz * 16384) / ((16384 * 6) + 12808) = 294.9MHz Further experimenting shows that HHI_MPLL_CNTL7[15] does not have any effect on the rate of MPLL0 as seen my meson-clk-msr (regardless of whether that bit is zero or one the rate is always the same according to meson-clk-msr). Using HHI_MPLL_CNTL[25] on the other hand as SDM_EN results in SDM being considered for the rate output by the hardware. The rate - as seen by meson-clk-msr - matches with what we expect when SDM_EN is enabled (fractional part is being considered, resulting in a 294.9MHz output) or disable (fractional part being ignored, resulting in a 333.33MHz output). Reported-by: Christian Hewitt <[email protected]> Tested-by: Christian Hewitt <[email protected]> Signed-off-by: Martin Blumenstingl <[email protected]> Signed-off-by: Jerome Brunet <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 95abac60d96d75d7fea3648cea55b38fb17e18fb Author: Joakim Tjernlund <[email protected]> Date: Thu May 11 14:20:33 2017 +0200 i2c: mpc: Correct I2C reset procedure [ Upstream commit ebe82cf92cd4825c3029434cabfcd2f1780e64be ] Current I2C reset procedure is broken in two ways: 1) It only generate 1 START instead of 9 STARTs and STOP. 2) It leaves the bus Busy so every I2C xfer after the first fixup calls the reset routine again, for every xfer there after. This fixes both errors. Signed-off-by: Joakim Tjernlund <[email protected]> Acked-by: Scott Wood <[email protected]> Signed-off-by: Wolfram Sang <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit f374976a7e4d5906991fea69c303e3c6e0003697 Author: Michael Ellerman <[email protected]> Date: Wed Nov 24 20:32:53 2021 +1100 powerpc/smp: Move setup_profiling_timer() under CONFIG_PROFILING [ Upstream commit a4ac0d249a5db80e79d573db9e4ad29354b643a8 ] setup_profiling_timer() is only needed when CONFIG_PROFILING is enabled. Fixes the following W=1 warning when CONFIG_PROFILING=n: linux/arch/powerpc/kernel/smp.c:1638:5: error: no previous prototype for ‘setup_profiling_timer’ Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit be9313f755a7bfa02230b15731d07074d5255ecb Author: Heiner Kallweit <[email protected]> Date: Sun Nov 7 22:57:00 2021 +0100 i2c: i801: Don't silently correct invalid transfer size [ Upstream commit effa453168a7eeb8a562ff4edc1dbf9067360a61 ] If an invalid block size is provided, reject it instead of silently changing it to a supported value. Especially critical I see the case of a write transfer with block length 0. In this case we have no guarantee that the byte we would write is valid. When silently reducing a read to 32 bytes then we don't return an error and the caller may falsely assume that we returned the full requested data. If this change should break any (broken) caller, then I think we should fix the caller. Signed-off-by: Heiner Kallweit <[email protected]> Reviewed-by: Jean Delvare <[email protected]> Signed-off-by: Wolfram Sang <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit b8526a5003d6c444b4e6e4d9598d735099c76366 Author: Ye Guojin <[email protected]> Date: Wed Nov 10 00:29:10 2021 +0000 ASoC: imx-hdmi: add put_device() after of_find_device_by_node() [ Upstream commit f670b274f7f6f4b2722d7f08d0fddf606a727e92 ] This was found by coccicheck: ./sound/soc/fsl/imx-hdmi.c,209,1-7,ERROR missing put_device; call of_find_device_by_node on line 119, but without a corresponding object release within this function. Reported-by: Zeal Robot <[email protected]> Signed-off-by: Ye Guojin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 52ce10c1878cf4583306fa2a2880d6f482c35cc7 Author: Nicholas Piggin <[email protected]> Date: Wed Nov 10 12:50:53 2021 +1000 powerpc/watchdog: Fix missed watchdog reset due to memory ordering race [ Upstream commit 5dad4ba68a2483fc80d70b9dc90bbe16e1f27263 ] It is possible for all CPUs to miss the pending cpumask becoming clear, and then nobody resetting it, which will cause the lockup detector to stop working. It will eventually expire, but watchdog_smp_panic will avoid doing anything if the pending mask is clear and it will never be reset. Order the cpumask clear vs the subsequent test to close this race. Add an extra check for an empty pending mask when the watchdog fires and finds its bit still clear, to try to catch any other possible races or bugs here and keep the watchdog working. The extra test in arch_touch_nmi_watchdog is required to prevent the new warning from firing off. Signed-off-by: Nicholas Piggin <[email protected]> Reviewed-by: Laurent Dufour <[email protected]> Debugged-by: Laurent Dufour <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit aa8c270145290f72d1d2caf5aa5d4b9fa6be4a11 Author: Julia Lawall <[email protected]> Date: Fri Nov 20 20:33:23 2015 +0000 powerpc/btext: add missing of_node_put [ Upstream commit a1d2b210ffa52d60acabbf7b6af3ef7e1e69cda0 ] for_each_node_by_type performs an of_node_get on each iteration, so a break out of the loop requires an of_node_put. A simplified version of the semantic patch that fixes this problem is as follows (http://coccinelle.lip6.fr): // <smpl> @@ local idexpression n; expression e; @@ for_each_node_by_type(n,...) { ... ( of_node_put(n); | e = n | + of_node_put(n); ? break; ) ... } ... when != n // </smpl> Signed-off-by: Julia Lawall <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit efe379f92d5f827e9707fa277a286cbf14f4ee32 Author: Julia Lawall <[email protected]> Date: Fri Nov 20 21:33:24 2015 +0100 powerpc/cell: add missing of_node_put [ Upstream commit a841fd009e51c8c0a8f07c942e9ab6bb48da8858 ] for_each_node_by_name performs an of_node_get on each iteration, so a break out of the loop requires an of_node_put. A simplified version of the semantic patch that fixes this problem is as follows (http://coccinelle.lip6.fr): // <smpl> @@ expression e,e1; local idexpression n; @@ for_each_node_by_name(n, e1) { ... when != of_node_put(n) when != e = n ( return n; | + of_node_put(n); ? return ...; ) ... } // </smpl> Signed-off-by: Julia Lawall <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 179ecdf5c08919c81a41ddfa20a00150c0f095cb Author: Julia Lawall <[email protected]> Date: Fri Nov 20 20:33:21 2015 +0000 powerpc/powernv: add missing of_node_put [ Upstream commit 7d405a939ca960162eb30c1475759cb2fdf38f8c ] for_each_compatible_node performs an of_node_get on each iteration, so a break out of the loop requires an of_node_put. A simplified version of the semantic patch that fixes this problem is as follows (http://coccinelle.lip6.fr): // <smpl> @@ local idexpression n; expression e; @@ for_each_compatible_node(n,...) { ... ( of_node_put(n); | e = n | + of_node_put(n); ? break; ) ... } ... when != n // </smpl> Signed-off-by: Julia Lawall <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 5203c7027fdd70967e3b7fb5c0e258891cb69388 Author: Julia Lawall <[email protected]> Date: Fri Nov 20 20:33:19 2015 +0000 powerpc/6xx: add missing of_node_put [ Upstream commit f6e82647ff71d427d4148964b71f239fba9d7937 ] for_each_compatible_node performs an of_node_get on each iteration, so a break out of the loop requires an of_node_put. A simplified version of the semantic patch that fixes this problem is as follows (http://coccinelle.lip6.fr): // <smpl> @@ expression e; local idexpression n; @@ @@ local idexpression n; expression e; @@ for_each_compatible_node(n,...) { ... ( of_node_put(n); | e = n | + of_node_put(n); ? break; ) ... } ... when != n // </smpl> Signed-off-by: Julia Lawall <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 992a9eafb1ecce5b714e6c00522389dcbc29237e Author: Ingo Molnar <[email protected]> Date: Wed Jan 5 01:35:58 2022 +0100 x86/kbuild: Enable CONFIG_KALLSYMS_ALL=y in the defconfigs [ Upstream commit b6aa86cff44cf099299d3a5e66348cb709cd7964 ] Most distro kernels have this option enabled, to improve debug output. Lockdep also selects it. Enable this in the defconfig kernel as well, to make it more representative of what people are using on x86. Signed-off-by: Ingo Molnar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 67de7d5ae29b13aa259132101a2e6e4efb3432ad Author: Marc Kleine-Budde <[email protected]> Date: Fri Jan 7 14:29:15 2022 +0100 can: flexcan: add more quirks to describe RX path capabilities [ Upstream commit c5c88591040ee7d84d037328eed9019d3ffab821 ] Most flexcan IP cores support 2 RX modes: - FIFO - mailbox Some IP core versions cannot receive CAN RTR messages via mailboxes. This patch adds quirks to document this. This information will be used in a later patch to switch from FIFO to more performant mailbox mode at the expense of losing the ability to receive RTR messages. This trade off is beneficial in certain use cases. Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit cf0649500913f55420e54349a942906657e218a6 Author: Marc Kleine-Budde <[email protected]> Date: Thu Jan 6 12:45:46 2022 +0100 can: flexcan: rename RX modes [ Upstream commit 34ea4e1c99f1f177f87e4ae7896caef238dd741a ] Most flexcan IP cores support 2 RX modes: - FIFO - mailbox The names for these modes were chosen to reflect the name of the rx-offload mode they are using. The name of the RX modes should better reflect their difference with regards the flexcan IP core. So this patch renames the various occurrences of OFF_FIFO to RX_FIFO and OFF_TIMESTAMP to RX_MAILBOX: | FLEXCAN_TX_MB_RESERVED_OFF_FIFO -> FLEXCAN_TX_MB_RESERVED_RX_FIFO | FLEXCAN_TX_MB_RESERVED_OFF_TIMESTAMP -> FLEXCAN_TX_MB_RESERVED_RX_MAILBOX | FLEXCAN_QUIRK_USE_OFF_TIMESTAMP -> FLEXCAN_QUIRK_USE_RX_MAILBOX Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit e719eeb508855db929ea92a9a8fdfd5767f0a80b Author: Dario Binacchi <[email protected]> Date: Tue Jan 4 14:20:25 2022 +0100 can: flexcan: allow to change quirks at runtime [ Upstream commit 01bb4dccd92b4dc21f6af3312e5696924e371111 ] This is a preparation patch for the upcoming support to change the rx-rtr capability via the ethtool API. Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Dario Binacchi <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit b9d50e591133a139fb7e5cfeb53fea2b27e16e18 Author: John David Anglin <[email protected]> Date: Wed Dec 22 16:52:26 2021 +0000 parisc: Avoid calling faulthandler_disabled() twice [ Upstream commit 9e9d4b460f23bab61672eae397417d03917d116c ] In handle_interruption(), we call faulthandler_disabled() to check whether the fault handler is not disabled. If the fault handler is disabled, we immediately call do_page_fault(). It then calls faulthandler_disabled(). If disabled, do_page_fault() attempts to fixup the exception by jumping to no_context: no_context: if (!user_mode(regs) && fixup_exception(regs)) { return; } parisc_terminate("Bad Address (null pointer deref?)", regs, code, address); Apart from the error messages, the two blocks of code perform the same function. We can avoid two calls to faulthandler_disabled() by a simple revision to the code in handle_interruption(). Note: I didn't try to fix the formatting of this code block. Signed-off-by: John David Anglin <[email protected]> Signed-off-by: Helge Deller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 4e2e5a033e93ec8805f2584e900a6bea4016ef5b Author: Maor Dickman <[email protected]> Date: Thu Dec 9 14:03:01 2021 +0200 net/mlx5e: Unblock setting vid 0 for VF in case PF isn't eswitch manager [ Upstream commit 7846665d3504812acaebf920d1141851379a7f37 ] When using libvirt to passthrough VF to VM it will always set the VF vlan to 0 even if user didn’t request it, this will cause libvirt to fail to boot in case the PF isn't eswitch owner. Example of such case is the DPU host PF which isn't eswitch manager, so any attempt to passthrough VF of it using libvirt will fail. Fix it by not returning error in case set VF vlan is called with vid 0. Signed-off-by: Maor Dickman <[email protected]> Reviewed-by: Roi Dayan <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit d24e3a126b2ea91e69f34c9487c6cddde84fa5b9 Author: Maher Sanalla <[email protected]> Date: Wed Jan 5 14:50:11 2022 +0200 net/mlx5: Update log_max_qp value to FW max capability [ Upstream commit f79a609ea6bf54ad2d2c24e4de4524288b221666 ] log_max_qp in driver's default profile #2 was set to 18, but FW actually supports 17 at the most - a situation that led to the concerning print when the driver is loaded: "log_max_qp value in current profile is 18, changing to HCA capabaility limit (17)" The expected behavior from mlx5_profile #2 is to match the maximum FW capability in regards to log_max_qp. Thus, log_max_qp in profile #2 is initialized to a defined static value (0xff) - which basically means that when loading this profile, log_max_qp value will be what the currently installed FW supports at most. Signed-off-by: Maher Sanalla <[email protected]> Reviewed-by: Maor Gottlieb <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 8c751aac0b64fb52743ac5deffc3ce85bbe1482b Author: Jason A. Donenfeld <[email protected]> Date: Wed Dec 29 22:10:05 2021 +0100 random: do not throw away excess input to crng_fast_load [ Upstream commit 73c7733f122e8d0107f88655a12011f68f69e74b ] When crng_fast_load() is called by add_hwgenerator_randomness(), we currently will advance to crng_init==1 once we've acquired 64 bytes, and then throw away the rest of the buffer. Usually, that is not a problem: When add_hwgenerator_randomness() gets called via EFI or DT during setup_arch(), there won't be any IRQ randomness. Therefore, the 64 bytes passed by EFI exactly matches what is needed to advance to crng_init==1. Usually, DT seems to pass 64 bytes as well -- with one notable exception being kexec, which hands over 128 bytes of entropy to the kexec'd kernel. In that case, we'll advance to crng_init==1 once 64 of those bytes are consumed by crng_fast_load(), but won't continue onward feeding in bytes to progress to crng_init==2. This commit fixes the issue by feeding any leftover bytes into the next phase in add_hwgenerator_randomness(). [[email protected]: rewrite commit message] Signed-off-by: Dominik Brodowski <[email protected]> Signed-off-by: Jason A. Donenfeld <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 0e7d8e930aba6a5b84d00713553f001fa06206f2 Author: Lukas Wunner <[email protected]> Date: Sun Jan 2 18:52:44 2022 +0100 serial: core: Keep mctrl register state and cached copy in sync [ Upstream commit 93a770b7e16772530196674ffc79bb13fa927dc6 ] struct uart_port contains a cached copy of the Modem Control signals. It is used to skip register writes in uart_update_mctrl() if the new signal state equals the old signal state. It also avoids a register read to obtain the current state of output signals. When a uart_port is registered, uart_configure_port() changes signal state but neglects to keep the cached copy in sync. That may cause a subsequent register write to be incorrectly skipped. Fix it before it trips somebody up. This behavior has been present ever since the serial core was introduced in 2002: https://git.kernel.org/history/history/c/33c0d1b0c3eb So far it was never an issue because the cached copy is initialized to 0 by kzalloc() and when uart_configure_port() is executed, at most DTR has been set by uart_set_options() or sunsu_console_setup(). Therefore, a stable designation seems unnecessary. Signed-off-by: Lukas Wunner <[email protected]> Link: https://lore.kernel.org/r/bceeaba030b028ed810272d55d5fc6f3656ddddb.1641129752.git.lukas@wunner.de Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 5b452507d5e768bd051d65188a50f35c4000b864 Author: Lukas Wunner <[email protected]> Date: Sun Jan 2 18:45:44 2022 +0100 serial: pl011: Drop CR register reset on set_termios [ Upstream commit e368cc656fd6d0075f1c3ab9676e2001451e3e04 ] pl011_set_termios() briefly resets the CR register to zero, thereby glitching DTR/RTS signals. With rs485 this may result in the bus being occupied for no reason. Where does this register write originate from? The PL011 driver was forked from the PL010 driver in 2004: https://git.kernel.org/history/history/c/157c0342e591 Until this commit, the PL010 driver's IRQ handler ambauart_int() modified the CR register without holding the port spinlock. ambauart_set_termios() also modified that register. To prevent concurrent read-modify-writes by the IRQ handler and to prevent transmission while changing baudrate, ambauart_set_termios() had to disable interrupts. On the PL010, that is achieved by writing zero to the CR register. However, on the PL011, interrupts are disabled in the IMSC register, not in the CR register. Additionally, the commit amended both the PL010 and PL011 driver to acquire the port spinlock in the IRQ handler, obviating the need to disable interrupts in ->set_termios(). So the CR register write is obsolete for two reasons. Drop it. Cc: Russell King <[email protected]> Signed-off-by: Lukas Wunner <[email protected]> Link: https://lore.kernel.org/r/f49f945375f5ccb979893c49f1129f51651ac738.1641129062.git.lukas@wunner.de Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 9201e1dd5aee66f093af9e1f035c916d396f0c93 Author: Lukas Wunner <[email protected]> Date: Sun Jan 2 18:42:44 2022 +0100 serial: pl010: Drop CR register reset on set_termios [ Upstream commit 08a0c6dff91c965e39905cf200d22db989203ccb ] pl010_set_termios() briefly resets the CR register to zero. Where does this register write come from? The PL010 driver's IRQ handler ambauart_int() originally modified the CR register without holding the port spinlock. ambauart_set_termios() also modified that register. To prevent concurrent read-modify-writes by the IRQ handler and to prevent transmission while changing baudrate, ambauart_set_termios() had to disable interrupts. That is achieved by writing zero to the CR register. However in 2004 the PL010 driver was amended to acquire the port spinlock in the IRQ handler, obviating the need to disable interrupts in ->set_termios(): https://git.kernel.org/history/history/c/157c0342e591 That rendered the CR register write obsolete. Drop it. Cc: Russell King <[email protected]> Signed-off-by: Lukas Wunner <[email protected]> Link: https://lore.kernel.org/r/fcaff16e5b1abb4cc3da5a2879ac13f278b99ed0.1641128728.git.lukas@wunner.de Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 7828830235cbd6e57ba21ca74a4d1d9bfe41508c Author: Konrad Dybcio <[email protected]> Date: Thu Dec 30 03:34:42 2021 +0100 regulator: qcom_smd: Align probe function with rpmh-regulator [ Upstream commit 14e2976fbabdacb01335d7f91eeebbc89c67ddb1 ] The RPMh regulator driver is much newer and gets more attention, which in consequence makes it do a few things better. Update qcom_smd-regulator's probe function to mimic what rpmh-regulator does to address a couple of issues: - Probe defer now works correctly, before it used to, well, kinda just die.. This fixes reliable probing on (at least) PM8994, because Linux apparently cannot deal with supply map dependencies yet.. - Regulator data is now matched more sanely: regulator data is matched against each individual regulator node name and throwing an -EINVAL if data is missing, instead of just assuming everything is fine and iterating over all subsequent array members. - status = "disabled" will now work for disabling individual regulators in DT. Previously it didn't seem to do much if anything at all. Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 59caf131b18cb6534f013e5c4614e988d599508d Author: Russell King (Oracle) <[email protected]> Date: Tue Jan 4 16:38:31 2022 +0000 net: gemini: allow any RGMII interface mode [ Upstream commit 4e4f325a0a55907b14f579e6b1a38c53755e3de2 ] The four RGMII interface modes take care of the required RGMII delay configuration at the PHY and should not be limited by the network MAC driver. Sadly, gemini was only permitting RGMII mode with no delays, which would require the required delay to be inserted via PCB tracking or by the MAC. However, there are designs that require the PHY to add the delay, which is impossible without Gemini permitting the other three PHY interface modes. Fix the driver to allow these. Signed-off-by: Russell King (Oracle) <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Tested-by: Corentin Labbe <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 00bf5ce4bf9a28caf92197b087850233bbe9407a Author: Russell King (Oracle) <[email protected]> Date: Tue Jan 4 16:38:19 2022 +0000 net: phy: marvell: configure RGMII delays for 88E1118 [ Upstream commit f22725c95ececb703c3f741e8f946d23705630b7 ] Corentin Labbe reports that the SSI 1328 does not work when allowing the PHY to operate at gigabit speeds, but does work with the generic PHY driver. This appears to be because m88e1118_config_init() writes a fixed value to the MSCR register, claiming that this is to enable 1G speeds. However, this always sets bits 4 and 5, enabling RGMII transmit and receive delays. The suspicion is that the original board this was added for required the delays to make 1G speeds work. Add the necessary configuration for RGMII delays for the 88E1118 to bring this into line with the requirements for RGMII support, and thus make the SSI 1328 work. Corentin Labbe has tested this on gemini-ssi1328 and gemini-ns2502. Reported-by: Corentin Labbe <[email protected]> Tested-by: Corentin Labbe <[email protected]> Signed-off-by: Russell King (Oracle) <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 5b2fd3370e7ff358e3e778244ea8f6a5b1e8c131 Author: Danielle Ratson <[email protected]> Date: Wed Jan 5 12:22:27 2022 +0200 mlxsw: pci: Avoid flow control for EMAD packets [ Upstream commit d43e4271747ace01a27a49a97a397cb4219f6487 ] Locally generated packets ingress the device through its CPU port. When the CPU port is congested and there are not enough credits in its headroom buffer, packets can be dropped. While this might be acceptable for data packets that traverse the network, configuration packets exchanged between the host and the device (EMADs) should not be subjected to this flow control. The "sdq_lp" bit in the SDQ (Send Descriptor Queue) context allows the host to instruct the device to treat packets sent on this queue as "local processing" and always process them, regardless of the state of the CPU port's headroom. Add the definition of this bit and set it for the dedicated SDQ reserved for the transmission of EMAD packets. This makes the "local processing" bit in the WQE (Work Queue Element) redundant, so clear it. Signed-off-by: Danielle Ratson <[email protected]> Signed-off-by: Ido Schimmel <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 0415b84eee93ce7c9ec4471a738ce533f3b22cc2 Author: Jiri Olsa <[email protected]> Date: Tue Jan 4 13:10:30 2022 +0100 bpf/selftests: Fix namespace mount setup in tc_redirect [ Upstream commit 5e22dd18626726028a93ff1350a8a71a00fd843d ] The tc_redirect umounts /sys in the new namespace, which can be mounted as shared and cause global umount. The lazy umount also takes down mounted trees under /sys like debugfs, which won't be available after sysfs mounts again and could cause fails in other tests. # cat /proc/self/mountinfo | grep debugfs 34 23 0:7 / /sys/kernel/debug rw,nosuid,nodev,noexec,relatime shared:14 - debugfs debugfs rw # cat /proc/self/mountinfo | grep sysfs 23 86 0:22 / /sys rw,nosuid,nodev,noexec,relatime shared:2 - sysfs sysfs rw # mount | grep debugfs debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime) # ./test_progs -t tc_redirect #164 tc_redirect:OK Summary: 1/4 PASSED, 0 SKIPPED, 0 FAILED # mount | grep debugfs # cat /proc/self/mountinfo | grep debugfs # cat /proc/self/mountinfo | grep sysfs 25 86 0:22 / /sys rw,relatime shared:2 - sysfs sysfs rw Making the sysfs private under the new namespace so the umount won't trigger the global sysfs umount. Reported-by: Hangbin Liu <[email protected]> Signed-off-by: Jiri Olsa <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Cc: Jussi Maki <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 1674124a885575fcb54d37e7ac90e1e15696b945 Author: Joe Thornber <[email protected]> Date: Fri Dec 10 13:49:53 2021 +0000 dm space map common: add bounds check to sm_ll_lookup_bitmap() [ Upstream commit cba23ac158db7f3cd48a923d6861bee2eb7a2978 ] Corrupted metadata could warrant returning error from sm_ll_lookup_bitmap(). Signed-off-by: Joe Thornber <[email protected]> Signed-off-by: Mike Snitzer <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit b5aee20b53163c9cfa810012ad073a25d96f6161 Author: Joe Thornber <[email protected]> Date: Fri Dec 10 13:44:13 2021 +0000 dm btree: add a defensive bounds check to insert_at() [ Upstream commit 85bca3c05b6cca31625437eedf2060e846c4bbad ] Corrupt metadata could trigger an out of bounds write. Signed-off-by: Joe Thornber <[email protected]> Signed-off-by: Mike Snitzer <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 3c3417b013cf1173d040f5225c918d7ebb4a6643 Author: Ping-Ke Shih <[email protected]> Date: Mon Jan 3 09:36:21 2022 +0800 mac80211: allow non-standard VHT MCS-10/11 [ Upstream commit 04be6d337d37400ad5b3d5f27ca87645ee5a18a3 ] Some AP can possibly try non-standard VHT rate and mac80211 warns and drops packets, and leads low TCP throughput. Rate marked as a VHT rate but data is invalid: MCS: 10, NSS: 2 WARNING: CPU: 1 PID: 7817 at net/mac80211/rx.c:4856 ieee80211_rx_list+0x223/0x2f0 [mac8021 Since commit c27aa56a72b8 ("cfg80211: add VHT rate entries for MCS-10 and MCS-11") has added, mac80211 adds this support as well. After this patch, throughput is good and iw can get the bitrate: rx bitrate: 975.1 MBit/s VHT-MCS 10 80MHz short GI VHT-NSS 2 or rx bitrate: 1083.3 MBit/s VHT-MCS 11 80MHz short GI VHT-NSS 2 Buglink: https://bugzilla.suse.com/show_bug.cgi?id=1192891 Reported-by: Goldwyn Rodrigues <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 2d1c1df9c899075d24bb698d55032cae6ae4c154 Author: Florian Fainelli <[email protected]> Date: Mon Jan 3 11:40:24 2022 -0800 net: mdio: Demote probed message to debug print [ Upstream commit 7590fc6f80ac2cbf23e6b42b668bbeded070850b ] On systems with large numbers of MDIO bus/muxes the message indicating that a given MDIO bus has been successfully probed is repeated for as many buses we have, which can eat up substantial boot time for no reason, demote to a debug print. Reported-by: Maxime Bizon <[email protected]> Signed-off-by: Florian Fainelli <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit a3fdfe36c36a0656749baefefd3b66b6cd63474d Author: Josef Bacik <[email protected]> Date: Fri Nov 5 16:45:35 2021 -0400 btrfs: remove BUG_ON(!eie) in find_parent_nodes [ Upstream commit 9f05c09d6baef789726346397438cca4ec43c3ee ] If we're looking for leafs that point to a data extent we want to record the extent items that point at our bytenr. At this point we have the reference and we know for a fact that this leaf should have a reference to our bytenr. However if there's some sort of corruption we may not find any references to our leaf, and thus could end up with eie == NULL. Replace this BUG_ON() with an ASSERT() and then return -EUCLEAN for the mortals. Signed-off-by: Josef Bacik <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit b667d77ca70cac65a2f7470714b5b255e24bf840 Author: Josef Bacik <[email protected]> Date: Fri Nov 5 16:45:34 2021 -0400 btrfs: remove BUG_ON() in find_parent_nodes() [ Upstream commit fcba0120edf88328524a4878d1d6f4ad39f2ec81 ] We search for an extent entry with .offset = -1, which shouldn't be a thing, but corruption happens. Add an ASSERT() for the developers, return -EUCLEAN for mortals. Signed-off-by: Josef Bacik <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit d70ce75d1d283953062ca96bd1a6830f4f37443c Author: Mario Limonciello <[email protected]> Date: Fri Dec 24 09:04:58 2021 +0800 ACPI: CPPC: Check present CPUs for determining _CPC is valid [ Upstream commit 2aeca6bd02776d7f56a49a32be0dd184f204d888 ] As this is a static check, it should be based upon what is currently present on the system. This makes probeing more deterministic. While local APIC flags field (lapic_flags) of cpu core in MADT table is 0, then the cpu core won't be enabled. In this case, _CPC won't be found in this core, and return back to _CPC invalid with walking through possible cpus (include disable cpus). This is not expected, so switch to check present CPUs instead. Reported-by: Jinzhou Su <[email protected]> Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Huang Rui <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit dd7c1a93025284d244bb5b00108b7417df00e1df Author: Thomas Weißschuh <[email protected]> Date: Wed Dec 22 22:20:14 2021 +0100 ACPI: battery: Add the ThinkPad "Not Charging" quirk [ Upstream commit e96c1197aca628f7d2480a1cc3214912b40b3414 ] The EC/ACPI firmware on Lenovo ThinkPads used to report a status of "Unknown" when the battery is between the charge start and charge stop thresholds. On Windows, it reports "Not Charging" so the quirk has been added to also report correctly. Now the "status" attribute returns "Not Charging" when the battery on ThinkPads is not physicaly charging. Signed-off-by: Thomas Weißschuh <[email protected]> Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit e4066c05d3327b530bb00d11d3492bac1e69982d Author: Marina Nikolic <[email protected]> Date: Tue Dec 14 20:57:53 2021 +0800 amdgpu/pm: Make sysfs pm attributes as read-only for VFs [ Upstream commit 11c9cc95f818f0f187e9b579a7f136f532b42445 ] == Description == Setting values of pm attributes through sysfs should not be allowed in SRIOV mode. These calls will not be processed by FW anyway, but error handling on sysfs level should be improved. == Changes == This patch prohibits performing of all set commands in SRIOV mode on sysfs level. It offers better error handling as calls that are not allowed will not be propagated further. == Test == Writing to any sysfs file in passthrough mode will succeed. Writing to any sysfs file in ONEVF mode will yield error: "calling process does not have sufficient permission to execute a command". Signed-off-by: Marina Nikolic <[email protected]> Acked-by: Evan Quan <[email protected]> Reviewed-by: Lijo Lazar <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 493b87970061f044c5cf795cfd1d679d114844ed Author: Zongmin Zhou <[email protected]> Date: Wed Dec 15 17:23:37 2021 +0800 drm/amdgpu: fixup bad vram size on gmc v8 [ Upstream commit 11544d77e3974924c5a9c8a8320b996a3e9b2f8b ] Some boards(like RX550) seem to have garbage in the upper 16 bits of the vram size register. Check for this and clamp the size properly. Fixes boards reporting bogus amounts of vram. after add this patch,the maximum GPU VRAM size is 64GB, otherwise only 64GB vram size will be used. Signed-off-by: Zongmin Zhou<[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 1ee70b4c5406711c563a8146b96e079592a4e0b9 Author: AngeloGioacchino Del Regno <[email protected]> Date: Thu Dec 16 13:57:44 2021 +0100 mmc: mtk-sd: Use readl_poll_timeout instead of open-coded polling [ Upstream commit ffaea6ebfe9ce06ebb3a54811a47688f2b0893cd ] Replace all instances of open-coded while loops for polling registers with calls to readl_poll_timeout() and, while at it, also fix some possible infinite loop instances. Signed-off-by: AngeloGioacchino Del Regno <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit dcedcbe177397122582e9e09b2ada9fdf9596409 Author: Kirill A. Shutemov <[email protected]> Date: Wed Dec 22 17:33:51 2021 +0100 ACPICA: Hardware: Do not flush CPU cache when entering S4 and S5 [ Upstream commit 1d4e0b3abb168b2ee1eca99c527cffa1b80b6161 ] ACPICA commit 3dd7e1f3996456ef81bfe14cba29860e8d42949e According to ACPI 6.4, Section 16.2, the CPU cache flushing is required on entering to S1, S2, and S3, but the ACPICA code flushes the CPU cache regardless of the sleep state. Blind cache flush on entering S5 causes problems for TDX. Flushing happens with WBINVD that is not supported in the TDX environment. TDX only supports S5 and adjusting ACPICA code to conform to the spec more strictly fixes the issue. Link: https://github.com/acpica/acpica/commit/3dd7e1f3 Signed-off-by: Kirill A. Shutemov <[email protected]> [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Bob Moore <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit a4c7a12027f2fc4dc6346a24fd3ab829e97955a3 Author: Sudeep Holla <[email protected]> Date: Wed Dec 22 17:31:54 2021 +0100 ACPICA: Fix wrong interpretation of PCC address [ Upstream commit 9a3b8655db1ada31c82189ae13f40eb25da48c35 ] ACPICA commit 41be6afacfdaec2dba3a5ed368736babc2a7aa5c With the PCC Opregion in the firmware and we are hitting below kernel crash: -->8 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 Workqueue: pm pm_runtime_work pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __memcpy+0x54/0x260 lr : acpi_ex_write_data_to_field+0xb8/0x194 Call trace: __memcpy+0x54/0x260 acpi_ex_store_object_to_node+0xa4/0x1d4 acpi_ex_store+0x44/0x164 acpi_ex_opcode_1A_1T_1R+0x25c/0x508 acpi_ds_exec_end_op+0x1b4/0x44c acpi_ps_parse_loop+0x3a8/0x614 acpi_ps_parse_aml+0x90/0x2f4 acpi_ps_execute_method+0x11c/0x19c acpi_ns_evaluate+0x1ec/0x2b0 acpi_evaluate_object+0x170/0x2b0 acpi_device_set_power+0x118/0x310 acpi_dev_suspend+0xd4/0x180 acpi_subsys_runtime_suspend+0x28/0x38 __rpm_callback+0x74/0x328 rpm_suspend+0x2d8/0x624 pm_runtime_work+0xa4/0xb8 process_one_work+0x194/0x25c worker_thread+0x260/0x49c kthread+0x14c/0x30c ret_from_fork+0x10/0x20 Code: f9000006 f81f80a7 d65f03c0 361000c2 (b9400026) ---[ end trace 24d8a032fa77b68a ]--- The reason for the crash is that the PCC channel index passed via region.address in acpi_ex_store_object_to_node is interpreted as the channel subtype incorrectly. Assuming the PCC op_region support is not used by any other type, let us remove the subtype check as the AML has no access to the subtype information. Once we remove it, the kernel crash disappears and correctly complains about missing PCC Opregion handler. ACPI Error: No handler for Region [PFRM] ((____ptrval____)) [PCC] (20210730/evregion-130) ACPI Error: Region PCC (ID=10) has no handler (20210730/exfldio-261) ACPI Error: Aborting method \_SB.ETH0._PS3 due to previous error (AE_NOT_EXIST) (20210730/psparse-531) Link: https://github.com/acpica/acpica/commit/41be6afa Signed-off-by: Sudeep Holla <[email protected]> Signed-off-by: Bob Moore <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 2718d4a8d632054c987ee3f9cf465fab8c67e05a Author: Rafael J. Wysocki <[email protected]> Date: Wed Dec 22 17:31:05 2021 +0100 ACPICA: Executer: Fix the REFCLASS_REFOF case in acpi_ex_opcode_1A_0T_1R() [ Upstream commit 24ea5f90ec9548044a6209685c5010edd66ffe8f ] ACPICA commit d984f12041392fa4156b52e2f7e5c5e7bc38ad9e If Operand[0] is a reference of the ACPI_REFCLASS_REFOF class, acpi_ex_opcode_1A_0T_1R () calls acpi_ns_get_attached_object () to obtain return_desc which may require additional resolution with the help of acpi_ex_read_data_from_field (). If the latter fails, the reference counter of the original return_desc is decremented which is incorrect, because acpi_ns_get_attached_object () does not increment the reference counter of the object returned by it. This issue may lead to premature deletion of the attached object while it is still attached and a use-after-free and crash in the host OS. For example, this may happen when on evaluation of ref_of() a local region field where there is no registered handler for the given Operation Region. Fix it by making acpi_ex_opcode_1A_0T_1R () return Status right away after a acpi_ex_read_data_from_field () failure. Link: https://github.com/acpica/acpica/commit/d984f120 Link: https://github.com/acpica/acpica/pull/685 Reported-by: Lenny Szubowicz <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Bob Moore <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 3c3b033d170d93536a5416016e572d46c3a0c7b5 Author: Rafael J. Wysocki <[email protected]> Date: Wed Dec 22 17:29:45 2021 +0100 ACPICA: Utilities: Avoid deleting the same object twice in a row [ Upstream commit 1cdfe9e346b4c5509ffe19ccde880fd259d9f7a3 ] ACPICA commit c11af67d8f7e3d381068ce7771322f2b5324d687 If original_count is 0 in acpi_ut_update_ref_count (), acpi_ut_delete_internal_obj () is invoked for the target object, which is incorrect, because that object has been deleted once already and the memory allocated to store it may have been reclaimed and allocated for a different purpose by the host OS. Moreover, a confusing debug message following the "Reference Count is already zero, cannot decrement" warning is printed in that case. To fix this issue, make acpi_ut_update_ref_count () return after finding that original_count is 0 and printing the above warning. Link: https://github.com/acpica/acpica/commit/c11af67d Link: https://github.com/acpica/acpica/pull/652 Reported-by: Mark Asselstine <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Bob Moore <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 78cc8a75303fadaae15305f60ff6001ff5e08d2c Author: Mark Langsdorf <[email protected]> Date: Wed Dec 22 16:57:34 2021 +0100 ACPICA: actypes.h: Expand the ACPI_ACCESS_ definitions [ Upstream commit f81bdeaf816142e0729eea0cc84c395ec9673151 ] ACPICA commit bc02c76d518135531483dfc276ed28b7ee632ce1 The current ACPI_ACCESS_*_WIDTH defines do not provide a way to test that size is small enough to not cause an overflow when applied to a 32-bit integer. Rather than adding more magic numbers, add ACPI_ACCESS_*_SHIFT, ACPI_ACCESS_*_MAX, and ACPI_ACCESS_*_DEFAULT #defines and redefine ACPI_ACCESS_*_WIDTH in terms of the new #defines. This was inititally reported on Linux where a size of 102 in ACPI_ACCESS_BIT_WIDTH caused an overflow error in the SPCR initialization code. Link: https://github.com/acpica/acpica/commit/bc02c76d Signed-off-by: Mark Langsdorf <[email protected]> Signed-off-by: Bob Moore <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 8c641409536dbcd4e1bf8e3704f85de1fa78b05f Author: Kyeong Yoo <[email protected]> Date: Tue Jul 4 16:22:38 2017 +1200 jffs2: GC deadlock reading a page that is used in jffs2_write_begin() [ Upstream commit aa39cc675799bc92da153af9a13d6f969c348e82 ] GC task can deadlock in read_cache_page() because it may attempt to release a page that is actually allocated by another task in jffs2_write_begin(). The reason is that in jffs2_write_begin() there is a small window a cache page is allocated for use but not set Uptodate yet. This ends up with a deadlock between two tasks: 1) A task (e.g. file copy) - jffs2_write_begin() locks a cache page - jffs2_write_end() tries to lock "alloc_sem" from jffs2_reserve_space() <-- STUCK 2) GC task (jffs2_gcd_mtd3) - jffs2_garbage_collect_pass() locks "alloc_sem" - try to lock the same cache page in read_cache_page() <-- STUCK So to avoid this deadlock, hold "alloc_sem" in jffs2_write_begin() while reading data in a cache page. Signed-off-by: Kyeong Yoo <[email protected]> Signed-off-by: Richard Weinberger <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 46241ec22925290e1f5d894de3ba7280fd4865f2 Author: Lucas Stach <[email protected]> Date: Wed Dec 22 01:17:28 2021 +0100 drm/etnaviv: consider completed fence seqno in hang check [ Upstream commit cdd156955f946beaa5f3a00d8ccf90e5a197becc ] Some GPU heavy test programs manage to trigger the hangcheck quite often. If there are no other GPU users in the system and the test program exhibits a very regular structure in the commandstreams that are being submitted, we can end up with two distinct submits managing to trigger the hangcheck with the FE in a very similar address range. This leads the hangcheck to believe that the GPU is stuck, while in reality the GPU is already busy working on a different job. To avoid those spurious GPU resets, also remember and consider the last completed fence seqno in the hang check. Reported-by: Joerg Albert <[email protected]> Signed-off-by: Lucas Stach <[email protected]> Reviewed-by: Christian Gmeiner <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 2b68b42a5d05b236e0eef29266ca8fa1f92a2d5f Author: Antony Antony <[email protected]> Date: Wed Dec 22 14:11:18 2021 +0100 xfrm: rate limit SA mapping change message to user space [ Upstream commit 4e484b3e969b52effd95c17f7a86f39208b2ccf4 ] Kernel generates mapping change message, XFRM_MSG_MAPPING, when a source port chage is detected on a input state with UDP encapsulation set. Kernel generates a message for each IPsec packet with new source port. For a high speed flow per packet mapping change message can be excessive, and can overload the user space listener. Introduce rate limiting for XFRM_MSG_MAPPING message to the user space. The rate limiting is configurable via netlink, when adding a new SA or updating it. Use the new attribute XFRMA_MTIMER_THRESH in seconds. v1->v2 change: update xfrm_sa_len() v2->v3 changes: use u32 insted unsigned long to reduce size of struct xfrm_state fix xfrm_ompat size Reported-by: kernel test robot <[email protected]> accept XFRM_MSG_MAPPING only when XFRMA_ENCAP is present Co-developed-by: Thomas Egerer <[email protected]> Signed-off-by: Thomas Egerer <[email protected]> Signed-off-by: Antony Antony <[email protected]> Signed-off-by: Steffen Klassert <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 74f1c807c679776da8c13be8ee53e1244eeedb43 Author: Luiz Augusto von Dentz <[email protected]> Date: Wed Dec 22 12:22:01 2021 -0800 Bluetooth: vhci: Set HCI_QUIRK_VALID_LE_STATES [ Upstream commit cfb4c313be670fd4bd09650216620fa4514cdb93 ] This set HCI_QUIRK_VALID_LE_STATES quirk which is required for the likes of experimental LE simultaneous roles. Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit e6e03a16eba4e197b4ec26097664e49f62096d27 Author: Tedd Ho-Jeong An <[email protected]> Date: Mon Dec 13 23:32:14 2021 -0800 Bluetooth: btintel: Add missing quirks and msft ext for legacy bootloader [ Upstream commit 3547a008c8962df2175db1e78b80f27e027ec549 ] This patch add missing HCI quirks and MSFT extension for legacy bootloader when it is running in the operational firmware. Signed-off-by: Tedd Ho-Jeong An <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 0863e7e0ceb5f7dfb09b936c860f8e3404bc0d3b Author: Ben Greear <[email protected]> Date: Thu Sep 3 12:52:54 2020 -0700 ath11k: Fix napi related hang [ Upstream commit d943fdad7589653065be0e20aadc6dff37725ed4 ] Similar to the same bug in ath10k, a napi disable w/out it being enabled will hang forever. I believe I saw this while trying rmmod after driver had some failure on startup. Fix it by keeping state on whether napi is enabled or not. And, remove un-used napi pointer in ath11k driver base struct. Signed-off-by: Ben Greear <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 617a9e6da974aac26523f9ebb5a00f6672cbd60d Author: Randy Dunlap <[email protected]> Date: Sun Sep 12 23:12:52 2021 -0700 um: registers: Rename function names to avoid conflicts and build problems [ Upstream commit 077b7320942b64b0da182aefd83c374462a65535 ] The function names init_registers() and restore_registers() are used in several net/ethernet/ and gpu/drm/ drivers for other purposes (not calls to UML functions), so rename them. This fixes multiple build errors. Signed-off-by: Randy Dunlap <[email protected]> Cc: Jeff Dike <[email protected]> Cc: Richard Weinberger <[email protected]> Cc: Anton Ivanov <[email protected]> Cc: [email protected] Signed-off-by: Richard Weinberger <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit f75868e020a1d03f87d49e9cd2cc349a45249f29 Author: Tetsuo Handa <[email protected]> Date: Fri Dec 17 23:51:25 2021 +0900 block: check minor range in device_add_disk() [ Upstream commit e338924bd05d6e71574bc13e310c89e10e49a8a5 ] ioctl(fd, LOOP_CTL_ADD, 1048576) causes sysfs: cannot create duplicate filename '/dev/block/7:0' message because such request is treated as if ioctl(fd, LOOP_CTL_ADD, 0) due to MINORMASK == 1048575. Verify that all minor numbers for that device fit in the minor range. Reported-by: wangyangbo <[email protected]> Signed-off-by: Tetsuo Handa <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 892805138cb49f0db59c44f38c6998d8a2137fce Author: Hector Martin <[email protected]> Date: Thu Dec 16 01:10:44 2021 +0900 mmc: sdhci-pci-gli: GL9755: Support for CD/WP inversion on OF platforms [ Upstream commit 189f1d9bc3a5ea3e442e119e4a5deda63da8c462 ] This is required on some Apple ARM64 laptops using this controller. As is typical on DT platforms, pull these quirks from the device tree using the standard mmc bindings. See Documentation/devicetree/bindings/mmc/mmc-controller.yaml Acked-by: Adrian Hunter <[email protected]> Signed-off-by: Hector Martin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 0c3f9c13796ea054e4683a506a404168d8456a21 Author: Luca Coelho <[email protected]> Date: Sun Dec 19 13:28:34 2021 +0200 iwlwifi: pcie: make sure prph_info is set when treating wakeup IRQ [ Upstream commit 459fc0f2c6b0f6e280bfa0f230c100c9dfe3a199 ] In some rare cases when the HW is in a bad state, we may get this interrupt when prph_info is not set yet. Then we will try to dereference it to check the sleep_notif element, which will cause an oops. Fix that by ignoring the interrupt if prph_info is not set yet. Signed-off-by: Luca Coelho <[email protected]> Link: https://lore.kernel.org/r/iwlwifi.20211219132536.0537aa562313.I183bb336345b9b3da196ba9e596a6f189fbcbd09@changeid Signed-off-by: Luca Coelho <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit ec53a638c18e087a7b1ffd8008541ff63129e52f Author: Avraham Stern <[email protected]> Date: Sun Dec 19 13:28:31 2021 +0200 iwlwifi: mvm: fix AUX ROC removal [ Upstream commit f0337cb48f3bf5f0bbccc985d8a0a8c4aa4934b7 ] When IWL_UCODE_TLV_CAPA_SESSION_PROT_CMD is set, removing a time event always tries to cancel session protection. However, AUX ROC does not use session protection so it was never removed. As a result, if the driver tries to allocate another AUX ROC event right after cancelling the first one, it will fail with a warning. In addition, the time event data passed to iwl_mvm_remove_aux_roc_te() is incorrect. Fix it. Signed-off-by: Avraham Stern <[email protected]> Signed-off-by: Luca Coelho <[email protected]> Link: https://lore.kernel.org/r/iwlwifi.20211219132536.915e1f69f062.Id837e917f1c2beaca7c1eb33333d622548918a76@changeid Signed-off-by: Luca Coelho <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit abce9e05089e91c1c1008ebfd2bfc3aa0f2e1298 Author: Ilan Peer <[email protected]> Date: Sun Dec 19 12:18:16 2021 +0200 iwlwifi: mvm: Fix calculation of frame length [ Upstream commit 40a0b38d7a7f91a6027287e0df54f5f547e8d27e ] The RADA might include in the Rx frame the MIC and CRC bytes. These bytes should be removed for non monitor interfaces and should not be passed to mac80211. Fix the Rx processing to remove the extra bytes on non monitor cases. Signed-off-by: Ilan Peer <[email protected]> Signed-off-by: Luca Coelho <[email protected]> Link: https://lore.kernel.org/r/iwlwifi.20211219121514.098be12c801e.I1d81733d8a75b84c3b20eb6e0d14ab3405ca6a86@changeid Signed-off-by: Luca Coelho <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 58d53fe49a5dfbd9204c6d605bff4c99f7549256 Author: Johannes Berg <[email protected]> Date: Fri Dec 10 11:12:45 2021 +0200 iwlwifi: remove module loading failure message [ Upstream commit 6518f83ffa51131daaf439b66094f684da3fb0ae ] When CONFIG_DEBUG_TEST_DRIVER_REMOVE is set, iwlwifi crashes when the opmode module cannot be loaded, due to completing the completion before using drv->dev, which can then already be freed. Fix this by removing the (fairly useless) message. Moving the completion later causes a deadlock instead, so that's not an option. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Luca Coelho <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Luca Coelho <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit e23f075d77987de4215c8e0696f28bcc707506f7 Author: Johannes Berg <[email protected]> Date: Fri Dec 10 11:12:42 2021 +0200 iwlwifi: fix leaks/bad data after failed firmware load [ Upstream commit ab07506b0454bea606095951e19e72c282bfbb42 ] If firmware load fails after having loaded some parts of the firmware, e.g. the IML image, then this would leak. For the host command list we'd end up running into a WARN on the next attempt to load another firmware image. Fix this by calling iwl_dealloc_ucode() on failures, and make that also clear the data so we start fresh on the next round. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Luca Coelho <[email protected]> Link: https://lore.kernel.org/r/iwlwifi.20211210110539.1f742f0eb58a.I1315f22f6aa632d94ae2069f85e1bca5e734dce0@changeid Signed-off-by: Luca Coelho <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 73a32ee6daefbcbc2d2a6d20c7c27e06a7441f05 Author: Changcheng Deng <[email protected]> Date: Thu Nov 25 01:43:11 2021 +0000 PM: AVS: qcom-cpr: Use div64_ul instead of do_div [ Upstream commit 92c550f9ffd2884bb5def52b5c0485a35e452784 ] do_div() does a 64-by-32 division. Here the divisor is an unsigned long which on some platforms is 64 bit wide. So use div64_ul instead of do_div to avoid a possible truncation. Reported-by: Zeal Robot <[email protected]> Signed-off-by: Changcheng Deng <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 9a9669e757354d5ab2be775481048ba6591258f5 Author: Po-Hao Huang <[email protected]> Date: Fri Dec 17 09:27:08 2021 +0800 rtw88: 8822c: update rx settings to prevent potential hw deadlock [ Upstream commit c1afb26727d9e507d3e17a9890e7aaf7fc85cd55 ] These settings enables mac to detect and recover when rx fifo circuit deadlock occurs. Previous version missed this, so we fix it. Signed-off-by: Po-Hao Huang <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 38d8d8a882745f87c6a0f54549734241a5818d37 Author: Zekun Shen <[email protected]> Date: Thu Oct 28 18:21:42 2021 -0400 ath9k: Fix out-of-bound memcpy in ath9k_hif_usb_rx_stream [ Upstream commit 6ce708f54cc8d73beca213cec66ede5ce100a781 ] Large pkt_len can lead to out-out-bound memcpy. Current ath9k_hif_usb_rx_stream allows combining the content of two urb inputs to one pkt. The first input can indicate the size of the pkt. Any remaining size is saved in hif_dev->rx_remain_len. While processing the next input, memcpy is used with rx_remain_len. 4-byte pkt_len can go up to 0xffff, while a single input is 0x4000 maximum in size (MAX_RX_BUF_SIZE). Thus, the patch adds a check for pkt_len which must not exceed 2 * MAX_RX_BUG_SIZE. BUG: KASAN: slab-out-of-bounds in ath9k_hif_usb_rx_cb+0x490/0xed7 [ath9k_htc] Read of size 46393 at addr ffff888018798000 by task kworker/0:1/23 CPU: 0 PID: 23 Comm: kworker/0:1 Not tainted 5.6.0 #63 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.10.2-0-g5f4c7b1-prebuilt.qemu-project.org 04/01/2014 Workqueue: events request_firmware_work_func Call Trace: <IRQ> dump_stack+0x76/0xa0 print_address_description.constprop.0+0x16/0x200 ? ath9k_hif_usb_rx_cb+0x490/0xed7 [ath9k_htc] ? ath9k_hif_usb_rx_cb+0x490/0xed7 [ath9k_htc] __kasan_report.cold+0x37/0x7c ? ath9k_hif_usb_rx_cb+0x490/0xed7 [ath9k_htc] kasan_report+0xe/0x20 check_memory_region+0x15a/0x1d0 memcpy+0x20/0x50 ath9k_hif_usb_rx_cb+0x490/0xed7 [ath9k_htc] ? hif_usb_mgmt_cb+0x2d9/0x2d9 [ath9k_htc] ? _raw_spin_lock_irqsave+0x7b/0xd0 ? _raw_spin_trylock_bh+0x120/0x120 ? __usb_unanchor_urb+0x12f/0x210 __usb_hcd_giveback_urb+0x1e4/0x380 usb_giveback_urb_bh+0x241/0x4f0 ? __hrtimer_run_queues+0x316/0x740 ? __usb_hcd_giveback_urb+0x380/0x380 tasklet_action_common.isra.0+0x135/0x330 __do_softirq+0x18c/0x634 irq_exit+0x114/0x140 smp_apic_timer_interrupt+0xde/0x380 apic_timer_interrupt+0xf/0x20 I found the bug using a custome USBFuzz port. It's a research work to fuzz USB stack/drivers. I modified it to fuzz ath9k driver only, providing hand-crafted usb descriptors to QEMU. After fixing the value of pkt_tag to ATH_USB_RX_STREAM_MODE_TAG in QEMU emulation, I found the KASAN report. The bug is triggerable whenever pkt_len is above two MAX_RX_BUG_SIZE. I used the same input that crashes to test the driver works when applying the patch. Signed-off-by: Zekun Shen <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 735aefae7b68025cd04c482a940c0f6fc6797a63 Author: Tetsuo Handa <[email protected]> Date: Tue Sep 21 22:06:26 2021 +0900 ath9k_htc: fix NULL pointer dereference at ath9k_htc_tx_get_packet() [ Upstream commit 8b3046abc99eefe11438090bcc4ec3a3994b55d0 ] syzbot is reporting lockdep warning at ath9k_wmi_event_tasklet() followed by kernel panic at get_htc_epid_queue() from ath9k_htc_tx_get_packet() from ath9k_htc_txstatus() [1], for ath9k_wmi_event_tasklet(WMI_TXSTATUS_EVENTID) depends on spin_lock_init() from ath9k_init_priv() being already completed. Since ath9k_wmi_event_tasklet() is set by ath9k_init_wmi() from ath9k_htc_probe_device(), it is possible that ath9k_wmi_event_tasklet() is called via tasklet interrupt before spin_lock_init() from ath9k_init_priv() from ath9k_init_device() from ath9k_htc_probe_device() is called. Let's hold ath9k_wmi_event_tasklet(WMI_TXSTATUS_EVENTID) no-op until ath9k_tx_init() completes. Link: https://syzkaller.appspot.com/bug?extid=31d54c60c5b254d6f75b [1] Reported-by: syzbot <[email protected]> Signed-off-by: Tetsuo Handa <[email protected]> Tested-by: syzbot <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 6eedec710840104c190f51d45a57daf34216b90e Author: Tetsuo Handa <[email protected]> Date: Tue Sep 21 22:06:23 2021 +0900 ath9k_htc: fix NULL pointer dereference at ath9k_htc_rxep() [ Upstream commit b0ec7e55fce65f125bd1d7f02e2dc4de62abee34 ] syzbot is reporting lockdep warning followed by kernel panic at ath9k_htc_rxep() [1], for ath9k_htc_rxep() depends on ath9k_rx_init() being already completed. Since ath9k_htc_rxep() is set by ath9k_htc_connect_svc(WMI_BEACON_SVC) from ath9k_init_htc_services(), it is possible that ath9k_htc_rxep() is called via timer interrupt before ath9k_rx_init() from ath9k_init_device() is called. Since we can't call ath9k_init_device() before ath9k_init_htc_services(), let's hold ath9k_htc_rxep() no-op until ath9k_rx_init() completes. Link: https://syzkaller.appspot.com/bug?extid=4d2d56175b934b9a7bf9 [1] Reported-by: syzbot <[email protected]> Signed-off-by: Tetsuo Handa <[email protected]> Tested-by: syzbot <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 243ab93501e6fc13d376673e26ab240a82bbcffa Author: Felix Fietkau <[email protected]> Date: Thu Nov 25 10:42:12 2021 +0100 mt76: mt7615: improve wmm index allocation [ Upstream commit 70fb028707c8871ef9e56b3ffa3d895e14956cc4 ] Typically all AP interfaces on a PHY will share the same WMM settings, while sta/mesh interfaces will usually inherit the settings from a remote device. In order minimize the likelihood of conflicting WMM settings, make all AP interfaces share one slot, and all non-AP interfaces another one. This also fixes running multiple AP interfaces on MT7613, which only has 3 WMM slots. Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 9d39145c49d09a8c2dcfd7b1aea162ee960b25b2 Author: Xing Song <[email protected]> Date: Fri Nov 19 14:37:06 2021 +0800 mt76: do not pass the received frame with decryption error [ Upstream commit dd28dea52ad9376d2b243a8981726646e1f60b1a ] MAC80211 doesn't care any decryption error in 802.3 path, so received frame will be dropped if HW tell us that the cipher configuration is not matched as well as the header has been translated to 802.3. This case only appears when IEEE80211_FCTL_PROTECTED is 0 and cipher suit is not none in the corresponding HW entry. The received frame is only reported to monitor interface if HW decryption block tell us there is ICV error or CCMP/BIP/WPI MIC error. Note in this case the reported frame is decrypted 802.11 frame and the payload may be malformed due to mismatched key. Signed-off-by: Xing Song <[email protected]> Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 3a1ef2b1233879e6ceb42b5ad33403c173a68d20 Author: Peter Chiu <[email protected]> Date: Mon Nov 1 10:01:13 2021 +0800 mt76: mt7615: fix possible deadlock while mt7615_register_ext_phy() [ Upstream commit 8c55516de3f9b76b9d9444e7890682ec2efc809f ] ieee80211_register_hw() is called with rtnl_lock held, and this could be caused lockdep from a work item that's on a workqueue that is flushed with the rtnl held. Move mt7615_register_ext_phy() outside the init_work(). Signed-off-by: Peter Chiu <[email protected]> Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit a09dc6c4638f92ad8046bbbd9df8dbde23ec426a Author: Kai-Heng Feng <[email protected]> Date: Wed Dec 15 20:01:06 2021 +0800 usb: hub: Add delay for SuperSpeed hub resume to let links transit to U0 [ Upstream commit 00558586382891540c59c9febc671062425a6e47 ] When a new USB device gets plugged to nested hubs, the affected hub, which connects to usb 2-1.4-port2, doesn't report there's any change, hence the nested hubs go back to runtime suspend like nothing happened: [ 281.032951] usb usb2: usb wakeup-resume [ 281.032959] usb usb2: usb auto-resume [ 281.032974] hub 2-0:1.0: hub_resume [ 281.033011] usb usb2-port1: status 0263 change 0000 [ 281.033077] hub 2-0:1.0: state 7 ports 4 chg 0000 evt 0000 [ 281.049797] usb 2-1: usb wakeup-resume [ 281.069800] usb 2-1: Waited 0ms for CONNECT [ 281.069810] usb 2-1: finish resume [ 281.070026] hub 2-1:1.0: hub_resume [ 281.070250] usb 2-1-port4: status 0203 change 0000 [ 281.070272] usb usb2-port1: resume, status 0 [ 281.070282] hub 2-1:1.0: state 7 ports 4 chg 0010 evt 0000 [ 281.089813] usb 2-1.4: usb wakeup-resume [ 281.109792] usb 2-1.4: Waited 0ms for CONNECT [ 281.109801] usb 2-1.4: finish resume [ 281.109991] hub 2-1.4:1.0: hub_resume [ 281.110147] usb 2-1.4-port2: status 0263 change 0000 [ 281.110234] usb 2-1-port4: resume, status 0 [ 281.110239] usb 2-1-port4: status 0203, change 0000, 10.0 Gb/s [ 281.110266] hub 2-1.4:1.0: state 7 ports 4 chg 0000 evt 0000 [ 281.110426] hub 2-1.4:1.0: hub_suspend [ 281.110565] usb 2-1.4: usb auto-suspend, wakeup 1 [ 281.130998] hub 2-1:1.0: hub_suspend [ 281.137788] usb 2-1: usb auto-suspend, wakeup 1 [ 281.142935] hub 2-0:1.0: state 7 ports 4 chg 0000 evt 0000 [ 281.177828] usb 2-1: usb wakeup-resume [ 281.197839] usb 2-1: Waited 0ms for CONNECT [ 281.197850] usb 2-1: finish resume [ 281.197984] hub 2-1:1.0: hub_resume [ 281.198203] usb 2-1-port4: status 0203 change 0000 [ 281.198228] usb usb2-port1: resume, status 0 [ 281.198237] hub 2-1:1.0: state 7 ports 4 chg 0010 evt 0000 [ 281.217835] usb 2-1.4: usb wakeup-resume [ 281.237834] usb 2-1.4: Waited 0ms for CONNECT [ 281.237845] usb 2-1.4: finish resume [ 281.237990] hub 2-1.4:1.0: hub_resume [ 281.238067] usb 2-1.4-port2: status 0263 change 0000 [ 281.238148] usb 2-1-port4: resume, status 0 [ 281.238152] usb 2-1-port4: status 0203, change 0000, 10.0 Gb/s [ 281.238166] hub 2-1.4:1.0: state 7 ports 4 chg 0000 evt 0000 [ 281.238385] hub 2-1.4:1.0: hub_suspend [ 281.238523] usb 2-1.4: usb auto-suspend, wakeup 1 [ 281.258076] hub 2-1:1.0: hub_suspend [ 281.265744] usb 2-1: usb auto-suspend, wakeup 1 [ 281.285976] hub 2-0:1.0: hub_suspend [ 281.285988] usb usb2: bus auto-suspend, wakeup 1 USB 3.2 spec, 9.2.5.4 "Changing Function Suspend State" says that "If the link is in a non-U0 state, then the device must transition the link to U0 prior to sending the remote wake message", but the hub only transits the link to U0 after signaling remote wakeup. So be more forgiving and use a 20ms delay to let the link transit to U0 for remote wakeup. Suggested-by: Alan Stern <[email protected]> Acked-by: Alan Stern <[email protected]> Signed-off-by: Kai-Heng Feng <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 79235edc66cbb891a845b4b7d9f210ae6bd18057 Author: Rafael J. Wysocki <[email protected]> Date: Thu Dec 16 20:32:15 2021 +0100 cpufreq: Fix initialization of min and max frequency QoS requests [ Upstream commit 521223d8b3ec078f670c7c35a1a04b1b2af07966 ] The min and max frequency QoS requests in the cpufreq core are initialized to whatever the current min and max frequency values are at the init time, but if any of these values change later (for example, cpuinfo.max_freq is updated by the driver), these initial request values will be limiting the CPU frequency unnecessarily unless they are changed by user space via sysfs. To address this, initialize min_freq_req and max_freq_req to FREQ_QOS_MIN_DEFAULT_VALUE and FREQ_QOS_MAX_DEFAULT_VALUE, respectively, so they don't really limit anything until user space updates them. Reported-by: Srinivas Pandruvada <[email protected]> Tested-by: Srinivas Pandruvada <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit fddbdd20c8e0bbc813bebebf82216a9bef22d29a Author: Rafael J. Wysocki <[email protected]> Date: Fri Dec 10 17:10:13 2021 +0100 PM: runtime: Add safety net to supplier device release [ Upstream commit d1579e61192e0e686faa4208500ef4c3b529b16c ] Because refcount_dec_not_one() returns true if the target refcount becomes saturated, it is generally unsafe to use its return value as a loop termination condition, but that is what happens when a device link's supplier device is released during runtime PM suspend operations and on device link removal. To address this, introduce pm_runtime_release_supplier() to be used in the above cases which will check the supplier device's runtime PM usage counter in addition to the refcount_dec_not_one() return value, so the loop can be terminated in case the rpm_active refcount value becomes invalid, and update the code in question to use it as appropriate. This change is not expected to have any visible functional impact. Reported-by: Peter Zijlstra <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Acked-by: Greg Kroah-Hartman <[email protected]> Acked-by: Peter Zijlstra (Intel) <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 4586d164c319a81aa98169bb863de5c3112f13e5 Author: Weili Qian <[email protected]> Date: Sat Dec 11 16:17:19 2021 +0800 crypto: hisilicon/hpre - fix memory leak in hpre_curve25519_src_init() [ Upstream commit 51fa916b81e5f406a74f14a31a3a228c3cc060ad ] hpre_curve25519_src_init() allocates memory for 'ptr' before calling memcmp(). If memcmp() returns 0, the function will return '-EINVAL' without freeing memory. Signed-off-by: Weili Qian <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit c0713b3017a8057819173830dc273c8fec4b0b77 Author: Peter Gonda <[email protected]> Date: Tue Dec 7 15:33:03 2021 -0800 crypto: ccp - Move SEV_INIT retry for corrupted data [ Upstream commit e423b9d75e779d921e6adf5ac3d0b59400d6ba7e ] Move the data corrupted retry of SEV_INIT into the __sev_platform_init_locked() function. This is for upcoming INIT_EX support as well as helping direct callers of __sev_platform_init_locked() which currently do not support the retry. Signed-off-by: Peter Gonda <[email protected]> Reviewed-by: Marc Orr <[email protected]> Acked-by: David Rientjes <[email protected]> Acked-by: Tom Lendacky <[email protected]> Acked-by: Brijesh Singh <[email protected]> Cc: Tom Lendacky <[email protected]> Cc: Brijesh Singh <[email protected]> Cc: Marc Orr <[email protected]> Cc: Joerg Roedel <[email protected]> Cc: Herbert Xu <[email protected]> Cc: David Rientjes <[email protected]> Cc: John Allen <[email protected]> Cc: "David S. Miller" <[email protected]> Cc: Paolo Bonzini <[email protected]> Cc: [email protected] Cc: [email protected] Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit a8186a100978cbae3266facef51b4c66e12608fa Author: Thierry Reding <[email protected]> Date: Tue Dec 7 14:28:29 2021 +0100 arm64: tegra: Adjust length of CCPLEX cluster MMIO region [ Upstream commit 2b14cbd643feea5fc17c6e8bead4e71088c69acd ] The Tegra186 CCPLEX cluster register region is 4 MiB is length, not 4 MiB - 1. This was likely presumed to be the "limit" rather than length. Fix it up. Signed-off-by: Thierry Reding <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 77e5d1974a1baa433b47b2f6e576112b77f4621f Author: Biwen Li <[email protected]> Date: Tue Dec 14 03:32:38 2021 -0600 arm64: dts: ls1028a-qds: move rtc node to the correct i2c bus [ Upstream commit cbe9d948eadfe352ad45495a7cc5bf20a1b29d90 ] The i2c rtc is on i2c2 bus not i2c1 bus, so fix it in dts. Signed-off-by: Biwen Li <[email protected]> Signed-off-by: Li Yang <[email protected]> Signed-off-by: Shawn Guo <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit d978295bb551ba98a92c6cd0d0edfdf5cd2e082f Author: Paul Moore <[email protected]> Date: Mon Dec 13 15:45:20 2021 -0500 audit: ensure userspace is penalized the same as the kernel when under pressure [ Upstream commit 8f110f530635af44fff1f4ee100ecef0bac62510 ] Due to the audit control mutex necessary for serializing audit userspace messages we haven't been able to block/penalize userspace processes that attempt to send audit records while the system is under audit pressure. The result is that privileged userspace applications have a priority boost with respect to audit as they are not bound by the same audit queue throttling as the other tasks on the system. This patch attempts to restore some balance to the system when under audit pressure by blocking these privileged userspace tasks after they have finished their audit processing, and dropped the audit control mutex, but before they return to userspace. Reported-by: Gaosheng Cui <[email protected]> Tested-by: Gaosheng Cui <[email protected]> Reviewed-by: Richard Guy Briggs <[email protected]> Signed-off-by: Paul Moore <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 305f07b93d34d292432251e9963bf232db38d67a Author: Jingwen Chen <[email protected]> Date: Tue Dec 14 11:50:39 2021 +0800 drm/amd/amdgpu: fix gmc bo pin count leak in SRIOV [ Upstream commit 948e7ce01413b71395723aaf846015062aea3a43 ] [Why] gmc bo will be pinned during loading amdgpu and reset in SRIOV while only unpinned in unload amdgpu [How] add amdgpu_in_reset and sriov judgement to skip pin bo v2: fix wrong judgement Signed-off-by: Jingwen Chen <[email protected]> Reviewed-by: Horace Chen <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 8662d0c6a36807093aed34b17b930484fd4bf22f Author: Jingwen Chen <[email protected]> Date: Tue Dec 14 11:31:16 2021 +0800 drm/amd/amdgpu: fix psp tmr bo pin count leak in SRIOV [ Upstream commit 85dfc1d692c9434c37842e610be37cd4ae4e0081 ] [Why] psp tmr bo will be pinned during loading amdgpu and reset in SRIOV while only unpinned in unload amdgpu [How] add amdgpu_in_reset and sriov judgement to skip pin bo v2: fix wrong judgement Signed-off-by: Jingwen Chen <[email protected]> Reviewed-by: Horace Chen <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 29d6a92af56d953e238869834b860d6be00f61ed Author: Ulf Hansson <[email protected]> Date: Wed Nov 10 18:17:09 2021 +0100 mmc: core: Fixup storing of OCR for MMC_QUIRK_NONSTD_SDIO [ Upstream commit 8c3e5b74b9e2146f564905e50ca716591c76d4f1 ] The mmc core takes a specific path to support initializing of a non-standard SDIO card. This is triggered by looking for the card-quirk, MMC_QUIRK_NONSTD_SDIO. In mmc_sdio_init_card() this gets rather messy, as it causes the code to bail out earlier, compared to the usual path. This leads to that the OCR doesn't get saved properly in card->ocr. Fortunately, only omap_hsmmc has been using the MMC_QUIRK_NONSTD_SDIO and is dealing with the issue, by assigning a hardcoded value (0x80) to card->ocr from an ->init_card() ops. To make the behaviour consistent, let's instead rely on the core to save the OCR in card->ocr during initialization. Reported-by: H. Nikolaus Schaller <[email protected]> Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: H. Nikolaus Schaller <[email protected]> Link: https://lore.kernel.org/r/e7936cff7fc24d187ef2680d3b4edb0ade58f293.1636564631.git.hns@goldelico.com Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 384a5e27a44f4bc76815a18391751d2243e91c21 Author: Biju Das <[email protected]> Date: Wed Nov 3 13:26:46 2021 +0100 mmc: tmio: reinit card irqs in reset routine [ Upstream commit e315b1f3a170f368da5618f8a598e68880302ed1 ] Refactor the code so that card detect irqs are always reenabled after a reset. This avoids doing it manually all over the code or forgetting to do this in the future. Reported-by: Wolfram Sang <[email protected]> Signed-off-by: Biju Das <[email protected]> [wsa: added a comment when 'native_hotplug' has to be set] Signed-off-by: Wolfram Sang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit c3d14b3585b78a007ee99066698655662c61e4bd Author: Zhou Qingyang <[email protected]> Date: Fri Dec 3 16:40:30 2021 +0100 media: saa7146: hexium_gemini: Fix a NULL pointer dereference in hexium_attach() [ Upstream commit 3af86b046933ba513d08399dba0d4d8b50d607d0 ] In hexium_attach(dev, info), saa7146_vv_init() is called to allocate a new memory for dev->vv_data. saa7146_vv_release() will be called on failure of saa7146_register_device(). There is a dereference of dev->vv_data in saa7146_vv_release(), which could lead to a NULL pointer dereference on failure of saa7146_vv_init(). Fix this bug by adding a check of saa7146_vv_init(). This bug was found by a static analyzer. The analysis employs differential checking to identify inconsistent security operations (e.g., checks or kfrees) between two code paths and confirms that the inconsistent operations are not recovered in the current function or the callers, so they constitute bugs. Note that, as a bug found by static analysis, it can be a false positive or hard to trigger. Multiple researchers have cross-reviewed the bug. Builds with CONFIG_VIDEO_HEXIUM_GEMINI=m show no new warnings, and our static analyzer no longer warns about this code. Link: https://lore.kernel.org/linux-media/[email protected] Signed-off-by: Zhou Qingyang <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 84155d2b06060e13655495d295f70d39f5dd7144 Author: Mikhail Rudenko <[email protected]> Date: Sun Oct 10 19:54:57 2021 +0200 media: rockchip: rkisp1: use device name for debugfs subdir name [ Upstream commit c2611e479f5d9b05108270e1ab423955486b4457 ] While testing Rockchip RK3399 with both ISPs enabled, a dmesg error was observed: ``` [ 15.559141] debugfs: Directory 'rkisp1' with parent '/' already present! ``` Fix it by using the device name for the debugfs subdirectory name instead of the driver name, thus preventing name collision. Link: https://lore.kernel.org/linux-media/[email protected] Signed-off-by: Mikhail Rudenko <[email protected]> Reviewed-by: Ezequiel Garcia <[email protected]> Reviewed-by: Kieran Bingham <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 87d0b8170234464822eb5cad16552145c5801faf Author: Sean Young <[email protected]> Date: Tue Nov 30 23:58:19 2021 +0100 media: igorplugusb: receiver overflow should be reported [ Upstream commit 8fede658e7ddb605bbd68ed38067ddb0af033db4 ] Without this, some IR will be missing mid-stream and we might decode something which never really occurred. Signed-off-by: Sean Young <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 26d516434d1c4af2e49305676612cdc81fe5b8a4 Author: Alistair Francis <[email protected]> Date: Wed Dec 8 22:40:44 2021 +1000 HID: i2c-hid-of: Expose the touchscreen-inverted properties [ Upstream commit b60d3c803d7603432a08aeaf988aff53b3a5ec64 ] Allow the touchscreen-inverted-x/y device tree properties to control the HID_QUIRK_X_INVERT/HID_QUIRK_Y_INVERT quirks for the hid-input device. Signed-off-by: Alistair Francis <[email protected]> Acked-by: Rob Herring <[email protected]> [bentiss: silence checkpatch warnings] Signed-off-by: Benjamin Tissoires <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit bc13af2535e550e2b7d0c6b57ca7549aa495425f Author: Alistair Francis <[email protected]> Date: Wed Dec 8 22:40:43 2021 +1000 HID: quirks: Allow inverting the absolute X/Y values [ Upstream commit fd8d135b2c5e88662f2729e034913f183455a667 ] Add a HID_QUIRK_X_INVERT/HID_QUIRK_Y_INVERT quirk that can be used to invert the X/Y values. Signed-off-by: Alistair Francis <[email protected]> [bentiss: silence checkpatch warning] Signed-off-by: Benjamin Tissoires <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 4a635b9d5ba5f691e378f7ec20e11b7b04f07a45 Author: Felix Kuehling <[email protected]> Date: Tue Dec 7 20:23:14 2021 -0500 drm/amdkfd: Fix error handling in svm_range_add [ Upstream commit 726be40607264b180a2b336c81e1dcff941de618 ] Add null-pointer check after the last svm_range_new call. This was originally reported by Zhou Qingyang <[email protected]> based on a static analyzer. To avoid duplicating the unwinding code from svm_range_handle_overlap, I merged the two functions into one. Signed-off-by: Felix Kuehling <[email protected]> Cc: Zhou Qingyang <[email protected]> Reviewed-by: Philip Yang <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 684815ff760b6d997d8f4c1a4b5cb7173dacc42f Author: Paolo Abeni <[email protected]> Date: Tue Nov 30 11:08:06 2021 +0100 bpf: Do not WARN in bpf_warn_invalid_xdp_action() [ Upstream commit 2cbad989033bff0256675c38f96f5faab852af4b ] The WARN_ONCE() in bpf_warn_invalid_xdp_action() can be triggered by any bugged program, and even attaching a correct program to a NIC not supporting the given action. The resulting splat, beyond polluting the logs, fouls automated tools: e.g. a syzkaller reproducers using an XDP program returning an unsupported action will never pass validation. Replace the WARN_ONCE with a less intrusive pr_warn_once(). Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Acked-by: Toke Høiland-Jørgensen <[email protected]> Link: https://lore.kernel.org/bpf/016ceec56e4817ebb2a9e35ce794d5c917df572c.1638189075.git.pabeni@redhat.com Signed-off-by: Sasha Levin <[email protected]> commit 451ee28aed9d02c54b12c8b8e845d9a0463c84f9 Author: David Gow <[email protected]> Date: Tue Nov 2 00:30:13 2021 -0700 kunit: Don't crash if no parameters are generated [ Upstream commit 37dbb4c7c7442dbfc9b651e4ddd4afe30b26afc9 ] It's possible that a parameterised test could end up with zero parameters. At the moment, the test function will nevertheless be called with NULL as the parameter. Instead, don't try to run the test code, and just mark the test as SKIPped. Reported-by: Daniel Latypov <[email protected]> Signed-off-by: David Gow <[email protected]> Reviewed-by: Daniel Latypov <[email protected]> Reviewed-by: Brendan Higgins <[email protected]> Signed-off-by: Shuah Khan <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 584d9e3e74590ce9f0a6f422feb9d64241ed7f99 Author: Suresh Kumar <[email protected]> Date: Mon Dec 13 11:17:09 2021 +0530 net: bonding: debug: avoid printing debug logs when bond is not notifying peers [ Upstream commit fee32de284ac277ba434a2d59f8ce46528ff3946 ] Currently "bond_should_notify_peers: slave ..." messages are printed whenever "bond_should_notify_peers" function is called. +++ Dec 12 12:33:26 node1 kernel: bond0: bond_should_notify_peers: slave enp0s25 Dec 12 12:33:26 node1 kernel: bond0: bond_should_notify_peers: slave enp0s25 Dec 12 12:33:26 node1 kernel: bond0: bond_should_notify_peers: slave enp0s25 Dec 12 12:33:26 node1 kernel: bond0: (slave enp0s25): Received LACPDU on port 1 Dec 12 12:33:26 node1 kernel: bond0: (slave enp0s25): Rx Machine: Port=1, Last State=6, Curr State=6 Dec 12 12:33:26 node1 kernel: bond0: (slave enp0s25): partner sync=1 Dec 12 12:33:26 node1 kernel: bond0: bond_should_notify_peers: slave enp0s25 Dec 12 12:33:26 node1 kernel: bond0: bond_should_notify_peers: slave enp0s25 Dec 12 12:33:26 node1 kernel: bond0: bond_should_notify_peers: slave enp0s25 ... Dec 12 12:33:30 node1 kernel: bond0: bond_should_notify_peers: slave enp0s25 Dec 12 12:33:30 node1 kernel: bond0: bond_should_notify_peers: slave enp0s25 Dec 12 12:33:30 node1 kernel: bond0: (slave enp4s3): Received LACPDU on port 2 Dec 12 12:33:30 node1 kernel: bond0: (slave enp4s3): Rx Machine: Port=2, Last State=6, Curr State=6 Dec 12 12:33:30 node1 kernel: bond0: (slave enp4s3): partner sync=1 Dec 12 12:33:30 node1 kernel: bond0: bond_should_notify_peers: slave enp0s25 Dec 12 12:33:30 node1 kernel: bond0: bond_should_notify_peers: slave enp0s25 Dec 12 12:33:30 node1 kernel: bond0: bond_should_notify_peers: slave enp0s25 +++ This is confusing and can also clutter up debug logs. Print logs only when the peer notification happens. Signed-off-by: Suresh Kumar <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 0f962554d016ba305f6ebe14f07e2d34a314706b Author: Borislav Petkov <[email protected]> Date: Tue Nov 2 11:14:48 2021 +0100 x86/mce: Mark mce_read_aux() noinstr [ Upstream commit db6c996d6ce45dfb44891f0824a65ecec216f47a ] Fixes vmlinux.o: warning: objtool: do_machine_check()+0x681: call to mce_read_aux() leaves .noinstr.text section Signed-off-by: Borislav Petkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit b26d3a8f826df29c01f27bbb05932fc899c8e271 Author: Borislav Petkov <[email protected]> Date: Mon Nov 1 16:43:33 2021 +0100 x86/mce: Mark mce_end() noinstr [ Upstream commit b4813539d37fa31fed62cdfab7bd2dd8929c5b2e ] It is called by the #MC handler which is noinstr. Fixes vmlinux.o: warning: objtool: do_machine_check()+0xbd6: call to memset() leaves .noinstr.text section Signed-off-by: Borislav Petkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit f166c0b3ac1cd033b419372acc6f12c612351de6 Author: Borislav Petkov <[email protected]> Date: Mon Nov 1 13:39:35 2021 +0100 x86/mce: Mark mce_panic() noinstr [ Upstream commit 3c7ce80a818fa7950be123cac80cd078e5ac1013 ] And allow instrumentation inside it because it does calls to other facilities which will not be tagged noinstr. Fixes vmlinux.o: warning: objtool: do_machine_check()+0xc73: call to mce_panic() leaves .noinstr.text section Signed-off-by: Borislav Petkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit f2bde2aeb1aea77b56d151b293a03cd5b1a19d07 Author: Borislav Petkov <[email protected]> Date: Wed Oct 13 09:07:19 2021 +0200 x86/mce: Allow instrumentation during task work queueing [ Upstream commit 4fbce464db81a42f9a57ee242d6150ec7f996415 ] Fixes vmlinux.o: warning: objtool: do_machine_check()+0xdb1: call to queue_task_work() leaves .noinstr.text section Signed-off-by: Borislav Petkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 3903e62795309c8cd041191f506941aa3fe2c548 Author: Alex Elder <[email protected]> Date: Fri Dec 10 16:31:22 2021 -0600 ARM: dts: qcom: sdx55: fix IPA interconnect definitions [ Upstream commit c0d6316c238b1bd743108bd4b08eda364f47c7c9 ] The first two interconnects defined for IPA on the SDX55 SoC are really two parts of what should be represented as a single path between IPA and system memory. Fix this by combining the "memory-a" and "memory-b" interconnects into a single "memory" interconnect. Reported-by: David Heidelberg <[email protected]> Tested-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Alex Elder <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit f6d165a8fa04ecf29b87d2ace13e2bd2439658c8 Author: Baochen Qiang <[email protected]> Date: Thu Dec 9 09:19:49 2021 +0800 ath11k: Avoid false DEADLOCK warning reported by lockdep [ Upstream commit 767c94caf0efad136157110787fe221b74cb5c8a ] With CONFIG_LOCKDEP=y and CONFIG_DEBUG_SPINLOCK=y, lockdep reports below warning: [ 166.059415] ============================================ [ 166.059416] WARNING: possible recursive locking detected [ 166.059418] 5.15.0-wt-ath+ #10 Tainted: G W O [ 166.059420] -------------------------------------------- [ 166.059421] kworker/0:2/116 is trying to acquire lock: [ 166.059423] ffff9905f2083160 (&srng->lock){+.-.}-{2:2}, at: ath11k_hal_reo_cmd_send+0x20/0x490 [ath11k] [ 166.059440] but task is already holding lock: [ 166.059442] ffff9905f2083230 (&srng->lock){+.-.}-{2:2}, at: ath11k_dp_process_reo_status+0x95/0x2d0 [ath11k] [ 166.059491] other info that might help us debug this: [ 166.059492] Possible unsafe locking scenario: [ 166.059493] CPU0 [ 166.059494] ---- [ 166.059495] lock(&srng->lock); [ 166.059498] lock(&srng->lock); [ 166.059500] *** DEADLOCK *** [ 166.059501] May be due to missing lock nesting notation [ 166.059502] 3 locks held by kworker/0:2/116: [ 166.059504] #0: ffff9905c0081548 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x1f6/0x660 [ 166.059511] #1: ffff9d2400a5fe68 ((debug_obj_work).work){+.+.}-{0:0}, at: process_one_work+0x1f6/0x660 [ 166.059517] #2: ffff9905f2083230 (&srng->lock){+.-.}-{2:2}, at: ath11k_dp_process_reo_status+0x95/0x2d0 [ath11k] [ 166.059532] stack backtrace: [ 166.059534] CPU: 0 PID: 116 Comm: kworker/0:2 Kdump: loaded Tainted: G W O 5.15.0-wt-ath+ #10 [ 166.059537] Hardware name: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0059.2019.1112.1124 11/12/2019 [ 166.059539] Workqueue: events free_obj_work [ 166.059543] Call Trace: [ 166.059545] <IRQ> [ 166.059547] dump_stack_lvl+0x56/0x7b [ 166.059552] __lock_acquire+0xb9a/0x1a50 [ 166.059556] lock_acquire+0x1e2/0x330 [ 166.059560] ? ath11k_hal_reo_cmd_send+0x20/0x490 [ath11k] [ 166.059571] _raw_spin_lock_bh+0x33/0x70 [ 166.059574] ? ath11k_hal_reo_cmd_send+0x20/0x490 [ath11k] [ 166.059584] ath11k_hal_reo_cmd_send+0x20/0x490 [ath11k] [ 166.059594] ath11k_dp_tx_send_reo_cmd+0x3f/0x130 [ath11k] [ 166.059605] ath11k_dp_rx_tid_del_func+0x221/0x370 [ath11k] [ 166.059618] ath11k_dp_process_reo_status+0x22f/0x2d0 [ath11k] [ 166.059632] ? ath11k_dp_service_srng+0x2ea/0x2f0 [ath11k] [ 166.059643] ath11k_dp_service_srng+0x2ea/0x2f0 [ath11k] [ 166.059655] ath11k_pci_ext_grp_napi_poll+0x1c/0x70 [ath11k_pci] [ 166.059659] __napi_poll+0x28/0x230 [ 166.059664] net_rx_action+0x285/0x310 [ 166.059668] __do_softirq+0xe6/0x4d2 [ 166.059672] irq_exit_rcu+0xd2/0xf0 [ 166.059675] common_interrupt+0xa5/0xc0 [ 166.059678] </IRQ> [ 166.059679] <TASK> [ 166.059680] asm_common_interrupt+0x1e/0x40 [ 166.059683] RIP: 0010:_raw_spin_unlock_irqrestore+0x38/0x70 [ 166.059686] Code: 83 c7 18 e8 2a 95 43 ff 48 89 ef e8 22 d2 43 ff 81 e3 00 02 00 00 75 25 9c 58 f6 c4 02 75 2d 48 85 db 74 01 fb bf 01 00 00 00 <e8> 63 2e 40 ff 65 8b 05 8c 59 97 5c 85 c0 74 0a 5b 5d c3 e8 00 6a [ 166.059689] RSP: 0018:ffff9d2400a5fca0 EFLAGS: 00000206 [ 166.059692] RAX: 0000000000000002 RBX: 0000000000000200 RCX: 0000000000000006 [ 166.059694] RDX: 0000000000000000 RSI: ffffffffa404879b RDI: 0000000000000001 [ 166.059696] RBP: ffff9905c0053000 R08: 0000000000000001 R09: 0000000000000001 [ 166.059698] R10: ffff9d2400a5fc50 R11: 0000000000000001 R12: ffffe186c41e2840 [ 166.059700] R13: 0000000000000001 R14: ffff9905c78a1c68 R15: 0000000000000001 [ 166.059704] free_debug_processing+0x257/0x3d0 [ 166.059708] ? free_obj_work+0x1f5/0x250 [ 166.059712] __slab_free+0x374/0x5a0 [ 166.059718] ? kmem_cache_free+0x2e1/0x370 [ 166.059721] ? free_obj_work+0x1f5/0x250 [ 166.059724] kmem_cache_free+0x2e1/0x370 [ 166.059727] free_obj_work+0x1f5/0x250 [ 166.059731] process_one_work+0x28b/0x660 [ 166.059735] ? process_one_work+0x660/0x660 [ 166.059738] worker_thread+0x37/0x390 [ 166.059741] ? process_one_work+0x660/0x660 [ 166.059743] kthread+0x176/0x1a0 [ 166.059746] ? set_kthread_struct+0x40/0x40 [ 166.059749] ret_from_fork+0x22/0x30 [ 166.059754] </TASK> Since these two lockes are both initialized in ath11k_hal_srng_setup, they are assigned with the same key. As a result lockdep suspects that the task is trying to acquire the same lock (due to same key) while already holding it, and thus reports the DEADLOCK warning. However as they are different spinlock instances, the warning is false positive. On the other hand, even no dead lock indeed, this is a major issue for upstream regression testing as it disables lockdep functionality. Fix it by assigning separate lock class key for each srng->lock. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Signed-off-by: Baochen Qiang <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 271842c326bb18fd7bb8f90c34c8a03e7783e5b9 Author: Heiko Carstens <[email protected]> Date: Tue Nov 30 13:25:46 2021 +0100 selftests/ftrace: make kprobe profile testcase description unique [ Upstream commit e5992f373c6eed6d09e5858e9623df1259b3ce30 ] Commit 32f6e5da83c7 ("selftests/ftrace: Add kprobe profile testcase") added a new kprobes testcase, but has a description which does not describe what the test case is doing and is duplicating the description of another test case. Therefore change the test case description, so it is unique and then allows easily to tell which test case actually passed or failed. Reported-by: Alexander Egorenkov <[email protected]> Signed-off-by: Heiko Carstens <[email protected]> Acked-by: Masami Hiramatsu <[email protected]> Signed-off-by: Shuah Khan <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 8bb1290e90504203c2909113e1af1828948b1b7a Author: Iwona Winiarska <[email protected]> Date: Sat Dec 4 18:10:27 2021 +0100 gpio: aspeed-sgpio: Convert aspeed_sgpio.lock to raw_spinlock [ Upstream commit ab39d6988dd53f354130438d8afa5596a2440fed ] The gpio-aspeed-sgpio driver implements an irq_chip which need to be invoked from hardirq context. Since spin_lock() can sleep with PREEMPT_RT, it is no longer legal to invoke it while interrupts are disabled. This also causes lockdep to complain about: [ 25.919465] [ BUG: Invalid wait context ] because aspeed_sgpio.lock (spin_lock_t) is taken under irq_desc.lock (raw_spinlock_t). Let's use of raw_spinlock_t instead of spinlock_t. Signed-off-by: Iwona Winiarska <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit d9332eab23381364b70e13eb17e7bf0a709504c5 Author: Iwona Winiarska <[email protected]> Date: Sat Dec 4 18:10:26 2021 +0100 gpio: aspeed: Convert aspeed_gpio.lock to raw_spinlock [ Upstream commit 61a7904b6ace99b1bde0d0e867fa3097f5c8cee2 ] The gpio-aspeed driver implements an irq_chip which need to be invoked from hardirq context. Since spin_lock() can sleep with PREEMPT_RT, it is no longer legal to invoke it while interrupts are disabled. This also causes lockdep to complain about: [ 0.649797] [ BUG: Invalid wait context ] because aspeed_gpio.lock (spin_lock_t) is taken under irq_desc.lock (raw_spinlock_t). Let's use of raw_spinlock_t instead of spinlock_t. Signed-off-by: Iwona Winiarska <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 3c2a24aa3412660b63041014864c53a6a5860f15 Author: Russell King (Oracle) <[email protected]> Date: Wed Dec 8 11:36:30 2021 +0000 net: phy: prefer 1000baseT over 1000baseKX [ Upstream commit f20f94f7f52c4685c81754f489ffcc72186e8bdb ] The PHY settings table is supposed to be sorted by descending match priority - in other words, earlier entries are preferred over later entries. The order of 1000baseKX/Full and 1000baseT/Full is such that we prefer 1000baseKX/Full over 1000baseT/Full, but 1000baseKX/Full is a lot rarer than 1000baseT/Full, and thus is much less likely to be preferred. This causes phylink problems - it means a fixed link specifying a speed of 1G and full duplex gets an ethtool linkmode of 1000baseKX/Full rather than 1000baseT/Full as would be expected - and since we offer userspace a software emulation of a conventional copper PHY, we want to offer copper modes in preference to anything else. However, we do still want to allow the rarer modes as well. Hence, let's reorder these two modes to prefer copper. Tested-by: Tom Lendacky <[email protected]> Signed-off-by: Russell King (Oracle) <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Reported-by: Florian Fainelli <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 0abd3f9903fae6ecf8db3c89a459971fe7925499 Author: Antoine Tenart <[email protected]> Date: Tue Dec 7 15:57:24 2021 +0100 net-sysfs: update the queue counts in the unregistration path [ Upstream commit d7dac083414eb5bb99a6d2ed53dc2c1b405224e5 ] When updating Rx and Tx queue kobjects, the queue count should always be updated to match the queue kobjects count. This was not done in the net device unregistration path, fix it. Tracking all queue count updates will allow in a following up patch to detect illegal updates. Signed-off-by: Antoine Tenart <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit f7bae4d4595dee71ae08738149d9c0096f45c391 Author: Sebastian Gottschall <[email protected]> Date: Wed May 5 15:58:06 2021 +0700 ath10k: Fix tx hanging [ Upstream commit e8a91863eba3966a447d2daa1526082d52b5db2a ] While running stress tests in roaming scenarios (switching ap's every 5 seconds, we discovered a issue which leads to tx hangings of exactly 5 seconds while or after scanning for new accesspoints. We found out that this hanging is triggered by ath10k_mac_wait_tx_complete since the empty_tx_wq was not wake when the num_tx_pending counter reaches zero. To fix this, we simply move the wake_up call to htt_tx_dec_pending, since this call was missed on several locations within the ath10k code. Signed-off-by: Sebastian Gottschall <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 21b07b470a4077ab6e8f13e0af6abf89ca6a4de9 Author: Wen Gong <[email protected]> Date: Tue Dec 7 17:23:36 2021 +0200 ath11k: avoid deadlock by change ieee80211_queue_work for regd_update_work [ Upstream commit ed05c7cf1286d7e31e7623bce55ff135723591bf ] When enable debug config, it print below warning while shut down wlan interface shuh as run "ifconfig wlan0 down". The reason is because ar->regd_update_work is ran once, and it is will call wiphy_lock(ar->hw->wiphy) in function ath11k_regd_update() which is running in workqueue of ieee80211_local queued by ieee80211_queue_work(). Another thread from "ifconfig wlan0 down" will also accuqire the lock by wiphy_lock(sdata->local->hw.wiphy) in function ieee80211_stop(), and then it call ieee80211_stop_device() to flush_workqueue(local->workqueue), this will wait the workqueue of ieee80211_local finished. Then deadlock will happen easily if the two thread run meanwhile. Below warning disappeared after this change. [ 914.088798] ath11k_pci 0000:05:00.0: mac remove interface (vdev 0) [ 914.088806] ath11k_pci 0000:05:00.0: mac stop 11d scan [ 914.088810] ath11k_pci 0000:05:00.0: mac stop 11d vdev id 0 [ 914.088827] ath11k_pci 0000:05:00.0: htc ep 2 consumed 1 credits (total 0) [ 914.088841] ath11k_pci 0000:05:00.0: send 11d scan stop vdev id 0 [ 914.088849] ath11k_pci 0000:05:00.0: htc insufficient credits ep 2 required 1 available 0 [ 914.088856] ath11k_pci 0000:05:00.0: htc insufficient credits ep 2 required 1 available 0 [ 914.096434] ath11k_pci 0000:05:00.0: rx ce pipe 2 len 16 [ 914.096442] ath11k_pci 0000:05:00.0: htc ep 2 got 1 credits (total 1) [ 914.096481] ath11k_pci 0000:05:00.0: htc ep 2 consumed 1 credits (total 0) [ 914.096491] ath11k_pci 0000:05:00.0: WMI vdev delete id 0 [ 914.111598] ath11k_pci 0000:05:00.0: rx ce pipe 2 len 16 [ 914.111628] ath11k_pci 0000:05:00.0: htc ep 2 got 1 credits (total 1) [ 914.114659] ath11k_pci 0000:05:00.0: rx ce pipe 2 len 20 [ 914.114742] ath11k_pci 0000:05:00.0: htc rx completion ep 2 skb pK-error [ 914.115977] ath11k_pci 0000:05:00.0: vdev delete resp for vdev id 0 [ 914.116685] ath11k_pci 0000:05:00.0: vdev 00:03:7f:29:61:11 deleted, vdev_id 0 [ 914.117583] ====================================================== [ 914.117592] WARNING: possible circular locking dependency detected [ 914.117600] 5.16.0-rc1-wt-ath+ #1 Tainted: G OE [ 914.117611] ------------------------------------------------------ [ 914.117618] ifconfig/2805 is trying to acquire lock: [ 914.117628] ffff9c00a62bb548 ((wq_completion)phy0){+.+.}-{0:0}, at: flush_workqueue+0x87/0x470 [ 914.117674] but task is already holding lock: [ 914.117682] ffff9c00baea07d0 (&rdev->wiphy.mtx){+.+.}-{4:4}, at: ieee80211_stop+0x38/0x180 [mac80211] [ 914.117872] which lock already depends on the new lock. [ 914.117880] the existing dependency chain (in reverse order) is: [ 914.117888] -> #3 (&rdev->wiphy.mtx){+.+.}-{4:4}: [ 914.117910] __mutex_lock+0xa0/0x9c0 [ 914.117930] mutex_lock_nested+0x1b/0x20 [ 914.117944] reg_process_self_managed_hints+0x3a/0xb0 [cfg80211] [ 914.118093] wiphy_regulatory_register+0x47/0x80 [cfg80211] [ 914.118229] wiphy_register+0x84f/0x9c0 [cfg80211] [ 914.118353] ieee80211_register_hw+0x6b1/0xd90 [mac80211] [ 914.118486] ath11k_mac_register+0x6af/0xb60 [ath11k] [ 914.118550] ath11k_core_qmi_firmware_ready+0x383/0x4a0 [ath11k] [ 914.118598] ath11k_qmi_driver_event_work+0x347/0x4a0 [ath11k] [ 914.118656] process_one_work+0x228/0x670 [ 914.118669] worker_thread+0x4d/0x440 [ 914.118680] kthread+0x16d/0x1b0 [ 914.118697] ret_from_fork+0x22/0x30 [ 914.118714] -> #2 (rtnl_mutex){+.+.}-{4:4}: [ 914.118736] __mutex_lock+0xa0/0x9c0 [ 914.118751] mutex_lock_nested+0x1b/0x20 [ 914.118767] rtnl_lock+0x17/0x20 [ 914.118783] ath11k_regd_update+0x15a/0x260 [ath11k] [ 914.118841] ath11k_regd_update_work+0x15/0x20 [ath11k] [ 914.118897] process_one_work+0x228/0x670 [ 914.118909] worker_thread+0x4d/0x440 [ 914.118920] kthread+0x16d/0x1b0 [ 914.118934] ret_from_fork+0x22/0x30 [ 914.118948] -> #1 ((work_completion)(&ar->regd_update_work)){+.+.}-{0:0}: [ 914.118972] process_one_work+0x1fa/0x670 [ 914.118984] worker_thread+0x4d/0x440 [ 914.118996] kthread+0x16d/0x1b0 [ 914.119010] ret_from_fork+0x22/0x30 [ 914.119023] -> #0 ((wq_completion)phy0){+.+.}-{0:0}: [ 914.119045] __lock_acquire+0x146d/0x1cf0 [ 914.119057] lock_acquire+0x19b/0x360 [ 914.119067] flush_workqueue+0xae/0x470 [ 914.119084] ieee80211_stop_device+0x3b/0x50 [mac80211] [ 914.119260] ieee80211_do_stop+0x5d7/0x830 [mac80211] [ 914.119409] ieee80211_stop+0x45/0x180 [mac80211] [ 914.119557] __dev_close_many+0xb3/0x120 [ 914.119573] __dev_change_flags+0xc3/0x1d0 [ 914.119590] dev_change_flags+0x29/0x70 [ 914.119605] devinet_ioctl+0x653/0x810 [ 914.119620] inet_ioctl+0x193/0x1e0 [ 914.119631] sock_do_ioctl+0x4d/0xf0 [ 914.119649] sock_ioctl+0x262/0x340 [ 914.119665] __x64_sys_ioctl+0x96/0xd0 [ 914.119678] do_syscall_64+0x3d/0xd0 [ 914.119694] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 914.119709] other info that might help us debug this: [ 914.119717] Chain exists of: (wq_completion)phy0 --> rtnl_mutex --> &rdev->wiphy.mtx [ 914.119745] Possible unsafe locking scenario: [ 914.119752] CPU0 CPU1 [ 914.119758] ---- ---- [ 914.119765] lock(&rdev->wiphy.mtx); [ 914.119778] lock(rtnl_mutex); [ 914.119792] lock(&rdev->wiphy.mtx); [ 914.119807] lock((wq_completion)phy0); [ 914.119819] *** DEADLOCK *** [ 914.119827] 2 locks held by ifconfig/2805: [ 914.119837] #0: ffffffffba3dc010 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_lock+0x17/0x20 [ 914.119872] #1: ffff9c00baea07d0 (&rdev->wiphy.mtx){+.+.}-{4:4}, at: ieee80211_stop+0x38/0x180 [mac80211] [ 914.120039] stack backtrace: [ 914.120048] CPU: 0 PID: 2805 Comm: ifconfig Tainted: G OE 5.16.0-rc1-wt-ath+ #1 [ 914.120064] Hardware name: LENOVO 418065C/418065C, BIOS 83ET63WW (1.33 ) 07/29/2011 [ 914.120074] Call Trace: [ 914.120084] <TASK> [ 914.120094] dump_stack_lvl+0x73/0xa4 [ 914.120119] dump_stack+0x10/0x12 [ 914.120135] print_circular_bug.isra.44+0x221/0x2e0 [ 914.120165] check_noncircular+0x106/0x150 [ 914.120203] __lock_acquire+0x146d/0x1cf0 [ 914.120215] ? __lock_acquire+0x146d/0x1cf0 [ 914.120245] lock_acquire+0x19b/0x360 [ 914.120259] ? flush_workqueue+0x87/0x470 [ 914.120286] ? lockdep_init_map_type+0x6b/0x250 [ 914.120310] flush_workqueue+0xae/0x470 [ 914.120327] ? flush_workqueue+0x87/0x470 [ 914.120344] ? lockdep_hardirqs_on+0xd7/0x150 [ 914.120391] ieee80211_stop_device+0x3b/0x50 [mac80211] [ 914.120565] ? ieee80211_stop_device+0x3b/0x50 [mac80211] [ 914.120736] ieee80211_do_stop+0x5d7/0x830 [mac80211] [ 914.120906] ieee80211_stop+0x45/0x180 [mac80211] [ 914.121060] __dev_close_many+0xb3/0x120 [ 914.121081] __dev_change_flags+0xc3/0x1d0 [ 914.121109] dev_change_flags+0x29/0x70 [ 914.121131] devinet_ioctl+0x653/0x810 [ 914.121149] ? __might_fault+0x77/0x80 [ 914.121179] inet_ioctl+0x193/0x1e0 [ 914.121194] ? inet_ioctl+0x193/0x1e0 [ 914.121218] ? __might_fault+0x77/0x80 [ 914.121238] ? _copy_to_user+0x68/0x80 [ 914.121266] sock_do_ioctl+0x4d/0xf0 [ 914.121283] ? inet_stream_connect+0x60/0x60 [ 914.121297] ? sock_do_ioctl+0x4d/0xf0 [ 914.121329] sock_ioctl+0x262/0x340 [ 914.121347] ? sock_ioctl+0x262/0x340 [ 914.121362] ? exit_to_user_mode_prepare+0x13b/0x280 [ 914.121388] ? syscall_enter_from_user_mode+0x20/0x50 [ 914.121416] __x64_sys_ioctl+0x96/0xd0 [ 914.121430] ? br_ioctl_call+0x90/0x90 [ 914.121445] ? __x64_sys_ioctl+0x96/0xd0 [ 914.121465] do_syscall_64+0x3d/0xd0 [ 914.121482] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 914.121497] RIP: 0033:0x7f0ed051737b [ 914.121513] Code: 0f 1e fa 48 8b 05 15 3b 0d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e5 3a 0d 00 f7 d8 64 89 01 48 [ 914.121527] RSP: 002b:00007fff7be38b98 EFLAGS: 00000202 ORIG_RAX: 0000000000000010 [ 914.121544] RAX: ffffffffffffffda RBX: 00007fff7be38ba0 RCX: 00007f0ed051737b [ 914.121555] RDX: 00007fff7be38ba0 RSI: 0000000000008914 RDI: 0000000000000004 [ 914.121566] RBP: 00007fff7be38c60 R08: 000000000000000a R09: 0000000000000001 [ 914.121576] R10: 0000000000000000 R11: 0000000000000202 R12: 00000000fffffffe [ 914.121586] R13: 0000000000000004 R14: 0000000000000000 R15: 0000000000000000 [ 914.121620] </TASK> Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Signed-off-by: Wen Gong <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit bcf404b305f43c7ee93a2c24e4a4b049d81327cb Author: Wander Lairson Costa <[email protected]> Date: Wed Nov 10 11:37:45 2021 -0300 rcutorture: Avoid soft lockup during cpu stall [ Upstream commit 5ff7c9f9d7e3e0f6db5b81945fa11b69d62f433a ] If we use the module stall_cpu option, we may get a soft lockup warning in case we also don't pass the stall_cpu_block option. Introduce the stall_no_softlockup option to avoid a soft lockup on cpu stall even if we don't use the stall_cpu_block option. Signed-off-by: Wander Lairson Costa <[email protected]> Signed-off-by: Paul E. McKenney <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit d63ddcee9ff3454a14f440ae684afcdbdc03fcf3 Author: Shaul Triebitz <[email protected]> Date: Sat Dec 4 13:10:47 2021 +0200 iwlwifi: mvm: avoid clearing a just saved session protection id [ Upstream commit 8e967c137df3b236d2075f9538cb888129425d1a ] When scheduling a session protection the id is saved but then it may be cleared when calling iwl_mvm_te_clear_data (if a previous session protection is currently active). Fix it by saving the id after calling iwl_mvm_te_clear_data. Signed-off-by: Shaul Triebitz <[email protected]> Signed-off-by: Luca Coelho <[email protected]> Link: https://lore.kernel.org/r/iwlwifi.20211204130722.b0743a588d14.I098fef6677d0dab3ef1b6183ed206a10bab01eb2@changeid Signed-off-by: Luca Coelho <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 59b49457fbd870b4d033159698c452f7248b57b1 Author: Johannes Berg <[email protected]> Date: Sat Dec 4 08:35:45 2021 +0200 iwlwifi: mvm: synchronize with FW after multicast commands [ Upstream commit db66abeea3aefed481391ecc564fb7b7fb31d742 ] If userspace installs a lot of multicast groups very quickly, then we may run out of command queue space as we send the updates in an asynchronous fashion (due to locking concerns), and the CPU can create them faster than the firmware can process them. This is true even when mac80211 has a work struct that gets scheduled. Fix this by synchronizing with the firmware after sending all those commands - outside of the iteration we can send a synchronous echo command that just has the effect of the CPU waiting for the prior asynchronous commands to finish. This also will cause fewer of the commands to be sent to the firmware overall, because the work will only run once when rescheduled multiple times while it's running. Link: https://bugzilla.kernel.org/show_bug.cgi?id=213649 Suggested-by: Emmanuel Grumbach <[email protected]> Reported-by: Maximilian Ernestus <[email protected]> Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Luca Coelho <[email protected]> Link: https://lore.kernel.org/r/iwlwifi.20211204083238.51aea5b79ea4.I88a44798efda16e9fe480fb3e94224931d311b29@changeid Signed-off-by: Luca Coelho <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit b52954c7798ecc2b833a68d20181e5efa5561453 Author: Kieran Bingham <[email protected]> Date: Thu Nov 4 22:40:25 2021 +0000 arm64: dts: renesas: Fix thermal bindings [ Upstream commit 82ce79391d0ec25ec8aaae3c0617b71048ff0836 ] The binding node names for the thermal zones are not successfully validated by the dt-schemas. Fix the validation by changing from sensor-thermalN or thermal-sensor-N to sensorN-thermal. Provide node labels of the form sensorN_thermal to ensure consistency with the other platform implementations. Signed-off-by: Kieran Bingham <[email protected]> Reviewed-by: Niklas Söderlund <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 2f804823b5b75b4b1b8d8a8fc14114e3bb8ca635 Author: Mika Westerberg <[email protected]> Date: Sun Nov 14 16:07:11 2021 +0200 thunderbolt: Runtime PM activate both ends of the device link [ Upstream commit f3380cac0c0b3a6f49ab161e2a057c363962f48d ] If protocol tunnels are already up when the driver is loaded, for instance if the boot firmware implements connection manager of its own, runtime PM reference count of the consumer devices behind the tunnel might have been increased already before the device link is created but the supplier device runtime PM reference count is not. This leads to a situation where the supplier (the Thunderbolt driver) can runtime suspend even if it should not because the corresponding protocol tunnel needs to be up causing the devices to be removed from the corresponding native bus. Prevent this from happening by making both sides of the link runtime PM active briefly. The pm_runtime_put() for the consumer (PCIe root/downstream port, xHCI) then allows it to runtime suspend again but keeps the supplier runtime resumed the whole time it is runtime active. Signed-off-by: Mika Westerberg <[email protected]> Reviewed-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 0c044e39d52abfbb4cb43dbc5a09c1dc1ed24648 Author: Mauro Carvalho Chehab <[email protected]> Date: Mon Dec 6 15:34:19 2021 +0100 media: m920x: don't use stack on USB reads [ Upstream commit a2ab06d7c4d6bfd0b545a768247a70463e977e27 ] Using stack-allocated pointers for USB message data don't work. This driver is almost OK with that, except for the I2C read logic. Fix it by using a temporary read buffer, just like on all other calls to m920x_read(). Link: https://lore.kernel.org/all/[email protected]/ Reported-by: [email protected] Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 6aaff2d7c9d52ae523ca318639c7dc74e751dc88 Author: Tsuchiya Yuto <[email protected]> Date: Wed Dec 1 15:19:04 2021 +0100 media: atomisp: fix "variable dereferenced before check 'asd'" [ Upstream commit ac56760a8bbb4e654b2fd54e5de79dd5d72f937d ] There are two occurrences where the variable 'asd' is dereferenced before check. Fix this issue by using the variable after the check. Link: https://lore.kernel.org/linux-media/20211122074122.GA6581@kili/ Link: https://lore.kernel.org/linux-media/[email protected] Reported-by: Dan Carpenter <[email protected]> Signed-off-by: Tsuchiya Yuto <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit a2e962b2d8b072f965abbd3b2f37984f0e7b2714 Author: Zhou Qingyang <[email protected]> Date: Tue Nov 30 17:25:49 2021 +0100 media: saa7146: hexium_orion: Fix a NULL pointer dereference in hexium_attach() [ Upstream commit 348df8035301dd212e3cc2860efe4c86cb0d3303 ] In hexium_attach(dev, info), saa7146_vv_init() is called to allocate a new memory for dev->vv_data. In hexium_detach(), saa7146_vv_release() will be called and there is a dereference of dev->vv_data in saa7146_vv_release(), which could lead to a NULL pointer dereference on failure of saa7146_vv_init() according to the following logic. Both hexium_attach() and hexium_detach() are callback functions of the variable 'extension', so there exists a possible call chain directly from hexium_attach() to hexium_detach(): hexium_attach(dev, info) -- fail to alloc memory to dev->vv_data | in saa7146_vv_init(). | | hexium_detach() -- a dereference of dev->vv_data in saa7146_vv_release() Fix this bug by adding a check of saa7146_vv_init(). This bug was found by a static analyzer. The analysis employs differential checking to identify inconsistent security operations (e.g., checks or kfrees) between two code paths and confirms that the inconsistent operations are not recovered in the current function or the callers, so they constitute bugs. Note that, as a bug found by static analysis, it can be a false positive or hard to trigger. Multiple researchers have cross-reviewed the bug. Builds with CONFIG_VIDEO_HEXIUM_ORION=m show no new warnings, and our static analyzer no longer warns about this code. Signed-off-by: Zhou Qingyang <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit d747b4831d5f1e16a8377b8895c1fb4ec419ca25 Author: Niklas Söderlund <[email protected]> Date: Fri Nov 26 00:02:57 2021 +0100 media: rcar-vin: Update format alignment constraints [ Upstream commit da6911f330d40cfe115a37249e47643eff555e82 ] This change fixes two issues with the size constraints for buffers. - There is no width alignment constraint for RGB formats. Prior to this change they were treated as YUV and as a result were more restricted than needed. Add a new check to differentiate between the two. - The minimum width and height supported is 5x2, not 2x4, this is an artifact from the driver's soc-camera days. Fix this incorrect assumption. Signed-off-by: Niklas Söderlund <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 1c9bbda87cdc199e18a04c656e326eec140838ee Author: James Hilliard <[email protected]> Date: Sun Nov 14 09:52:36 2021 +0100 media: uvcvideo: Increase UVC_CTRL_CONTROL_TIMEOUT to 5 seconds. [ Upstream commit c8ed7d2f614cd8b315981d116c7a2fb01829500d ] Some uvc devices appear to require the maximum allowed USB timeout for GET_CUR/SET_CUR requests. So lets just bump the UVC control timeout to 5 seconds which is the same as the usb ctrl get/set defaults: USB_CTRL_GET_TIMEOUT 5000 USB_CTRL_SET_TIMEOUT 5000 It fixes the following runtime warnings: Failed to query (GET_CUR) UVC control 11 on unit 2: -110 (exp. 1). Failed to query (SET_CUR) UVC control 3 on unit 2: -110 (exp. 2). Signed-off-by: James Hilliard <[email protected]> Signed-off-by: Laurent Pinchart <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 4d6a98ce80f6fd34f8c3034602bc53e219b6d9f1 Author: Laurent Pinchart <[email protected]> Date: Mon Nov 29 03:10:46 2021 +0200 drm: rcar-du: Fix CRTC timings when CMM is used [ Upstream commit f0ce591dc9a97067c6e783a2eaccd22c5476144d ] When the CMM is enabled, an offset of 25 pixels must be subtracted from the HDS (horizontal display start) and HDE (horizontal display end) registers. Fix the timings calculation, and take this into account in the mode validation. This fixes a visible horizontal offset in the image with VGA monitors. HDMI monitors seem to be generally more tolerant to incorrect timings, but may be affected too. Signed-off-by: Laurent Pinchart <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 30bd6733ef960e02fcbac7f2bedb9df1830a5a7d Author: Joerg Roedel <[email protected]> Date: Thu Dec 2 16:32:25 2021 +0100 x86/mm: Flush global TLB when switching to trampoline page-table [ Upstream commit 71d5049b053876afbde6c3273250b76935494ab2 ] Move the switching code into a function so that it can be re-used and add a global TLB flush. This makes sure that usage of memory which is not mapped in the trampoline page-table is reliably caught. Also move the clearing of CR4.PCIDE before the CR3 switch because the cr4_clear_bits() function will access data not mapped into the trampoline page-table. Signed-off-by: Joerg Roedel <[email protected]> Signed-off-by: Borislav Petkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 1b4422befeba0cb77149ca6a0907077f65f788d1 Author: Xiongwei Song <[email protected]> Date: Tue Nov 16 21:10:33 2021 +0800 floppy: Add max size check for user space request [ Upstream commit 545a32498c536ee152331cd2e7d2416aa0f20e01 ] We need to check the max request size that is from user space before allocating pages. If the request size exceeds the limit, return -EINVAL. This check can avoid the warning below from page allocator. WARNING: CPU: 3 PID: 16525 at mm/page_alloc.c:5344 current_gfp_context include/linux/sched/mm.h:195 [inline] WARNING: CPU: 3 PID: 16525 at mm/page_alloc.c:5344 __alloc_pages+0x45d/0x500 mm/page_alloc.c:5356 Modules linked in: CPU: 3 PID: 16525 Comm: syz-executor.3 Not tainted 5.15.0-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 RIP: 0010:__alloc_pages+0x45d/0x500 mm/page_alloc.c:5344 Code: be c9 00 00 00 48 c7 c7 20 4a 97 89 c6 05 62 32 a7 0b 01 e8 74 9a 42 07 e9 6a ff ff ff 0f 0b e9 a0 fd ff ff 40 80 e5 3f eb 88 <0f> 0b e9 18 ff ff ff 4c 89 ef 44 89 e6 45 31 ed e8 1e 76 ff ff e9 RSP: 0018:ffffc90023b87850 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 1ffff92004770f0b RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000033 RDI: 0000000000010cc1 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000001 R10: ffffffff81bb4686 R11: 0000000000000001 R12: ffffffff902c1960 R13: 0000000000000033 R14: 0000000000000000 R15: ffff88804cf64a30 FS: 0000000000000000(0000) GS:ffff88802cd00000(0063) knlGS:00000000f44b4b40 CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033 CR2: 000000002c921000 CR3: 000000004f507000 CR4: 0000000000150ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> alloc_pages+0x1a7/0x300 mm/mempolicy.c:2191 __get_free_pages+0x8/0x40 mm/page_alloc.c:5418 raw_cmd_copyin drivers/block/floppy.c:3113 [inline] raw_cmd_ioctl drivers/block/floppy.c:3160 [inline] fd_locked_ioctl+0x12e5/0x2820 drivers/block/floppy.c:3528 fd_ioctl drivers/block/floppy.c:3555 [inline] fd_compat_ioctl+0x891/0x1b60 drivers/block/floppy.c:3869 compat_blkdev_ioctl+0x3b8/0x810 block/ioctl.c:662 __do_compat_sys_ioctl+0x1c7/0x290 fs/ioctl.c:972 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0x65/0xf0 arch/x86/entry/common.c:178 do_fast_syscall_32+0x2f/0x70 arch/x86/entry/common.c:203 entry_SYSENTER_compat_after_hwframe+0x4d/0x5c Reported-by: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Xiongwei Song <[email protected]> Signed-off-by: Denis Efremov <[email protected]> Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit eeefb3436d42d5ee8186adee8855c1cd27c9fb95 Author: Neal Liu <[email protected]> Date: Fri Nov 26 18:00:21 2021 +0800 usb: uhci: add aspeed ast2600 uhci support [ Upstream commit 554abfe2eadec97d12c71d4a69da1518478f69eb ] Enable ast2600 uhci quirks. Signed-off-by: Neal Liu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 750f28d69b99a3584c809918f280b6c55842eae2 Author: Kishon Vijay Abraham I <[email protected]> Date: Fri Nov 26 14:15:55 2021 +0530 arm64: dts: ti: j721e-main: Fix 'dtbs_check' in serdes_ln_ctrl node [ Upstream commit 3f92a5be6084b77f764a8bbb881ac0d12cb9e863 ] Fix 'dtbs_check' in serdes_ln_ctrl (mux@4080) node by changing the node name to mux-controller@4080. Signed-off-by: Kishon Vijay Abraham I <[email protected]> Reviewed-by: Aswath Govindraju <[email protected]> Signed-off-by: Vignesh Raghavendra <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit e785275d780e4034c73234cbd9fdd5a0fa40ee26 Author: Kishon Vijay Abraham I <[email protected]> Date: Fri Nov 26 14:15:54 2021 +0530 arm64: dts: ti: j7200-main: Fix 'dtbs_check' serdes_ln_ctrl node [ Upstream commit 4d3984906397581dc0ccb6a02bf16b6ff82c9192 ] Fix 'dtbs_check' in serdes_ln_ctrl (serdes-ln-ctrl@4080) node by changing the node name to mux-controller@4080. Signed-off-by: Kishon Vijay Abraham I <[email protected]> Reviewed-by: Aswath Govindraju <[email protected]> Signed-off-by: Vignesh Raghavendra <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 94168f47f9b15284ffb14a8cce23e8fe3b0fe939 Author: Hans de Goede <[email protected]> Date: Mon Nov 22 18:05:33 2021 +0100 ACPI / x86: Add not-present quirk for the PCI0.SDHB.BRC1 device on the GPD win [ Upstream commit 57d2dbf710d832841872fb15ebb79429cab90fae ] The GPD win and its sibling the GPD pocket (99% the same electronics in a different case) use a PCI wifi card. But the ACPI tables on both variants contain a bug where the SDIO MMC controller for SDIO wifi cards is enabled despite this. This SDIO MMC controller has a PCI0.SDHB.BRC1 child-device which _PS3 method sets a GPIO causing the PCI wifi card to turn off. At the moment there is a pretty ugly kludge in the sdhci-acpi.c code, just to work around the bug in the DSDT of this single design. This can be solved cleaner/simply with a quirk overriding the _STA return of the broken PCI0.SDHB.BRC1 PCI0.SDHB.BRC1 child with a status value of 0, so that its power_manageable flag gets cleared, avoiding this problem. Note that even though it is not used, the _STA method for the MMC controller is deliberately not overridden. If the status of the MMC controller were forced to 0 it would never get suspended, which would cause these mini-laptops to not reach S0i3 level when suspended. Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 10f2c10c0e2073a17f10d5929425a079a8f32827 Author: Hans de Goede <[email protected]> Date: Mon Nov 22 18:05:32 2021 +0100 ACPI / x86: Allow specifying acpi_device_override_status() quirks by path [ Upstream commit ba46e42e925b5d09b4e441f8de3db119cc7df58f ] Not all ACPI-devices have a HID + UID, allow specifying quirks for acpi_device_override_status() by path too. Note this moves the path/HID+UID check to after the CPU + DMI checks since the path lookup is somewhat costly. This way this lookup is only done on devices where the other checks match. Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 91f918b7885fb7757bf498a310cc65d71d3e6f72 Author: Hans de Goede <[email protected]> Date: Mon Nov 22 18:05:31 2021 +0100 ACPI: Change acpi_device_always_present() into acpi_device_override_status() [ Upstream commit 1a68b346a2c9969c05e80a3b99a9ab160b5655c0 ] Currently, acpi_bus_get_status() calls acpi_device_always_present() to allow platform quirks to override the _STA return to report that a device is present (status = ACPI_STA_DEFAULT) independent of the _STA return. In some cases it might also be useful to have the opposite functionality and have a platform quirk which marks a device as not present (status = 0) to work around ACPI table bugs. Change acpi_device_always_present() into a more generic acpi_device_override_status() function to allow this. Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 1fd897834b772db18b5831797f3ec8d90e914124 Author: Hans de Goede <[email protected]> Date: Mon Nov 22 18:05:30 2021 +0100 ACPI / x86: Drop PWM2 device on Lenovo Yoga Book from always present table [ Upstream commit d431dfb764b145369be820fcdfd50f2159b9bbc2 ] It turns out that there is a WMI object which controls the PWM2 device used for the keyboard backlight and that WMI object also provides some other useful functionality. The upcoming lenovo-yogabook-wmi driver will offer both backlight control and the other functionality, so there no longer is a need to have the lpss-pwm driver binding to PWM2 for backlight control; and this is now actually undesirable because this will cause both the WMI code and the lpss-pwm driver to poke at the same PWM controller. Drop the always-present quirk for the PWM2 ACPI-device, so that the lpss-pwm controller will no longer bind to it. Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 2518f943a18e27dce8ad0c5af430acb9d1c21b43 Author: Zack Rusin <[email protected]> Date: Fri Nov 5 15:38:45 2021 -0400 drm/vmwgfx: Introduce a new placement for MOB page tables [ Upstream commit f6be23264bbac88d1e2bb39658e1b8a397e3f46d ] For larger (bigger than a page) and noncontiguous mobs we have to create page tables that allow the host to find the memory. Those page tables just used regular system memory. Unfortunately in TTM those BO's are not allowed to be busy thus can't be fenced and we have to fence those bo's because we don't want to destroy the page tables while the host is still executing the command buffers which might be accessing them. To solve it we introduce a new placement VMW_PL_SYSTEM which is very similar to TTM_PL_SYSTEM except that it allows fencing. This fixes kernel oops'es during unloading of the driver (and pci hot remove/add) which were caused by busy BO's in TTM_PL_SYSTEM being present in the delayed deletion list in TTM (TTM_PL_SYSTEM manager is destroyed before the delayed deletions are executed) Signed-off-by: Zack Rusin <[email protected]> Reviewed-by: Martin Krastev <[email protected]> Cc: Christian König <[email protected]> Cc: Thomas Hellström <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit ff74a49da07b402b898f63244096c857ae454bf5 Author: Zack Rusin <[email protected]> Date: Fri Nov 5 15:38:43 2021 -0400 drm/vmwgfx: Release ttm memory if probe fails [ Upstream commit 28b5f3b6121b7db2a44be499cfca0b6b801588b6 ] The ttm mem global state was leaking if the vmwgfx driver load failed. In case of a driver load failure we have to make sure we also release the ttm mem global state. Signed-off-by: Zack Rusin <[email protected]> Reviewed-by: Martin Krastev <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit f168858f60962161a32e94acddc5a241327f70aa Author: Adam Ward <[email protected]> Date: Mon Nov 29 22:10:12 2021 +0000 regulator: da9121: Prevent current limit change when enabled [ Upstream commit 24f0853228f3b98f1ef08d5824376c69bb8124d2 ] Prevent changing current limit when enabled as a precaution against possibile instability due to tight integration with switching cycle Signed-off-by: Adam Ward <[email protected]> Link: https://lore.kernel.org/r/52ee682476004a1736c1e0293358987319c1c415.1638223185.git.Adam.Ward.opensource@diasemi.com Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 34b1e259b1f5a39787fd04a7f1e526e413d8647a Author: Mansur Alisha Shaik <[email protected]> Date: Mon Nov 8 06:48:51 2021 +0100 media: venus: avoid calling core_clk_setrate() concurrently during concurrent video sessions [ Upstream commit 91f2b7d269e5c885c38c7ffa261f5276bd42f907 ] In existing implementation, core_clk_setrate() is getting called concurrently in concurrent video sessions. Before the previous call to core_clk_setrate returns, new call to core_clk_setrate is invoked from another video session running concurrently. This results in latest calculated frequency being set (higher/lower) instead of actual frequency required for that video session. It also results in stability crashes mention below. These resources are specific to video core, hence keeping under core lock would ensure that they are estimated for all running video sessions and called once for the video core. Crash logs: [ 1.900089] WARNING: CPU: 4 PID: 1 at drivers/opp/debugfs.c:33 opp_debug_remove_one+0x2c/0x48 [ 1.908493] Modules linked in: [ 1.911524] CPU: 4 PID: 1 Comm: swapper/0 Not tainted 5.10.67 #35 f8edb8c30cf2dd6838495dd9ef9be47af7f5f60c [ 1.921036] Hardware name: Qualcomm Technologies, Inc. sc7280 IDP SKU2 platform (DT) [ 1.928673] pstate: 60800009 (nZCv daif -PAN +UAO -TCO BTYPE=--) [ 1.934608] pc : opp_debug_remove_one+0x2c/0x48 [ 1.939080] lr : opp_debug_remove_one+0x2c/0x48 [ 1.943560] sp : ffffffc011d7b7f0 [ 1.946836] pmr_save: 000000e0 [ 1.949854] x29: ffffffc011d7b7f0 x28: ffffffc010733bbc [ 1.955104] x27: ffffffc010733ba8 x26: ffffff8083cedd00 [ 1.960355] x25: 0000000000000001 x24: 0000000000000000 [ 1.965603] x23: ffffff8083cc2878 x22: ffffff8083ceb900 [ 1.970852] x21: ffffff8083ceb910 x20: ffffff8083cc2800 [ 1.976101] x19: ffffff8083ceb900 x18: 00000000ffff0a10 [ 1.981352] x17: ffffff80837a5620 x16: 00000000000000ec [ 1.986601] x15: ffffffc010519ad4 x14: 0000000000000003 [ 1.991849] x13: 0000000000000004 x12: 0000000000000001 [ 1.997100] x11: c0000000ffffdfff x10: 00000000ffffffff [ 2.002348] x9 : d2627c580300dc00 x8 : d2627c580300dc00 [ 2.007596] x7 : 0720072007200720 x6 : ffffff80802ecf00 [ 2.012845] x5 : 0000000000190004 x4 : 0000000000000000 [ 2.018094] x3 : ffffffc011d7b478 x2 : ffffffc011d7b480 [ 2.023343] x1 : 00000000ffffdfff x0 : 0000000000000017 [ 2.028594] Call trace: [ 2.031022] opp_debug_remove_one+0x2c/0x48 [ 2.035160] dev_pm_opp_put+0x94/0xb0 [ 2.038780] _opp_remove_all+0x7c/0xc8 [ 2.042486] _opp_remove_all_static+0x54/0x7c [ 2.046796] dev_pm_opp_remove_table+0x74/0x98 [ 2.051183] devm_pm_opp_of_table_release+0x18/0x24 [ 2.056001] devm_action_release+0x1c/0x28 [ 2.060053] release_nodes+0x23c/0x2b8 [ 2.063760] devres_release_group+0xcc/0xd0 [ 2.067900] component_bind+0xac/0x168 [ 2.071608] component_bind_all+0x98/0x124 [ 2.075664] msm_drm_bind+0x1e8/0x678 [ 2.079287] try_to_bring_up_master+0x60/0x134 [ 2.083674] component_master_add_with_match+0xd8/0x120 [ 2.088834] msm_pdev_probe+0x20c/0x2a0 [ 2.092629] platform_drv_probe+0x9c/0xbc [ 2.096598] really_probe+0x11c/0x46c [ 2.100217] driver_probe_device+0x8c/0xf0 [ 2.104270] device_driver_attach+0x54/0x78 [ 2.108407] __driver_attach+0x48/0x148 [ 2.112201] bus_for_each_dev+0x88/0xd4 [ 2.115998] driver_attach+0x2c/0x38 [ 2.119534] bus_add_driver+0x10c/0x200 [ 2.123330] driver_register+0x6c/0x104 [ 2.127122] __platform_driver_register+0x4c/0x58 [ 2.131767] msm_drm_register+0x6c/0x70 [ 2.135560] do_one_initcall+0x64/0x23c [ 2.139357] do_initcall_level+0xac/0x15c [ 2.143321] do_initcalls+0x5c/0x9c [ 2.146778] do_basic_setup+0x2c/0x38 [ 2.150401] kernel_init_freeable+0xf8/0x15c [ 2.154622] kernel_init+0x1c/0x11c [ 2.158079] ret_from_fork+0x10/0x30 [ 2.161615] ---[ end trace a2cc45a0f784b212 ]--- [ 2.166272] Removing OPP: 300000000 Signed-off-by: Mansur Alisha Shaik <[email protected]> Signed-off-by: Stanimir Varbanov <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 371a75dfaadb5eb608d9987754c571272bd44610 Author: Sriram R <[email protected]> Date: Thu Nov 25 15:00:14 2021 +0530 ath11k: Avoid NULL ptr access during mgmt tx cleanup [ Upstream commit a93789ae541c7d5c1c2a4942013adb6bcc5e2848 ] Currently 'ar' reference is not added in skb_cb during WMI mgmt tx. Though this is generally not used during tx completion callbacks, on interface removal the remaining idr cleanup callback uses the ar ptr from skb_cb from mgmt txmgmt_idr. Hence fill them during tx call for proper usage. Also free the skb which is missing currently in these callbacks. Crash_info: [19282.489476] Unable to handle kernel NULL pointer dereference at virtual address 00000000 [19282.489515] pgd = 91eb8000 [19282.496702] [00000000] *pgd=00000000 [19282.502524] Internal error: Oops: 5 [#1] PREEMPT SMP ARM [19282.783728] PC is at ath11k_mac_vif_txmgmt_idr_remove+0x28/0xd8 [ath11k] [19282.789170] LR is at idr_for_each+0xa0/0xc8 Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.5.0.1-00729-QCAHKSWPL_SILICONZ-3 v2 Signed-off-by: Sriram R <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit dbba81756c1b7a8e7a6df443f863d8da11c2054b Author: Zekun Shen <[email protected]> Date: Fri Oct 29 16:19:23 2021 -0400 rsi: Fix out-of-bounds read in rsi_read_pkt() [ Upstream commit f1cb3476e48b60c450ec3a1d7da0805bffc6e43a ] rsi_get_* functions rely on an offset variable from usb input. The size of usb input is RSI_MAX_RX_USB_PKT_SIZE(3000), while 2-byte offset can be up to 0xFFFF. Thus a large offset can cause out-of-bounds read. The patch adds a bound checking condition when rcv_pkt_len is 0, indicating it's USB. It's unclear whether this is triggerable from other type of bus. The following check might help in that case. offset > rcv_pkt_len - FRAME_DESC_SZ The bug is trigerrable with conpromised/malfunctioning USB devices. I tested the patch with the crashing input and got no more bug report. Attached is the KASAN report from fuzzing. BUG: KASAN: slab-out-of-bounds in rsi_read_pkt+0x42e/0x500 [rsi_91x] Read of size 2 at addr ffff888019439fdb by task RX-Thread/227 CPU: 0 PID: 227 Comm: RX-Thread Not tainted 5.6.0 #66 Call Trace: dump_stack+0x76/0xa0 print_address_description.constprop.0+0x16/0x200 ? rsi_read_pkt+0x42e/0x500 [rsi_91x] ? rsi_read_pkt+0x42e/0x500 [rsi_91x] __kasan_report.cold+0x37/0x7c ? rsi_read_pkt+0x42e/0x500 [rsi_91x] kasan_report+0xe/0x20 rsi_read_pkt+0x42e/0x500 [rsi_91x] rsi_usb_rx_thread+0x1b1/0x2fc [rsi_usb] ? rsi_probe+0x16a0/0x16a0 [rsi_usb] ? _raw_spin_lock_irqsave+0x7b/0xd0 ? _raw_spin_trylock_bh+0x120/0x120 ? __wake_up_common+0x10b/0x520 ? rsi_probe+0x16a0/0x16a0 [rsi_usb] kthread+0x2b5/0x3b0 ? kthread_create_on_node+0xd0/0xd0 ret_from_fork+0x22/0x40 Reported-by: Brendan Dolan-Gavitt <[email protected]> Signed-off-by: Zekun Shen <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit bac512a0f3fe611d076566328067bd430f0d888c Author: Zekun Shen <[email protected]> Date: Fri Oct 29 15:49:03 2021 -0400 rsi: Fix use-after-free in rsi_rx_done_handler() [ Upstream commit b07e3c6ebc0c20c772c0f54042e430acec2945c3 ] When freeing rx_cb->rx_skb, the pointer is not set to NULL, a later rsi_rx_done_handler call will try to read the freed address. This bug will very likley lead to double free, although detected early as use-after-free bug. The bug is triggerable with a compromised/malfunctional usb device. After applying the patch, the same input no longer triggers the use-after-free. Attached is the kasan report from fuzzing. BUG: KASAN: use-after-free in rsi_rx_done_handler+0x354/0x430 [rsi_usb] Read of size 4 at addr ffff8880188e5930 by task modprobe/231 Call Trace: <IRQ> dump_stack+0x76/0xa0 print_address_description.constprop.0+0x16/0x200 ? rsi_rx_done_handler+0x354/0x430 [rsi_usb] ? rsi_rx_done_handler+0x354/0x430 [rsi_usb] __kasan_report.cold+0x37/0x7c ? dma_direct_unmap_page+0x90/0x110 ? rsi_rx_done_handler+0x354/0x430 [rsi_usb] kasan_report+0xe/0x20 rsi_rx_done_handler+0x354/0x430 [rsi_usb] __usb_hcd_giveback_urb+0x1e4/0x380 usb_giveback_urb_bh+0x241/0x4f0 ? __usb_hcd_giveback_urb+0x380/0x380 ? apic_timer_interrupt+0xa/0x20 tasklet_action_common.isra.0+0x135/0x330 __do_softirq+0x18c/0x634 ? handle_irq_event+0xcd/0x157 ? handle_edge_irq+0x1eb/0x7b0 irq_exit+0x114/0x140 do_IRQ+0x91/0x1e0 common_interrupt+0xf/0xf </IRQ> Reported-by: Brendan Dolan-Gavitt <[email protected]> Signed-off-by: Zekun Shen <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/YXxQL/vIiYcZUu/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit b2762757f4e484f8a164546f93aca82568d87649 Author: Zekun Shen <[email protected]> Date: Sat Oct 30 22:42:50 2021 -0400 mwifiex: Fix skb_over_panic in mwifiex_usb_recv() [ Upstream commit 04d80663f67ccef893061b49ec8a42ff7045ae84 ] Currently, with an unknown recv_type, mwifiex_usb_recv just return -1 without restoring the skb. Next time mwifiex_usb_rx_complete is invoked with the same skb, calling skb_put causes skb_over_panic. The bug is triggerable with a compromised/malfunctioning usb device. After applying the patch, skb_over_panic no longer shows up with the same input. Attached is the panic report from fuzzing. skbuff: skb_over_panic: text:000000003bf1b5fa len:2048 put:4 head:00000000dd6a115b data:000000000a9445d8 tail:0x844 end:0x840 dev:<NULL> kernel BUG at net/core/skbuff.c:109! invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 0 PID: 198 Comm: in:imklog Not tainted 5.6.0 #60 RIP: 0010:skb_panic+0x15f/0x161 Call Trace: <IRQ> ? mwifiex_usb_rx_complete+0x26b/0xfcd [mwifiex_usb] skb_put.cold+0x24/0x24 mwifiex_usb_rx_complete+0x26b/0xfcd [mwifiex_usb] __usb_hcd_giveback_urb+0x1e4/0x380 usb_giveback_urb_bh+0x241/0x4f0 ? __hrtimer_run_queues+0x316/0x740 ? __usb_hcd_giveback_urb+0x380/0x380 tasklet_action_common.isra.0+0x135/0x330 __do_softirq+0x18c/0x634 irq_exit+0x114/0x140 smp_apic_timer_interrupt+0xde/0x380 apic_timer_interrupt+0xf/0x20 </IRQ> Reported-by: Brendan Dolan-Gavitt <[email protected]> Signed-off-by: Zekun Shen <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit bed51dafd5442c5c0e3e77d2891aebee05c1ba56 Author: Stephan Müller <[email protected]> Date: Sun Nov 21 15:14:20 2021 +0100 crypto: jitter - consider 32 LSB for APT [ Upstream commit 552d03a223eda3df84526ab2c1f4d82e15eaee7a ] The APT compares the current time stamp with a pre-set value. The current code only considered the 4 LSB only. Yet, after reviews by mathematicians of the user space Jitter RNG version >= 3.1.0, it was concluded that the APT can be calculated on the 32 LSB of the time delta. Thi change is applied to the kernel. This fixes a bug where an AMD EPYC fails this test as its RDTSC value contains zeros in the LSB. The most appropriate fix would have been to apply a GCD calculation and divide the time stamp by the GCD. Yet, this is a significant code change that will be considered for a future update. Note, tests showed that constantly the GCD always was 32 on these systems, i.e. the 5 LSB were always zero (thus failing the APT since it only considered the 4 LSB for its calculation). Signed-off-by: Stephan Mueller <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 0c3df095fab62e22b018e1c455f75c25062b4a32 Author: Chengfeng Ye <[email protected]> Date: Fri Nov 5 06:45:07 2021 -0700 HSI: core: Fix return freed object in hsi_new_client [ Upstream commit a1ee1c08fcd5af03187dcd41dcab12fd5b379555 ] cl is freed on error of calling device_register, but this object is return later, which will cause uaf issue. Fix it by return NULL on error. Signed-off-by: Chengfeng Ye <[email protected]> Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 8c124608bf46dc450cbe71dc713aa82159349bd2 Author: Hans de Goede <[email protected]> Date: Thu Nov 25 21:30:10 2021 +0100 gpiolib: acpi: Do not set the IRQ type if the IRQ is already in use [ Upstream commit bdfd6ab8fdccd8b138837efff66f4a1911496378 ] If the IRQ is already in use, then acpi_dev_gpio_irq_get_by() really should not change the type underneath the current owner. I specifically hit an issue with this an a Chuwi Hi8 Super (CWI509) Bay Trail tablet, when the Boot OS selection in the BIOS is set to Android. In this case _STA for a MAX17047 ACPI I2C device wrongly returns 0xf and the _CRS resources for this device include a GpioInt pointing to a GPIO already in use by an _AEI handler, with a different type then specified in the _CRS for the MAX17047 device. Leading to the acpi_dev_gpio_irq_get() call done by the i2c-core-acpi.c code changing the type breaking the _AEI handler. Now this clearly is a bug in the DSDT of this tablet (in Android mode), but in general calling irq_set_irq_type() on an IRQ which already is in use seems like a bad idea. Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit c6d9c77a19d0a46ee1bb4ae9d952f4f9347ef07f Author: Fugang Duan <[email protected]> Date: Thu Nov 25 10:03:49 2021 +0800 tty: serial: imx: disable UCR4_OREN in .stop_rx() instead of .shutdown() [ Upstream commit 028e083832b06fdeeb290e1e57dc1f6702c4c215 ] The UCR4_OREN should be disabled before disabling the uart receiver in .stop_rx() instead of in the .shutdown(). Otherwise, if we have the overrun error during the receiver disable process, the overrun interrupt will keep trigging until we disable the OREN interrupt in the .shutdown(), because the ORE status can only be cleared when read the rx FIFO or reset the controller. Although the called time between the receiver disable and OREN disable in .shutdown() is very short, there is still the risk of endless interrupt during this short period of time. So here change to disable OREN before the receiver been disabled in .stop_rx(). Signed-off-by: Fugang Duan <[email protected]> Signed-off-by: Sherry Sun <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 93306292b7760a446392b7f2a24d260224e204b5 Author: Jiri Slaby <[email protected]> Date: Thu Nov 18 08:31:09 2021 +0100 mxser: keep only !tty test in ISR [ Upstream commit 274ab58dc2b460cc474ffc7ccfcede4b2be1a3f5 ] The others are superfluous with tty refcounting in place now. And they are racy in fact: * tty_port_initialized() reports false for a small moment after interrupts are enabled. * closing is 1 while the port is still alive. The queues are flushed later during close anyway. So there is no need for this special handling. Actually, the ISR should not flush the queues. It should behave as every other driver, just queue the chars into tty buffer and go on. But this will be changed later. There is still a lot code depending on having tty in ISR (and not only tty_port). Signed-off-by: Jiri Slaby <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 405856460d3e7aefb7c1aef047ec88fc4ef2e2a5 Author: Martyn Welch <[email protected]> Date: Thu Nov 25 10:53:02 2021 +0000 drm/bridge: megachips: Ensure both bridges are probed before registration [ Upstream commit 11632d4aa2b3f126790e81a4415d6c23103cf8bb ] In the configuration used by the b850v3, the STDP2690 is used to read EDID data whilst it's the STDP4028 which can detect when monitors are connected. This can result in problems at boot with monitors connected when the STDP4028 is probed first, a monitor is detected and an attempt is made to read the EDID data before the STDP2690 has probed: [ 3.795721] Unable to handle kernel NULL pointer dereference at virtual address 00000018 [ 3.803845] pgd = (ptrval) [ 3.806581] [00000018] *pgd=00000000 [ 3.810180] Internal error: Oops: 5 [#1] SMP ARM [ 3.814813] Modules linked in: [ 3.817879] CPU: 0 PID: 64 Comm: kworker/u4:1 Not tainted 5.15.0 #1 [ 3.824161] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) [ 3.830705] Workqueue: events_unbound deferred_probe_work_func [ 3.836565] PC is at stdp2690_get_edid+0x44/0x19c [ 3.841286] LR is at ge_b850v3_lvds_get_modes+0x2c/0x5c [ 3.846526] pc : [<805eae10>] lr : [<805eb138>] psr: 80000013 [ 3.852802] sp : 81c359d0 ip : 7dbb550b fp : 81c35a1c [ 3.858037] r10: 81c73840 r9 : 81c73894 r8 : 816d9800 [ 3.863270] r7 : 00000000 r6 : 81c34000 r5 : 00000000 r4 : 810c35f0 [ 3.869808] r3 : 80e3e294 r2 : 00000080 r1 : 00000cc0 r0 : 81401180 [ 3.876349] Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [ 3.883499] Control: 10c5387d Table: 1000404a DAC: 00000051 [ 3.889254] Register r0 information: slab kmem_cache start 81401180 pointer offset 0 [ 3.897034] Register r1 information: non-paged memory [ 3.902097] Register r2 information: non-paged memory [ 3.907160] Register r3 information: non-slab/vmalloc memory [ 3.912832] Register r4 information: non-slab/vmalloc memory [ 3.918503] Register r5 information: NULL pointer [ 3.923217] Register r6 information: non-slab/vmalloc memory [ 3.928887] Register r7 information: NULL pointer [ 3.933601] Register r8 information: slab kmalloc-1k start 816d9800 pointer offset 0 size 1024 [ 3.942244] Register r9 information: slab kmalloc-2k start 81c73800 pointer offset 148 size 2048 [ 3.951058] Register r10 information: slab kmalloc-2k start 81c73800 pointer offset 64 size 2048 [ 3.959873] Register r11 information: non-slab/vmalloc memory [ 3.965632] Register r12 information: non-paged memory [ 3.970781] Process kworker/u4:1 (pid: 64, stack limit = 0x(ptrval)) [ 3.977148] Stack: (0x81c359d0 to 0x81c36000) [ 3.981517] 59c0: 80b2b668 80b2b5bc 000002e2 0000034e [ 3.989712] 59e0: 81c35a8c 816d98e8 81c35a14 7dbb550b 805bfcd0 810c35f0 81c73840 824addc0 [ 3.997906] 5a00: 00001000 816d9800 81c73894 81c73840 81c35a34 81c35a20 805eb138 805eadd8 [ 4.006099] 5a20: 810c35f0 00000045 81c35adc 81c35a38 80594188 805eb118 80d7c788 80dd1848 [ 4.014292] 5a40: 00000000 81c35a50 80dca950 811194d3 80dca7c4 80dca944 80dca91c 816d9800 [ 4.022485] 5a60: 81c34000 81c760a8 816d9800 80c58c98 810c35f0 816d98e8 00001000 00001000 [ 4.030678] 5a80: 00000000 00000000 8017712c 81c60000 00000002 00000001 00000000 00000000 [ 4.038870] 5aa0: 816d9900 816d9900 00000000 7dbb550b 805c700c 00000008 826282c8 826282c8 [ 4.047062] 5ac0: 00001000 81e1ce40 00001000 00000002 81c35bf4 81c35ae0 805d9694 80593fc0 [ 4.055255] 5ae0: 8017a970 80179ad8 00000179 00000000 81c35bcc 81c35b00 80177108 8017a950 [ 4.063447] 5b00: 00000000 81c35b10 81c34000 00000000 81004fd8 81010a38 00000000 00000059 [ 4.071639] 5b20: 816d98d4 81fbb718 00000013 826282c8 8017a940 81c35b40 81134448 00000400 [ 4.079831] 5b40: 00000178 00000000 e063b9c1 00000000 c2000049 00000040 00000000 00000008 [ 4.088024] 5b60: 82628300 82628380 00000000 00000000 81c34000 00000000 81fbb700 82628340 [ 4.096216] 5b80: 826283c0 00001000 00000000 00000010 816d9800 826282c0 801766f8 00000000 [ 4.104408] 5ba0: 00000000 81004fd8 00000049 00000000 00000000 00000001 80dcf940 80178de4 [ 4.112601] 5bc0: 81c35c0c 7dbb550b 80178de4 81fbb700 00000010 00000010 810c35f4 81e1ce40 [ 4.120793] 5be0: 81c40908 0000000c 81c35c64 81c35bf8 805a7f18 805d94a0 81c35c3c 816d9800 [ 4.128985] 5c00: 00000010 81c34000 81c35c2c 81c35c18 8012fce0 805be90c 81c35c3c 81c35c28 [ 4.137178] 5c20: 805be90c 80173210 81fbb600 81fbb6b4 81c35c5c 7dbb550b 81c35c64 81fbb700 [ 4.145370] 5c40: 816d9800 00000010 810c35f4 81e1ce40 81c40908 0000000c 81c35c84 81c35c68 [ 4.153565] 5c60: 805a8c78 805a7ed0 816d9800 81fbb700 00000010 00000000 81c35cac 81c35c88 [ 4.161758] 5c80: 805a8dc4 805a8b68 816d9800 00000000 816d9800 00000000 8179f810 810c42d0 [ 4.169950] 5ca0: 81c35ccc 81c35cb0 805e47b0 805a8d18 824aa240 81e1ea80 81c40908 81126b60 [ 4.178144] 5cc0: 81c35d14 81c35cd0 8060db1c 805e46cc 81c35d14 81c35ce0 80dd90f8 810c4d58 [ 4.186338] 5ce0: 80dd90dc 81fe9740 fffffffe 81fe9740 81e1ea80 00000000 810c4d6c 80c4b95c [ 4.194531] 5d00: 80dd9a3c 815c6810 81c35d34 81c35d18 8060dc9c 8060d8fc 8246b440 815c6800 [ 4.202724] 5d20: 815c6810 eefd8e00 81c35d44 81c35d38 8060dd80 8060dbec 81c35d6c 81c35d48 [ 4.210918] 5d40: 805e98a4 8060dd70 00000000 815c6810 810c45b0 81126e90 81126e90 80dd9a3c [ 4.219112] 5d60: 81c35d8c 81c35d70 80619574 805e9808 815c6810 00000000 810c45b0 81126e90 [ 4.227305] 5d80: 81c35db4 81c35d90 806168dc 80619514 80625df0 80623c80 815c6810 810c45b0 [ 4.235498] 5da0: 81c35e6c 815c6810 81c35dec 81c35db8 80616d04 80616800 81c35de4 81c35dc8 [ 4.243691] 5dc0: 808382b0 80b2f444 8116e310 8116e314 81c35e6c 815c6810 00000003 80dd9a3c [ 4.251884] 5de0: 81c35e14 81c35df0 80616ec8 80616c60 00000001 810c45b0 81c35e6c 815c6810 [ 4.260076] 5e00: 00000001 80dd9a3c 81c35e34 81c35e18 80617338 80616e90 00000000 81c35e6c [ 4.268269] 5e20: 80617284 81c34000 81c35e64 81c35e38 80614730 80617290 81c35e64 8171a06c [ 4.276461] 5e40: 81e220b8 7dbb550b 815c6810 81c34000 815c6854 81126e90 81c35e9c 81c35e68 [ 4.284654] 5e60: 8061673c 806146a8 8060f5e0 815c6810 00000001 7dbb550b 00000000 810c5080 [ 4.292847] 5e80: 810c5320 815c6810 81126e90 00000000 81c35eac 81c35ea0 80617554 80616650 [ 4.301040] 5ea0: 81c35ecc 81c35eb0 80615694 80617544 810c5080 810c5080 810c5094 81126e90 [ 4.309233] 5ec0: 81c35efc 81c35ed0 80615c6c 8061560c 80615bc0 810c50c0 817eeb00 81412800 [ 4.317425] 5ee0: 814c3000 00000000 814c300d 81119a60 81c35f3c 81c35f00 80141488 80615bcc [ 4.325618] 5f00: 81c60000 81c34000 81c35f24 81c35f18 80143078 817eeb00 81412800 817eeb18 [ 4.333811] 5f20: 81412818 81003d00 00000088 81412800 81c35f74 81c35f40 80141a48 80141298 [ 4.342005] 5f40: 81c35f74 81c34000 801481ac 817efa40 817efc00 801417d8 817eeb00 00000000 [ 4.350199] 5f60: 815a7e7c 81c34000 81c35fac 81c35f78 80149b1c 801417e4 817efc20 817efc20 [ 4.358391] 5f80: ffffe000 817efa40 801499a8 00000000 00000000 00000000 00000000 00000000 [ 4.366583] 5fa0: 00000000 81c35fb0 80100130 801499b4 00000000 00000000 00000000 00000000 [ 4.374774] 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 4.382966] 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000 [ 4.391155] Backtrace: [ 4.393613] [<805eadcc>] (stdp2690_get_edid) from [<805eb138>] (ge_b850v3_lvds_get_modes+0x2c/0x5c) [ 4.402691] r10:81c73840 r9:81c73894 r8:816d9800 r7:00001000 r6:824addc0 r5:81c73840 [ 4.410534] r4:810c35f0 [ 4.413073] [<805eb10c>] (ge_b850v3_lvds_get_modes) from [<80594188>] (drm_helper_probe_single_connector_modes+0x1d4/0x84c) [ 4.424240] r5:00000045 r4:810c35f0 [ 4.427822] [<80593fb4>] (drm_helper_probe_single_connector_modes) from [<805d9694>] (drm_client_modeset_probe+0x200/0x1384) [ 4.439074] r10:00000002 r9:00001000 r8:81e1ce40 r7:00001000 r6:826282c8 r5:826282c8 [ 4.446917] r4:00000008 [ 4.449455] [<805d9494>] (drm_client_modeset_probe) from [<805a7f18>] (__drm_fb_helper_initial_config_and_unlock+0x54/0x5b4) [ 4.460713] r10:0000000c r9:81c40908 r8:81e1ce40 r7:810c35f4 r6:00000010 r5:00000010 [ 4.468556] r4:81fbb700 [ 4.471095] [<805a7ec4>] (__drm_fb_helper_initial_config_and_unlock) from [<805a8c78>] (drm_fbdev_client_hotplug+0x11c/0x1b0) [ 4.482434] r10:0000000c r9:81c40908 r8:81e1ce40 r7:810c35f4 r6:00000010 r5:816d9800 [ 4.490276] r4:81fbb700 [ 4.492814] [<805a8b5c>] (drm_fbdev_client_hotplug) from [<805a8dc4>] (drm_fbdev_generic_setup+0xb8/0x1a4) [ 4.502494] r7:00000000 r6:00000010 r5:81fbb700 r4:816d9800 [ 4.508160] [<805a8d0c>] (drm_fbdev_generic_setup) from [<805e47b0>] (imx_drm_bind+0xf0/0x130) [ 4.516805] r7:810c42d0 r6:8179f810 r5:00000000 r4:816d9800 [ 4.522474] [<805e46c0>] (imx_drm_bind) from [<8060db1c>] (try_to_bring_up_master+0x22c/0x2f0) [ 4.531116] r7:81126b60 r6:81c40908 r5:81e1ea80 r4:824aa240 [ 4.536783] [<8060d8f0>] (try_to_bring_up_master) from [<8060dc9c>] (__component_add+0xbc/0x184) [ 4.545597] r10:815c6810 r9:80dd9a3c r8:80c4b95c r7:810c4d6c r6:00000000 r5:81e1ea80 [ 4.553440] r4:81fe9740 [ 4.555980] [<8060dbe0>] (__component_add) from [<8060dd80>] (component_add+0x1c/0x20) [ 4.563921] r7:eefd8e00 r6:815c6810 r5:815c6800 r4:8246b440 [ 4.569589] [<8060dd64>] (component_add) from [<805e98a4>] (dw_hdmi_imx_probe+0xa8/0xe8) [ 4.577702] [<805e97fc>] (dw_hdmi_imx_probe) from [<80619574>] (platform_probe+0x6c/0xc8) [ 4.585908] r9:80dd9a3c r8:81126e90 r7:81126e90 r6:810c45b0 r5:815c6810 r4:00000000 [ 4.593662] [<80619508>] (platform_probe) from [<806168dc>] (really_probe+0xe8/0x460) [ 4.601524] r7:81126e90 r6:810c45b0 r5:00000000 r4:815c6810 [ 4.607191] [<806167f4>] (really_probe) from [<80616d04>] (__driver_probe_device+0xb0/0x230) [ 4.615658] r7:815c6810 r6:81c35e6c r5:810c45b0 r4:815c6810 [ 4.621326] [<80616c54>] (__driver_probe_device) from [<80616ec8>] (driver_probe_device+0x44/0xe0) [ 4.630313] r9:80dd9a3c r8:00000003 r7:815c6810 r6:81c35e6c r5:8116e314 r4:8116e310 [ 4.638068] [<80616e84>] (driver_probe_device) from [<80617338>] (__device_attach_driver+0xb4/0x12c) [ 4.647227] r9:80dd9a3c r8:00000001 r7:815c6810 r6:81c35e6c r5:810c45b0 r4:00000001 [ 4.654981] [<80617284>] (__device_attach_driver) from [<80614730>] (bus_for_each_drv+0x94/0xd8) [ 4.663794] r7:81c34000 r6:80617284 r5:81c35e6c r4:00000000 [ 4.669461] [<8061469c>] (bus_for_each_drv) from [<8061673c>] (__device_attach+0xf8/0x190) [ 4.677753] r7:81126e90 r6:815c6854 r5:81c34000 r4:815c6810 [ 4.683419] [<80616644>] (__device_attach) from [<80617554>] (device_initial_probe+0x1c/0x20) [ 4.691971] r8:00000000 r7:81126e90 r6:815c6810 r5:810c5320 r4:810c5080 [ 4.698681] [<80617538>] (device_initial_probe) from [<80615694>] (bus_probe_device+0x94/0x9c) [ 4.707318] [<80615600>] (bus_probe_device) from [<80615c6c>] (deferred_probe_work_func+0xac/0xf0) [ 4.716305] r7:81126e90 r6:810c5094 r5:810c5080 r4:810c5080 [ 4.721973] [<80615bc0>] (deferred_probe_work_func) from [<80141488>] (process_one_work+0x1fc/0x54c) [ 4.731139] r10:81119a60 r9:814c300d r8:00000000 r7:814c3000 r6:81412800 r5:817eeb00 [ 4.738981] r4:810c50c0 r3:80615bc0 [ 4.742563] [<8014128c>] (process_one_work) from [<80141a48>] (worker_thread+0x270/0x570) [ 4.750765] r10:81412800 r9:00000088 r8:81003d00 r7:81412818 r6:817eeb18 r5:81412800 [ 4.758608] r4:817eeb00 [ 4.761147] [<801417d8>] (worker_thread) from [<80149b1c>] (kthread+0x174/0x190) [ 4.768574] r10:81c34000 r9:815a7e7c r8:00000000 r7:817eeb00 r6:801417d8 r5:817efc00 [ 4.776417] r4:817efa40 [ 4.778955] [<801499a8>] (kthread) from [<80100130>] (ret_from_fork+0x14/0x24) [ 4.786201] Exception stack(0x81c35fb0 to 0x81c35ff8) [ 4.791266] 5fa0: 00000000 00000000 00000000 00000000 [ 4.799459] 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 4.807651] 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 4.814279] r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:801499a8 [ 4.822120] r4:817efa40 [ 4.824664] Code: e3a02080 e593001c e3a01d33 e3a05000 (e5979018) Split the registration from the STDP4028 probe routine and only perform registration once both the STDP4028 and STDP2690 have probed. Signed-off-by: Martyn Welch <[email protected]> CC: Peter Senna Tschudin <[email protected]> CC: Martyn Welch <[email protected]> CC: Neil Armstrong <[email protected]> CC: Robert Foss <[email protected]> CC: Laurent Pinchart <[email protected]> CC: Jonas Karlman <[email protected]> CC: Jernej Skrabec <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/43552c3404e8fdf92d8bc5658fac24e9f03c2c57.1637836606.git.martyn.welch@collabora.com Signed-off-by: Sasha Levin <[email protected]> commit 58d33532664c1580beeb127ffe771a7739fb63d3 Author: Martin Leung <[email protected]> Date: Fri Nov 12 17:59:31 2021 -0500 drm/amd/display: add else to avoid double destroy clk_mgr [ Upstream commit 11dff0e871037a6ad978e52f826a2eb7f5fb274a ] [Why & How] when changing some code we accidentally changed else if-> if. reverting that. Reviewed-by: Aric Cyr <[email protected]> Acked-by: Qingqing Zhuo <[email protected]> Signed-off-by: Martin Leung <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit ae93accee3177fe36e136e749fc7f2616f2bf2d3 Author: Danielle Ratson <[email protected]> Date: Tue Nov 23 09:54:47 2021 +0200 mlxsw: pci: Add shutdown method in PCI driver [ Upstream commit c1020d3cf4752f61a6a413f632ea2ce2370e150d ] On an arm64 platform with the Spectrum ASIC, after loading and executing a new kernel via kexec, the following trace [1] is observed. This seems to be caused by the fact that the device is not properly shutdown before executing the new kernel. Fix this by implementing a shutdown method which mirrors the remove method, as recommended by the kexec maintainer [2][3]. [1] BUG: Bad page state in process devlink pfn:22f73d page:fffffe00089dcf40 refcount:-1 mapcount:0 mapping:0000000000000000 index:0x0 flags: 0x2ffff00000000000() raw: 2ffff00000000000 0000000000000000 ffffffff089d0201 0000000000000000 raw: 0000000000000000 0000000000000000 ffffffffffffffff 0000000000000000 page dumped because: nonzero _refcount Modules linked in: CPU: 1 PID: 16346 Comm: devlink Tainted: G B 5.8.0-rc6-custom-273020-gac6b365b1bf5 #44 Hardware name: Marvell Armada 7040 TX4810M (DT) Call trace: dump_backtrace+0x0/0x1d0 show_stack+0x1c/0x28 dump_stack+0xbc/0x118 bad_page+0xcc/0xf8 check_free_page_bad+0x80/0x88 __free_pages_ok+0x3f8/0x418 __free_pages+0x38/0x60 kmem_freepages+0x200/0x2a8 slab_destroy+0x28/0x68 slabs_destroy+0x60/0x90 ___cache_free+0x1b4/0x358 kfree+0xc0/0x1d0 skb_free_head+0x2c/0x38 skb_release_data+0x110/0x1a0 skb_release_all+0x2c/0x38 consume_skb+0x38/0x130 __dev_kfree_skb_any+0x44/0x50 mlxsw_pci_rdq_fini+0x8c/0xb0 mlxsw_pci_queue_fini.isra.0+0x28/0x58 mlxsw_pci_queue_group_fini+0x58/0x88 mlxsw_pci_aqs_fini+0x2c/0x60 mlxsw_pci_fini+0x34/0x50 mlxsw_core_bus_device_unregister+0x104/0x1d0 mlxsw_devlink_core_bus_device_reload_down+0x2c/0x48 devlink_reload+0x44/0x158 devlink_nl_cmd_reload+0x270/0x290 genl_rcv_msg+0x188/0x2f0 netlink_rcv_skb+0x5c/0x118 genl_rcv+0x3c/0x50 netlink_unicast+0x1bc/0x278 netlink_sendmsg+0x194/0x390 __sys_sendto+0xe0/0x158 __arm64_sys_sendto+0x2c/0x38 el0_svc_common.constprop.0+0x70/0x168 do_el0_svc+0x28/0x88 el0_sync_handler+0x88/0x190 el0_sync+0x140/0x180 [2] https://www.mail-archive.com/[email protected]/msg1195432.html [3] https://patchwork.kernel.org/project/linux-scsi/patch/[email protected]/#20116693 Cc: Eric Biederman <[email protected]> Signed-off-by: Danielle Ratson <[email protected]> Signed-off-by: Ido Schimmel <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit b019927f1c4aa1daabdb7f332180e301c218ae37 Author: Jan Kiszka <[email protected]> Date: Mon Jun 21 20:08:28 2021 +0200 soc: ti: pruss: fix referenced node in error message [ Upstream commit 8aa35e0bb5eaa42bac415ad0847985daa7b4890c ] So far, "(null)" is reported for the node that is missing clocks. Signed-off-by: Jan Kiszka <[email protected]> Acked-by: Suman Anna <[email protected]> Signed-off-by: Nishanth Menon <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit f94cf1cb17963905910c2adc332ebb9e44e7fa4b Author: Alex Deucher <[email protected]> Date: Wed Nov 10 10:23:25 2021 -0500 drm/amdgpu/display: set vblank_disable_immediate for DC [ Upstream commit 92020e81ddbeac351ea4a19bcf01743f32b9c800 ] Disable vblanks immediately to save power. I think this was missed when we merged DC support. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1781 Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 1fffa8ffd62fc511d4447b793641252c4743e81c Author: Yang Li <[email protected]> Date: Mon Nov 15 16:10:19 2021 +0800 drm/amd/display: check top_pipe_to_program pointer [ Upstream commit a689e8d1f80012f90384ebac9dcfac4201f9f77e ] Clang static analysis reports this error drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:2870:7: warning: Dereference of null pointer [clang-analyzer-core.NullDereference] if (top_pipe_to_program->stream_res.tg->funcs->lock_doublebuffer_enable) { ^ top_pipe_to_program being NULL is caught as an error But then it is used to report the error. So add a check before using it. Reported-by: Abaci Robot <[email protected]> Signed-off-by: Yang Li <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 5e0f1c68da1e92ec598d3d547ae456e74412825a Author: Lukas Bulwahn <[email protected]> Date: Thu Oct 28 16:19:33 2021 +0200 ARM: imx: rename DEBUG_IMX21_IMX27_UART to DEBUG_IMX27_UART [ Upstream commit b0100bce4ff82ec1ccd3c1f3d339fd2df6a81784 ] Since commit 4b563a066611 ("ARM: imx: Remove imx21 support"), the config DEBUG_IMX21_IMX27_UART is really only debug support for IMX27. So, rename this option to DEBUG_IMX27_UART and adjust dependencies in Kconfig and rename the definitions to IMX27 as further clean-up. This issue was discovered with ./scripts/checkkconfigsymbols.py, which reported that DEBUG_IMX21_IMX27_UART depends on the non-existing config SOC_IMX21. Signed-off-by: Lukas Bulwahn <[email protected]> Reviewed-by: Arnd Bergmann <[email protected]> Signed-off-by: Shawn Guo <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit b16e928b6a30126f11fcb0030ca9ded6b29062ff Author: Marek Vasut <[email protected]> Date: Sat Oct 16 23:05:47 2021 +0200 soc: imx: gpcv2: Synchronously suspend MIX domains [ Upstream commit f756f435f7dd823f2d4bd593ce1bf3168def1308 ] In case the following power domain sequence happens, iMX8M Mini always hangs: gpumix:on -> gpu:on -> gpu:off -> gpu:on This is likely due to another quirk of the GPC block. This situation can be prevented by always synchronously powering off both the domain and MIX domain. Make it so. This turns the aforementioned sequence into: gpumix:on -> gpu:on -> gpu:off -> gpumix:off -> gpumix:on -> gpu:on Signed-off-by: Marek Vasut <[email protected]> Cc: Frieder Schrempf <[email protected]> Cc: Lucas Stach <[email protected]> Cc: NXP Linux Team <[email protected]> Cc: Peng Fan <[email protected]> Cc: Shawn Guo <[email protected]> Acked-by: Lucas Stach <[email protected]> Signed-off-by: Shawn Guo <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit f573eda00b394d9c784452c6be1b88b2571aa480 Author: Konrad Dybcio <[email protected]> Date: Sun Nov 14 02:27:45 2021 +0100 arm64: dts: qcom: sm8350: Shorten camera-thermal-bottom name [ Upstream commit f52dd33943ca5f84ae76890f352f6d9e12512c3f ] Thermal zone names should not be longer than 20 names, which is indicated by a message at boot. Change "camera-thermal-bottom" to "cam-thermal-bottom" to fix it. Signed-off-by: Konrad Dybcio <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit c41c4bc61db250d8793424e73c2686bb89ff6b7b Author: Dinh Nguyen <[email protected]> Date: Tue Oct 12 14:07:06 2021 -0500 EDAC/synopsys: Use the quirk for version instead of ddr version [ Upstream commit bd1d6da17c296bd005bfa656952710d256e77dd3 ] Version 2.40a supports DDR_ECC_INTR_SUPPORT for a quirk, so use that quirk to determine a call to setup_address_map(). Signed-off-by: Dinh Nguyen <[email protected]> Signed-off-by: Borislav Petkov <[email protected]> Reviewed-by: Michal Simek <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 342aa207c9dafd9bfd0ce2ae12754a4d50543581 Author: Yang Li <[email protected]> Date: Thu Nov 18 17:48:03 2021 +0800 ethernet: renesas: Use div64_ul instead of do_div [ Upstream commit d9f31aeaa1e5aefa68130878af3c3513d41c1e2d ] do_div() does a 64-by-32 division. Here the divisor is an unsigned long which on some platforms is 64 bit wide. So use div64_ul instead of do_div to avoid a possible truncation. Eliminate the following coccicheck warning: ./drivers/net/ethernet/renesas/ravb_main.c:2492:1-7: WARNING: do_div() does a 64-by-32 division, please consider using div64_ul instead. Reported-by: Abaci Robot <[email protected]> Signed-off-by: Yang Li <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Reviewed-by: Sergey Shtylyov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit a111f8e113c76efe7c9b3feffb4d487240d61286 Author: Andrii Nakryiko <[email protected]> Date: Wed Nov 17 11:41:13 2021 -0800 libbpf: Accommodate DWARF/compiler bug with duplicated structs [ Upstream commit efdd3eb8015e7447095f02a26eaabd164cd18004 ] According to [0], compilers sometimes might produce duplicate DWARF definitions for exactly the same struct/union within the same compilation unit (CU). We've had similar issues with identical arrays and handled them with a similar workaround in 6b6e6b1d09aa ("libbpf: Accomodate DWARF/compiler bug with duplicated identical arrays"). Do the same for struct/union by ensuring that two structs/unions are exactly the same, down to the integer values of field referenced type IDs. Solving this more generically (allowing referenced types to be equivalent, but using different type IDs, all within a single CU) requires a huge complexity increase to handle many-to-many mappings between canonidal and candidate type graphs. Before we invest in that, let's see if this approach handles all the instances of this issue in practice. Thankfully it's pretty rare, it seems. [0] https://lore.kernel.org/bpf/YXr2NFlJTAhHdZqq@krava/ Reported-by: Jiri Olsa <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 299951bd1ef99087213709782a368ef2ce06dadf Author: Zheyu Ma <[email protected]> Date: Tue May 11 10:00:03 2021 +0100 media: b2c2: Add missing check in flexcop_pci_isr: [ Upstream commit b13203032e679674c7c518f52a7ec0801ca3a829 ] A out-of-bounds bug can be triggered by an interrupt, the reason for this bug is the lack of checking of register values. In flexcop_pci_isr, the driver reads value from a register and uses it as a dma address. Finally, this address will be passed to the count parameter of find_next_packet. If this value is larger than the size of dma, the index of buffer will be out-of-bounds. Fix this by adding a check after reading the value of the register. The following KASAN report reveals it: BUG: KASAN: slab-out-of-bounds in find_next_packet drivers/media/dvb-core/dvb_demux.c:528 [inline] BUG: KASAN: slab-out-of-bounds in _dvb_dmx_swfilter drivers/media/dvb-core/dvb_demux.c:572 [inline] BUG: KASAN: slab-out-of-bounds in dvb_dmx_swfilter+0x3fa/0x420 drivers/media/dvb-core/dvb_demux.c:603 Read of size 1 at addr ffff8880608c00a0 by task swapper/2/0 CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.19.177-gdba4159c14ef #25 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xec/0x156 lib/dump_stack.c:118 print_address_description+0x78/0x290 mm/kasan/report.c:256 kasan_report_error mm/kasan/report.c:354 [inline] kasan_report+0x25b/0x380 mm/kasan/report.c:412 __asan_report_load1_noabort+0x19/0x20 mm/kasan/report.c:430 find_next_packet drivers/media/dvb-core/dvb_demux.c:528 [inline] _dvb_dmx_swfilter drivers/media/dvb-core/dvb_demux.c:572 [inline] dvb_dmx_swfilter+0x3fa/0x420 drivers/media/dvb-core/dvb_demux.c:603 flexcop_pass_dmx_data+0x2e/0x40 drivers/media/common/b2c2/flexcop.c:167 flexcop_pci_isr+0x3d1/0x5d0 drivers/media/pci/b2c2/flexcop-pci.c:212 __handle_irq_event_percpu+0xfb/0x770 kernel/irq/handle.c:149 handle_irq_event_percpu+0x79/0x150 kernel/irq/handle.c:189 handle_irq_event+0xac/0x140 kernel/irq/handle.c:206 handle_fasteoi_irq+0x232/0x5c0 kernel/irq/chip.c:725 generic_handle_irq_desc include/linux/irqdesc.h:155 [inline] handle_irq+0x230/0x3a0 arch/x86/kernel/irq_64.c:87 do_IRQ+0xa7/0x1e0 arch/x86/kernel/irq.c:247 common_interrupt+0xf/0xf arch/x86/entry/entry_64.S:670 </IRQ> RIP: 0010:native_safe_halt+0x28/0x30 arch/x86/include/asm/irqflags.h:61 Code: 00 00 55 be 04 00 00 00 48 c7 c7 00 62 2f 8c 48 89 e5 e8 fb 31 e8 f8 8b 05 75 4f 8e 03 85 c0 7e 07 0f 00 2d 8a 61 66 00 fb f4 <5d> c3 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 RSP: 0018:ffff88806b71fcc8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffffde RAX: 0000000000000000 RBX: ffffffff8bde44c8 RCX: ffffffff88a11285 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffffff8c2f6200 RBP: ffff88806b71fcc8 R08: fffffbfff185ec40 R09: fffffbfff185ec40 R10: 0000000000000001 R11: fffffbfff185ec40 R12: 0000000000000002 R13: ffffffff8be9d6e0 R14: 0000000000000000 R15: 0000000000000000 arch_safe_halt arch/x86/include/asm/paravirt.h:94 [inline] default_idle+0x6f/0x360 arch/x86/kernel/process.c:557 arch_cpu_idle+0xf/0x20 arch/x86/kernel/process.c:548 default_idle_call+0x3b/0x60 kernel/sched/idle.c:93 cpuidle_idle_call kernel/sched/idle.c:153 [inline] do_idle+0x2ab/0x3c0 kernel/sched/idle.c:263 cpu_startup_entry+0xcb/0xe0 kernel/sched/idle.c:369 start_secondary+0x3b8/0x4e0 arch/x86/kernel/smpboot.c:271 secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:243 Allocated by task 1: save_stack+0x43/0xd0 mm/kasan/kasan.c:448 set_track mm/kasan/kasan.c:460 [inline] kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:553 kasan_slab_alloc+0x11/0x20 mm/kasan/kasan.c:490 slab_post_alloc_hook mm/slab.h:445 [inline] slab_alloc_node mm/slub.c:2741 [inline] slab_alloc mm/slub.c:2749 [inline] kmem_cache_alloc+0xeb/0x280 mm/slub.c:2754 kmem_cache_zalloc include/linux/slab.h:699 [inline] __kernfs_new_node+0xe2/0x6f0 fs/kernfs/dir.c:633 kernfs_new_node+0x9a/0x120 fs/kernfs/dir.c:693 __kernfs_create_file+0x5f/0x340 fs/kernfs/file.c:992 sysfs_add_file_mode_ns+0x22a/0x4e0 fs/sysfs/file.c:306 create_files fs/sysfs/group.c:63 [inline] internal_create_group+0x34e/0xc30 fs/sysfs/group.c:147 sysfs_create_group fs/sysfs/group.c:173 [inline] sysfs_create_groups+0x9c/0x140 fs/sysfs/group.c:200 driver_add_groups+0x3e/0x50 drivers/base/driver.c:129 bus_add_driver+0x3a5/0x790 drivers/base/bus.c:684 driver_register+0x1cd/0x410 drivers/base/driver.c:170 __pci_register_driver+0x197/0x200 drivers/pci/pci-driver.c:1411 cx88_audio_pci_driver_init+0x23/0x25 drivers/media/pci/cx88/cx88-alsa.c: 1017 do_one_initcall+0xe0/0x610 init/main.c:884 do_initcall_level init/main.c:952 [inline] do_initcalls init/main.c:960 [inline] do_basic_setup init/main.c:978 [inline] kernel_init_freeable+0x4d0/0x592 init/main.c:1145 kernel_init+0x18/0x190 init/main.c:1062 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415 Freed by task 0: (stack is not available) The buggy address belongs to the object at ffff8880608c0000 which belongs to the cache kernfs_node_cache of size 160 The buggy address is located 0 bytes to the right of 160-byte region [ffff8880608c0000, ffff8880608c00a0) The buggy address belongs to the page: page:ffffea0001823000 count:1 mapcount:0 mapping:ffff88806bed1e00 index:0x0 compound_mapcount: 0 flags: 0x100000000008100(slab|head) raw: 0100000000008100 dead000000000100 dead000000000200 ffff88806bed1e00 raw: 0000000000000000 0000000000240024 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8880608bff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff8880608c0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff8880608c0080: 00 00 00 00 fc fc fc fc fc fc fc fc 00 00 00 00 ^ ffff8880608c0100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff8880608c0180: fc fc fc fc fc fc fc fc 00 00 00 00 00 00 00 00 ================================================================== Link: https://lore.kernel.org/linux-media/[email protected] Reported-by: Zheyu Ma <[email protected]> Signed-off-by: Zheyu Ma <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 3396b7cf1478b4776c10c7548ffcd621b64f4131 Author: José Expósito <[email protected]> Date: Thu Nov 18 08:29:53 2021 +0100 HID: apple: Do not reset quirks when the Fn key is not found [ Upstream commit a5fe7864d8ada170f19cc47d176bf8260ffb4263 ] When a keyboard without a function key is detected, instead of removing all quirks, remove only the APPLE_HAS_FN quirk. Signed-off-by: José Expósito <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit e6ad399596bd234be4722022146e33e15c7e424d Author: José Expósito <[email protected]> Date: Thu Nov 18 17:52:08 2021 +0100 HID: magicmouse: Report battery level over USB [ Upstream commit 0b91b4e4dae63cd43871fc2012370b86ee588f91 ] When connected over USB, the Apple Magic Mouse 2 and the Apple Magic Trackpad 2 register multiple interfaces, one of them is used to report the battery level. However, unlike when connected over Bluetooth, the battery level is not reported automatically and it is required to fetch it manually. Fix the battery report descriptor and add a timer to fetch the battery level. Signed-off-by: José Expósito <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit c350fcc74035f48ee5a7226faee7079dd0ce9565 Author: Hans de Goede <[email protected]> Date: Sat Nov 6 14:02:27 2021 +0100 drm: panel-orientation-quirks: Add quirk for the Lenovo Yoga Book X91F/L [ Upstream commit bc30c3b0c8a1904d83d5f0d60fb8650a334b207b ] The Lenovo Yoga Book X91F/L uses a panel which has been mounted 90 degrees rotated. Add a quirk for this. Cc: Yauhen Kharuzhy <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Acked-by: Simon Ser <[email protected]> Tested-by: Yauhen Kharuzhy <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit d168123f1388882bf5b41d07e5534a319f5fff1a Author: Brian Chen <[email protected]> Date: Wed Nov 10 21:33:12 2021 +0000 psi: Fix PSI_MEM_FULL state when tasks are in memstall and doing reclaim [ Upstream commit cb0e52b7748737b2cf6481fdd9b920ce7e1ebbdf ] We've noticed cases where tasks in a cgroup are stalled on memory but there is little memory FULL pressure since tasks stay on the runqueue in reclaim. A simple example involves a single threaded program that keeps leaking and touching large amounts of memory. It runs in a cgroup with swap enabled, memory.high set at 10M and cpu.max ratio set at 5%. Though there is significant CPU pressure and memory SOME, there is barely any memory FULL since the task enters reclaim and stays on the runqueue. However, this memory-bound task is effectively stalled on memory and we expect memory FULL to match memory SOME in this scenario. The code is confused about memstall && running, thinking there is a stalled task and a productive task when there's only one task: a reclaimer that's counted as both. To fix this, we redefine the condition for PSI_MEM_FULL to check that all running tasks are in an active memstall instead of checking that there are no running tasks. case PSI_MEM_FULL: - return unlikely(tasks[NR_MEMSTALL] && !tasks[NR_RUNNING]); + return unlikely(tasks[NR_MEMSTALL] && + tasks[NR_RUNNING] == tasks[NR_MEMSTALL_RUNNING]); This will capture reclaimers. It will also capture tasks that called psi_memstall_enter() and are about to sleep, but this should be negligible noise. Signed-off-by: Brian Chen <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Acked-by: Johannes Weiner <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 07888a4fbcf23dd79c2e361ded5b9bd98e881a7f Author: Pavankumar Kondeti <[email protected]> Date: Fri Nov 12 15:54:40 2021 +0530 usb: gadget: f_fs: Use stream_open() for endpoint files [ Upstream commit c76ef96fc00eb398c8fc836b0eb2f82bcc619dc7 ] Function fs endpoint file operations are synchronized via an interruptible mutex wait. However we see threads that do ep file operations concurrently are getting blocked for the mutex lock in __fdget_pos(). This is an uninterruptible wait and we see hung task warnings and kernel panic if hung_task_panic systcl is enabled if host does not send/receive the data for long time. The reason for threads getting blocked in __fdget_pos() is due to the file position protection introduced by the commit 9c225f2655e3 ("vfs: atomic f_pos accesses as per POSIX"). Since function fs endpoint files does not have the notion of the file position, switch to the stream mode. This will bypass the file position mutex and threads will be blocked in interruptible state for the function fs mutex. It should not affects user space as we are only changing the task state changes the task state from UNINTERRUPTIBLE to INTERRUPTIBLE while waiting for the USB transfers to be finished. However there is a slight change to the O_NONBLOCK behavior. Earlier threads that are using O_NONBLOCK are also getting blocked inside fdget_pos(). Now they reach to function fs and error code is returned. The non blocking behavior is actually honoured now. Reviewed-by: John Keeping <[email protected]> Signed-off-by: Pavankumar Kondeti <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 7171e60715a695f4c62c434e6df94b38965de3ec Author: Haimin Zhang <[email protected]> Date: Sat Nov 13 11:53:20 2021 -0500 USB: ehci_brcm_hub_control: Improve port index sanitizing [ Upstream commit 9933698f6119886c110750e67c10ac66f12b730f ] Due to (wIndex & 0xff) - 1 can get an integer greater than 15, this can cause array index to be out of bounds since the size of array port_status is 15. This change prevents a possible out-of-bounds pointer computation by forcing the use of a valid port number. Reported-by: TCS Robot <[email protected]> Signed-off-by: Haimin Zhang <[email protected]> Signed-off-by: Alan Stern <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 432acc8ad2443807d59c51acf5058a1f14b55566 Author: Amjad Ouled-Ameur <[email protected]> Date: Fri Nov 12 17:28:26 2021 +0100 usb: dwc3: meson-g12a: fix shared reset control use [ Upstream commit 4ce3b45704d5ef46fb4b28083c8aba6716fabf3b ] reset_control_(de)assert() calls are called on a shared reset line when reset_control_reset has been used. This is not allowed by the reset framework. Use reset_control_rearm() call in suspend() and remove() as a way to state that the resource is no longer used, hence the shared reset line may be triggered again by other devices. Use reset_control_rearm() also in case probe fails after reset() has been called. reset_control_rearm() keeps use of triggered_count sane in the reset framework, use of reset_control_reset() on shared reset line should be balanced with reset_control_rearm(). Signed-off-by: Amjad Ouled-Ameur <[email protected]> Reported-by: Jerome Brunet <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 79a3d8f1882d5ba1d221c0baef8f6d5d365ee509 Author: Baochen Qiang <[email protected]> Date: Tue Oct 26 09:16:05 2021 +0800 ath11k: Fix crash caused by uninitialized TX ring [ Upstream commit 273703ebdb01b6c5f1aaf4b98fb57b177609055c ] Commit 31582373a4a8 ("ath11k: Change number of TCL rings to one for QCA6390") avoids initializing the other entries of dp->tx_ring cause the corresponding TX rings on QCA6390/WCN6855 are not used, but leaves those ring masks in ath11k_hw_ring_mask_qca6390.tx unchanged. Normally this is OK because we will only get interrupts from the first TX ring on these chips and thus only the first entry of dp->tx_ring is involved. In case of one MSI vector, all DP rings share the same IRQ. For each interrupt, all rings have to be checked, which means the other entries of dp->tx_ring are involved. However since they are not initialized, system crashes. Fix this issue by simply removing those ring masks. crash stack: [ 102.907438] BUG: kernel NULL pointer dereference, address: 0000000000000028 [ 102.907447] #PF: supervisor read access in kernel mode [ 102.907451] #PF: error_code(0x0000) - not-present page [ 102.907453] PGD 1081f0067 P4D 1081f0067 PUD 1081f1067 PMD 0 [ 102.907460] Oops: 0000 [#1] SMP DEBUG_PAGEALLOC NOPTI [ 102.907465] CPU: 0 PID: 3511 Comm: apt-check Kdump: loaded Tainted: G E 5.15.0-rc4-wt-ath+ #20 [ 102.907470] Hardware name: AMD Celadon-RN/Celadon-RN, BIOS RCD1005E 10/08/2020 [ 102.907472] RIP: 0010:ath11k_dp_tx_completion_handler+0x201/0x830 [ath11k] [ 102.907497] Code: 3c 24 4e 8d ac 37 10 04 00 00 4a 8d bc 37 68 04 00 00 48 89 3c 24 48 63 c8 89 83 84 18 00 00 48 c1 e1 05 48 03 8b 78 18 00 00 <8b> 51 08 89 d6 83 e6 07 89 74 24 24 83 fe 03 74 04 85 f6 75 63 41 [ 102.907501] RSP: 0000:ffff9b7340003e08 EFLAGS: 00010202 [ 102.907505] RAX: 0000000000000001 RBX: ffff8e21530c0100 RCX: 0000000000000020 [ 102.907508] RDX: 0000000000000000 RSI: 00000000fffffe00 RDI: ffff8e21530c1938 [ 102.907511] RBP: ffff8e21530c0000 R08: 0000000000000001 R09: 0000000000000000 [ 102.907513] R10: ffff8e2145534c10 R11: 0000000000000001 R12: ffff8e21530c2938 [ 102.907515] R13: ffff8e21530c18e0 R14: 0000000000000100 R15: ffff8e21530c2978 [ 102.907518] FS: 00007f5d4297e740(0000) GS:ffff8e243d600000(0000) knlGS:0000000000000000 [ 102.907521] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 102.907524] CR2: 0000000000000028 CR3: 00000001034ea000 CR4: 0000000000350ef0 [ 102.907527] Call Trace: [ 102.907531] <IRQ> [ 102.907537] ath11k_dp_service_srng+0x5c/0x2f0 [ath11k] [ 102.907556] ath11k_pci_ext_grp_napi_poll+0x21/0x70 [ath11k_pci] [ 102.907562] __napi_poll+0x2c/0x160 [ 102.907570] net_rx_action+0x251/0x310 [ 102.907576] __do_softirq+0x107/0x2fc [ 102.907585] irq_exit_rcu+0x74/0x90 [ 102.907593] common_interrupt+0x83/0xa0 [ 102.907600] </IRQ> [ 102.907601] asm_common_interrupt+0x1e/0x40 Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Signed-off-by: Baochen Qiang <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit f1d85deaf343044ce4d2bb4983f9797df4f798c0 Author: Mauro Carvalho Chehab <[email protected]> Date: Thu Nov 11 23:04:09 2021 +0000 media: atomisp: handle errors at sh_css_create_isp_params() [ Upstream commit 58043dbf6d1ae9deab4f5aa1e039c70112017682 ] The succ var tracks memory allocation erros on this function. Fix it, in order to stop this W=1 Werror in clang: drivers/staging/media/atomisp/pci/sh_css_params.c:2430:7: error: variable 'succ' set but not used [-Werror,-Wunused-but-set-variable] bool succ = true; ^ Reviewed-by: Nathan Chancellor <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit bab93d53661778f788c48a57ec1b8f64cec72735 Author: Linus Lüssing <[email protected]> Date: Sun Oct 31 22:30:12 2021 +0100 batman-adv: allow netlink usage in unprivileged containers [ Upstream commit 9057d6c23e7388ee9d037fccc9a7bc8557ce277b ] Currently, creating a batman-adv interface in an unprivileged LXD container and attaching secondary interfaces to it with "ip" or "batctl" works fine. However all batctl debug and configuration commands fail: root@container:~# batctl originators Error received: Operation not permitted root@container:~# batctl orig_interval 1000 root@container:~# batctl orig_interval 2000 root@container:~# batctl orig_interval 1000 To fix this change the generic netlink permissions from GENL_ADMIN_PERM to GENL_UNS_ADMIN_PERM. This way a batman-adv interface is fully maintainable as root from within a user namespace, from an unprivileged container. All except one batman-adv netlink setting are per interface and do not leak information or change settings from the host system and are therefore save to retrieve or modify as root from within an unprivileged container. "batctl routing_algo" / BATADV_CMD_GET_ROUTING_ALGOS is the only exception: It provides the batman-adv kernel module wide default routing algorithm. However it is read-only from netlink and an unprivileged container is still not allowed to modify /sys/module/batman_adv/parameters/routing_algo. Instead it is advised to use the newly introduced "batctl if create routing_algo RA_NAME" / IFLA_BATADV_ALGO_NAME to set the routing algorithm on interface creation, which already works fine in an unprivileged container. Cc: Tycho Andersen <[email protected]> Signed-off-by: Linus Lüssing <[email protected]> Signed-off-by: Sven Eckelmann <[email protected]> Signed-off-by: Simon Wunderlich <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 5a47ca7f78944fd2d56113fc36cca97d1e25704f Author: Wan Jiabing <[email protected]> Date: Sun Oct 17 21:45:03 2021 -0400 ARM: shmobile: rcar-gen2: Add missing of_node_put() [ Upstream commit 85744f2d938c5f3cfc44cb6533c157469634da93 ] Fix following coccicheck warning: ./arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c:156:1-33: Function for_each_matching_node_and_match should have of_node_put() before break and goto. Early exits from for_each_matching_node_and_match() should decrement the node reference counter. Signed-off-by: Wan Jiabing <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 75272f75eddf15294a301cadab6f594153831c26 Author: Mauro Carvalho Chehab <[email protected]> Date: Wed Nov 10 12:59:11 2021 +0000 media: atomisp: check before deference asd variable [ Upstream commit 71665d816214124d6bc4eb80314ac8f84ecacd78 ] The asd->isp was referenced before checking if asd is not NULL. This fixes this warning: ../drivers/staging/media/atomisp/pci/atomisp_cmd.c:5548 atomisp_set_fmt_to_snr() warn: variable dereferenced before check 'asd' (see line 5540) While here, avoid getting the pipe pointer twice. Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 8335807ce3132c6ff95af77685c54b66de80893b Author: Hans de Goede <[email protected]> Date: Sun Nov 7 17:15:48 2021 +0000 media: atomisp-ov2680: Fix ov2680_set_fmt() clobbering the exposure [ Upstream commit 4492289c31364d28c2680b43b18883385a5d216c ] Now that we restore the default or last user set exposure setting on power_up() there is no need for the registers written by ov2680_set_fmt() to write to the exposure register. Not doing so fixes the exposure always being reset to the value from the res->regs array after a set_fmt(). Link: https://lore.kernel.org/linux-media/[email protected] Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit f04b8bdddf7a56308f3be018c6beb6af9a8fc0de Author: Mauro Carvalho Chehab <[email protected]> Date: Fri Oct 29 08:09:39 2021 +0100 media: atomisp: set per-device's default mode [ Upstream commit 2c45e343c581091835c9047ed5298518aa133163 ] The atomisp driver originally used the s_parm command to initialize the run_mode type to the driver. So, before start setting up the streaming, s_parm should be called. So, even having 5 "normal" video devices, one meant to be used for each type, the run_mode was actually selected when s_parm is called. Without setting the run mode, applications that don't call VIDIOC_SET_PARM with a custom atomisp parameters won't work, as the pipeline won't be set: atomisp-isp2 0000:00:03.0: can't create streams atomisp-isp2 0000:00:03.0: __get_frame_info 1600x1200 (padded to 0) returned -22 However, commit 8a7c5594c020 ("media: v4l2-ioctl: clear fields in s_parm") broke support for it, with a good reason, as drivers shoudn't be extending the API for their own purposes. So, as an step to allow generic apps to use this driver, put the device's run_mode in preview after open. After this patch, using v4l2grab starts to work on preview mode (/dev/video2): $ v4l2grab -f YUYV -x 1600 -y 1200 -d /dev/video2 -n 1 -u $ feh out000.pnm So, let's just setup the default run_mode that each video devnode should assume, setting it at open() time. Reported-by: Tsuchiya Yuto <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit d4c0cb23e5b368e9df953948456aa15a0b19f18d Author: Mauro Carvalho Chehab <[email protected]> Date: Thu Nov 4 11:45:27 2021 +0000 media: atomisp: fix try_fmt logic [ Upstream commit c9e9094c4e42124af909b2f5f6ded0498e0854ac ] The internal try_fmt logic is not meant to provide everything that the V4L2 API should provide. Also, it doesn't decrement the pads that are used only internally by the driver, but aren't part of the device's output. Fix it. Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 7be59e8a666098367574f927c3ba4a8754f419f4 Author: Ben Skeggs <[email protected]> Date: Wed Feb 24 19:29:52 2021 +1000 drm/nouveau/pmu/gm200-: avoid touching PMU outside of DEVINIT/PREOS/ACR [ Upstream commit 1d2271d2fb85e54bfc9630a6c30ac0feb9ffb983 ] There have been reports of the WFI timing out on some boards, and a patch was proposed to just remove it. This stuff is rather fragile, and I believe the WFI might be needed with our FW prior to GM200. However, we probably should not be touching PMU during init on GPUs where we depend on NVIDIA FW, outside of limited circumstances, so this should be a somewhat safer change that achieves the desired result. Reported-by: Diego Viola <[email protected]> Signed-off-by: Ben Skeggs <[email protected]> Reviewed-by: Karol Herbst <[email protected]> Signed-off-by: Karol Herbst <[email protected]> Link: https://gitlab.freedesktop.org/drm/nouveau/-/merge_requests/10 Signed-off-by: Sasha Levin <[email protected]> commit 0dedaf16ca439667e06c75df97563d20d00c3feb Author: Neil Armstrong <[email protected]> Date: Fri Oct 29 15:59:47 2021 +0200 drm/bridge: dw-hdmi: handle ELD when DRM_BRIDGE_ATTACH_NO_CONNECTOR [ Upstream commit 3f2532d65a571ca02258b547b5b68ab2e9406fdb ] The current ELD handling takes the internal connector ELD buffer and shares it to the I2S and AHB sub-driver. But with DRM_BRIDGE_ATTACH_NO_CONNECTOR, the connector is created elsewhere (or not), and an eventual connector is known only if the bridge chain up to a connector is enabled. The current dw-hdmi code gets the current connector from atomic_enable() so use the already stored connector pointer and replace the buffer pointer with a callback returning the current connector ELD buffer. Since a connector is not always available, either pass an empty ELD to the alsa HDMI driver or don't call snd_pcm_hw_constraint_eld() in AHB driver. Reported-by: Martin Blumenstingl <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> [narmstrong: fixed typo in commit log] Acked-by: Jernej Skrabec <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit fbcd1e9f8a4306cea72195292658ab51f7722b98 Author: Zekun Shen <[email protected]> Date: Thu Oct 28 18:37:49 2021 -0400 ar5523: Fix null-ptr-deref with unexpected WDCMSG_TARGET_START reply [ Upstream commit ae80b6033834342601e99f74f6a62ff5092b1cee ] Unexpected WDCMSG_TARGET_START replay can lead to null-ptr-deref when ar->tx_cmd->odata is NULL. The patch adds a null check to prevent such case. KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] ar5523_cmd+0x46a/0x581 [ar5523] ar5523_probe.cold+0x1b7/0x18da [ar5523] ? ar5523_cmd_rx_cb+0x7a0/0x7a0 [ar5523] ? __pm_runtime_set_status+0x54a/0x8f0 ? _raw_spin_trylock_bh+0x120/0x120 ? pm_runtime_barrier+0x220/0x220 ? __pm_runtime_resume+0xb1/0xf0 usb_probe_interface+0x25b/0x710 really_probe+0x209/0x5d0 driver_probe_device+0xc6/0x1b0 device_driver_attach+0xe2/0x120 I found the bug using a custome USBFuzz port. It's a research work to fuzz USB stack/drivers. I modified it to fuzz ath9k driver only, providing hand-crafted usb descriptors to QEMU. After fixing the code (fourth byte in usb packet) to WDCMSG_TARGET_START, I got the null-ptr-deref bug. I believe the bug is triggerable whenever cmd->odata is NULL. After patching, I tested with the same input and no longer see the KASAN report. This was NOT tested on a real device. Signed-off-by: Zekun Shen <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 1f1161c9bb4783ab7ab081e225d4b65407bd1ef4 Author: Andrii Nakryiko <[email protected]> Date: Sun Nov 7 08:55:21 2021 -0800 selftests/bpf: Fix bpf_object leak in skb_ctx selftest [ Upstream commit 8c7a95520184b6677ca6075e12df9c208d57d088 ] skb_ctx selftest didn't close bpf_object implicitly allocated by bpf_prog_test_load() helper. Fix the problem by explicitly calling bpf_object__close() at the end of the test. Signed-off-by: Andrii Nakryiko <[email protected]> Signed-off-by: Alexei Starovoitov <[email protected]> Reviewed-by: Hengqi Chen <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 57d3ec1106fcbde49083adbb7feb8930d1a787a2 Author: Andrii Nakryiko <[email protected]> Date: Sun Nov 7 08:55:20 2021 -0800 selftests/bpf: Destroy XDP link correctly [ Upstream commit f91231eeeed752119f49eb6620cae44ec745a007 ] bpf_link__detach() was confused with bpf_link__destroy() and leaves leaked FD in the process. Fix the problem. Signed-off-by: Andrii Nakryiko <[email protected]> Signed-off-by: Alexei Starovoitov <[email protected]> Reviewed-by: Hengqi Chen <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 7ffd2af8085c845f6935fe93768812439ce3b14b Author: Andrii Nakryiko <[email protected]> Date: Sun Nov 7 08:55:15 2021 -0800 selftests/bpf: Fix memory leaks in btf_type_c_dump() helper [ Upstream commit 8ba285874913da21ca39a46376e9cc5ce0f45f94 ] Free up memory and resources used by temporary allocated memstream and btf_dump instance. Signed-off-by: Andrii Nakryiko <[email protected]> Signed-off-by: Alexei Starovoitov <[email protected]> Reviewed-by: Hengqi Chen <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 9c46c1f1d2acc00151bd92959634fef74641c7e6 Author: Qiang Yu <[email protected]> Date: Sun Oct 31 12:16:04 2021 +0800 drm/lima: fix warning when CONFIG_DEBUG_SG=y & CONFIG_DMA_API_DEBUG=y [ Upstream commit 89636a06fa2ee7826a19c39c19a9bc99ab9340a9 ] Otherwise get following warning: DMA-API: lima 1c40000.gpu: mapping sg segment longer than device claims to support [len=4149248] [max=65536] See: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5496 Reviewed-by: Vasily Khoruzhick <[email protected]> Reported-by: Roman Stratiienko <[email protected]> Signed-off-by: Qiang Yu <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 5dc41e6caecc2c66646600f85f69f6f9982ee087 Author: Alexander Aring <[email protected]> Date: Tue Nov 2 15:17:24 2021 -0400 fs: dlm: filter user dlm messages for kernel locks [ Upstream commit 6c2e3bf68f3e5e5a647aa52be246d5f552d7496d ] This patch fixes the following crash by receiving a invalid message: [ 160.672220] ================================================================== [ 160.676206] BUG: KASAN: user-memory-access in dlm_user_add_ast+0xc3/0x370 [ 160.679659] Read of size 8 at addr 00000000deadbeef by task kworker/u32:13/319 [ 160.681447] [ 160.681824] CPU: 10 PID: 319 Comm: kworker/u32:13 Not tainted 5.14.0-rc2+ #399 [ 160.683472] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.14.0-1.module+el8.6.0+12648+6ede71a5 04/01/2014 [ 160.685574] Workqueue: dlm_recv process_recv_sockets [ 160.686721] Call Trace: [ 160.687310] dump_stack_lvl+0x56/0x6f [ 160.688169] ? dlm_user_add_ast+0xc3/0x370 [ 160.689116] kasan_report.cold.14+0x116/0x11b [ 160.690138] ? dlm_user_add_ast+0xc3/0x370 [ 160.690832] dlm_user_add_ast+0xc3/0x370 [ 160.691502] _receive_unlock_reply+0x103/0x170 [ 160.692241] _receive_message+0x11df/0x1ec0 [ 160.692926] ? rcu_read_lock_sched_held+0xa1/0xd0 [ 160.693700] ? rcu_read_lock_bh_held+0xb0/0xb0 [ 160.694427] ? lock_acquire+0x175/0x400 [ 160.695058] ? do_purge.isra.51+0x200/0x200 [ 160.695744] ? lock_acquired+0x360/0x5d0 [ 160.696400] ? lock_contended+0x6a0/0x6a0 [ 160.697055] ? lock_release+0x21d/0x5e0 [ 160.697686] ? lock_is_held_type+0xe0/0x110 [ 160.698352] ? lock_is_held_type+0xe0/0x110 [ 160.699026] ? ___might_sleep+0x1cc/0x1e0 [ 160.699698] ? dlm_wait_requestqueue+0x94/0x140 [ 160.700451] ? dlm_process_requestqueue+0x240/0x240 [ 160.701249] ? down_write_killable+0x2b0/0x2b0 [ 160.701988] ? do_raw_spin_unlock+0xa2/0x130 [ 160.702690] dlm_receive_buffer+0x1a5/0x210 [ 160.703385] dlm_process_incoming_buffer+0x726/0x9f0 [ 160.704210] receive_from_sock+0x1c0/0x3b0 [ 160.704886] ? dlm_tcp_shutdown+0x30/0x30 [ 160.705561] ? lock_acquire+0x175/0x400 [ 160.706197] ? rcu_read_lock_sched_held+0xa1/0xd0 [ 160.706941] ? rcu_read_lock_bh_held+0xb0/0xb0 [ 160.707681] process_recv_sockets+0x32/0x40 [ 160.708366] process_one_work+0x55e/0xad0 [ 160.709045] ? pwq_dec_nr_in_flight+0x110/0x110 [ 160.709820] worker_thread+0x65/0x5e0 [ 160.710423] ? process_one_work+0xad0/0xad0 [ 160.711087] kthread+0x1ed/0x220 [ 160.711628] ? set_kthread_struct+0x80/0x80 [ 160.712314] ret_from_fork+0x22/0x30 The issue is that we received a DLM message for a user lock but the destination lock is a kernel lock. Note that the address which is trying to derefence is 00000000deadbeef, which is in a kernel lock lkb->lkb_astparam, this field should never be derefenced by the DLM kernel stack. In case of a user lock lkb->lkb_astparam is lkb->lkb_ua (memory is shared by a union field). The struct lkb_ua will be handled by the DLM kernel stack but on a kernel lock it will contain invalid data and ends in most likely crashing the kernel. It can be reproduced with two cluster nodes. node 2: dlm_tool join test echo "862 fooobaar 1 2 1" > /sys/kernel/debug/dlm/test_locks echo "862 3 1" > /sys/kernel/debug/dlm/test_waiters node 1: dlm_tool join test python: foo = DLM(h_cmd=3, o_nextcmd=1, h_nodeid=1, h_lockspace=0x77222027, \ m_type=7, m_flags=0x1, m_remid=0x862, m_result=0xFFFEFFFE) newFile = open("/sys/kernel/debug/dlm/comms/2/rawmsg", "wb") newFile.write(bytes(foo)) Signed-off-by: Alexander Aring <[email protected]> Signed-off-by: David Teigland <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 41966cae91f1446449fba546f870e62eb39904aa Author: Archie Pusaka <[email protected]> Date: Thu Oct 28 19:17:25 2021 +0800 Bluetooth: Fix removing adv when processing cmd complete [ Upstream commit 2128939fe2e771645dd88e1938c27fdf96bd1cd0 ] If we remove one instance of adv using Set Extended Adv Enable, there is a possibility of issue occurs when processing the Command Complete event. Especially, the adv_info might not be found since we already remove it in hci_req_clear_adv_instance() -> hci_remove_adv_instance(). If that's the case, we will mistakenly proceed to remove all adv instances instead of just one single instance. This patch fixes the issue by checking the content of the HCI command instead of checking whether the adv_info is found. Signed-off-by: Archie Pusaka <[email protected]> Reviewed-by: Sonny Sasaka <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 57347363de0bc55adb5dbb3f2f5739f3f38d9b63 Author: Brian Norris <[email protected]> Date: Thu Sep 23 17:33:55 2021 -0700 drm/panel: Delete panel on mipi_dsi_attach() failure [ Upstream commit 9bf7123bb07f98dc76acb5daa91248e6f95713cb ] Many DSI panel drivers fail to clean up their panel references on mipi_dsi_attach() failure, so we're leaving a dangling drm_panel reference to freed memory. Clean that up on failure. Noticed by inspection, after seeing similar problems on other drivers. Therefore, I'm not marking Fixes/stable. Signed-off-by: Brian Norris <[email protected]> Signed-off-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20210923173336.3.If9e74fa9b1d6eaa9e0e5b95b2b957b992740251c@changeid Signed-off-by: Sasha Levin <[email protected]> commit 493c7d56ac22bcea643750ffb8dcbda8a62b5472 Author: Wei Yongjun <[email protected]> Date: Wed Oct 13 16:55:01 2021 +0800 Bluetooth: Fix memory leak of hci device [ Upstream commit 75d9b8559ac36e059238ee4f8e33cd86086586ba ] Fault injection test reported memory leak of hci device as follows: unreferenced object 0xffff88800b858000 (size 8192): comm "kworker/0:2", pid 167, jiffies 4294955747 (age 557.148s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 ad 4e ad de .............N.. backtrace: [<0000000070eb1059>] kmem_cache_alloc_trace mm/slub.c:3208 [<00000000015eb521>] hci_alloc_dev_priv include/linux/slab.h:591 [<00000000dcfc1e21>] bpa10x_probe include/net/bluetooth/hci_core.h:1240 [<000000005d3028c7>] usb_probe_interface drivers/usb/core/driver.c:397 [<00000000cbac9243>] really_probe drivers/base/dd.c:517 [<0000000024cab3f0>] __driver_probe_device drivers/base/dd.c:751 [<00000000202135cb>] driver_probe_device drivers/base/dd.c:782 [<000000000761f2bc>] __device_attach_driver drivers/base/dd.c:899 [<00000000f7d63134>] bus_for_each_drv drivers/base/bus.c:427 [<00000000c9551f0b>] __device_attach drivers/base/dd.c:971 [<000000007f79bd16>] bus_probe_device drivers/base/bus.c:487 [<000000007bb8b95a>] device_add drivers/base/core.c:3364 [<000000009564d9ea>] usb_set_configuration drivers/usb/core/message.c:2171 [<00000000e4657087>] usb_generic_driver_probe drivers/usb/core/generic.c:239 [<0000000071ede518>] usb_probe_device drivers/usb/core/driver.c:294 [<00000000cbac9243>] really_probe drivers/base/dd.c:517 hci_alloc_dev() do not init the device's flag. And hci_free_dev() using put_device() to free the memory allocated for this device, but it calls just put_device(dev) only in case of HCI_UNREGISTER flag is set, So any error handing before hci_register_dev() success will cause memory leak. To avoid this behaviour we can using kfree() to release dev before hci_register_dev() success. Signed-off-by: Wei Yongjun <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit d86db46b5cf5f02dc8c54da3b31d90e3dc7b02cd Author: Wei Yongjun <[email protected]> Date: Wed Oct 13 16:55:46 2021 +0800 Bluetooth: Fix debugfs entry leak in hci_register_dev() [ Upstream commit 5a4bb6a8e981d3d0d492aa38412ee80b21033177 ] Fault injection test report debugfs entry leak as follows: debugfs: Directory 'hci0' with parent 'bluetooth' already present! When register_pm_notifier() failed in hci_register_dev(), the debugfs create by debugfs_create_dir() do not removed in the error handing path. Add the remove debugfs code to fix it. Signed-off-by: Wei Yongjun <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit b03b18f0d1e913e4f9b9f251f6791962b3c781e9 Author: Merlijn Wajer <[email protected]> Date: Sun Dec 12 23:40:07 2021 +0100 leds: lp55xx: initialise output direction from dts [ Upstream commit 9e87a8da747bf72365abb79e6f64fcca955b4f56 ] Commit a5d3d1adc95f ("leds: lp55xx: Initialize enable GPIO direction to output") attempts to fix this, but the fix did not work since at least for the Nokia N900 the value needs to be set to HIGH, per the device tree. So rather than hardcoding the value to a potentially invalid value for some devices, let's set direction in lp55xx_init_device. Fixes: a5d3d1adc95f ("leds: lp55xx: Initialize enable GPIO direction to output") Fixes: 92a81562e695 ("leds: lp55xx: Add multicolor framework support to lp55xx") Fixes: ac219bf3c9bd ("leds: lp55xx: Convert to use GPIO descriptors") Signed-off-by: Merlijn Wajer <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Signed-off-by: Pavel Machek <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit bc8c07fcb49212f125c2a35e2dff25d98d15163b Author: Sicelo A. Mhlongo <[email protected]> Date: Sun Dec 12 23:40:06 2021 +0100 ARM: dts: omap3-n900: Fix lp5523 for multi color [ Upstream commit e9af026a3b24f59d7af4609f73e0ef60a4d6d516 ] Since the LED multicolor framework support was added in commit 92a81562e695 ("leds: lp55xx: Add multicolor framework support to lp55xx") LEDs on this platform stopped working. Fixes: 92a81562e695 ("leds: lp55xx: Add multicolor framework support to lp55xx") Fixes: ac219bf3c9bd ("leds: lp55xx: Convert to use GPIO descriptors") Signed-off-by: Merlijn Wajer <[email protected]> Signed-off-by: Sicelo A. Mhlongo <[email protected]> Signed-off-by: Pavel Machek <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 55f8559ba8d354acc1896a129133b5a3d61453f1 Author: jason-jh.lin <[email protected]> Date: Thu Dec 23 22:51:55 2021 +0800 mailbox: fix gce_num of mt8192 driver data [ Upstream commit 35ca43710f792ce183312fdc7e4b2bb0b721a173 ] Because mt8192 only have 1 gce, the gce_num should be 1. Fixes: 85dfdbfc13ea ("mailbox: cmdq: add multi-gce clocks support for mt8195") Signed-off-by: jason-jh.lin <[email protected]> Reviewed-by: Matthias Brugger <[email protected]> Signed-off-by: Jassi Brar <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 38e9447399ff98c94f8a57951319fa8d56014759 Author: Paul Cercueil <[email protected]> Date: Fri Jan 7 18:57:22 2022 +0000 MIPS: compressed: Fix build with ZSTD compression [ Upstream commit c5c7440fe7f74645940d5c9e2c49cd7efb706a4f ] Fix the following build issues: mips64el-linux-ld: arch/mips/boot/compressed/decompress.o: in function `FSE_buildDTable_internal': decompress.c:(.text.FSE_buildDTable_internal+0x2cc): undefined reference to `__clzdi2' mips64el-linux-ld: arch/mips/boot/compressed/decompress.o: in function `BIT_initDStream': decompress.c:(.text.BIT_initDStream+0x7c): undefined reference to `__clzdi2' mips64el-linux-ld: decompress.c:(.text.BIT_initDStream+0x158): undefined reference to `__clzdi2' mips64el-linux-ld: arch/mips/boot/compressed/decompress.o: in function `ZSTD_buildFSETable_body_default.constprop.0': decompress.c:(.text.ZSTD_buildFSETable_body_default.constprop.0+0x2a8): undefined reference to `__clzdi2' mips64el-linux-ld: arch/mips/boot/compressed/decompress.o: in function `FSE_readNCount_body_default': decompress.c:(.text.FSE_readNCount_body_default+0x130): undefined reference to `__ctzdi2' mips64el-linux-ld: decompress.c:(.text.FSE_readNCount_body_default+0x1a4): undefined reference to `__ctzdi2' mips64el-linux-ld: decompress.c:(.text.FSE_readNCount_body_default+0x2e4): undefined reference to `__clzdi2' mips64el-linux-ld: arch/mips/boot/compressed/decompress.o: in function `HUF_readStats_body_default': decompress.c:(.text.HUF_readStats_body_default+0x184): undefined reference to `__clzdi2' mips64el-linux-ld: decompress.c:(.text.HUF_readStats_body_default+0x1b4): undefined reference to `__clzdi2' mips64el-linux-ld: arch/mips/boot/compressed/decompress.o: in function `ZSTD_DCtx_getParameter': decompress.c:(.text.ZSTD_DCtx_getParameter+0x60): undefined reference to `__clzdi2' Fixes: a510b616131f ("MIPS: Add support for ZSTD-compressed kernels") Reported-by: kernel test robot <[email protected]> Reported-by: Nick Terrell <[email protected]> Signed-off-by: Paul Cercueil <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 925b35b54583129c5addae509885428bfbfe8fa9 Author: Paul Cercueil <[email protected]> Date: Fri Nov 19 17:50:52 2021 +0000 MIPS: boot/compressed/: add __ashldi3 to target for ZSTD compression [ Upstream commit fbf3bce458214bb971d3d571515b3b129eac290b ] Just like before with __bswapdi2(), for MIPS pre-boot when CONFIG_KERNEL_ZSTD=y the decompressor function will use __ashldi3(), so the object file should be added to the target object file. Fixes these build errors: mipsel-linux-ld: arch/mips/boot/compressed/decompress.o: in function `FSE_buildDTable_internal': decompress.c:(.text.FSE_buildDTable_internal+0x48): undefined reference to `__ashldi3' mipsel-linux-ld: arch/mips/boot/compressed/decompress.o: in function `FSE_decompress_wksp_body_default': decompress.c:(.text.FSE_decompress_wksp_body_default+0xa8): undefined reference to `__ashldi3' mipsel-linux-ld: arch/mips/boot/compressed/decompress.o: in function `ZSTD_getFrameHeader_advanced': decompress.c:(.text.ZSTD_getFrameHeader_advanced+0x134): undefined reference to `__ashldi3' Signed-off-by: Paul Cercueil <[email protected]> Reviewed-by: Randy Dunlap <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit c19b9b755482162bab71a63a639d6df2fce90add Author: Stephen Boyd <[email protected]> Date: Fri Jan 7 11:42:32 2022 -0800 of/fdt: Don't worry about non-memory region overlap for no-map [ Upstream commit da17d6905d29ddcdc04b2fdc37ed8cf1e8437cc8 ] In commit 8a5a75e5e9e5 ("of/fdt: Make sure no-map does not remove already reserved regions") we returned -EBUSY when trying to mark regions as no-map when they intersect with reserved memory. The goal was to find bad no-map reserved memory DT nodes that would unmap the kernel text/data sections. The problem is the reserved memory check will still trigger if the DT has a /memreserve/ that completely subsumes the no-map memory carveouts in the reserved memory node _and_ that region is also not part of the memory reg property. For example in sc7180.dtsi we have the following reserved-memory and memory node: memory@80000000 { /* We expect the bootloader to fill in the size */ reg = <0 0x80000000 0 0>; }; smem_mem: memory@80900000 { reg = <0x0 0x80900000 0x0 0x200000>; no-map; }; and the memreserve filled in by the bootloader is /memreserve/ 0x80800000 0x400000; while the /memory node is transformed into memory@80000000 { /* The bootloader fills in the size, and adds another region */ reg = <0 0x80000000 0 0x00800000>, <0 0x80c00000 0 0x7f200000>; }; The smem region is doubly reserved via /memreserve/ and by not being part of the /memory reg property. This leads to the following warning printed at boot. OF: fdt: Reserved memory: failed to reserve memory for node 'memory@80900000': base 0x0000000080900000, size 2 MiB Otherwise nothing really goes wrong because the smem region is not going to be mapped by the kernel's direct linear mapping given that it isn't part of the memory node. Therefore, let's only consider this to be a problem if we're trying to mark a region as no-map and it is actually memory that we're intending to keep out of the kernel's direct mapping but it's already been reserved. Acked-by: Mike Rapoport <[email protected]> Cc: Douglas Anderson <[email protected]> Cc: Nicolas Boichat <[email protected]> Cc: Quentin Perret <[email protected]> Cc: Jan Kiszka <[email protected]> Fixes: 8a5a75e5e9e5 ("of/fdt: Make sure no-map does not remove already reserved regions") Signed-off-by: Stephen Boyd <[email protected]> Signed-off-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit dc4e2dbe6171f1c163507164d525a6aa1a1745a2 Author: Baruch Siach <[email protected]> Date: Thu Dec 30 18:31:52 2021 +0200 of: base: Fix phandle argument length mismatch error message [ Upstream commit 94a4950a4acff39b5847cc1fee4f65e160813493 ] The cell_count field of of_phandle_iterator is the number of cells we expect in the phandle arguments list when cells_name is missing. The error message should show the number of cells we actually see. Fixes: af3be70a3211 ("of: Improve of_phandle_iterator_next() error message") Cc: Florian Fainelli <[email protected]> Signed-off-by: Baruch Siach <[email protected]> Signed-off-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/96519ac55be90a63fa44afe01480c30d08535465.1640881913.git.baruch@tkos.co.il Signed-off-by: Sasha Levin <[email protected]> commit 91dcfc658d38ad6e434c8957dc29d157e753d3aa Author: Conor Dooley <[email protected]> Date: Thu Dec 23 15:42:44 2021 +0000 clk: bm1880: remove kfrees on static allocations [ Upstream commit c861c1be3897845313a0df47804b1db37c7052e1 ] bm1880_clk_unregister_pll & bm1880_clk_unregister_div both try to free statically allocated variables, so remove those kfrees. For example, if we take L703 kfree(div_hw): - div_hw is a bm1880_div_hw_clock pointer - in bm1880_clk_register_plls this is pointed to an element of arg1: struct bm1880_div_hw_clock *clks - in the probe, where bm1880_clk_register_plls is called arg1 is bm1880_div_clks, defined on L371: static struct bm1880_div_hw_clock bm1880_div_clks[] Signed-off-by: Conor Dooley <[email protected]> Fixes: 1ab4601da55b ("clk: Add common clock driver for BM1880 SoC") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Stephen Boyd <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 8f5e866cbb97fd959a027ee185da3df7b16c5084 Author: Shengjiu Wang <[email protected]> Date: Wed Jan 5 19:08:03 2022 +0800 ASoC: fsl_asrc: refine the check of available clock divider [ Upstream commit 320386343451ab6a3577e0ee200dac56a6182944 ] According to RM, the clock divider range is from 1 to 8, clock prescaling ratio may be any power of 2 from 1 to 128. So the supported divider is not all the value between 1 and 1024, just limited value in that range. Create table for the supported divder and add function to check the clock divider is available by comparing with the table. Fixes: d0250cf4f2ab ("ASoC: fsl_asrc: Add an option to select internal ratio mode") Signed-off-by: Shengjiu Wang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 0cd1ef3f7b898b7bb30e0ef0c475764b4007195a Author: Shengjiu Wang <[email protected]> Date: Tue Jan 4 18:40:35 2022 +0800 ASoC: imx-card: improve the sound quality for low rate [ Upstream commit 3969341813eb56d2dfc39bb64229359a6ae3c195 ] According to RM, on auto mode: For codec AK4458 and AK4497, the lowest ratio of MLCK/FS is 256 if sample rate is 8kHz-48kHz, For codec AK5558, the lowest ratio of MLCK/FS is 512 if sample rate is 8kHz-48kHz. With these setting the sound quality for 8kHz-48kHz can be improved. Fixes: aa736700f42f ("ASoC: imx-card: Add imx-card machine driver") Signed-off-by: Shengjiu Wang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit edc07df0df20f0ae9944c4e141ea48458d0cbdd1 Author: Shengjiu Wang <[email protected]> Date: Tue Jan 4 18:40:34 2022 +0800 ASoC: imx-card: Fix mclk calculation issue for akcodec [ Upstream commit f331ae5fa59fbfb748317b290648fc3f1a50d932 ] Transfer the refined slots and slot_width to akcodec_get_mclk_rate() for mclk calculation, otherwise the mclk frequency does not match with the slots and slot_width for S16_LE format, because the default slot_width is 32. Fixes: aa736700f42f ("ASoC: imx-card: Add imx-card machine driver") Signed-off-by: Shengjiu Wang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 6bedc3b3d13015fb618533b1ecbd2de6cb0070ca Author: Shengjiu Wang <[email protected]> Date: Tue Jan 4 18:40:33 2022 +0800 ASoC: imx-card: Need special setting for ak4497 on i.MX8MQ [ Upstream commit 3349b3d0c63b8b6fcca58156d72407f0b2e101ac ] The SAI on i.MX8MQ don't support one2one ratio for mclk:bclk, so the mclk frequency exceeds the supported range of codec for the case that sample rate is larger than 705kHZ and format is S32_LE. Update the supported width for such case. Fixes: aa736700f42f ("ASoC: imx-card: Add imx-card machine driver") Signed-off-by: Shengjiu Wang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 35816546936d7487e1e54ce717da6f9c399cda17 Author: Taniya Das <[email protected]> Date: Mon Dec 20 22:13:56 2021 +0530 clk: qcom: gcc-sc7280: Mark gcc_cfg_noc_lpass_clk always enabled [ Upstream commit 9c337073d9d81a145434b22f42dc3128ecd17730 ] The gcc cfg noc lpass clock is required to be always enabled for the LPASS core and audio drivers to be functional. Fixes: a3cc092196ef ("clk: qcom: Add Global Clock controller (GCC) driver for SC7280") Signed-off-by: Taniya Das <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Stephen Boyd <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 60037a56e08b5b1e353d96269163965460a888f7 Author: Kamal Heib <[email protected]> Date: Mon Dec 20 17:25:30 2021 +0200 RDMA/cxgb4: Set queue pair state when being queried [ Upstream commit e375b9c92985e409c4bb95dd43d34915ea7f5e28 ] The API for ib_query_qp requires the driver to set cur_qp_state on return, add the missing set. Fixes: 67bbc05512d8 ("RDMA/cxgb4: Add query_qp support") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Kamal Heib <[email protected]> Reviewed-by: Leon Romanovsky <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 32faa4c17a566cfd0de6df91cc51baafdb266b30 Author: Christian A. Ehrhardt <[email protected]> Date: Fri Dec 31 14:44:32 2021 +0100 ALSA: hda/cs8409: Fix Jack detection after resume [ Upstream commit 57f234248ff925d88caedf4019ec84e6ecb83909 ] The suspend code unconditionally sets ->hp_jack_in and ->mic_jack_in to zero but without reporting this status change to the HDA core. To compensate for this, always assume a status change on the first unsol event after boot or resume. Fixes: 424e531b47f8 ("ALSA: hda/cs8409: Ensure Type Detection is only run on startup when necessary") Signed-off-by: Christian A. Ehrhardt <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit b624b5b2fe028ac28023e36c82b718ddd4a4c00a Author: Christian A. Ehrhardt <[email protected]> Date: Fri Dec 31 14:12:21 2021 +0100 ALSA: hda/cs8409: Increase delay during jack detection [ Upstream commit 8cd07657177006b67cc1610e4466cc75ad781c05 ] Commit c8b4f0865e82 reduced delays related to cs42l42 jack detection. However, the change was too aggressive. As a result internal speakers on DELL Inspirion 3501 are not detected. Increase the delay in cs42l42_run_jack_detect() a bit. Fixes: c8b4f0865e82 ("ALSA: hda/cs8409: Remove unnecessary delays") Signed-off-by: Christian A. Ehrhardt <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 65b517f4e0c65c80a9006eabc5ad418998690404 Author: Alyssa Ross <[email protected]> Date: Tue Jan 4 13:22:16 2022 +0000 ASoC: fsl_mqs: fix MODULE_ALIAS [ Upstream commit 9f3d45318dd9e739ed62e4218839a7a824d3cced ] modprobe can't handle spaces in aliases. Fixes: 9e28f6532c61 ("ASoC: fsl_mqs: Add MQS component driver") Signed-off-by: Alyssa Ross <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit ef9893bb73e75d1dae8680a6b755d370569113d7 Author: Ammar Faizi <[email protected]> Date: Sun Dec 26 20:54:02 2021 +0700 powerpc/xive: Add missing null check after calling kmalloc [ Upstream commit 18dbfcdedc802f9500b2c29794f22a31d27639c0 ] Commit 930914b7d528fc ("powerpc/xive: Add a debugfs file to dump internal XIVE state") forgot to add a null check. Add it. Fixes: 930914b7d528fc6b0249bffc00564100bcf6ef75 ("powerpc/xive: Add a debugfs file to dump internal XIVE state") Signed-off-by: Ammar Faizi <[email protected]> Reviewed-by: Cédric Le Goater <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit f1750bf326908ca210b49a5a630306820217362e Author: Randy Dunlap <[email protected]> Date: Tue Dec 28 16:05:53 2021 -0800 mips: bcm63xx: add support for clk_set_parent() [ Upstream commit 6f03055d508ff4feb8db02ba3df9303a1db8d381 ] The MIPS BMC63XX subarch does not provide/support clk_set_parent(). This causes build errors in a few drivers, so add a simple implementation of that function so that callers of it will build without errors. Fixes these build errors: ERROR: modpost: "clk_set_parent" [sound/soc/jz4740/snd-soc-jz4740-i2s.ko] undefined! ERROR: modpost: "clk_set_parent" [sound/soc/atmel/snd-soc-atmel-i2s.ko] undefined! Fixes: e7300d04bd08 ("MIPS: BCM63xx: Add support for the Broadcom BCM63xx family of SOCs." ) Signed-off-by: Randy Dunlap <[email protected]> Reviewed-by: Jonathan Cameron <[email protected]> Acked-by: Florian Fainelli <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit b88fea46621da1649dcd99712d39d6ab880a86fb Author: Randy Dunlap <[email protected]> Date: Tue Dec 28 16:03:45 2021 -0800 mips: lantiq: add support for clk_set_parent() [ Upstream commit 76f66dfd60dc5d2f9dec22d99091fea1035c5d03 ] Provide a simple implementation of clk_set_parent() in the lantiq subarch so that callers of it will build without errors. Fixes these build errors: ERROR: modpost: "clk_set_parent" [sound/soc/jz4740/snd-soc-jz4740-i2s.ko] undefined! ERROR: modpost: "clk_set_parent" [sound/soc/atmel/snd-soc-atmel-i2s.ko] undefined! Fixes: 171bb2f19ed6 ("MIPS: Lantiq: Add initial support for Lantiq SoCs") Signed-off-by: Randy Dunlap <[email protected]> Reported-by: kernel test robot <[email protected]> [email protected] --cc="John Crispin <[email protected]>" --cc="Jonathan Cameron <[email protected]>" --cc="Russell King <[email protected]>" --cc="Andy Shevchenko <[email protected]>" [email protected] --to="Thomas Bogendoerfer <[email protected]>" Reviewed-by: Jonathan Cameron <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit a92e8b510fb4b1cfaebe65cdf5d1b8423fb03712 Author: Sameer Pujar <[email protected]> Date: Thu Dec 23 17:23:51 2021 +0530 arm64: tegra: Remove non existent Tegra194 reset [ Upstream commit 146b3a77af8091cabbd1decc51d67799e69682d2 ] Tegra194 does not really have "hda2codec_2x" related reset. Hence drop this entry to reflect actual HW. Fixes: 4878cc0c9fab ("arm64: tegra: Add HDA controller on Tegra194") Signed-off-by: Sameer Pujar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 78926da03360c3dbba0ccad8f934a8f7f5a29cc7 Author: Trevor Wu <[email protected]> Date: Thu Dec 30 16:47:30 2021 +0800 ASoC: mediatek: mt8195: correct pcmif BE dai control flow [ Upstream commit 2355028c0c54c03afb66c589347f1dc9f6fe2e38 ] Originally, the conditions for preventing reentry are not correct. dai->component->active is not the state specifically for pcmif dai, so it is not a correct condition to indicate the status of pcmif dai. On the other hand, snd_soc_dai_stream_actvie() in prepare ops for both playback and capture possibly return true at the first entry when these two streams are opened at the same time. In the patch, I refer to the implementation in mt8192-dai-pcm.c. Clock and enabling bit for PCMIF are managed by DAPM, and the condition for prepare ops is replaced by the status of dai widget. Fixes: 1f95c019115c ("ASoC: mediatek: mt8195: support pcm in platform driver") Signed-off-by: Trevor Wu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 1cf0a19e33ad7f3b435d99b52ab41ce4feb892a5 Author: Wei Yongjun <[email protected]> Date: Tue Dec 28 12:55:22 2021 +0000 misc: lattice-ecp3-config: Fix task hung when firmware load failed [ Upstream commit fcee5ce50bdb21116711e38635e3865594af907e ] When firmware load failed, kernel report task hung as follows: INFO: task xrun:5191 blocked for more than 147 seconds. Tainted: G W 5.16.0-rc5-next-20211220+ #11 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:xrun state:D stack: 0 pid: 5191 ppid: 270 flags:0x00000004 Call Trace: __schedule+0xc12/0x4b50 kernel/sched/core.c:4986 schedule+0xd7/0x260 kernel/sched/core.c:6369 (discriminator 1) schedule_timeout+0x7aa/0xa80 kernel/time/timer.c:1857 wait_for_completion+0x181/0x290 kernel/sched/completion.c:85 lattice_ecp3_remove+0x32/0x40 drivers/misc/lattice-ecp3-config.c:221 spi_remove+0x72/0xb0 drivers/spi/spi.c:409 lattice_ecp3_remove() wait for signals from firmware loading, but when load failed, firmware_load() does not send this signal. This cause device remove hung. Fix it by sending signal even if load failed. Fixes: 781551df57c7 ("misc: Add Lattice ECP3 FPGA configuration via SPI") Reported-by: Hulk Robot <[email protected]> Signed-off-by: Wei Yongjun <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit a17f93a1f0a5255d76ad879b971d23d2d6908165 Author: Jiasheng Jiang <[email protected]> Date: Tue Dec 28 11:40:26 2021 +0800 ASoC: samsung: idma: Check of ioremap return value [ Upstream commit 3ecb46755eb85456b459a1a9f952c52986bce8ec ] Because of the potential failure of the ioremap(), the buf->area could be NULL. Therefore, we need to check it and return -ENOMEM in order to transfer the error. Fixes: f09aecd50f39 ("ASoC: SAMSUNG: Add I2S0 internal dma driver") Signed-off-by: Jiasheng Jiang <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 8b5d69613b1297ca1cdc011ab4361b961b5b3f1b Author: Swapnil Jakhade <[email protected]> Date: Thu Dec 23 07:01:33 2021 +0100 phy: cadence: Sierra: Fix to get correct parent for mux clocks [ Upstream commit da08aab940092a050a4fb2857ed9479d2b0e03c4 ] Fix get_parent() callback to return the correct index of the parent for PLL_CMNLC1 clock. Add a separate table of register values corresponding to the parent index for PLL_CMNLC1. Update set_parent() callback accordingly. Fixes: 28081b72859f ("phy: cadence: Sierra: Model PLL_CMNLC and PLL_CMNLC1 as clocks (mux clocks)") Signed-off-by: Swapnil Jakhade <[email protected]> Reviewed-by: Aswath Govindraju <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit fca58a434425dc831cc8c0da192117d38f05b092 Author: Michael Ellerman <[email protected]> Date: Wed Dec 22 00:51:00 2021 +1100 powerpc/64s: Use EMIT_WARN_ENTRY for SRR debug warnings [ Upstream commit fd1eaaaaa6864b5fb8f99880fcefb49760b8fe4e ] When CONFIG_PPC_RFI_SRR_DEBUG=y we check the SRR values before returning from interrupts. This is done in asm using EMIT_BUG_ENTRY, and passing BUGFLAG_WARNING. However that fails to create an exception table entry for the warning, and so do_program_check() fails the exception table search and proceeds to call _exception(), resulting in an oops like: Oops: Exception in kernel mode, sig: 5 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries Modules linked in: CPU: 2 PID: 1204 Comm: sigreturn_unali Tainted: P 5.16.0-rc2-00194-g91ca3d4f77c5 #12 NIP: c00000000000c5b0 LR: 0000000000000000 CTR: 0000000000000000 ... NIP [c00000000000c5b0] system_call_common+0x150/0x268 LR [0000000000000000] 0x0 Call Trace: [c00000000db73e10] [c00000000000c558] system_call_common+0xf8/0x268 (unreliable) ... Instruction dump: 7cc803a6 888d0931 2c240000 4082001c 38800000 988d0931 e8810170 e8a10178 7c9a03a6 7cbb03a6 7d7a02a6 e9810170 <7f0b6088> 7d7b02a6 e9810178 7f0b6088 We should instead use EMIT_WARN_ENTRY, which creates an exception table entry for the warning, allowing the warning to be correctly recognised, and the code to resume after printing the warning. Note however that because this warning is buried deep in the interrupt return path, we are not able to recover from it (due to MSR_RI being clear), so we still end up in die() with an unrecoverable exception. Fixes: 59dc5bfca0cb ("powerpc/64s: avoid reloading (H)SRR registers if they are still valid") Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 5bb2d955e81bcba9cfb3a4880c6c4f0e5f25b524 Author: Michael Ellerman <[email protected]> Date: Wed Dec 22 00:50:59 2021 +1100 powerpc/64s: Mask NIP before checking against SRR0 [ Upstream commit 314f6c23dd8d417281eb9e8a516dd98036f2e7b3 ] When CONFIG_PPC_RFI_SRR_DEBUG=y we check that NIP and SRR0 match when returning from interrupts. This can trigger falsely if NIP has either of its two low bits set via sigreturn or ptrace, while SRR0 has its low two bits masked in hardware. As a quick fix make sure to mask the low bits before doing the check. Fixes: 59dc5bfca0cb ("powerpc/64s: avoid reloading (H)SRR registers if they are still valid") Reported-by: Sachin Sant <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Tested-by: Sachin Sant <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 38accfd85e41b7ca547c5a7d4866bbc1462950cb Author: Jiasheng Jiang <[email protected]> Date: Wed Dec 22 09:51:57 2021 +0800 ASoC: mediatek: Check for error clk pointer [ Upstream commit 9de2b9286a6dd16966959b3cb34fc2ddfd39213e ] Yes, you are right and now the return code depending on the init_clks(). Fixes: 6078c651947a ("soc: mediatek: Refine scpsys to support multiple platform") Signed-off-by: Jiasheng Jiang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 799b2c6cd7b6e8790edbe0c02c87f43d64bff89f Author: Ryuta NAKANISHI <[email protected]> Date: Wed Dec 22 14:19:29 2021 +0900 phy: uniphier-usb3ss: fix unintended writing zeros to PHY register [ Upstream commit 898c7a9ec81620125f2463714a0f4dea18ad6e54 ] Similar to commit 4a90bbb478db ("phy: uniphier-pcie: Fix updating phy parameters"), in function uniphier_u3ssphy_set_param(), unintentionally write zeros to other fields when writing PHY registers. Fixes: 5ab43d0f8697 ("phy: socionext: add USB3 PHY driver for UniPhier SoC") Signed-off-by: Ryuta NAKANISHI <[email protected]> Signed-off-by: Kunihiko Hayashi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit af8cab36bfb8b6836daf1b9a94a8bc211fe6f207 Author: Alan Stern <[email protected]> Date: Mon Dec 20 19:21:26 2021 +0800 scsi: block: pm: Always set request queue runtime active in blk_post_runtime_resume() [ Upstream commit 6e1fcab00a23f7fe9f4fe9704905a790efa1eeab ] John Garry reported a deadlock that occurs when trying to access a runtime-suspended SATA device. For obscure reasons, the rescan procedure causes the link to be hard-reset, which disconnects the device. The rescan tries to carry out a runtime resume when accessing the device. scsi_rescan_device() holds the SCSI device lock and won't release it until it can put commands onto the device's block queue. This can't happen until the queue is successfully runtime-resumed or the device is unregistered. But the runtime resume fails because the device is disconnected, and __scsi_remove_device() can't do the unregistration because it can't get the device lock. The best way to resolve this deadlock appears to be to allow the block queue to start running again even after an unsuccessful runtime resume. The idea is that the driver or the SCSI error handler will need to be able to use the queue to resolve the runtime resume failure. This patch removes the err argument to blk_post_runtime_resume() and makes the routine act as though the resume was successful always. This fixes the deadlock. Link: https://lore.kernel.org/r/[email protected] Fixes: e27829dc92e5 ("scsi: serialize ->rescan against ->remove") Reported-and-tested-by: John Garry <[email protected]> Reviewed-by: Bart Van Assche <[email protected]> Signed-off-by: Alan Stern <[email protected]> Signed-off-by: Xiang Chen <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit e421973fbe6e9490e3cf3ee2ab38a739928243d0 Author: Pingfan Liu <[email protected]> Date: Wed Dec 15 10:13:48 2021 +0800 efi: apply memblock cap after memblock_add() [ Upstream commit b398123bff3bcbc1facb0f29bf6e7b9f1bc55931 ] On arm64, during kdump kernel saves vmcore, it runs into the following bug: ... [ 15.148919] usercopy: Kernel memory exposure attempt detected from SLUB object 'kmem_cache_node' (offset 0, size 4096)! [ 15.159707] ------------[ cut here ]------------ [ 15.164311] kernel BUG at mm/usercopy.c:99! [ 15.168482] Internal error: Oops - BUG: 0 [#1] SMP [ 15.173261] Modules linked in: xfs libcrc32c crct10dif_ce ghash_ce sha2_ce sha256_arm64 sha1_ce sbsa_gwdt ast i2c_algo_bit drm_vram_helper drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec drm_ttm_helper ttm drm nvme nvme_core xgene_hwmon i2c_designware_platform i2c_designware_core dm_mirror dm_region_hash dm_log dm_mod overlay squashfs zstd_decompress loop [ 15.206186] CPU: 0 PID: 542 Comm: cp Not tainted 5.16.0-rc4 #1 [ 15.212006] Hardware name: GIGABYTE R272-P30-JG/MP32-AR0-JG, BIOS F12 (SCP: 1.5.20210426) 05/13/2021 [ 15.221125] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 15.228073] pc : usercopy_abort+0x9c/0xa0 [ 15.232074] lr : usercopy_abort+0x9c/0xa0 [ 15.236070] sp : ffff8000121abba0 [ 15.239371] x29: ffff8000121abbb0 x28: 0000000000003000 x27: 0000000000000000 [ 15.246494] x26: 0000000080000400 x25: 0000ffff885c7000 x24: 0000000000000000 [ 15.253617] x23: 000007ff80400000 x22: ffff07ff80401000 x21: 0000000000000001 [ 15.260739] x20: 0000000000001000 x19: ffff07ff80400000 x18: ffffffffffffffff [ 15.267861] x17: 656a626f2042554c x16: 53206d6f72662064 x15: 6574636574656420 [ 15.274983] x14: 74706d6574746120 x13: 2129363930342065 x12: 7a6973202c302074 [ 15.282105] x11: ffffc8b041d1b148 x10: 00000000ffff8000 x9 : ffffc8b04012812c [ 15.289228] x8 : 00000000ffff7fff x7 : ffffc8b041d1b148 x6 : 0000000000000000 [ 15.296349] x5 : 0000000000000000 x4 : 0000000000007fff x3 : 0000000000000000 [ 15.303471] x2 : 0000000000000000 x1 : ffff07ff8c064800 x0 : 000000000000006b [ 15.310593] Call trace: [ 15.313027] usercopy_abort+0x9c/0xa0 [ 15.316677] __check_heap_object+0xd4/0xf0 [ 15.320762] __check_object_size.part.0+0x160/0x1e0 [ 15.325628] __check_object_size+0x2c/0x40 [ 15.329711] copy_oldmem_page+0x7c/0x140 [ 15.333623] read_from_oldmem.part.0+0xfc/0x1c0 [ 15.338142] __read_vmcore.constprop.0+0x23c/0x350 [ 15.342920] read_vmcore+0x28/0x34 [ 15.346309] proc_reg_read+0xb4/0xf0 [ 15.349871] vfs_read+0xb8/0x1f0 [ 15.353088] ksys_read+0x74/0x100 [ 15.356390] __arm64_sys_read+0x28/0x34 ... This bug introduced by commit b261dba2fdb2 ("arm64: kdump: Remove custom linux,usable-memory-range handling"), which moves memblock_cap_memory_range() to fdt, but it breaches the rules that memblock_cap_memory_range() should come after memblock_add() etc as said in commit e888fa7bb882 ("memblock: Check memory add/cap ordering"). As a consequence, the virtual address set up by copy_oldmem_page() does not bail out from the test of virt_addr_valid() in check_heap_object(), and finally hits the BUG_ON(). Since memblock allocator has no idea about when the memblock is fully populated, while efi_init() is aware, so tackling this issue by calling the interface early_init_dt_check_for_usable_mem_range() exposed by of/fdt. Fixes: b261dba2fdb2 ("arm64: kdump: Remove custom linux,usable-memory-range handling") Signed-off-by: Pingfan Liu <[email protected]> Cc: Rob Herring <[email protected]> Cc: Zhen Lei <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Will Deacon <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Mike Rapoport <[email protected]> Cc: Geert Uytterhoeven <[email protected]> Cc: Frank Rowand <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Nick Terrell <[email protected]> Cc: [email protected] To: [email protected] To: [email protected] Acked-by: Ard Biesheuvel <[email protected]> Signed-off-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 77d37071811be224062eae8e63308c24afe96449 Author: Zhen Lei <[email protected]> Date: Tue Dec 14 12:01:56 2021 +0800 of: fdt: Aggregate the processing of "linux,usable-memory-range" [ Upstream commit 8347b41748c3019157312fbe7f8a6792ae396eb7 ] Currently, we parse the "linux,usable-memory-range" property in early_init_dt_scan_chosen(), to obtain the specified memory range of the crash kernel. We then reserve the required memory after early_init_dt_scan_memory() has identified all available physical memory. Because the two pieces of code are separated far, the readability and maintainability are reduced. So bring them together. Suggested-by: Rob Herring <[email protected]> Signed-off-by: Zhen Lei <[email protected]> (change the prototype of early_init_dt_check_for_usable_mem_range(), in order to use it outside) Signed-off-by: Pingfan Liu <[email protected]> Tested-by: Dave Kleikamp <[email protected]> Acked-by: John Donnelly <[email protected]> Reviewed-by: Rob Herring <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Will Deacon <[email protected]> Cc: [email protected] To: [email protected] To: [email protected] Signed-off-by: Rob Herring <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 073d9a2237b1e9a54ea1b928bfcdfd30afaa0ad8 Author: Trevor Wu <[email protected]> Date: Thu Dec 16 10:24:24 2021 +0800 ASoC: mediatek: mt8195: correct default value [ Upstream commit 30e693ee82d20361f2caacca3b68c79e1a7cb16c ] mt8195_cg_patch is used to reset the default value of audio cg, so the register value could be consistent with CCF reference count. Nevertheless, AUDIO_TOP_CON1[1:0] is used to control an internal mux, and it's expected to keep the default value 0. This patch corrects the default value in case an unexpected behavior happens in the future. Fixes: 6746cc8582599 ("ASoC: mediatek: mt8195: add platform driver") Signed-off-by: Trevor Wu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit ef0af09d411386754d049e468025b4b3216869aa Author: Xiongfeng Wang <[email protected]> Date: Fri Dec 17 15:30:55 2021 +0000 iommu/iova: Fix race between FQ timeout and teardown [ Upstream commit d7061627d701c90e1cac1e1e60c45292f64f3470 ] It turns out to be possible for hotplugging out a device to reach the stage of tearing down the device's group and default domain before the domain's flush queue has drained naturally. At this point, it is then possible for the timeout to expire just before the del_timer() call in free_iova_flush_queue(), such that we then proceed to free the FQ resources while fq_flush_timeout() is still accessing them on another CPU. Crashes due to this have been observed in the wild while removing NVMe devices. Close the race window by using del_timer_sync() to safely wait for any active timeout handler to finish before we start to free things. We already avoid any locking in free_iova_flush_queue() since the FQ is supposed to be inactive anyway, so the potential deadlock scenario does not apply. Fixes: 9a005a800ae8 ("iommu/iova: Add flush timer") Reviewed-by: John Garry <[email protected]> Signed-off-by: Xiongfeng Wang <[email protected]> [ rm: rewrite commit message ] Signed-off-by: Robin Murphy <[email protected]> Link: https://lore.kernel.org/r/0a365e5b07f14b7344677ad6a9a734966a8422ce.1639753638.git.robin.murphy@arm.com Signed-off-by: Joerg Roedel <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 56c3b723859416be3c5bb3b86cab7f8fc8087868 Author: Cezary Rojewski <[email protected]> Date: Thu Dec 16 12:57:39 2021 +0100 ASoC: Intel: catpt: Test dmaengine_submit() result before moving on [ Upstream commit 2a9a72e290d4a4741e673f86b9fba9bfb319786d ] After calling dmaengine_submit(), the submitted transfer descriptor belongs to the DMA engine. Pointer to that descriptor may no longer be valid after the call and should be tested before awaiting transfer completion. Reported-by: Kevin Tian <[email protected]> Suggested-by: Dave Jiang <[email protected]> Fixes: 4fac9b31d0b9 ("ASoC: Intel: Add catpt base members") Signed-off-by: Cezary Rojewski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 9bc6d3abccbfd46ca22488201622c0b42e68c347 Author: Maxim Levitsky <[email protected]> Date: Tue Nov 23 18:10:38 2021 +0200 iommu/amd: Remove useless irq affinity notifier [ Upstream commit 575f5cfb13c84f324f9898383fa4a5694e53c9ef ] iommu->intcapxt_notify field is no longer used after a switch to a separate domain was done Fixes: d1adcfbb520c ("iommu/amd: Fix IOMMU interrupt generation in X2APIC mode") Signed-off-by: Maxim Levitsky <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 7e7e12092a6670e9b487b059f608b07daae26147 Author: Maxim Levitsky <[email protected]> Date: Tue Nov 23 18:10:37 2021 +0200 iommu/amd: X2apic mode: mask/unmask interrupts on suspend/resume [ Upstream commit 1980105e3cfc2215c75b4f6b172661d675c467d1 ] Use IRQCHIP_MASK_ON_SUSPEND to make the core irq code to mask the iommu interrupt on suspend and unmask it on the resume. Since now the unmask function updates the INTX settings, that will restore them on resume from s3/s4. Since IRQCHIP_MASK_ON_SUSPEND is only effective for interrupts which are not wakeup sources, remove IRQCHIP_SKIP_SET_WAKE flag and instead implement a dummy .irq_set_wake which doesn't allow the interrupt to become a wakeup source. Fixes: 66929812955bb ("iommu/amd: Add support for X2APIC IOMMU interrupts") Signed-off-by: Maxim Levitsky <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 88c62a000be5e80f84758c510b7ac414de83d379 Author: Maxim Levitsky <[email protected]> Date: Tue Nov 23 18:10:36 2021 +0200 iommu/amd: X2apic mode: setup the INTX registers on mask/unmask [ Upstream commit 4691f79d62a637958f7b5f55c232a65399500b7a ] This is more logically correct and will also allow us to to use mask/unmask logic to restore INTX setttings after the resume from s3/s4. Fixes: 66929812955bb ("iommu/amd: Add support for X2APIC IOMMU interrupts") Signed-off-by: Maxim Levitsky <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 0210cbc1efa3939bf86a43949781b801c553afcb Author: Maxim Levitsky <[email protected]> Date: Tue Nov 23 18:10:35 2021 +0200 iommu/amd: X2apic mode: re-enable after resume [ Upstream commit 01b297a48a26bcb96769505ac948db4603b72bd1 ] Otherwise it is guaranteed to not work after the resume... Fixes: 66929812955bb ("iommu/amd: Add support for X2APIC IOMMU interrupts") Signed-off-by: Maxim Levitsky <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit fd77922c94e4dd16b4bcf1a0fcd52eb928bf75b9 Author: Maxim Levitsky <[email protected]> Date: Tue Nov 23 18:10:34 2021 +0200 iommu/amd: Restore GA log/tail pointer on host resume [ Upstream commit a8d4a37d1bb93608501d0d0545f902061152669a ] This will give IOMMU GA log a chance to work after resume from s3/s4. Fixes: 8bda0cfbdc1a6 ("iommu/amd: Detect and initialize guest vAPIC log") Signed-off-by: Maxim Levitsky <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 86bcde384570b22c5633160d4a735ba01ff61181 Author: Arnd Bergmann <[email protected]> Date: Mon Nov 22 23:21:58 2021 +0100 dmaengine: pxa/mmp: stop referencing config->slave_id [ Upstream commit 134c37fa250a87a7e77c80a7c59ae16c462e46e0 ] The last driver referencing the slave_id on Marvell PXA and MMP platforms was the SPI driver, but this stopped doing so a long time ago, so the TODO from the earlier patch can no be removed. Fixes: b729bf34535e ("spi/pxa2xx: Don't use slave_id of dma_slave_config") Fixes: 13b3006b8ebd ("dma: mmp_pdma: add filter function") Signed-off-by: Arnd Bergmann <[email protected]> Acked-by: Mark Brown <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit b1f659597761e93041b284bb183c4029bcfdab47 Author: Lukas Bulwahn <[email protected]> Date: Mon Dec 13 12:16:42 2021 +0100 mips: fix Kconfig reference to PHYS_ADDR_T_64BIT [ Upstream commit a670c82d9ca4f1e7385d9d6f26ff41a50fbdd944 ] Commit d4a451d5fc84 ("arch: remove the ARCH_PHYS_ADDR_T_64BIT config symbol") removes config ARCH_PHYS_ADDR_T_64BIT with all instances of that config refactored appropriately. Since then, it is recommended to use the config PHYS_ADDR_T_64BIT instead. Commit 171543e75272 ("MIPS: Disallow CPU_SUPPORTS_HUGEPAGES for XPA,EVA") introduces the expression "!(32BIT && (ARCH_PHYS_ADDR_T_64BIT || EVA))" for config CPU_SUPPORTS_HUGEPAGES, which unintentionally refers to the non-existing symbol ARCH_PHYS_ADDR_T_64BIT instead of the intended PHYS_ADDR_T_64BIT. Fix this Kconfig reference to the intended PHYS_ADDR_T_64BIT. This issue was identified with the script ./scripts/checkkconfigsymbols.py. I then reported it on the mailing list and Paul confirmed the mistake in the linked email thread. Link: https://lore.kernel.org/lkml/[email protected]/ Suggested-by: Paul Cercueil <[email protected]> Fixes: 171543e75272 ("MIPS: Disallow CPU_SUPPORTS_HUGEPAGES for XPA,EVA") Signed-off-by: Lukas Bulwahn <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit f345281019b29f3340414b34fc86deb2b2b46a53 Author: Lukas Bulwahn <[email protected]> Date: Mon Dec 13 12:16:35 2021 +0100 mips: add SYS_HAS_CPU_MIPS64_R5 config for MIPS Release 5 support [ Upstream commit fd4eb90b164442cb1e9909f7845e12a0835ac699 ] Commit ab7c01fdc3cf ("mips: Add MIPS Release 5 support") adds the two configs CPU_MIPS32_R5 and CPU_MIPS64_R5, which depend on the corresponding SYS_HAS_CPU_MIPS32_R5 and SYS_HAS_CPU_MIPS64_R5, respectively. The config SYS_HAS_CPU_MIPS32_R5 was already introduced with commit c5b367835cfc ("MIPS: Add support for XPA."); the config SYS_HAS_CPU_MIPS64_R5, however, was never introduced. Hence, ./scripts/checkkconfigsymbols.py warns: SYS_HAS_CPU_MIPS64_R5 Referencing files: arch/mips/Kconfig, arch/mips/include/asm/cpu-type.h Add the definition for config SYS_HAS_CPU_MIPS64_R5 under the assumption that SYS_HAS_CPU_MIPS64_R5 follows the same pattern as the existing SYS_HAS_CPU_MIPS32_R5 and SYS_HAS_CPU_MIPS64_R6. Fixes: ab7c01fdc3cf ("mips: Add MIPS Release 5 support") Signed-off-by: Lukas Bulwahn <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit cfb6756aea7e8f2464b543ec1ab2e143d5321270 Author: Dillon Min <[email protected]> Date: Tue Oct 26 15:11:21 2021 +0800 clk: stm32: Fix ltdc's clock turn off by clk_disable_unused() after system enter shell [ Upstream commit 6fc058a72f3b7b07fc4de6d66ad1f68951b00f6e ] stm32's clk driver register two ltdc gate clk to clk core by clk_hw_register_gate() and clk_hw_register_composite() first: 'stm32f429_gates[]', clk name is 'ltdc', which no user to use. second: 'stm32f429_aux_clk[]', clk name is 'lcd-tft', used by ltdc driver both of them point to the same offset of stm32's RCC register. after kernel enter console, clk core turn off ltdc's clk as 'stm32f429_gates[]' is no one to use. but, actually 'stm32f429_aux_clk[]' is in use. stm32f469/746/769 have the same issue, fix it. Fixes: daf2d117cbca ("clk: stm32f4: Add lcd-tft clock") Link: https://lore.kernel.org/linux-arm-kernel/[email protected]/ Link: https://lore.kernel.org/lkml/CAPTRvHkf0cK_4ZidM17rPo99gWDmxgqFt4CDUjqFFwkOeQeFDg@mail.gmail.com/ Signed-off-by: Dillon Min <[email protected]> Reviewed-by: Patrice Chotard <[email protected]> Acked-by: Gabriel Fernandez <[email protected]> Acked-by: Stephen Boyd <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Stephen Boyd <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit e7962a878b38bdc153035e07bb4d3b81d33eb405 Author: Frank Rowand <[email protected]> Date: Sun Dec 12 16:18:52 2021 -0600 of: unittest: 64 bit dma address test requires arch support [ Upstream commit 9fd4cf5d3571b27d746b8ead494a3f051485b679 ] If an architecture does not support 64 bit dma addresses then testing for an expected dma address >= 0x100000000 will fail. Fixes: e0d072782c73 ("dma-mapping: introduce DMA range map, supplanting dma_pfn_offset") Signed-off-by: Frank Rowand <[email protected]> Signed-off-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit d00393b2c3549f1ebfc74417ecde252f93df9064 Author: Jim Quinlan <[email protected]> Date: Fri Dec 10 13:46:35 2021 -0500 of: unittest: fix warning on PowerPC frame size warning [ Upstream commit a8d61a9112ad0c9216ab45d050991e07bc4f3408 ] The struct device variable "dev_bogus" was triggering this warning on a PowerPC build: drivers/of/unittest.c: In function 'of_unittest_dma_ranges_one.constprop': [...] >> The frame size of 1424 bytes is larger than 1024 bytes [-Wframe-larger-than=] This variable is now dynamically allocated. Fixes: e0d072782c734 ("dma-mapping: introduce DMA range map, supplanting dma_pfn_offset") Reported-by: kernel test robot <[email protected]> Signed-off-by: Jim Quinlan <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Reviewed-by: Frank Rowand <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Signed-off-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit e91edc3b443c398a2ba3d5b5d7fb0728b9ae3ac4 Author: Jiasheng Jiang <[email protected]> Date: Wed Dec 15 11:15:50 2021 +0800 ASoC: rt5663: Handle device_property_read_u32_array error codes [ Upstream commit 2167c0b205960607fb136b4bb3c556a62be1569a ] The return value of device_property_read_u32_array() is not always 0. To catch the exception in case that devm_kzalloc failed and the rt5663->imp_table was NULL, which caused the failure of device_property_read_u32_array. Fixes: 450f0f6a8fb4 ("ASoC: rt5663: Add the manual offset field to compensate the DC offset") Signed-off-by: Jiasheng Jiang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 45f4e3c7587782e30d61c3769b35634ea05f8a71 Author: Avihai Horon <[email protected]> Date: Thu Dec 9 15:16:07 2021 +0200 RDMA/cma: Let cma_resolve_ib_dev() continue search even after empty entry [ Upstream commit 20679094a0161c94faf77e373fa3f7428a8e14bd ] Currently, when cma_resolve_ib_dev() searches for a matching GID it will stop searching after encountering the first empty GID table entry. This behavior is wrong since neither IB nor RoCE spec enforce tightly packed GID tables. For example, when the matching valid GID entry exists at index N, and if a GID entry is empty at index N-1, cma_resolve_ib_dev() will fail to find the matching valid entry. Fix it by making cma_resolve_ib_dev() continue searching even after encountering missing entries. Fixes: f17df3b0dede ("RDMA/cma: Add support for AF_IB to rdma_resolve_addr()") Link: https://lore.kernel.org/r/b7346307e3bb396c43d67d924348c6c496493991.1639055490.git.leonro@nvidia.com Signed-off-by: Avihai Horon <[email protected]> Reviewed-by: Mark Zhang <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 8d76d0e4880d0843238f8b22d0be045e7a3d291d Author: Avihai Horon <[email protected]> Date: Thu Dec 9 15:16:06 2021 +0200 RDMA/core: Let ib_find_gid() continue search even after empty entry [ Upstream commit 483d805191a23191f8294bbf9b4e94836f5d92e4 ] Currently, ib_find_gid() will stop searching after encountering the first empty GID table entry. This behavior is wrong since neither IB nor RoCE spec enforce tightly packed GID tables. For example, when a valid GID entry exists at index N, and if a GID entry is empty at index N-1, ib_find_gid() will fail to find the valid entry. Fix it by making ib_find_gid() continue searching even after encountering missing entries. Fixes: 5eb620c81ce3 ("IB/core: Add helpers for uncached GID and P_Key searches") Link: https://lore.kernel.org/r/e55d331b96cecfc2cf19803d16e7109ea966882d.1639055490.git.leonro@nvidia.com Signed-off-by: Avihai Horon <[email protected]> Reviewed-by: Mark Zhang <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit b77f233986b3099d8216c9fd466b99cb65503e7f Author: Rob Clark <[email protected]> Date: Mon Nov 8 09:17:23 2021 -0800 iommu/arm-smmu-qcom: Fix TTBR0 read [ Upstream commit c31112fbd4077a51a14ff338038c82e9571dc821 ] It is a 64b register, lets not lose the upper bits. Fixes: ab5df7b953d8 ("iommu/arm-smmu-qcom: Add an adreno-smmu-priv callback to get pagefault info") Signed-off-by: Rob Clark <[email protected]> Reviewed-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 2b78e026b455a7a28941786bb4dad7503e1d1a51 Author: Christophe Leroy <[email protected]> Date: Wed Dec 8 17:36:52 2021 +0000 powerpc/powermac: Add additional missing lockdep_register_key() [ Upstream commit b149d5d45ac9171ed699a256f026c8ebef901112 ] Commit df1f679d19ed ("powerpc/powermac: Add missing lockdep_register_key()") fixed a problem that was causing a WARNING. There are two other places in the same file with the same problem originating from commit 9e607f72748d ("i2c_powermac: shut up lockdep warning"). Add missing lockdep_register_key() Fixes: 9e607f72748d ("i2c_powermac: shut up lockdep warning") Reported-by: Erhard Furtner <[email protected]> Signed-off-by: Christophe Leroy <[email protected]> Depends-on: df1f679d19ed ("powerpc/powermac: Add missing lockdep_register_key()") Signed-off-by: Michael Ellerman <[email protected]> Link: https://bugzilla.kernel.org/show_bug.cgi?id=200055 Link: https://lore.kernel.org/r/2c7e421874e21b2fb87813d768cf662f630c2ad4.1638984999.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin <[email protected]> commit db3e0d59f1c88db975a15c6f461208ba541ec5f0 Author: Thomas Gleixner <[email protected]> Date: Mon Dec 6 23:27:26 2021 +0100 PCI/MSI: Fix pci_irq_vector()/pci_irq_get_affinity() [ Upstream commit 29bbc35e29d9b6347780dcacde2deb4b39344167 ] pci_irq_vector() and pci_irq_get_affinity() use the list position to find the MSI-X descriptor at a given index. That's correct for the normal case where the entry number is the same as the list position. But it's wrong for cases where MSI-X was allocated with an entries array describing sparse entry numbers into the hardware message descriptor table. That's inconsistent at best. Make it always check the entry number because that's what the zero base index really means. This change won't break existing users which use a sparse entries array for allocation because these users retrieve the Linux interrupt number from the entries array after allocation and none of them uses pci_irq_vector() or pci_irq_get_affinity(). Fixes: aff171641d18 ("PCI: Provide sensible IRQ vector alloc/free routines") Signed-off-by: Thomas Gleixner <[email protected]> Tested-by: Juergen Gross <[email protected]> Reviewed-by: Jason Gunthorpe <[email protected]> Acked-by: Bjorn Helgaas <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 1526f0ae4949491247a66ff5cc15149fc4c4ff92 Author: Kamal Heib <[email protected]> Date: Mon Dec 6 22:13:14 2021 +0200 RDMA/qedr: Fix reporting max_{send/recv}_wr attrs [ Upstream commit b1a4da64bfc189510e08df1ccb1c589e667dc7a3 ] Fix the wrongly reported max_send_wr and max_recv_wr attributes for user QP by making sure to save their valuse on QP creation, so when query QP is called the attributes will be reported correctly. Fixes: cecbcddf6461 ("qedr: Add support for QP verbs") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Kamal Heib <[email protected]> Acked-by: Michal Kalderon <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit f10876654e82400109990748c1e51d05b9020d9a Author: Bart Van Assche <[email protected]> Date: Fri Dec 3 15:19:39 2021 -0800 scsi: ufs: Fix race conditions related to driver data [ Upstream commit 21ad0e49085deb22c094f91f9da57319a97188e4 ] The driver data pointer must be set before any callbacks are registered that use that pointer. Hence move the initialization of that pointer from after the ufshcd_init() call to inside ufshcd_init(). Link: https://lore.kernel.org/r/[email protected] Fixes: 3b1d05807a9a ("[SCSI] ufs: Segregate PCI Specific Code") Reported-by: Alexey Dobriyan <[email protected]> Tested-by: Bean Huo <[email protected]> Reviewed-by: Bean Huo <[email protected]> Signed-off-by: Bart Van Assche <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit c9f350ade563ce87d97ff9c756640ed83e0cce46 Author: Bart Van Assche <[email protected]> Date: Fri Dec 3 15:19:34 2021 -0800 scsi: core: Fix scsi_device_max_queue_depth() [ Upstream commit 4bc3bffc1a885eb5cb259e4a25146a4c7b1034e3 ] The comment above scsi_device_max_queue_depth() and also the description of commit ca4453213951 ("scsi: core: Make sure sdev->queue_depth is <= max(shost->can_queue, 1024)") contradict the implementation of the function scsi_device_max_queue_depth(). Additionally, the maximum queue depth of a SCSI LUN never exceeds host->can_queue. Fix scsi_device_max_queue_depth() by changing max_t() into min_t(). Link: https://lore.kernel.org/r/[email protected] Fixes: ca4453213951 ("scsi: core: Make sure sdev->queue_depth is <= max(shost->can_queue, 1024)") Cc: Hannes Reinecke <[email protected]> Cc: Sumanesh Samanta <[email protected]> Tested-by: Bean Huo <[email protected]> Reviewed-by: Ming Lei <[email protected]> Reviewed-by: Bean Huo <[email protected]> Signed-off-by: Bart Van Assche <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 3db62f98b49fdafd5a5a8153a525b2e570a54e74 Author: Hector Martin <[email protected]> Date: Sat Nov 20 12:13:43 2021 +0900 iommu/io-pgtable-arm: Fix table descriptor paddr formatting [ Upstream commit 9abe2ac834851a7d0b0756e295cf7a292c45ca53 ] Table descriptors were being installed without properly formatting the address using paddr_to_iopte, which does not match up with the iopte_deref in __arm_lpae_map. This is incorrect for the LPAE pte format, as it does not handle the high bits properly. This was found on Apple T6000 DARTs, which require a new pte format (different shift); adding support for that to paddr_to_iopte/iopte_to_paddr caused it to break badly, as even <48-bit addresses would end up incorrect in that case. Fixes: 6c89928ff7a0 ("iommu/io-pgtable-arm: Support 52-bit physical address") Acked-by: Robin Murphy <[email protected]> Signed-off-by: Hector Martin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 004d84063fa22ef983ade4edfd970474aa0f86c3 Author: Lu Baolu <[email protected]> Date: Mon Nov 8 14:13:49 2021 +0800 iommu: Extend mutex lock scope in iommu_probe_device() [ Upstream commit 556f99ac886635e8da15528995f06d1d7028cfca ] Extend the scope of holding group->mutex so that it can cover the default domain check/attachment and direct mappings of reserved regions. Cc: Ashish Mhetre <[email protected]> Fixes: 211ff31b3d33b ("iommu: Fix race condition during default domain allocation") Signed-off-by: Lu Baolu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 37fb3dec665c7c9295ac86d5be078fea945ed9ba Author: Stafford Horne <[email protected]> Date: Sat Dec 4 07:10:18 2021 +0900 openrisc: Add clone3 ABI wrapper [ Upstream commit 433fe39f674d58bc7a3e8254a5d2ffc290b7e04e ] Like fork and clone the clone3 syscall needs a wrapper to save callee saved registers, which is required by the OpenRISC ABI. This came up after auditing code following a discussion with Rob Landley and Arnd Bergmann [0]. Tested with the clone3 kselftests and there were no issues. [0] https://lore.kernel.org/all/[email protected]/T/#m9c0cdb2703813b9df4da04cf6b30de1f1aa89944 Fixes: 07e83dfbe16c ("openrisc: Enable the clone3 syscall") Cc: Rob Landley <[email protected]> Cc: Arnd Bergmann <[email protected]> Signed-off-by: Stafford Horne <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 7a9ad4aceb0226b391c9d3b8e4ac2e7d438b6bde Author: Todd Kjos <[email protected]> Date: Tue Nov 30 10:51:50 2021 -0800 binder: avoid potential data leakage when copying txn [ Upstream commit 6d98eb95b450a75adb4516a1d33652dc78d2b20c ] Transactions are copied from the sender to the target first and objects like BINDER_TYPE_PTR and BINDER_TYPE_FDA are then fixed up. This means there is a short period where the sender's version of these objects are visible to the target prior to the fixups. Instead of copying all of the data first, copy data only after any needed fixups have been applied. Fixes: 457b9a6f09f0 ("Staging: android: add binder driver") Reviewed-by: Martijn Coenen <[email protected]> Acked-by: Christian Brauner <[email protected]> Signed-off-by: Todd Kjos <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit f9848823d4e8c2c88bc9975a5d0e4810678b639c Author: Todd Kjos <[email protected]> Date: Tue Nov 30 10:51:49 2021 -0800 binder: fix handling of error during copy [ Upstream commit fe6b1869243f23a485a106c214bcfdc7aa0ed593 ] If a memory copy function fails to copy the whole buffer, a positive integar with the remaining bytes is returned. In binder_translate_fd_array() this can result in an fd being skipped due to the failed copy, but the loop continues processing fds since the early return condition expects a negative integer on error. Fix by returning "ret > 0 ? -EINVAL : ret" to handle this case. Fixes: bb4a2e48d510 ("binder: return errors from buffer copy functions") Suggested-by: Dan Carpenter <[email protected]> Acked-by: Christian Brauner <[email protected]> Signed-off-by: Todd Kjos <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 695ca3e0e24b03c36ba089bbb445e2867f97a07c Author: Kees Cook <[email protected]> Date: Fri Dec 3 00:42:06 2021 -0800 char/mwave: Adjust io port register size [ Upstream commit f5912cc19acd7c24b2dbf65a6340bf194244f085 ] Using MKWORD() on a byte-sized variable results in OOB read. Expand the size of the reserved area so both MKWORD and MKBYTE continue to work without overflow. Silences this warning on a -Warray-bounds build: drivers/char/mwave/3780i.h:346:22: error: array subscript 'short unsigned int[0]' is partly outside array bounds of 'DSP_ISA_SLAVE_CONTROL[1]' [-Werror=array-bounds] 346 | #define MKWORD(var) (*((unsigned short *)(&var))) | ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/char/mwave/3780i.h:356:40: note: in definition of macro 'OutWordDsp' 356 | #define OutWordDsp(index,value) outw(value,usDspBaseIO+index) | ^~~~~ drivers/char/mwave/3780i.c:373:41: note: in expansion of macro 'MKWORD' 373 | OutWordDsp(DSP_IsaSlaveControl, MKWORD(rSlaveControl)); | ^~~~~~ drivers/char/mwave/3780i.c:358:31: note: while referencing 'rSlaveControl' 358 | DSP_ISA_SLAVE_CONTROL rSlaveControl; | ^~~~~~~~~~~~~ Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Kees Cook <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 356b4ed3ea706d97d135884c35818bf80b9ea7f8 Author: Andy Shevchenko <[email protected]> Date: Thu Nov 25 23:27:27 2021 +0200 misc: at25: Make driver OF independent again [ Upstream commit 5b557298d7d09cce04e0565a535fbca63661724a ] The commit f60e7074902a ("misc: at25: Make use of device property API") made a good job by enabling the driver for non-OF platforms, but the recent commit 604288bc6196 ("nvmem: eeprom: at25: fix type compiler warnings") brought that back. Restore greatness of the driver once again. Fixes: eab61fb1cc2e ("nvmem: eeprom: at25: fram discovery simplification") Fixes: fd307a4ad332 ("nvmem: prepare basics for FRAM support") Acked-by: Arnd Bergmann <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit ee22462a419b4c5892855ff6fdee8c57c10a7fbf Author: Takashi Iwai <[email protected]> Date: Thu Dec 2 09:38:33 2021 +0100 ALSA: usb-audio: Drop superfluous '0' in Presonus Studio 1810c's ID [ Upstream commit 1e583aef12aa74afd37c1418255cc4b74e023236 ] The vendor ID of Presonus Studio 1810c had a superfluous '0' in its USB ID. Drop it. Fixes: 8dc5efe3d17c ("ALSA: usb-audio: Add support for Presonus Studio 1810c") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 6f90ccd962269d4fdb9451bee08aef733eeddcf1 Author: Bixuan Cui <[email protected]> Date: Wed Dec 1 16:58:54 2021 +0800 ALSA: oss: fix compile error when OSS_DEBUG is enabled [ Upstream commit 8e7daf318d97f25e18b2fc7eb5909e34cd903575 ] Fix compile error when OSS_DEBUG is enabled: sound/core/oss/pcm_oss.c: In function 'snd_pcm_oss_set_trigger': sound/core/oss/pcm_oss.c:2055:10: error: 'substream' undeclared (first use in this function); did you mean 'csubstream'? pcm_dbg(substream->pcm, "pcm_oss: trigger = 0x%x\n", trigger); ^ Fixes: 61efcee8608c ("ALSA: oss: Use standard printk helpers") Signed-off-by: Bixuan Cui <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit cf9b8de20168ddeb261a1e2d4f918d3c0d502fc5 Author: Waiman Long <[email protected]> Date: Thu Nov 18 14:14:36 2021 -0500 clocksource: Avoid accidental unstable marking of clocksources [ Upstream commit c86ff8c55b8ae68837b2fa59dc0c203907e9a15f ] Since commit db3a34e17433 ("clocksource: Retry clock read if long delays detected") and commit 2e27e793e280 ("clocksource: Reduce clocksource-skew threshold"), it is found that tsc clocksource fallback to hpet can sometimes happen on both Intel and AMD systems especially when they are running stressful benchmarking workloads. Of the 23 systems tested with a v5.14 kernel, 10 of them have switched to hpet clock source during the test run. The result of falling back to hpet is a drastic reduction of performance when running benchmarks. For example, the fio performance tests can drop up to 70% whereas the iperf3 performance can drop up to 80%. 4 hpet fallbacks happened during bootup. They were: [ 8.749399] clocksource: timekeeping watchdog on CPU13: hpet read-back delay of 263750ns, attempt 4, marking unstable [ 12.044610] clocksource: timekeeping watchdog on CPU19: hpet read-back delay of 186166ns, attempt 4, marking unstable [ 17.336941] clocksource: timekeeping watchdog on CPU28: hpet read-back delay of 182291ns, attempt 4, marking unstable [ 17.518565] clocksource: timekeeping watchdog on CPU34: hpet read-back delay of 252196ns, attempt 4, marking unstable Other fallbacks happen when the systems were running stressful benchmarks. For example: [ 2685.867873] clocksource: timekeeping watchdog on CPU117: hpet read-back delay of 57269ns, attempt 4, marking unstable [46215.471228] clocksource: timekeeping watchdog on CPU8: hpet read-back delay of 61460ns, attempt 4, marking unstable Commit 2e27e793e280 ("clocksource: Reduce clocksource-skew threshold"), changed the skew margin from 100us to 50us. I think this is too small and can easily be exceeded when running some stressful workloads on a thermally stressed system. So it is switched back to 100us. Even a maximum skew margin of 100us may be too small in for some systems when booting up especially if those systems are under thermal stress. To eliminate the case that the large skew is due to the system being too busy slowing down the reading of both the watchdog and the clocksource, an extra consecutive read of watchdog clock is being done to check this. The consecutive watchdog read delay is compared against WATCHDOG_MAX_SKEW/2. If the delay exceeds the limit, we assume that the system is just too busy. A warning will be printed to the console and the clock skew check is skipped for this round. Fixes: db3a34e17433 ("clocksource: Retry clock read if long delays detected") Fixes: 2e27e793e280 ("clocksource: Reduce clocksource-skew threshold") Signed-off-by: Waiman Long <[email protected]> Signed-off-by: Paul E. McKenney <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit e3e6b74fad2df4114dd80f1be51742e0f683cfce Author: Christophe Leroy <[email protected]> Date: Tue Nov 30 09:42:37 2021 +0100 powerpc/32s: Fix shift-out-of-bounds in KASAN init [ Upstream commit af11dee4361b3519981fa04d014873f9d9edd6ac ] ================================================================================ UBSAN: shift-out-of-bounds in arch/powerpc/mm/kasan/book3s_32.c:22:23 shift exponent -1 is negative CPU: 0 PID: 0 Comm: swapper Not tainted 5.15.5-gentoo-PowerMacG4 #9 Call Trace: [c214be60] [c0ba0048] dump_stack_lvl+0x80/0xb0 (unreliable) [c214be80] [c0b99288] ubsan_epilogue+0x10/0x5c [c214be90] [c0b98fe0] __ubsan_handle_shift_out_of_bounds+0x94/0x138 [c214bf00] [c1c0f010] kasan_init_region+0xd8/0x26c [c214bf30] [c1c0ed84] kasan_init+0xc0/0x198 [c214bf70] [c1c08024] setup_arch+0x18/0x54c [c214bfc0] [c1c037f0] start_kernel+0x90/0x33c [c214bff0] [00003610] 0x3610 ================================================================================ This happens when the directly mapped memory is a power of 2. Fix it by checking the shift and set the result to 0 when shift is -1 Fixes: 7974c4732642 ("powerpc/32s: Implement dedicated kasan_init_region()") Reported-by: Erhard Furtner <[email protected]> Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://bugzilla.kernel.org/show_bug.cgi?id=215169 Link: https://lore.kernel.org/r/15cbc3439d4ad988b225e2119ec99502a5cc6ad3.1638261744.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin <[email protected]> commit 2d17ab8874bc57e903d0256aaa17bd8bdb590c91 Author: Christophe Leroy <[email protected]> Date: Tue Nov 30 11:10:43 2021 +0100 powerpc/modules: Don't WARN on first module allocation attempt [ Upstream commit f1797e4de1146009c888bcf8b6bb6648d55394f1 ] module_alloc() first tries to allocate module text within 24 bits direct jump from kernel text, and tries a wider allocation if first one fails. When first allocation fails the following is observed in kernel logs: vmap allocation for size 2400256 failed: use vmalloc=<size> to increase size systemd-udevd: vmalloc error: size 2395133, vm_struct allocation failed, mode:0xcc0(GFP_KERNEL), nodemask=(null) CPU: 0 PID: 127 Comm: systemd-udevd Tainted: G W 5.15.5-gentoo-PowerMacG4 #9 Call Trace: [e2a53a50] [c0ba0048] dump_stack_lvl+0x80/0xb0 (unreliable) [e2a53a70] [c0540128] warn_alloc+0x11c/0x2b4 [e2a53b50] [c0531be8] __vmalloc_node_range+0xd8/0x64c [e2a53c10] [c00338c0] module_alloc+0xa0/0xac [e2a53c40] [c027a368] load_module+0x2ae0/0x8148 [e2a53e30] [c027fc78] sys_finit_module+0xfc/0x130 [e2a53f30] [c0035098] ret_from_syscall+0x0/0x28 ... Add __GFP_NOWARN flag to first allocation so that no warning appears when it fails. Reported-by: Erhard Furtner <[email protected]> Fixes: 2ec13df16704 ("powerpc/modules: Load modules closer to kernel text") Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/93c9b84d6ec76aaf7b4f03468e22433a6d308674.1638267035.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin <[email protected]> commit fadcafa3959281ce2d96feedece8c75c3f95f8a5 Author: Athira Rajeev <[email protected]> Date: Wed Jul 21 01:48:29 2021 -0400 powerpc/perf: Fix PMU callbacks to clear pending PMI before resetting an overflown PMC [ Upstream commit 2c9ac51b850d84ee496b0a5d832ce66d411ae552 ] Running perf fuzzer showed below in dmesg logs: "Can't find PMC that caused IRQ" This means a PMU exception happened, but none of the PMC's (Performance Monitor Counter) were found to be overflown. There are some corner cases that clears the PMCs after PMI gets masked. In such cases, the perf interrupt handler will not find the active PMC values that had caused the overflow and thus leads to this message while replaying. Case 1: PMU Interrupt happens during replay of other interrupts and counter values gets cleared by PMU callbacks before replay: During replay of interrupts like timer, __do_irq() and doorbell exception, we conditionally enable interrupts via may_hard_irq_enable(). This could potentially create a window to generate a PMI. Since irq soft mask is set to ALL_DISABLED, the PMI will get masked here. We could get IPIs run before perf interrupt is replayed and the PMU events could be deleted or stopped. This will change the PMU SPR values and resets the counters. Snippet of ftrace log showing PMU callbacks invoked in __do_irq(): <idle>-0 [051] dns. 132025441306354: __do_irq <-call_do_irq <idle>-0 [051] dns. 132025441306430: irq_enter <-__do_irq <idle>-0 [051] dns. 132025441306503: irq_enter_rcu <-__do_irq <idle>-0 [051] dnH. 132025441306599: xive_get_irq <-__do_irq <<>> <idle>-0 [051] dnH. 132025441307770: generic_smp_call_function_single_interrupt <-smp_ipi_demux_relaxed <idle>-0 [051] dnH. 132025441307839: flush_smp_call_function_queue <-smp_ipi_demux_relaxed <idle>-0 [051] dnH. 132025441308057: _raw_spin_lock <-event_function <idle>-0 [051] dnH. 132025441308206: power_pmu_disable <-perf_pmu_disable <idle>-0 [051] dnH. 132025441308337: power_pmu_del <-event_sched_out <idle>-0 [051] dnH. 132025441308407: power_pmu_read <-power_pmu_del <idle>-0 [051] dnH. 132025441308477: read_pmc <-power_pmu_read <idle>-0 [051] dnH. 132025441308590: isa207_disable_pmc <-power_pmu_del <idle>-0 [051] dnH. 132025441308663: write_pmc <-power_pmu_del <idle>-0 [051] dnH. 132025441308787: power_pmu_event_idx <-perf_event_update_userpage <idle>-0 [051] dnH. 132025441308859: rcu_read_unlock_strict <-perf_event_update_userpage <idle>-0 [051] dnH. 132025441308975: power_pmu_enable <-perf_pmu_enable <<>> <idle>-0 [051] dnH. 132025441311108: irq_exit <-__do_irq <idle>-0 [051] dns. 132025441311319: performance_monitor_exception <-replay_soft_interrupts Case 2: PMI's masked during local_* operations, example local_add(). If the local_add() operation happens within a local_irq_save(), replay of PMI will be during local_irq_restore(). Similar to case 1, this could also create a window before replay where PMU events gets deleted or stopped. Fix it by updating the PMU callback function power_pmu_disable() to check for pending perf interrupt. If there is an overflown PMC and pending perf interrupt indicated in paca, clear the PMI bit in paca to drop that sample. Clearing of PMI bit is done in power_pmu_disable() since disable is invoked before any event gets deleted/stopped. With this fix, if there are more than one event running in the PMU, there is a chance that we clear the PMI bit for the event which is not getting deleted/stopped. The other events may still remain active. Hence to make sure we don't drop valid sample in such cases, another check is added in power_pmu_enable. This checks if there is an overflown PMC found among the active events and if so enable back the PMI bit. Two new helper functions are introduced to clear/set the PMI, ie clear_pmi_irq_pending() and set_pmi_irq_pending(). Helper function pmi_irq_pending() is introduced to give a warning if there is pending PMI bit in paca, but no PMC is overflown. Also there are corner cases which result in performance monitor interrupts being triggered during power_pmu_disable(). This happens since PMXE bit is not cleared along with disabling of other MMCR0 bits in the pmu_disable. Such PMI's could leave the PMU running and could trigger PMI again which will set MMCR0 PMAO bit. This could lead to spurious interrupts in some corner cases. Example, a timer after power_pmu_del() which will re-enable interrupts and triggers a PMI again since PMAO bit is still set. But fails to find valid overflow since PMC was cleared in power_pmu_del(). Fix that by disabling PMXE along with disabling of other MMCR0 bits in power_pmu_disable(). We can't just replay PMI any time. Hence this approach is preferred rather than replaying PMI before resetting overflown PMC. Patch also documents core-book3s on a race condition which can trigger these PMC messages during idle path in PowerNV. Fixes: f442d004806e ("powerpc/64s: Add support to mask perf interrupts and replay them") Reported-by: Nageswara R Sastry <[email protected]> Suggested-by: Nicholas Piggin <[email protected]> Suggested-by: Madhavan Srinivasan <[email protected]> Signed-off-by: Athira Rajeev <[email protected]> Tested-by: Nageswara R Sastry <[email protected]> Reviewed-by: Nicholas Piggin <[email protected]> [mpe: Make pmi_irq_pending() return bool, reflow/reword some comments] Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit c15d1468f339cc872a5901f337a087ca862a180a Author: Niklas Söderlund <[email protected]> Date: Tue Nov 9 11:30:45 2021 +0100 dt-bindings: thermal: Fix definition of cooling-maps contribution property [ Upstream commit 49bcb1506f2e095262c01bda7fd1c0db524c91e2 ] When converting the thermal-zones bindings to yaml the definition of the contribution property changed. The intention is the same, an integer value expressing a ratio of a sum on how much cooling is provided by the device to the zone. But after the conversion the integer value is limited to the range 0 to 100 and expressed as a percentage. This is problematic for two reasons. - This do not match how the binding is used. Out of the 18 files that make use of the property only two (ste-dbx5x0.dtsi and ste-hrefv60plus.dtsi) sets it at a value that satisfy the binding, 100. The remaining 16 files set the value higher and fail to validate. - Expressing the value as a percentage instead of a ratio of the sum is confusing as there is nothing to enforce the sum in the zone is not greater then 100. This patch restore the pre yaml conversion description and removes the value limitation allowing the usage of the bindings to validate. Fixes: 1202a442a31fd2e5 ("dt-bindings: thermal: Add yaml bindings for thermal zones") Reported-by: Kieran Bingham <[email protected]> Signed-off-by: Niklas Söderlund <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Rob Herring <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 9de9858d7bf0d6920e3612bef798fefead9ca10b Author: Thomas Gleixner <[email protected]> Date: Wed Nov 24 23:40:01 2021 +0100 ALSA: hda: Make proper use of timecounter [ Upstream commit 6dd21ad81bf96478db3403b1bbe251c0612d0431 ] HDA uses a timecounter to read a hardware clock running at 24 MHz. The conversion factor is set with a mult value of 125 and a shift value of 0, which is not converting the hardware clock to nanoseconds, it is converting to 1/3 nanoseconds because the conversion factor from 24Mhz to nanoseconds is 125/3. The usage sites divide the "nanoseconds" value returned by timecounter_read() by 3 to get a real nanoseconds value. There is a lengthy comment in azx_timecounter_init() explaining this choice. That comment makes blatantly wrong assumptions about how timecounters work and what can overflow. The comment says: * Applying the 1/3 factor as part of the multiplication * requires at least 20 bits for a decent precision, however * overflows occur after about 4 hours or less, not a option. timecounters operate on time deltas between two readouts of a clock and use the mult/shift pair to calculate a precise nanoseconds value: delta_nsec = (delta_clock * mult) >> shift; The fractional part is also taken into account and preserved to prevent accumulated rounding errors. For details see cyclecounter_cyc2ns(). The mult/shift pair has to be chosen so that the multiplication of the maximum expected delta value does not result in a 64bit overflow. As the counter wraps around on 32bit, the maximum observable delta between two reads is (1 << 32) - 1 which is about 178.9 seconds. That in turn means the maximum multiplication factor which fits into an u32 will not cause a 64bit overflow ever because it's guaranteed that: ((1 << 32) - 1) ^ 2 < (1 << 64) The resulting correct multiplication factor is 2796202667 and the shift value is 26, i.e. 26 bit precision. The overflow of the multiplication would happen exactly at a clock readout delta of 6597069765 which is way after the wrap around of the hardware clock at around 274.8 seconds which is off from the claimed 4 hours by more than an order of magnitude. If the counter ever wraps around the last read value then the calculation is off by the number of wrap arounds times 178.9 seconds because the overflow cannot be observed. Use clocks_calc_mult_shift(), which calculates the most accurate mult/shift pair based on the given clock frequency, and remove the bogus comment along with the divisions at the readout sites. Fixes: 5d890f591d15 ("ALSA: hda: support for wallclock timestamps") Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Pierre-Louis Bossart <[email protected]> Link: https://lore.kernel.org/r/871r35kwji.ffs@tglx Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit a2e525d618012a7070af633e138e235d2065909a Author: Jack Wang <[email protected]> Date: Wed Nov 24 09:10:40 2021 +0100 RDMA/rtrs-clt: Fix the initial value of min_latency [ Upstream commit 925cac6358677d3d64f9b25f205eeb3d31c9f7f8 ] The type of min_latency is ktime_t, so use KTIME_MAX to initialize the initial value. Fixes: dc3b66a0ce70 ("RDMA/rtrs-clt: Add a minimum latency multipath policy") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jack Wang <[email protected]> Reviewed-by: Guoqing Jiang <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 278df2c08602cfc7f1db74394d93c12e4fe4cbd1 Author: Lukas Bulwahn <[email protected]> Date: Thu Nov 25 10:51:58 2021 +0100 ASoC: codecs: wcd938x: add SND_SOC_WCD938_SDW to codec list instead [ Upstream commit 2039cc1da4bee1fd0df644e26b28ed769cd32a81 ] Commit 045442228868 ("ASoC: codecs: wcd938x: add audio routing and Kconfig") adds SND_SOC_WCD937X, which does not exist, and SND_SOC_WCD938X, which seems not really to be the intended config to be selected, but only a supporting config symbol to the actual config SND_SOC_WCD938X_SDW for the codec. Add SND_SOC_WCD938_SDW to the list instead of SND_SOC_WCD93{7,8}X. The issue was identified with ./scripts/checkkconfigsymbols.py. Fixes: 045442228868 ("ASoC: codecs: wcd938x: add audio routing and Kconfig") Signed-off-by: Lukas Bulwahn <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit dc240056731286b6808d6d9d1f89bb8276e9f477 Author: Lukas Bulwahn <[email protected]> Date: Thu Nov 25 10:51:57 2021 +0100 ASoC: uniphier: drop selecting non-existing SND_SOC_UNIPHIER_AIO_DMA [ Upstream commit 49f893253ab43566e34332a969324531fea463f6 ] Commit f37fe2f9987b ("ASoC: uniphier: add support for UniPhier AIO common driver") adds configs SND_SOC_UNIPHIER_{LD11,PXS2}, which select the non-existing config SND_SOC_UNIPHIER_AIO_DMA. Hence, ./scripts/checkkconfigsymbols.py warns: SND_SOC_UNIPHIER_AIO_DMA Referencing files: sound/soc/uniphier/Kconfig Probably, there is actually no further config intended to be selected here. So, just drop selecting the non-existing config. Fixes: f37fe2f9987b ("ASoC: uniphier: add support for UniPhier AIO common driver") Signed-off-by: Lukas Bulwahn <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 49a237c73a78bebf7d683ce4b3159e07bf6b786e Author: Peiwei Hu <[email protected]> Date: Fri Nov 19 17:12:18 2021 +0800 powerpc/prom_init: Fix improper check of prom_getprop() [ Upstream commit 869fb7e5aecbc163003f93f36dcc26d0554319f6 ] prom_getprop() can return PROM_ERROR. Binary operator can not identify it. Fixes: 94d2dde738a5 ("[POWERPC] Efika: prune fixups and make them more carefull") Signed-off-by: Peiwei Hu <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit e459a89df303944c918cf57bc8a22bb1b4674846 Author: Adam Ford <[email protected]> Date: Wed Nov 17 07:32:02 2021 -0600 clk: imx8mn: Fix imx8mn_clko1_sels [ Upstream commit 570727e9acfac1c2330a01dd5e1272e9c3acec08 ] When attempting to use sys_pll1_80m as the parent for clko1, the system hangs. This is due to the fact that the source select for sys_pll1_80m was incorrectly pointing to m7_alt_pll_clk, which doesn't yet exist. According to Rev 3 of the TRM, The imx8mn_clko1_sels also incorrectly references an osc_27m which does not exist, nor does an entry for source select bits 010b. Fix both by inserting a dummy clock into the missing space in the table and renaming the incorrectly name clock with dummy. Fixes: 96d6392b54db ("clk: imx: Add support for i.MX8MN clock driver") Signed-off-by: Adam Ford <[email protected]> Reviewed-by: Fabio Estevam <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Abel Vesa <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 6b0335e66b51dc6057edb02ebdb8836684e4a8db Author: Lad Prabhakar <[email protected]> Date: Wed Nov 17 11:50:59 2021 +0000 clk: renesas: rzg2l: propagate return value of_genpd_add_provider_simple() [ Upstream commit 33748744f15a110a233b6ae0380f476006e770f0 ] of_genpd_add_provider_simple() might fail, this patch makes sure we check the return value of of_genpd_add_provider_simple() by propagating the return value to the caller of rzg2l_cpg_add_clk_domain(). Fixes: ef3c613ccd68a ("clk: renesas: Add CPG core wrapper for RZ/G2L SoC") Signed-off-by: Lad Prabhakar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 02beeed3928f7eabbeb7f1a49c6eaa6f2a215218 Author: Lad Prabhakar <[email protected]> Date: Wed Nov 17 11:50:58 2021 +0000 clk: renesas: rzg2l: Check return value of pm_genpd_init() [ Upstream commit 27527a3d3b162e4512798c058c0e8a216c721187 ] Make sure we check the return value of pm_genpd_init() which might fail. Also add a devres action to remove the power-domain in-case the probe callback fails further down in the code flow. Fixes: ef3c613ccd68a ("clk: renesas: Add CPG core wrapper for RZ/G2L SoC") Signed-off-by: Lad Prabhakar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit a0b4447677ddf293ba2d85960cbfc2cfff75c283 Author: Igor Pylypiv <[email protected]> Date: Mon Nov 1 16:28:24 2021 -0700 scsi: pm80xx: Update WARN_ON check in pm8001_mpi_build_cmd() [ Upstream commit 606c54ae975ad3af540b505b46b55a687501711f ] Starting from commit 05c6c029a44d ("scsi: pm80xx: Increase number of supported queues") driver initializes only max_q_num queues. Do not use an invalid queue if the WARN_ON condition is true. Link: https://lore.kernel.org/r/[email protected] Fixes: 7640e1eb8c5d ("scsi: pm80xx: Make mpi_build_cmd locking consistent") Reviewed-by: Vishakha Channapattan <[email protected]> Acked-by: Jack Wang <[email protected]> Signed-off-by: Igor Pylypiv <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 4a1723367f5e632cf0b40f134bd3cd8aea9d26a8 Author: Kamal Heib <[email protected]> Date: Wed Nov 17 16:59:54 2021 +0200 RDMA/hns: Validate the pkey index [ Upstream commit 2a67fcfa0db6b4075515bd23497750849b88850f ] Before query pkey, make sure that the queried index is valid. Fixes: 9a4435375cd1 ("IB/hns: Add driver files for hns RoCE driver") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Kamal Heib <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 8fe8161c50f4de73d56274a90247e84aba624046 Author: Christophe JAILLET <[email protected]> Date: Fri Nov 12 09:59:04 2021 +0100 RDMA/bnxt_re: Scan the whole bitmap when checking if "disabling RCFW with pending cmd-bit" [ Upstream commit a917dfb66c0a1fa1caacf3d71edcafcab48e6ff0 ] The 'cmdq->cmdq_bitmap' bitmap is 'rcfw->cmdq_depth' bits long. The size stored in 'cmdq->bmap_size' is the size of the bitmap in bytes. Remove this erroneous 'bmap_size' and use 'rcfw->cmdq_depth' directly in 'bnxt_qplib_disable_rcfw_channel()'. Otherwise some error messages may be missing. Other uses of 'cmdq_bitmap' already take into account 'rcfw->cmdq_depth' directly. Fixes: 1ac5a4047975 ("RDMA/bnxt_re: Add bnxt_re RoCE driver") Link: https://lore.kernel.org/r/47ed717c3070a1d0f53e7b4c768a4fd11caf365d.1636707421.git.christophe.jaillet@wanadoo.fr Signed-off-by: Christophe JAILLET <[email protected]> Acked-by: Selvin Xavier <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit ec085da3437ba5f8752be304de214183222c38e7 Author: Takashi Iwai <[email protected]> Date: Tue Nov 16 08:24:59 2021 +0100 ALSA: hda: Fix potential deadlock at codec unbinding [ Upstream commit 7206998f578d5553989bc01ea2e544b622e79539 ] When a codec is unbound dynamically via sysfs while its stream is in use, we may face a potential deadlock at the proc remove or a UAF. This happens since the hda_pcm is managed by a linked list, as it handles the hda_pcm object release via kref. When a PCM is opened at the unbinding time, the release of hda_pcm gets delayed and it ends up with the close of the PCM stream releasing the associated hda_pcm object of its own. The hda_pcm destructor contains the PCM device release that includes the removal of procfs entries. And, this removal has the sync of the close of all in-use files -- which would never finish because it's called from the PCM file descriptor itself, i.e. it's trying to shoot its foot. For addressing the deadlock above, this patch changes the way to manage and release the hda_pcm object. The kref of hda_pcm is dropped, and instead a simple refcount is introduced in hda_codec for keeping the track of the active PCM streams, and at each PCM open and close, this refcount is adjusted accordingly. At unbinding, the driver calls snd_device_disconnect() for each PCM stream, then synchronizes with the refcount finish, and finally releases the object resources. Fixes: bbbc7e8502c9 ("ALSA: hda - Allocate hda_pcm objects dynamically") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 1b378f59bc86b39aa6594877405f6aaf96cd05fe Author: Takashi Iwai <[email protected]> Date: Tue Nov 16 08:13:14 2021 +0100 ALSA: hda: Add missing rwsem around snd_ctl_remove() calls [ Upstream commit 80bd64af75b4bb11c0329bc66c35da2ddfb66d88 ] snd_ctl_remove() has to be called with card->controls_rwsem held (when called after the card instantiation). This patch add the missing rwsem calls around it. Fixes: d13bd412dce2 ("ALSA: hda - Manage kcontrol lists") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 9b9f32c0c744da046fa30b807364de797f8bdbeb Author: Takashi Iwai <[email protected]> Date: Tue Nov 16 08:13:13 2021 +0100 ALSA: PCM: Add missing rwsem around snd_ctl_remove() calls [ Upstream commit 5471e9762e1af4b7df057a96bfd46cc250979b88 ] snd_ctl_remove() has to be called with card->controls_rwsem held (when called after the card instantiation). This patch add the missing rwsem calls around it. Fixes: a8ff48cb7083 ("ALSA: pcm: Free chmap at PCM free callback, too") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 19eebde28fc68141580aa40931ea1b637e6a2de8 Author: Takashi Iwai <[email protected]> Date: Tue Nov 16 08:13:12 2021 +0100 ALSA: jack: Add missing rwsem around snd_ctl_remove() calls [ Upstream commit 06764dc931848c3a9bc01a63bbf76a605408bb54 ] snd_ctl_remove() has to be called with card->controls_rwsem held (when called after the card instantiation). This patch add the missing rwsem calls around it. Fixes: 9058cbe1eed2 ("ALSA: jack: implement kctl creating for jack devices") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 03c2fbca897393619632d0839366365c6f75cbf5 Author: Pierre-Louis Bossart <[email protected]> Date: Wed Oct 27 10:18:16 2021 +0800 ASoC: Intel: sof_sdw: fix jack detection on HP Spectre x360 convertible [ Upstream commit 0527b19fa4f390a6054612e1fa1dd4f8efc96739 ] Tests on device show the JD2 mode does not work at all, the 'Headphone Jack' and 'Headset Mic Jack' are shown as 'on' always. JD1 seems to be the better option, with at least a change between the two cases. Jack not plugged-in: [root@fedora ~]# amixer -Dhw:0 cget numid=12 numid=12,iface=CARD,name='Headphone Jack' ; type=BOOLEAN,access=r-------,values=1 : values=off [root@fedora ~]# amixer -Dhw:0 cget numid=13 numid=13,iface=CARD,name='Headset Mic Jack' ; type=BOOLEAN,access=r-------,values=1 : values=off Jack plugged-in: [root@fedora ~]# amixer -Dhw:0 cget numid=13 numid=13,iface=CARD,name='Headset Mic Jack' ; type=BOOLEAN,access=r-------,values=1 : values=on [root@fedora ~]# amixer -Dhw:0 cget numid=13 numid=13,iface=CARD,name='Headset Mic Jack' ; type=BOOLEAN,access=r-------,values=1 : values=on The 'Headset Mic Jack' is updated with a delay which seems normal with additional calibration needed. Fixes: d92e279dee56 ('ASoC: Intel: sof_sdw: add quirk for HP Spectre x360 convertible') Signed-off-by: Pierre-Louis Bossart <[email protected]> Reviewed-by: Ranjani Sridharan <[email protected]> Signed-off-by: Bard Liao <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 4846b55a2cd9314ebb8f70a37f8826fce1ceba2f Author: Jan Kara <[email protected]> Date: Fri Nov 12 16:22:02 2021 +0100 ext4: avoid trim error on fs with small groups [ Upstream commit 173b6e383d2a204c9921ffc1eca3b87aa2106c33 ] A user reported FITRIM ioctl failing for him on ext4 on some devices without apparent reason. After some debugging we've found out that these devices (being LVM volumes) report rather large discard granularity of 42MB and the filesystem had 1k blocksize and thus group size of 8MB. Because ext4 FITRIM implementation puts discard granularity into minlen, ext4_trim_fs() declared the trim request as invalid. However just silently doing nothing seems to be a more appropriate reaction to such combination of parameters since user did not specify anything wrong. CC: Lukas Czerner <[email protected]> Fixes: 5c2ed62fd447 ("ext4: Adjust minlen with discard_granularity in the FITRIM ioctl") Signed-off-by: Jan Kara <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 0d3bbe7eb15ee3b7fb7027fcdfa40ab86391deba Author: Pavel Skripkin <[email protected]> Date: Fri Jan 7 01:57:16 2022 +0300 net: mcs7830: handle usb read errors properly [ Upstream commit d668769eb9c52b150753f1653f7f5a0aeb8239d2 ] Syzbot reported uninit value in mcs7830_bind(). The problem was in missing validation check for bytes read via usbnet_read_cmd(). usbnet_read_cmd() internally calls usb_control_msg(), that returns number of bytes read. Code should validate that requested number of bytes was actually read. So, this patch adds missing size validation check inside mcs7830_get_reg() to prevent uninit value bugs Reported-and-tested-by: [email protected] Fixes: 2a36d7083438 ("USB: driver for mcs7830 (aka DeLOCK) USB ethernet adapter") Signed-off-by: Pavel Skripkin <[email protected]> Reviewed-by: Arnd Bergmann <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 86971970aeed561131e1f65ce063220c8a3f5832 Author: Edwin Peer <[email protected]> Date: Sun Jan 9 18:54:44 2022 -0500 bnxt_en: use firmware provided max timeout for messages [ Upstream commit bce9a0b7900836df223ab638090df0cb8430d9e8 ] Some older devices cannot accommodate the 40 seconds timeout cap for long running commands (such as NVRAM commands) due to hardware limitations. Allow these devices to request more time for these long running commands, but print a warning, since the longer timeout may cause the hung task watchdog to trigger. In the case of a firmware update operation, this is preferable to failing outright. v2: Use bp->hwrm_cmd_max_timeout directly without the constants. Fixes: 881d8353b05e ("bnxt_en: Add an upper bound for all firmware command timeouts.") Signed-off-by: Edwin Peer <[email protected]> Signed-off-by: Michael Chan <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit e685851f04561ca0ebf534db4cbfa3056f34307d Author: Edwin Peer <[email protected]> Date: Fri Oct 29 03:47:48 2021 -0400 bnxt_en: move coredump functions into dedicated file [ Upstream commit b032228e58ea2477955058ad4d70a636ce1dec51 ] Change bnxt_get_coredump() and bnxt_get_coredump_length() to non-static functions. Signed-off-by: Edwin Peer <[email protected]> Signed-off-by: Michael Chan <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit a2037e7e4d02c0b9d8714ab1a712b4e57792b22f Author: Edwin Peer <[email protected]> Date: Fri Oct 29 03:47:47 2021 -0400 bnxt_en: Refactor coredump functions [ Upstream commit 9a575c8c25ae2372112db6d6b3e553cd90e9f02b ] The coredump functionality will be used by devlink health. Refactor these functions that get coredump and coredump length. There is no functional change, but the following checkpatch warnings were addressed: - strscpy is preferred over strlcpy. - sscanf results should be checked, with an additional warning. Signed-off-by: Edwin Peer <[email protected]> Signed-off-by: Michael Chan <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 57214d92a69f6cc8eaf466b65be25eba495a96b8 Author: Nathan Chancellor <[email protected]> Date: Mon Dec 27 12:17:57 2021 -0700 iwlwifi: mvm: Use div_s64 instead of do_div in iwl_mvm_ftm_rtt_smoothing() [ Upstream commit 4ccdcc8ffd955490feec05380223db6a48961eb5 ] When building ARCH=arm allmodconfig: drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c: In function ‘iwl_mvm_ftm_rtt_smoothing’: ./include/asm-generic/div64.h:222:35: error: comparison of distinct pointer types lacks a cast [-Werror] 222 | (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \ | ^~ drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c:1070:9: note: in expansion of macro ‘do_div’ 1070 | do_div(rtt_avg, 100); | ^~~~~~ do_div() has to be used with an unsigned 64-bit integer dividend but rtt_avg is a signed 64-bit integer. div_s64() expects a signed 64-bit integer dividend and signed 32-bit divisor, which fits this scenario, so use that function here to fix the warning. Fixes: 8b0f92549f2c ("iwlwifi: mvm: fix 32-bit build in FTM") Signed-off-by: Nathan Chancellor <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit cf2ce93a7afa96659c5980ae114c5f2ee3510a8d Author: Paul Blakey <[email protected]> Date: Thu Jan 6 17:38:04 2022 +0200 net: openvswitch: Fix ct_state nat flags for conns arriving from tc [ Upstream commit 6f022c2ddbcefaee79502ce5386dfe351d457070 ] Netfilter conntrack maintains NAT flags per connection indicating whether NAT was configured for the connection. Openvswitch maintains NAT flags on the per packet flow key ct_state field, indicating whether NAT was actually executed on the packet. When a packet misses from tc to ovs the conntrack NAT flags are set. However, NAT was not necessarily executed on the packet because the connection's state might still be in NEW state. As such, openvswitch wrongly assumes that NAT was executed and sets an incorrect flow key NAT flags. Fix this, by flagging to openvswitch which NAT was actually done in act_ct via tc_skb_ext and tc_skb_cb to the openvswitch module, so the packet flow key NAT flags will be correctly set. Fixes: b57dc7c13ea9 ("net/sched: Introduce action ct") Signed-off-by: Paul Blakey <[email protected]> Acked-by: Jamal Hadi Salim <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit e7b33ff6439ac071ade78b49d3a9dd6519ddb78d Author: Paul Blakey <[email protected]> Date: Tue Dec 14 19:24:35 2021 +0200 net: openvswitch: Fix matching zone id for invalid conns arriving from tc [ Upstream commit 635d448a1cce4b4ebee52b351052c70434fa90ea ] Zone id is not restored if we passed ct and ct rejected the connection, as there is no ct info on the skb. Save the zone from tc skb cb to tc skb extension and pass it on to ovs, use that info to restore the zone id for invalid connections. Fixes: d29334c15d33 ("net/sched: act_api: fix miss set post_ct for ovs after do conntrack in act_ct") Signed-off-by: Paul Blakey <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit a006c84824634fd13f442cd57c1217cc2b1aedbd Author: Paul Blakey <[email protected]> Date: Tue Dec 14 19:24:34 2021 +0200 net/sched: flow_dissector: Fix matching on zone id for invalid conns [ Upstream commit 3849595866166b23bf6a0cb9ff87e06423167f67 ] If ct rejects a flow, it removes the conntrack info from the skb. act_ct sets the post_ct variable so the dissector will see this case as an +tracked +invalid state, but the zone id is lost with the conntrack info. To restore the zone id on such cases, set the last executed zone, via the tc control block, when passing ct, and read it back in the dissector if there is no ct info on the skb (invalid connection). Fixes: 7baf2429a1a9 ("net/sched: cls_flower add CT_FLAGS_INVALID flag support") Signed-off-by: Paul Blakey <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 3a4ecdfc0cf49f5d5536cd244052b251f8c63365 Author: Dominik Brodowski <[email protected]> Date: Sun Jan 9 10:02:51 2022 +0100 pcmcia: fix setting of kthread task states [ Upstream commit fbb3485f1f931102d8ba606f1c28123f5b48afa3 ] We need to set TASK_INTERRUPTIBLE before calling kthread_should_stop(). Otherwise, kthread_stop() might see that the pccardd thread is still in TASK_RUNNING state and fail to wake it up. Additionally, we only need to set the state back to TASK_RUNNING if kthread_should_stop() breaks the loop. Cc: Greg Kroah-Hartman <[email protected]> Reported-by: Al Viro <[email protected]> Reviewed-by: Matthew Wilcox (Oracle) <[email protected]> Fixes: d3046ba809ce ("pcmcia: fix a boot time warning in pcmcia cs code") Signed-off-by: Dominik Brodowski <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 4a71828b273865ddde1a04473be2786d1fb48e3b Author: Lad Prabhakar <[email protected]> Date: Thu Jan 6 11:48:00 2022 +0000 can: rcar_canfd: rcar_canfd_channel_probe(): make sure we free CAN network device [ Upstream commit 72b1e360572f9fa7d08ee554f1da29abce23f288 ] Make sure we free CAN network device in the error path. There are several jumps to fail label after allocating the CAN network device successfully. This patch places the free_candev() under fail label so that in failure path a jump to fail label frees the CAN network device. Fixes: 76e9353a80e9 ("can: rcar_canfd: Add support for RZ/G2L family") Link: https://lore.kernel.org/all/[email protected] Reported-by: Pavel Machek <[email protected]> Signed-off-by: Lad Prabhakar <[email protected]> Reviewed-by: Kieran Bingham <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 61970e8b5d78eb4a59ce75748dd7f2965f5edf93 Author: Jiasheng Jiang <[email protected]> Date: Fri Dec 24 10:13:24 2021 +0800 can: xilinx_can: xcan_probe(): check for error irq [ Upstream commit c6564c13dae25cd7f8e1de5127b4da4500ee5844 ] For the possible failure of the platform_get_irq(), the returned irq could be error number and will finally cause the failure of the request_irq(). Consider that platform_get_irq() can now in certain cases return -EPROBE_DEFER, and the consequences of letting request_irq() effectively convert that into -EINVAL, even at probe time rather than later on. So it might be better to check just now. Fixes: b1201e44f50b ("can: xilinx CAN controller support") Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Jiasheng Jiang <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit b8609cb64101a3b6c21560999264f12eb5f6330e Author: Marc Kleine-Budde <[email protected]> Date: Sat Jan 8 21:57:51 2022 +0100 can: softing: softing_startstop(): fix set but not used variable warning [ Upstream commit 370d988cc529598ebaec6487d4f84c2115dc696b ] In the function softing_startstop() the variable error_reporting is assigned but not used. The code that uses this variable is commented out. Its stated that the functionality is not finally verified. To fix the warning: | drivers/net/can/softing/softing_fw.c:424:9: error: variable 'error_reporting' set but not used [-Werror,-Wunused-but-set-variable] remove the comment, activate the code, but add a "0 &&" to the if expression and rely on the optimizer rather than the preprocessor to remove the code. Link: https://lore.kernel.org/all/[email protected] Fixes: 03fd3cf5a179 ("can: add driver for Softing card") Cc: Kurt Van Dijck <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit deb81894f56e8063d471465f42e09afbb5779baf Author: Christophe Jaillet <[email protected]> Date: Sat Nov 6 17:42:04 2021 +0100 tpm_tis: Fix an error handling path in 'tpm_tis_core_init()' [ Upstream commit e96d52822f5ac0a25de78f95cd23421bcbc93584 ] Commit 79ca6f74dae0 ("tpm: fix Atmel TPM crash caused by too frequent queries") has moved some code around without updating the error handling path. This is now pointless to 'goto out_err' when neither 'clk_enable()' nor 'ioremap()' have been called yet. Make a direct return instead to avoid undoing things that have not been done. Fixes: 79ca6f74dae0 ("tpm: fix Atmel TPM crash caused by too frequent queries") Signed-off-by: Christophe Jaillet <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit ea1fd8364c9fbe0dfad677fd23d0ff240c3c7a7f Author: Chen Jun <[email protected]> Date: Wed Oct 13 06:25:56 2021 +0000 tpm: add request_locality before write TPM_INT_ENABLE [ Upstream commit 0ef333f5ba7f24f5d8478425c163d3097f1c7afd ] Locality is not appropriately requested before writing the int mask. Add the missing boilerplate. Fixes: e6aef069b6e9 ("tpm_tis: convert to using locality callbacks") Signed-off-by: Chen Jun <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 8609525ee0ee7796403e4555514215ef4722a19d Author: Marc Kleine-Budde <[email protected]> Date: Tue Oct 19 17:05:25 2021 +0200 can: mcp251xfd: add missing newline to printed strings [ Upstream commit 3bd9d8ce6f8c5c43ee2f1106021db0f98882cc75 ] This patch adds the missing newline to printed strings. Fixes: 55e5b97f003e ("can: mcp25xxfd: add driver for Microchip MCP25xxFD SPI CAN") Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit f5b7e80e25c484639afb9689d9b39dcb3662f817 Author: Vladimir Oltean <[email protected]> Date: Fri Jan 7 18:43:32 2022 +0200 net: mscc: ocelot: fix incorrect balancing with down LAG ports [ Upstream commit a14e6b69f393d651913edcbe4ec0dec27b8b4b40 ] Assuming the test setup described here: https://patchwork.kernel.org/project/netdevbpf/cover/[email protected]/ (swp1 and swp2 are in bond0, and bond0 is in a bridge with swp0) it can be seen that when swp1 goes down (on either board A or B), then traffic that should go through that port isn't forwarded anywhere. A dump of the PGID table shows the following: PGID_DST[0] = ports 0 PGID_DST[1] = ports 1 PGID_DST[2] = ports 2 PGID_DST[3] = ports 3 PGID_DST[4] = ports 4 PGID_DST[5] = ports 5 PGID_DST[6] = no ports PGID_AGGR[0] = ports 0, 1, 2, 3, 4, 5 PGID_AGGR[1] = ports 0, 1, 2, 3, 4, 5 PGID_AGGR[2] = ports 0, 1, 2, 3, 4, 5 PGID_AGGR[3] = ports 0, 1, 2, 3, 4, 5 PGID_AGGR[4] = ports 0, 1, 2, 3, 4, 5 PGID_AGGR[5] = ports 0, 1, 2, 3, 4, 5 PGID_AGGR[6] = ports 0, 1, 2, 3, 4, 5 PGID_AGGR[7] = ports 0, 1, 2, 3, 4, 5 PGID_AGGR[8] = ports 0, 1, 2, 3, 4, 5 PGID_AGGR[9] = ports 0, 1, 2, 3, 4, 5 PGID_AGGR[10] = ports 0, 1, 2, 3, 4, 5 PGID_AGGR[11] = ports 0, 1, 2, 3, 4, 5 PGID_AGGR[12] = ports 0, 1, 2, 3, 4, 5 PGID_AGGR[13] = ports 0, 1, 2, 3, 4, 5 PGID_AGGR[14] = ports 0, 1, 2, 3, 4, 5 PGID_AGGR[15] = ports 0, 1, 2, 3, 4, 5 PGID_SRC[0] = ports 1, 2 PGID_SRC[1] = ports 0 PGID_SRC[2] = ports 0 PGID_SRC[3] = no ports PGID_SRC[4] = no ports PGID_SRC[5] = no ports PGID_SRC[6] = ports 0, 1, 2, 3, 4, 5 Whereas a "good" PGID configuration for that setup should have looked like this: PGID_DST[0] = ports 0 PGID_DST[1] = ports 1, 2 PGID_DST[2] = ports 1, 2 PGID_DST[3] = ports 3 PGID_DST[4] = ports 4 PGID_DST[5] = ports 5 PGID_DST[6] = no ports PGID_AGGR[0] = ports 0, 2, 3, 4, 5 PGID_AGGR[1] = ports 0, 2, 3, 4, 5 PGID_AGGR[2] = ports 0, 2, 3, 4, 5 PGID_AGGR[3] = ports 0, 2, 3, 4, 5 PGID_AGGR[4] = ports 0, 2, 3, 4, 5 PGID_AGGR[5] = ports 0, 2, 3, 4, 5 PGID_AGGR[6] = ports 0, 2, 3, 4, 5 PGID_AGGR[7] = ports 0, 2, 3, 4, 5 PGID_AGGR[8] = ports 0, 2, 3, 4, 5 PGID_AGGR[9] = ports 0, 2, 3, 4, 5 PGID_AGGR[10] = ports 0, 2, 3, 4, 5 PGID_AGGR[11] = ports 0, 2, 3, 4, 5 PGID_AGGR[12] = ports 0, 2, 3, 4, 5 PGID_AGGR[13] = ports 0, 2, 3, 4, 5 PGID_AGGR[14] = ports 0, 2, 3, 4, 5 PGID_AGGR[15] = ports 0, 2, 3, 4, 5 PGID_SRC[0] = ports 1, 2 PGID_SRC[1] = ports 0 PGID_SRC[2] = ports 0 PGID_SRC[3] = no ports PGID_SRC[4] = no ports PGID_SRC[5] = no ports PGID_SRC[6] = ports 0, 1, 2, 3, 4, 5 In other words, in the "bad" configuration, the attempt is to remove the inactive swp1 from the destination ports via PGID_DST. But when a MAC table entry is learned, it is learned towards PGID_DST 1, because that is the logical port id of the LAG itself (it is equal to the lowest numbered member port). So when swp1 becomes inactive, if we set PGID_DST[1] to contain just swp1 and not swp2, the packet will not have any chance to reach the destination via swp2. The "correct" way to remove swp1 as a destination is via PGID_AGGR (remove swp1 from the aggregation port groups for all aggregation codes). This means that PGID_DST[1] and PGID_DST[2] must still contain both swp1 and swp2. This makes the MAC table still treat packets destined towards the single-port LAG as "multicast", and the inactive ports are removed via the aggregation code tables. The change presented here is a design one: the ocelot_get_bond_mask() function used to take an "only_active_ports" argument. We don't need that. The only call site that specifies only_active_ports=true, ocelot_set_aggr_pgids(), must retrieve the entire bonding mask, because it must program that into PGID_DST. Additionally, it must also clear the inactive ports from the bond mask here, which it can't do if bond_mask just contains the active ports: ac = ocelot_read_rix(ocelot, ANA_PGID_PGID, i); ac &= ~bond_mask; <---- here /* Don't do division by zero if there was no active * port. Just make all aggregation codes zero. */ if (num_active_ports) ac |= BIT(aggr_idx[i % num_active_ports]); ocelot_write_rix(ocelot, ac, ANA_PGID_PGID, i); So it becomes the responsibility of ocelot_set_aggr_pgids() to take ocelot_port->lag_tx_active into consideration when populating the aggr_idx array. Fixes: 23ca3b727ee6 ("net: mscc: ocelot: rebalance LAGs on link up/down events") Signed-off-by: Vladimir Oltean <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 5aff6ae24b3904a074b4f81baf19b492a73c1231 Author: Fabio Estevam <[email protected]> Date: Fri Jan 7 13:33:07 2022 -0300 regmap: Call regmap_debugfs_exit() prior to _init() [ Upstream commit 530792efa6cb86f5612ff093333fec735793b582 ] Since commit cffa4b2122f5 ("regmap: debugfs: Fix a memory leak when calling regmap_attach_dev"), the following debugfs error is seen on i.MX boards: debugfs: Directory 'dummy-iomuxc-gpr@20e0000' with parent 'regmap' already present! In the attempt to fix the memory leak, the above commit added a NULL check for map->debugfs_name. For the first debufs entry, map->debugfs_name is NULL and then the new name is allocated via kasprintf(). For the second debugfs entry, map->debugfs_name() is no longer NULL, so it will keep using the old entry name and the duplicate name error is seen. Quoting Mark Brown: "That means that if the device gets freed we'll end up with the old debugfs file hanging around pointing at nothing. ... To be more explicit this means we need a call to regmap_debugfs_exit() which will clean up all the existing debugfs stuff before we loose references to it." Call regmap_debugfs_exit() prior to regmap_debugfs_init() to fix the problem. Tested on i.MX6Q and i.MX6SX boards. Fixes: cffa4b2122f5 ("regmap: debugfs: Fix a memory leak when calling regmap_attach_dev") Suggested-by: Mark Brown <[email protected]> Signed-off-by: Fabio Estevam <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit af5dcf968ebe69bd8c24ba7359aae002f8b4cdd9 Author: Dan Carpenter <[email protected]> Date: Fri Jan 7 10:12:10 2022 +0300 netrom: fix api breakage in nr_setsockopt() [ Upstream commit dc35616e6c2907b0c0c391a205802d8880f7fd85 ] This needs to copy an unsigned int from user space instead of a long to avoid breaking user space with an API change. I have updated all the integer overflow checks from ULONG to UINT as well. This is a slight API change but I do not expect it to affect anything in real life. Fixes: 3087a6f36ee0 ("netrom: fix copying in user data in nr_setsockopt") Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 7b9986a0425a83dc763222667ceb67036ac15640 Author: Dan Carpenter <[email protected]> Date: Fri Jan 7 10:13:12 2022 +0300 ax25: uninitialized variable in ax25_setsockopt() [ Upstream commit 9371937092d5fd502032c1bb4475b36b39b1f1b3 ] The "opt" variable is unsigned long but we only copy 4 bytes from the user so the lower 4 bytes are uninitialized. I have changed the integer overflow checks from ULONG to UINT as well. This is a slight API change but I don't expect it to break anything. Fixes: a7b75c5a8c41 ("net: pass a sockptr_t into ->setsockopt") Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit c48c7678739d11e9982a435b9eb9fb0d68431129 Author: Subbaraya Sundeep <[email protected]> Date: Fri Jan 7 12:00:29 2022 +0530 octeontx2-af: Increment ptp refcount before use [ Upstream commit 93440f4888cf049dbd22b41aaf94d2e2153b3eb8 ] Before using the ptp pci device by AF driver increment the reference count of it. Fixes: a8b90c9d26d6 ("octeontx2-af: Add PTP device id for CN10K and 95O silcons") Signed-off-by: Subbaraya Sundeep <[email protected]> Signed-off-by: Sunil Goutham <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit aac0b364904fe81c8c16b7def3a28eaaef327e20 Author: Miaoqian Lin <[email protected]> Date: Fri Jan 7 07:54:24 2022 +0000 spi: spi-meson-spifc: Add missing pm_runtime_disable() in meson_spifc_probe [ Upstream commit 69c1b87516e327a60b39f96b778fe683259408bf ] If the probe fails, we should use pm_runtime_disable() to balance pm_runtime_enable(). Add missing pm_runtime_disable() for meson_spifc_probe. Fixes: c3e4bc5434d2 ("spi: meson: Add support for Amlogic Meson SPIFC") Signed-off-by: Miaoqian Lin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit e1652f70e8964218c916ae4b6da3056b8f3c6e11 Author: Geliang Tang <[email protected]> Date: Thu Jan 6 14:06:37 2022 -0800 mptcp: fix a DSS option writing error [ Upstream commit 110b6d1fe98fd7af9893992459b651594d789293 ] 'ptr += 1;' was omitted in the original code. If the DSS is the last option -- which is what we have most of the time -- that's not an issue. But it is if we need to send something else after like a RM_ADDR or an MP_PRIO. Fixes: 1bff1e43a30e ("mptcp: optimize out option generation") Reviewed-by: Matthieu Baerts <[email protected]> Signed-off-by: Geliang Tang <[email protected]> Signed-off-by: Mat Martineau <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 72aba03ba836c7b72b29cbec1c8ddc61b57edada Author: Matthieu Baerts <[email protected]> Date: Thu Jan 6 14:06:36 2022 -0800 mptcp: fix opt size when sending DSS + MP_FAIL [ Upstream commit 04fac2cae9422a3401c172571afbcfdd58fa5c7e ] When these two options had to be sent -- which is not common -- the DSS size was not being taken into account in the remaining size. Additionally in this situation, the reported size was only the one of the MP_FAIL which can cause issue if at the end, we need to write more in the TCP options than previously said. Here we use a dedicated variable for MP_FAIL size to keep the WARN_ON_ONCE() just after. Fixes: c25aeb4e0953 ("mptcp: MP_FAIL suboption sending") Acked-and-tested-by: Geliang Tang <[email protected]> Signed-off-by: Matthieu Baerts <[email protected]> Signed-off-by: Mat Martineau <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit c310df0eabe5667028c2979d93a31a52cf33d0f2 Author: Paolo Abeni <[email protected]> Date: Thu Jan 6 16:20:20 2022 -0800 mptcp: fix per socket endpoint accounting [ Upstream commit f7d6a237d7422809d458d754016de2844017cb4d ] Since full-mesh endpoint support, the reception of a single ADD_ADDR option can cause multiple subflows creation. When such option is accepted we increment 'add_addr_accepted' by one. When we received a paired RM_ADDR option, we deleted all the relevant subflows, decrementing 'add_addr_accepted' by one for each of them. We have a similar issue for 'local_addr_used' Fix them moving the pm endpoint accounting outside the subflow traversal. Fixes: 1a0d6136c5f0 ("mptcp: local addresses fullmesh") Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Mat Martineau <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit abe4b2c214ea83a89716288956f88b85b33bd04f Author: Dan Carpenter <[email protected]> Date: Fri Jan 7 10:16:44 2022 +0300 Bluetooth: L2CAP: uninitialized variables in l2cap_sock_setsockopt() [ Upstream commit 2b70d4f9b20635ac328836e50d183632e1930f94 ] The "opt" variable is a u32, but on some paths only the top bytes were initialized and the others contained random stack data. Fixes: a7b75c5a8c41 ("net: pass a sockptr_t into ->setsockopt") Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit b918c668d2954461eeaa8f2409e61bca92dcb324 Author: Zizhuang Deng <[email protected]> Date: Thu Dec 30 15:03:31 2021 +0800 lib/mpi: Add the return value check of kcalloc() [ Upstream commit dd827abe296fe4249b2f8c9b95f72f814ea8348c ] Add the return value check of kcalloc() to avoid potential NULL ptr dereference. Fixes: a8ea8bdd9df9 ("lib/mpi: Extend the MPI library") Signed-off-by: Zizhuang Deng <[email protected]> Reviewed-by: Tianjia Zhang <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit d73d81447c6651904dd4a9e3fd88651ff174c1b7 Author: Moshe Shemesh <[email protected]> Date: Sun Dec 5 12:07:49 2021 +0200 net/mlx5: Set command entry semaphore up once got index free [ Upstream commit 8e715cd613a1e872b9d918e912d90b399785761a ] Avoid a race where command work handler may fail to allocate command entry index, by holding the command semaphore down till command entry index is being freed. Fixes: 410bd754cd73 ("net/mlx5: Add retry mechanism to the command entry index allocation") Signed-off-by: Moshe Shemesh <[email protected]> Reviewed-by: Eran Ben Elisha <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 266e6a36546f0734a2a3ee9b4422c9d5b942c707 Author: Maor Dickman <[email protected]> Date: Mon Jan 3 15:04:18 2022 +0200 net/mlx5e: Sync VXLAN udp ports during uplink representor profile change [ Upstream commit 07f6dc4024ea1d2314b9c8b81fd4e492864fcca1 ] Currently during NIC profile disablement all VXLAN udp ports offloaded to the HW are flushed and during its enablement the driver send notification to the stack to inform the core that the entire UDP tunnel port state has been lost, uplink representor doesn't have the same behavior which can cause VXLAN udp ports offload to be in bad state while moving between modes while VXLAN interface exist. Fixed by aligning the uplink representor profile behavior to the NIC behavior. Fixes: 84db66124714 ("net/mlx5e: Move set vxlan nic info to profile init") Signed-off-by: Maor Dickman <[email protected]> Reviewed-by: Roi Dayan <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit fbe5f19824baacaeb3aff38a4841d70e0d0da1bc Author: Shay Drory <[email protected]> Date: Thu Dec 30 08:54:08 2021 +0200 net/mlx5: Fix access to sf_dev_table on allocation failure [ Upstream commit a1c7c49c2091926962f8c1c866d386febffec5d8 ] Even when SF devices are supported, the SF device table allocation can still fail. In such case mlx5_sf_dev_supported still reports true, but SF device table is invalid. This can result in NULL table access. Hence, fix it by adding NULL table check. Fixes: 1958fc2f0712 ("net/mlx5: SF, Add auxiliary device driver") Signed-off-by: Shay Drory <[email protected]> Reviewed-by: Parav Pandit <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 7c1f9797e1b55cb14e9e9bcb817b39d06e021fc8 Author: Paul Blakey <[email protected]> Date: Wed Jun 16 10:55:56 2021 +0300 net/mlx5e: Fix matching on modified inner ip_ecn bits [ Upstream commit b6dfff21a170af5c695ebaa153b7f5e297ddca03 ] Tunnel device follows RFC 6040, and during decapsulation inner ip_ecn might change depending on inner and outer ip_ecn as follows: +---------+----------------------------------------+ |Arriving | Arriving Outer Header | | Inner +---------+---------+---------+----------+ | Header | Not-ECT | ECT(0) | ECT(1) | CE | +---------+---------+---------+---------+----------+ | Not-ECT | Not-ECT | Not-ECT | Not-ECT | <drop> | | ECT(0) | ECT(0) | ECT(0) | ECT(1) | CE* | | ECT(1) | ECT(1) | ECT(1) | ECT(1)* | CE* | | CE | CE | CE | CE | CE | +---------+---------+---------+---------+----------+ Cells marked above are changed from original inner packet ip_ecn value. Tc then matches on the modified inner ip_ecn, but hw offload which matches the inner ip_ecn value before decap, will fail. Fix that by mapping all the cases of outer and inner ip_ecn matching, and only supporting cases where we know inner wouldn't be changed by decap, or in the outer ip_ecn=CE case, inner ip_ecn didn't matter. Fixes: bcef735c59f2 ("net/mlx5e: Offload TC matching on tos/ttl for ip tunnels") Signed-off-by: Paul Blakey <[email protected]> Reviewed-by: Oz Shlomo <[email protected]> Reviewed-by: Eli Cohen <[email protected]> Reviewed-by: Roi Dayan <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 46a8a5a42984928914c20d6c8b33d2c8a3cdbd27 Author: Aya Levin <[email protected]> Date: Sun Oct 24 16:52:23 2021 +0300 Revert "net/mlx5e: Block offload of outer header csum for GRE tunnel" [ Upstream commit 01c3fd113ef50490ffd43f78f347ef6bb008510b ] This reverts commit 54e1217b90486c94b26f24dcee1ee5ef5372f832. Although the NIC doesn't support offload of outer header CSUM, using gso_partial_features allows offloading the tunnel's segmentation. The driver relies on the stack CSUM calculation of the outer header. For this, NETIF_F_GSO_GRE_CSUM must be a member of the device's features. Fixes: 54e1217b9048 ("net/mlx5e: Block offload of outer header csum for GRE tunnel") Signed-off-by: Aya Levin <[email protected]> Reviewed-by: Gal Pressman <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit a8176f18ab5fa6e7a59a23309f4ee5a4b19890a5 Author: Aya Levin <[email protected]> Date: Sun Oct 24 11:47:41 2021 +0300 Revert "net/mlx5e: Block offload of outer header csum for UDP tunnels" [ Upstream commit 64050cdad0983ad8060e33c3f4b5aee2366bcebd ] This reverts commit 6d6727dddc7f93fcc155cb8d0c49c29ae0e71122. Although the NIC doesn't support offload of outer header CSUM, using gso_partial_features allows offloading the tunnel's segmentation. The driver relies on the stack CSUM calculation of the outer header. For this, NETIF_F_GSO_UDP_TUNNEL_CSUM must be a member of the device's features. Fixes: 6d6727dddc7f ("net/mlx5e: Block offload of outer header csum for UDP tunnels") Signed-off-by: Aya Levin <[email protected]> Reviewed-by: Gal Pressman <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 44008999815b9485eca28d09cb4975f4b84b3f68 Author: Maor Dickman <[email protected]> Date: Thu Dec 30 11:20:10 2021 +0200 net/mlx5e: Don't block routes with nexthop objects in SW [ Upstream commit 9e72a55a3c9d54b38a704bb7292d984574a81d9d ] Routes with nexthop objects is currently not supported by multipath offload and any attempts to use it is blocked, however this also block adding SW routes with nexthop. Resolve this by returning NOTIFY_DONE instead of an error which will allow such a route to be created in SW but not offloaded. This fix also solve an issue which block adding such routes on different devices due to missing check if the route FIB device is one of multipath devices. Fixes: 6a87afc072c3 ("mlx5: Fail attempts to use routes with nexthop objects") Signed-off-by: Maor Dickman <[email protected]> Reviewed-by: Roi Dayan <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 360cbb1c3ec71e9b92f4bdb3455349914b911bd4 Author: Maor Dickman <[email protected]> Date: Wed Dec 29 16:10:41 2021 +0200 net/mlx5e: Fix wrong usage of fib_info_nh when routes with nexthop objects are used [ Upstream commit 885751eb1b01d276e38f57d78c583e4ce006c5ed ] Creating routes with nexthop objects while in switchdev mode leads to access to un-allocated memory and trigger bellow call trace due to hitting WARN_ON. This is caused due to illegal usage of fib_info_nh in TC tunnel FIB event handling to resolve the FIB device while fib_info built in with nexthop. Fixed by ignoring attempts to use nexthop objects with routes until support can be properly added. WARNING: CPU: 1 PID: 1724 at include/net/nexthop.h:468 mlx5e_tc_tun_fib_event+0x448/0x570 [mlx5_core] CPU: 1 PID: 1724 Comm: ip Not tainted 5.15.0_for_upstream_min_debug_2021_11_09_02_04 #1 RIP: 0010:mlx5e_tc_tun_fib_event+0x448/0x570 [mlx5_core] RSP: 0018:ffff8881349f7910 EFLAGS: 00010202 RAX: ffff8881492f1980 RBX: ffff8881349f79e8 RCX: 0000000000000000 RDX: ffff8881349f79e8 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff8881349f7950 R08: 00000000000000fe R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000000 R12: ffff88811e9d0000 R13: ffff88810eb62000 R14: ffff888106710268 R15: 0000000000000018 FS: 00007f1d5ca6e800(0000) GS:ffff88852c880000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffedba44ff8 CR3: 0000000129808004 CR4: 0000000000370ea0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> atomic_notifier_call_chain+0x42/0x60 call_fib_notifiers+0x21/0x40 fib_table_insert+0x479/0x6d0 ? try_charge_memcg+0x480/0x6d0 inet_rtm_newroute+0x65/0xb0 rtnetlink_rcv_msg+0x2af/0x360 ? page_add_file_rmap+0x13/0x130 ? do_set_pte+0xcd/0x120 ? rtnl_calcit.isra.0+0x120/0x120 netlink_rcv_skb+0x4e/0xf0 netlink_unicast+0x1ee/0x2b0 netlink_sendmsg+0x22e/0x460 sock_sendmsg+0x33/0x40 ____sys_sendmsg+0x1d1/0x1f0 ___sys_sendmsg+0xab/0xf0 ? __mod_memcg_lruvec_state+0x40/0x60 ? __mod_lruvec_page_state+0x95/0xd0 ? page_add_new_anon_rmap+0x4e/0xf0 ? __handle_mm_fault+0xec6/0x1470 __sys_sendmsg+0x51/0x90 ? internal_get_user_pages_fast+0x480/0xa10 do_syscall_64+0x3d/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae Fixes: 8914add2c9e5 ("net/mlx5e: Handle FIB events to update tunnel endpoint device") Signed-off-by: Maor Dickman <[email protected]> Reviewed-by: Vlad Buslov <[email protected]> Reviewed-by: Roi Dayan <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 423bf4c1ea8afd2e58178cf033a7d3b96d9f05cc Author: Aya Levin <[email protected]> Date: Thu Dec 23 14:38:28 2021 +0200 net/mlx5e: Fix page DMA map/unmap attributes [ Upstream commit 0b7cfa4082fbf550595bc0e40f05614bd83bf0cd ] Driver initiates DMA sync, hence it may skip CPU sync. Add DMA_ATTR_SKIP_CPU_SYNC as input attribute both to dma_map_page and dma_unmap_page to avoid redundant sync with the CPU. When forcing the device to work with SWIOTLB, the extra sync might cause data corruption. The driver unmaps the whole page while the hardware used just a part of the bounce buffer. So syncing overrides the entire page with bounce buffer that only partially contains real data. Fixes: bc77b240b3c5 ("net/mlx5e: Add fragmented memory support for RX multi packet WQE") Fixes: db05815b36cb ("net/mlx5e: Add XSK zero-copy support") Signed-off-by: Aya Levin <[email protected]> Reviewed-by: Gal Pressman <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 6d818695065df8466e67e02e3e120408fa1a592b Author: Huang Rui <[email protected]> Date: Thu Jan 6 15:43:06 2022 +0800 x86, sched: Fix undefined reference to init_freq_invariance_cppc() build error [ Upstream commit 6c4ab1b86dac3954d15c00c1a6396d60a1023fab ] The init_freq_invariance_cppc function is implemented in smpboot and depends on CONFIG_SMP. MODPOST vmlinux.symvers MODINFO modules.builtin.modinfo GEN modules.builtin LD .tmp_vmlinux.kallsyms1 ld: drivers/acpi/cppc_acpi.o: in function `acpi_cppc_processor_probe': /home/ray/brahma3/linux/drivers/acpi/cppc_acpi.c:819: undefined reference to `init_freq_invariance_cppc' make: *** [Makefile:1161: vmlinux] Error 1 See https://lore.kernel.org/lkml/[email protected]/. Fixes: 41ea667227ba ("x86, sched: Calculate frequency invariance for AMD systems") Reported-by: kernel test robot <[email protected]> Reported-by: Randy Dunlap <[email protected]> Reported-by: Stephen Rothwell <[email protected]> Signed-off-by: Huang Rui <[email protected]> [ rjw: Subject edits ] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit f7e2f374799ff87cc0734cb3efe1a168aae77d8e Author: Valentin Caron <[email protected]> Date: Tue Jan 4 19:24:42 2022 +0100 serial: stm32: move tx dma terminate DMA to shutdown [ Upstream commit 56a23f9319e86e1d62a109896e2c7e52c414e67d ] Terminate DMA transaction and clear CR3_DMAT when shutdown is requested, instead of when remove is requested. If DMA transfer is not stopped in shutdown ops, driver will fail to start a new DMA transfer after next startup ops. Fixes: 3489187204eb ("serial: stm32: adding dma support") Signed-off-by: Erwan Le Ray <[email protected]> Signed-off-by: Valentin Caron <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 8209b0b395aaed26779286d7caa735277217353d Author: Alyssa Ross <[email protected]> Date: Tue Jan 4 13:10:28 2022 +0000 serial: liteuart: fix MODULE_ALIAS [ Upstream commit 556172fabd226ba14b70c1740d0826a4717473dc ] modprobe can't handle spaces in aliases. Fixes: 1da81e5562fa ("drivers/tty/serial: add LiteUART driver") Signed-off-by: Alyssa Ross <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 71db96193317626954073c24344d5cf4759e0af3 Author: Miaoqian Lin <[email protected]> Date: Fri Dec 31 08:04:25 2021 +0000 drivers/firmware: Add missing platform_device_put() in sysfb_create_simplefb [ Upstream commit 0589e8889dce8e0f0ea5bbf757f38865e2a469c1 ] Add the missing platform_device_put() before return from sysfb_create_simplefb() in the error handling case. Fixes: 8633ef82f101 ("drivers/firmware: consolidate EFI framebuffer setup for all arches") Signed-off-by: Miaoqian Lin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 1850a403bd0b9b61dffcf6afa2fefe6db9a49fd4 Author: Michal Suchanek <[email protected]> Date: Tue Jan 4 18:05:05 2022 +0100 debugfs: lockdown: Allow reading debugfs files that are not world readable [ Upstream commit 358fcf5ddbec4e6706405847d6a666f5933a6c25 ] When the kernel is locked down the kernel allows reading only debugfs files with mode 444. Mode 400 is also valid but is not allowed. Make the 444 into a mask. Fixes: 5496197f9b08 ("debugfs: Restrict debugfs when the kernel is locked down") Signed-off-by: Michal Suchanek <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 0fc97f944245de471cbabf637fd84036939e009a Author: José Expósito <[email protected]> Date: Wed Jan 5 18:29:15 2022 +0100 HID: hid-uclogic-params: Invalid parameter check in uclogic_params_frame_init_v1_buttonpad [ Upstream commit aa320fdbbbb482c19100f51461bd0069753ce3d7 ] The function performs a check on the hdev input parameters, however, it is used before the check. Initialize the udev variable after the sanity check to avoid a possible NULL pointer dereference. Fixes: 9614219e9310e ("HID: uclogic: Extract tablet parameter discovery into a module") Addresses-Coverity-ID: 1443763 ("Null pointer dereference") Signed-off-by: José Expósito <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit fc8a47ed624bd29b0ae91fbd96019274c87870cc Author: José Expósito <[email protected]> Date: Wed Jan 5 18:29:14 2022 +0100 HID: hid-uclogic-params: Invalid parameter check in uclogic_params_huion_init [ Upstream commit ff6b548afe4d9d1ff3a0f6ef79e8cbca25d8f905 ] The function performs a check on its input parameters, however, the hdev parameter is used before the check. Initialize the stack variables after checking the input parameters to avoid a possible NULL pointer dereference. Fixes: 9614219e9310e ("HID: uclogic: Extract tablet parameter discovery into a module") Addresses-Coverity-ID: 1443804 ("Null pointer dereference") Signed-off-by: José Expósito <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 964e6a78cb1df2ca1a4ec92bd6159ff93483032d Author: José Expósito <[email protected]> Date: Wed Jan 5 18:29:13 2022 +0100 HID: hid-uclogic-params: Invalid parameter check in uclogic_params_get_str_desc [ Upstream commit 0a94131d6920916ccb6a357037c535533af08819 ] The function performs a check on the hdev input parameters, however, it is used before the check. Initialize the udev variable after the sanity check to avoid a possible NULL pointer dereference. Fixes: 9614219e9310e ("HID: uclogic: Extract tablet parameter discovery into a module") Addresses-Coverity-ID: 1443827 ("Null pointer dereference") Signed-off-by: José Expósito <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 621aade97324398e74e8cd921fc02fc015e1d606 Author: José Expósito <[email protected]> Date: Wed Jan 5 18:29:12 2022 +0100 HID: hid-uclogic-params: Invalid parameter check in uclogic_params_init [ Upstream commit f364c571a5c77e96de2d32062ff019d6b8d2e2bc ] The function performs a check on its input parameters, however, the hdev parameter is used before the check. Initialize the stack variables after checking the input parameters to avoid a possible NULL pointer dereference. Fixes: 9614219e9310e ("HID: uclogic: Extract tablet parameter discovery into a module") Addresses-Coverity-ID: 1443831 ("Null pointer dereference") Signed-off-by: José Expósito <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 78e8660e9d909702d5d17660c46360bcd57e80ba Author: Pavel Hofman <[email protected]> Date: Wed Jan 5 11:46:43 2022 +0100 usb: gadget: u_audio: Subdevice 0 for capture ctls [ Upstream commit 601a5bc1aeef772ab1f47582fd322957799f5ab5 ] Both capture and playback alsa devices use subdevice 0. Yet capture-side ctls are defined for subdevice 1. The patch sets subdevice 0 for them. Fixes: 02de698ca812 ("usb: gadget: u_audio: add bi-directional volume and mute support") Signed-off-by: Pavel Hofman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit e3e610612234ff17eeaa8363a4003f170583e354 Author: John Keeping <[email protected]> Date: Thu Jan 6 11:57:31 2022 +0000 usb: dwc2: gadget: initialize max_speed from params [ Upstream commit 92ef98a4caacad6d4a1490dda45d81ae5ccf5bc9 ] DWC2 may be paired with a full-speed PHY which is not capable of high-speed operation. Report this correctly to the gadget core by setting max_speed from the core parameters. Prior to commit 5324bad66f09f ("usb: dwc2: gadget: implement udc_set_speed()") this didn't cause the hardware to be configured incorrectly, although the speed may have been reported incorrectly. But after that commit params.speed is updated based on a value passed in by the gadget core which may set it to a faster speed than is supported by the hardware. Initialising the max_speed parameter ensures the speed passed to dwc2_gadget_set_speed() will be one supported by the hardware. Fixes: 5324bad66f09f ("usb: dwc2: gadget: implement udc_set_speed()") Acked-by: Minas Harutyunyan <[email protected]> Signed-off-by: John Keeping <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 85a75d45f7155ce3b4ea99f2fc5f2acd952bf921 Author: Dinh Nguyen <[email protected]> Date: Tue Jan 4 07:59:22 2022 -0600 usb: dwc2: do not gate off the hardware if it does not support clock gating [ Upstream commit 34146c68083f1aef6709196b3dc888c1ceffd357 ] We should not be clearing the HCD_FLAG_HW_ACCESSIBLE bit if the hardware does not support clock gating. Fixes: 50fb0c128b6e ("usb: dwc2: Add clock gating entering flow by system suspend") Acked-by: Minas Harutyunyan <[email protected]> Signed-off-by: Dinh Nguyen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 5157828d3975768b53a51cdf569203b953184022 Author: Miaoqian Lin <[email protected]> Date: Wed Dec 22 11:18:23 2021 +0000 usb: dwc3: qcom: Fix NULL vs IS_ERR checking in dwc3_qcom_probe [ Upstream commit b52fe2dbb3e655eb1483000adfab68a219549e13 ] Since the acpi_create_platform_device() function may return error pointers, dwc3_qcom_create_urs_usb_platdev() function may return error pointers too. Using IS_ERR_OR_NULL() to check the return value to fix this. Fixes: c25c210f590e ("usb: dwc3: qcom: add URS Host support for sdm845 ACPI boot") Signed-off-by: Miaoqian Lin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit db7d1a2e0609d473335a908df9780ecd65853e1d Author: Wen Gu <[email protected]> Date: Thu Jan 6 20:42:08 2022 +0800 net/smc: Reset conn->lgr when link group registration fails [ Upstream commit 36595d8ad46d9e4c41cc7c48c4405b7c3322deac ] SMC connections might fail to be registered in a link group due to unable to find a usable link during its creation. As a result, smc_conn_create() will return a failure and most resources related to the connection won't be applied or initialized, such as conn->abort_work or conn->lnk. If smc_conn_free() is invoked later, it will try to access the uninitialized resources related to the connection, thus causing a warning or crash. This patch tries to fix this by resetting conn->lgr to NULL if an abnormal exit occurs in smc_lgr_register_conn(), thus avoiding the access to uninitialized resources in smc_conn_free(). Meanwhile, the new created link group should be terminated if smc connections can't be registered in it. So smc_lgr_cleanup_early() is modified to take care of link group only and invoked to terminate unusable link group by smc_conn_create(). The call to smc_conn_free() is moved out from smc_lgr_cleanup_early() to smc_conn_abort(). Fixes: 56bc3b2094b4 ("net/smc: assign link to a new connection") Suggested-by: Karsten Graul <[email protected]> Signed-off-by: Wen Gu <[email protected]> Acked-by: Karsten Graul <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 9186e6ba52af11ba7b5f432aa2321f36e00ad721 Author: Miaoqian Lin <[email protected]> Date: Fri Dec 24 08:02:49 2021 +0000 Bluetooth: hci_qca: Fix NULL vs IS_ERR_OR_NULL check in qca_serdev_probe [ Upstream commit 6845667146a28c09b5dfc401c1ad112374087944 ] The function devm_gpiod_get_index() return error pointers on error. Thus devm_gpiod_get_index_optional() could return NULL and error pointers. The same as devm_gpiod_get_optional() function. Using IS_ERR_OR_NULL() check to catch error pointers. Fixes: 77131dfe ("Bluetooth: hci_qca: Replace devm_gpiod_get() with devm_gpiod_get_optional()") Signed-off-by: Miaoqian Lin <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit ede559376794a204e86667dd36b1401987e3b084 Author: Jiasheng Jiang <[email protected]> Date: Fri Dec 24 10:53:18 2021 +0800 Bluetooth: hci_bcm: Check for error irq [ Upstream commit b38cd3b42fba66cc538edb9cf77e07881f43f8e2 ] For the possible failure of the platform_get_irq(), the returned irq could be error number and will finally cause the failure of the request_irq(). Consider that platform_get_irq() can now in certain cases return -EPROBE_DEFER, and the consequences of letting request_irq() effectively convert that into -EINVAL, even at probe time rather than later on. So it might be better to check just now. Fixes: 0395ffc1ee05 ("Bluetooth: hci_bcm: Add PM for BCM devices") Signed-off-by: Jiasheng Jiang <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 3983254b43c24d871acc5e732fee872606d445b9 Author: Jiasheng Jiang <[email protected]> Date: Thu Jan 6 18:04:10 2022 +0800 fsl/fman: Check for null pointer after calling devm_ioremap [ Upstream commit d5a73ec96cc57cf67e51b12820fc2354e7ca46f8 ] As the possible failure of the allocation, the devm_ioremap() may return NULL pointer. Take tgec_initialization() as an example. If allocation fails, the params->base_addr will be NULL pointer and will be assigned to tgec->regs in tgec_config(). Then it will cause the dereference of NULL pointer in set_mac_address(), which is called by tgec_init(). Therefore, it should be better to add the sanity check after the calling of the devm_ioremap(). Fixes: 3933961682a3 ("fsl/fman: Add FMan MAC driver") Signed-off-by: Jiasheng Jiang <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit c154574b84a5798258aea42a5398ccc13057d548 Author: Jiasheng Jiang <[email protected]> Date: Tue Jan 4 23:06:28 2022 +0800 staging: greybus: audio: Check null pointer [ Upstream commit 2e81948177d769106754085c3e03534e6cc1f623 ] As the possible alloc failure of devm_kcalloc(), it could return null pointer. Therefore, 'strings' should be checked and return NULL if alloc fails to prevent the dereference of the NULL pointer. Also, the caller should also deal with the return value of the gb_generate_enum_strings() and return -ENOMEM if returns NULL. Moreover, because the memory allocated with devm_kzalloc() will be freed automatically when the last reference to the device is dropped, the 'gbe' in gbaudio_tplg_create_enum_kctl() and gbaudio_tplg_create_enum_ctl() do not need to free manually. But the 'control' in gbaudio_tplg_create_widget() and gbaudio_tplg_process_kcontrols() has a specially error handle to cleanup. So it should be better to cleanup 'control' when fails. Fixes: e65579e335da ("greybus: audio: topology: Enable enumerated control support") Reviewed-by: Alex Elder <[email protected]> Signed-off-by: Jiasheng Jiang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 4a308769df64bfcaea7a398e9c548386f9b6a075 Author: Dan Carpenter <[email protected]> Date: Thu Jan 6 14:57:54 2022 +0300 rocker: fix a sleeping in atomic bug [ Upstream commit 43d012123122cc69feacab55b71369f386c19566 ] This code is holding the &ofdpa->flow_tbl_lock spinlock so it is not allowed to sleep. That means we have to pass the OFDPA_OP_FLAG_NOWAIT flag to ofdpa_flow_tbl_del(). Fixes: 936bd486564a ("rocker: use FIB notifications instead of switchdev calls") Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 5f54a0355802cfcd3e868541417b55c81b05e54e Author: Eric Dumazet <[email protected]> Date: Wed Jan 5 03:48:42 2022 -0800 ppp: ensure minimum packet size in ppp_write() [ Upstream commit 44073187990d5629804ce0627525f6ea5cfef171 ] It seems pretty clear ppp layer assumed user space would always be kind to provide enough data in their write() to a ppp device. This patch makes sure user provides at least 2 bytes. It adds PPP_PROTO_LEN macro that could replace in net-next many occurrences of hard-coded 2 value. I replaced only one occurrence to ease backports to stable kernels. The bug manifests in the following report: BUG: KMSAN: uninit-value in ppp_send_frame+0x28d/0x27c0 drivers/net/ppp/ppp_generic.c:1740 ppp_send_frame+0x28d/0x27c0 drivers/net/ppp/ppp_generic.c:1740 __ppp_xmit_process+0x23e/0x4b0 drivers/net/ppp/ppp_generic.c:1640 ppp_xmit_process+0x1fe/0x480 drivers/net/ppp/ppp_generic.c:1661 ppp_write+0x5cb/0x5e0 drivers/net/ppp/ppp_generic.c:513 do_iter_write+0xb0c/0x1500 fs/read_write.c:853 vfs_writev fs/read_write.c:924 [inline] do_writev+0x645/0xe00 fs/read_write.c:967 __do_sys_writev fs/read_write.c:1040 [inline] __se_sys_writev fs/read_write.c:1037 [inline] __x64_sys_writev+0xe5/0x120 fs/read_write.c:1037 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xae Uninit was created at: slab_post_alloc_hook mm/slab.h:524 [inline] slab_alloc_node mm/slub.c:3251 [inline] __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4974 kmalloc_reserve net/core/skbuff.c:354 [inline] __alloc_skb+0x545/0xf90 net/core/skbuff.c:426 alloc_skb include/linux/skbuff.h:1126 [inline] ppp_write+0x11d/0x5e0 drivers/net/ppp/ppp_generic.c:501 do_iter_write+0xb0c/0x1500 fs/read_write.c:853 vfs_writev fs/read_write.c:924 [inline] do_writev+0x645/0xe00 fs/read_write.c:967 __do_sys_writev fs/read_write.c:1040 [inline] __se_sys_writev fs/read_write.c:1037 [inline] __x64_sys_writev+0xe5/0x120 fs/read_write.c:1037 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xae Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Eric Dumazet <[email protected]> Cc: Paul Mackerras <[email protected]> Cc: [email protected] Reported-by: syzbot <[email protected]> Acked-by: Guillaume Nault <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit ff53c861e97e89a19c1643b3e104d737eb02568d Author: Miroslav Lichvar <[email protected]> Date: Wed Jan 5 11:33:26 2022 +0100 net: fix SOF_TIMESTAMPING_BIND_PHC to work with multiple sockets [ Upstream commit 007747a984ea5e895b7d8b056b24ebf431e1e71d ] When multiple sockets using the SOF_TIMESTAMPING_BIND_PHC flag received a packet with a hardware timestamp (e.g. multiple PTP instances in different PTP domains using the UDPv4/v6 multicast or L2 transport), the timestamps received on some sockets were corrupted due to repeated conversion of the same timestamp (by the same or different vclocks). Fix ptp_convert_timestamp() to not modify the shared skb timestamp and return the converted timestamp as a ktime_t instead. If the conversion fails, return 0 to not confuse the application with timestamps corresponding to an unexpected PHC. Fixes: d7c088265588 ("net: socket: support hardware timestamp conversion to PHC bound") Signed-off-by: Miroslav Lichvar <[email protected]> Cc: Yangbo Lu <[email protected]> Cc: Richard Cochran <[email protected]> Acked-by: Richard Cochran <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 29a0827b749151dae6271410332fb9d0a33923d7 Author: Florian Westphal <[email protected]> Date: Wed Jan 5 14:19:54 2022 +0100 netfilter: nft_set_pipapo: allocate pcpu scratch maps on clone [ Upstream commit 23c54263efd7cb605e2f7af72717a2a951999217 ] This is needed in case a new transaction is made that doesn't insert any new elements into an already existing set. Else, after second 'nft -f ruleset.txt', lookups in such a set will fail because ->lookup() encounters raw_cpu_ptr(m->scratch) == NULL. For the initial rule load, insertion of elements takes care of the allocation, but for rule reloads this isn't guaranteed: we might not have additions to the set. Fixes: 3c4287f62044a90e ("nf_tables: Add set type for arbitrary concatenation of ranges") Reported-by: etkaar <[email protected]> Signed-off-by: Florian Westphal <[email protected]> Reviewed-by: Stefano Brivio <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 500193142a20346e7be674a59b674e4c5e8dc1ae Author: Pablo Neira Ayuso <[email protected]> Date: Wed Jan 5 16:09:57 2022 +0100 netfilter: nft_payload: do not update layer 4 checksum when mangling fragments [ Upstream commit 4e1860a3863707e8177329c006d10f9e37e097a8 ] IP fragments do not come with the transport header, hence skip bogus layer 4 checksum updates. Fixes: 1814096980bb ("netfilter: nft_payload: layer 4 checksum adjustment for pseudoheader fields") Reported-and-tested-by: Steffen Weinreich <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 2db60bb564056e87a9985ce866f250b7847efd81 Author: Kuniyuki Iwashima <[email protected]> Date: Tue Jan 4 10:31:48 2022 +0900 bpf: Fix SO_RCVBUF/SO_SNDBUF handling in _bpf_setsockopt(). [ Upstream commit 04c350b1ae6bdb12b84009a4d0bf5ab4e621c47b ] The commit 4057765f2dee ("sock: consistent handling of extreme SO_SNDBUF/SO_RCVBUF values") added a change to prevent underflow in setsockopt() around SO_SNDBUF/SO_RCVBUF. This patch adds the same change to _bpf_setsockopt(). Fixes: 4057765f2dee ("sock: consistent handling of extreme SO_SNDBUF/SO_RCVBUF values") Signed-off-by: Kuniyuki Iwashima <[email protected]> Signed-off-by: Alexei Starovoitov <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 2fbd466952728c088cb1b430256afa8d5c58615b Author: Kris Van Hees <[email protected]> Date: Wed Jan 5 16:01:50 2022 -0500 bpf: Fix verifier support for validation of async callbacks [ Upstream commit a5bebc4f00dee47113eed48098c68e88b5ba70e8 ] Commit bfc6bb74e4f1 ("bpf: Implement verifier support for validation of async callbacks.") added support for BPF_FUNC_timer_set_callback to the __check_func_call() function. The test in __check_func_call() is flaweed because it can mis-interpret a regular BPF-to-BPF pseudo-call as a BPF_FUNC_timer_set_callback callback call. Consider the conditional in the code: if (insn->code == (BPF_JMP | BPF_CALL) && insn->imm == BPF_FUNC_timer_set_callback) { The BPF_FUNC_timer_set_callback has value 170. This means that if you have a BPF program that contains a pseudo-call with an instruction delta of 170, this conditional will be found to be true by the verifier, and it will interpret the pseudo-call as a callback. This leads to a mess with the verification of the program because it makes the wrong assumptions about the nature of this call. Solution: include an explicit check to ensure that insn->src_reg == 0. This ensures that calls cannot be mis-interpreted as an async callback call. Fixes: bfc6bb74e4f1 ("bpf: Implement verifier support for validation of async callbacks.") Signed-off-by: Kris Van Hees <[email protected]> Signed-off-by: Alexei Starovoitov <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit a65df848dbe083bfe1c01200b6b5038083824872 Author: Daniel Borkmann <[email protected]> Date: Wed Jan 5 11:35:13 2022 -0800 bpf: Don't promote bogus looking registers after null check. [ Upstream commit e60b0d12a95dcf16a63225cead4541567f5cb517 ] If we ever get to a point again where we convert a bogus looking <ptr>_or_null typed register containing a non-zero fixed or variable offset, then lets not reset these bounds to zero since they are not and also don't promote the register to a <ptr> type, but instead leave it as <ptr>_or_null. Converting to a unknown register could be an avenue as well, but then if we run into this case it would allow to leak a kernel pointer this way. Fixes: f1174f77b50c ("bpf/verifier: rework value tracking") Signed-off-by: Daniel Borkmann <[email protected]> Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 073f7fb020b52832ab5a05d48fe1c9f73345652b Author: John Fastabend <[email protected]> Date: Tue Jan 4 13:46:45 2022 -0800 bpf, sockmap: Fix double bpf_prog_put on error case in map_link [ Upstream commit 218d747a4142f281a256687bb513a135c905867b ] sock_map_link() is called to update a sockmap entry with a sk. But, if the sock_map_init_proto() call fails then we return an error to the map_update op against the sockmap. In the error path though we need to cleanup psock and dec the refcnt on any programs associated with the map, because we refcnt them early in the update process to ensure they are pinned for the psock. (This avoids a race where user deletes programs while also updating the map with new socks.) In current code we do the prog refcnt dec explicitely by calling bpf_prog_put() when the program was found in the map. But, after commit '38207a5e81230' in this error path we've already done the prog to psock assignment so the programs have a reference from the psock as well. This then causes the psock tear down logic, invoked by sk_psock_put() in the error path, to similarly call bpf_prog_put on the programs there. To be explicit this logic does the prog->psock assignment: if (msg_*) psock_set_prog(...) Then the error path under the out_progs label does a similar check and dec with: if (msg_*) bpf_prog_put(...) And the teardown logic sk_psock_put() does ... psock_set_prog(msg_*, NULL) ... triggering another bpf_prog_put(...). Then KASAN gives us this splat, found by syzbot because we've created an inbalance between bpf_prog_inc and bpf_prog_put calling put twice on the program. BUG: KASAN: vmalloc-out-of-bounds in __bpf_prog_put kernel/bpf/syscall.c:1812 [inline] BUG: KASAN: vmalloc-out-of-bounds in __bpf_prog_put kernel/bpf/syscall.c:1812 [inline] kernel/bpf/syscall.c:1829 BUG: KASAN: vmalloc-out-of-bounds in bpf_prog_put+0x8c/0x4f0 kernel/bpf/syscall.c:1829 kernel/bpf/syscall.c:1829 Read of size 8 at addr ffffc90000e76038 by task syz-executor020/3641 To fix clean up error path so it doesn't try to do the bpf_prog_put in the error path once progs are assigned then it relies on the normal psock tear down logic to do complete cleanup. For completness we also cover the case whereh sk_psock_init_strp() fails, but this is not expected because it indicates an incorrect socket type and should be caught earlier. Fixes: 38207a5e8123 ("bpf, sockmap: Attach map progs to psock early for feature probes") Reported-by: [email protected] Signed-off-by: John Fastabend <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit f26349213d975300dbfb0104cc03f7a760ccf2de Author: John Fastabend <[email protected]> Date: Tue Jan 4 12:59:18 2022 -0800 bpf, sockmap: Fix return codes from tcp_bpf_recvmsg_parser() [ Upstream commit 5b2c5540b8110eea0d67a78fb0ddb9654c58daeb ] Applications can be confused slightly because we do not always return the same error code as expected, e.g. what the TCP stack normally returns. For example on a sock err sk->sk_err instead of returning the sock_error we return EAGAIN. This usually means the application will 'try again' instead of aborting immediately. Another example, when a shutdown event is received we should immediately abort instead of waiting for data when the user provides a timeout. These tend to not be fatal, applications usually recover, but introduces bogus errors to the user or introduces unexpected latency. Before 'c5d2177a72a16' we fell back to the TCP stack when no data was available so we managed to catch many of the cases here, although with the extra latency cost of calling tcp_msg_wait_data() first. To fix lets duplicate the error handling in TCP stack into tcp_bpf so that we get the same error codes. These were found in our CI tests that run applications against sockmap and do longer lived testing, at least compared to test_sockmap that does short-lived ping/pong tests, and in some of our test clusters we deploy. Its non-trivial to do these in a shorter form CI tests that would be appropriate for BPF selftests, but we are looking into it so we can ensure this keeps working going forward. As a preview one idea is to pull in the packetdrill testing which catches some of this. Fixes: c5d2177a72a16 ("bpf, sockmap: Fix race in ingress receive verdict with redirect to self") Signed-off-by: John Fastabend <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit a1c2d9a513e560864575325b5a316db64ac100fb Author: Xin Xiong <[email protected]> Date: Thu Dec 23 10:48:12 2021 +0800 netfilter: ipt_CLUSTERIP: fix refcount leak in clusterip_tg_check() [ Upstream commit d94a69cb2cfa77294921aae9afcfb866e723a2da ] The issue takes place in one error path of clusterip_tg_check(). When memcmp() returns nonzero, the function simply returns the error code, forgetting to decrease the reference count of a clusterip_config object, which is bumped earlier by clusterip_config_find_get(). This may incur reference count leak. Fix this issue by decrementing the refcount of the object in specific error path. Fixes: 06aa151ad1fc74 ("netfilter: ipt_CLUSTERIP: check MAC address when duplicate config is set") Signed-off-by: Xin Xiong <[email protected]> Signed-off-by: Xiyu Yang <[email protected]> Signed-off-by: Xin Tan <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 21bdddc9648b9b44868e496103adfa16d55aaf69 Author: Vladimir Oltean <[email protected]> Date: Wed Jan 5 15:18:11 2022 +0200 net: dsa: fix incorrect function pointer check for MRP ring roles [ Upstream commit ff91e1b68490b97c18c649b769618815eb945f11 ] The cross-chip notifier boilerplate code meant to check the presence of ds->ops->port_mrp_add_ring_role before calling it, but checked ds->ops->port_mrp_add instead, before calling ds->ops->port_mrp_add_ring_role. Therefore, a driver which implements one operation but not the other would trigger a NULL pointer dereference. There isn't any such driver in DSA yet, so there is no reason to backport the change. Issue found through code inspection. Cc: Horatiu Vultur <[email protected]> Fixes: c595c4330da0 ("net: dsa: add MRP support") Signed-off-by: Vladimir Oltean <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 6dab20da69f9b92ebbdd8beed45002ecb3c83cda Author: Daniel Golle <[email protected]> Date: Tue Jan 4 12:06:22 2022 +0000 net: ethernet: mtk_eth_soc: fix return values and refactor MDIO ops [ Upstream commit eda80b249df7bbc7b3dd13907343a3e59bfc57fd ] Instead of returning -1 (-EPERM) when MDIO bus is stuck busy while writing or 0xffff if it happens while reading, return the appropriate -ETIMEDOUT. Also fix return type to int instead of u32. Refactor functions to use bitfield helpers instead of having various masking and shifting constants in the code, which also results in the register definitions in the header file being more obviously related to what is stated in the MediaTek's Reference Manual. Fixes: 656e705243fd0 ("net-next: mediatek: add support for MT7623 ethernet") Signed-off-by: Daniel Golle <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 10f849d3e563f0b443cdc38ff9e4000ec12ca432 Author: Raed Salem <[email protected]> Date: Mon Jan 3 13:19:29 2022 +0200 net/xfrm: IPsec tunnel mode fix inner_ipproto setting in sec_path [ Upstream commit 45a98ef4922def8c679ca7c454403d1957fe70e7 ] The inner_ipproto saves the inner IP protocol of the plain text packet. This allows vendor's IPsec feature making offload decision at skb's features_check and configuring hardware at ndo_start_xmit, current code implenetation did not handle the case where IPsec is used in tunnel mode. Fix by handling the case when IPsec is used in tunnel mode by reading the protocol of the plain text packet IP protocol. Fixes: fa4535238fb5 ("net/xfrm: Add inner_ipproto into sec_path") Signed-off-by: Raed Salem <[email protected]> Signed-off-by: Steffen Klassert <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 4849eca4fc6fc35fdf3e667110fd8156fe77f90a Author: Jiasheng Jiang <[email protected]> Date: Mon Dec 20 16:38:11 2021 +0800 power: reset: mt6397: Check for null res pointer [ Upstream commit 1c1348bf056dee665760a3bd1cd30b0be7554fc2 ] The return value of platform_get_resource() needs to be checked. To avoid use of error pointer in case that there is no suitable resource. Fixes: d28c74c10751 ("power: reset: add driver for mt6323 poweroff") Signed-off-by: Jiasheng Jiang <[email protected]> Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit a3b31433147bc793d2adccccecde804ec8e17a57 Author: Zhou Qingyang <[email protected]> Date: Wed Dec 1 02:11:40 2021 +0800 pcmcia: rsrc_nonstatic: Fix a NULL pointer dereference in nonstatic_find_mem_region() [ Upstream commit 977d2e7c63c3d04d07ba340b39987742e3241554 ] In nonstatic_find_mem_region(), pcmcia_make_resource() is assigned to res and used in pci_bus_alloc_resource(). There a dereference of res in pci_bus_alloc_resource(), which could lead to a NULL pointer dereference on failure of pcmcia_make_resource(). Fix this bug by adding a check of res. This bug was found by a static analyzer. The analysis employs differential checking to identify inconsistent security operations (e.g., checks or kfrees) between two code paths and confirms that the inconsistent operations are not recovered in the current function or the callers, so they constitute bugs. Note that, as a bug found by static analysis, it can be a false positive or hard to trigger. Multiple researchers have cross-reviewed the bug. Builds with CONFIG_PCCARD_NONSTATIC=y show no new warnings, and our static analyzer no longer warns about this code. Fixes: 49b1153adfe1 ("pcmcia: move all pcmcia_resource_ops providers into one module") Signed-off-by: Zhou Qingyang <[email protected]> Signed-off-by: Dominik Brodowski <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 7756cb45dbfe65af431c555e30e9a030272b4f45 Author: Zhou Qingyang <[email protected]> Date: Wed Dec 1 00:59:23 2021 +0800 pcmcia: rsrc_nonstatic: Fix a NULL pointer dereference in __nonstatic_find_io_region() [ Upstream commit ca0fe0d7c35c97528bdf621fdca75f13157c27af ] In __nonstatic_find_io_region(), pcmcia_make_resource() is assigned to res and used in pci_bus_alloc_resource(). There is a dereference of res in pci_bus_alloc_resource(), which could lead to a NULL pointer dereference on failure of pcmcia_make_resource(). Fix this bug by adding a check of res. This bug was found by a static analyzer. The analysis employs differential checking to identify inconsistent security operations (e.g., checks or kfrees) between two code paths and confirms that the inconsistent operations are not recovered in the current function or the callers, so they constitute bugs. Note that, as a bug found by static analysis, it can be a false positive or hard to trigger. Multiple researchers have cross-reviewed the bug. Builds with CONFIG_PCCARD_NONSTATIC=y show no new warnings, and our static analyzer no longer warns about this code. Fixes: 49b1153adfe1 ("pcmcia: move all pcmcia_resource_ops providers into one module") Signed-off-by: Zhou Qingyang <[email protected]> [[email protected]: Fix typo in commit message] Signed-off-by: Dominik Brodowski <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 5d2fd6fff8e49e4f5542b5f38fde308268927d9f Author: Hans de Goede <[email protected]> Date: Thu Dec 30 12:57:47 2021 +0100 ACPI: scan: Create platform device for BCM4752 and LNV4752 ACPI nodes [ Upstream commit f85196bdd5a50da74670250564740fc852b3c239 ] BCM4752 and LNV4752 ACPI nodes describe a Broadcom 4752 GPS module attached to an UART of the system. The GPS modules talk a custom protocol which only works with a closed- source Android gpsd daemon which knows this protocol. The ACPI nodes also describe GPIOs to turn the GPS on/off these are handled by the net/rfkill/rfkill-gpio.c code. This handling predates the addition of enumeration of ACPI instantiated serdevs to the kernel and was broken by that addition, because the ACPI scan code now no longer instantiates platform_device-s for these nodes. Rename the i2c_multi_instantiate_ids HID list to ignore_serial_bus_ids and add the BCM4752 and LNV4752 HIDs, so that rfkill-gpio gets a platform_device to bind to again; and so that a tty cdev for gpsd gets created for these. Fixes: e361d1f85855 ("ACPI / scan: Fix enumeration for special UART devices") Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 0a9b1fb2a7784aa469c36db2483c7adbe154ac93 Author: Lad Prabhakar <[email protected]> Date: Fri Dec 24 14:29:09 2021 +0000 serial: 8250_bcm7271: Propagate error codes from brcmuart_probe() [ Upstream commit c195438f1e84de8fa46b4f5264d12379bee6e9a1 ] In case of failures brcmuart_probe() always returned -ENODEV, this isn't correct for example platform_get_irq_byname() may return -EPROBE_DEFER to handle such cases propagate error codes in brcmuart_probe() in case of failures. Fixes: 41a469482de25 ("serial: 8250: Add new 8250-core based Broadcom STB driver") Acked-by: Florian Fainelli <[email protected]> Signed-off-by: Lad Prabhakar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit deb0c71e0b26031c962278313d33a4867b9a1e19 Author: Pavel Begunkov <[email protected]> Date: Wed Dec 15 22:08:44 2021 +0000 io_uring: remove double poll on poll update [ Upstream commit e840b4baf3cfb37e2ead4f649a45bb78178677ff ] Before updating a poll request we should remove it from poll queues, including the double poll entry. Fixes: b69de288e913 ("io_uring: allow events and user_data update of running poll requests") Signed-off-by: Pavel Begunkov <[email protected]> Link: https://lore.kernel.org/r/ac39e7f80152613603b8a6cc29a2b6063ac2434f.1639605189.git.asml.silence@gmail.com Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 8d3d1c365a8925d25d586170e3efb54d4b2fa373 Author: Zhang Zixun <[email protected]> Date: Mon Dec 27 22:02:49 2021 +0100 x86/mce/inject: Avoid out-of-bounds write when setting flags [ Upstream commit de768416b203ac84e02a757b782a32efb388476f ] A contrived zero-length write, for example, by using write(2): ... ret = write(fd, str, 0); ... to the "flags" file causes: BUG: KASAN: stack-out-of-bounds in flags_write Write of size 1 at addr ffff888019be7ddf by task writefile/3787 CPU: 4 PID: 3787 Comm: writefile Not tainted 5.16.0-rc7+ #12 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 due to accessing buf one char before its start. Prevent such out-of-bounds access. [ bp: Productize into a proper patch. Link below is the next best thing because the original mail didn't get archived on lore. ] Fixes: 0451d14d0561 ("EDAC, mce_amd_inj: Modify flags attribute to use string arguments") Signed-off-by: Zhang Zixun <[email protected]> Signed-off-by: Borislav Petkov <[email protected]> Link: https://lore.kernel.org/linux-edac/[email protected]/ Signed-off-by: Sasha Levin <[email protected]> commit 4f1096828ececd4f9fd508eaf0aded64af994f4c Author: Arseny Demidov <[email protected]> Date: Sun Dec 19 13:22:39 2021 +0300 hwmon: (mr75203) fix wrong power-up delay value [ Upstream commit a8d6d4992ad9d92356619ac372906bd29687bb46 ] In the file mr75203.c we have a macro named POWER_DELAY_CYCLE_256, the correct value should be 0x100. The register ip_tmr is expressed in units of IP clk cycles, in accordance with the datasheet. Typical power-up delays for Temperature Sensor are 256 cycles i.e. 0x100. Fixes: 9d823351a337 ("hwmon: Add hardware monitoring driver for Moortec MR75203 PVT controller") Signed-off-by: Arseny Demidov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit a96546df99ea0851b6839c35ac129c535f0b2d97 Author: Marijn Suijten <[email protected]> Date: Fri Dec 24 12:34:50 2021 +0100 regulator: qcom-labibb: OCP interrupts are not a failure while disabled [ Upstream commit d27bb69dc83f00f86a830298c967052cded6e784 ] Receiving the Over-Current Protection interrupt while the regulator is disabled does not count as unhandled/failure (IRQ_NONE, or 0 as it were) but a "fake event", usually due to inrush as the is regulator about to be enabled. Fixes: 390af53e0411 ("regulator: qcom-labibb: Implement short-circuit and over-current IRQs") Signed-off-by: Marijn Suijten <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 78cafdf7d219bd10b365fc1a6a9da67daf0a1d62 Author: Dan Carpenter <[email protected]> Date: Fri Dec 17 10:13:32 2021 +0300 crypto: octeontx2 - prevent underflow in get_cores_bmap() [ Upstream commit 10371b6212bb682f13247733d6b76b91b2b80f9a ] If we're going to cap "eng_grp->g->engs_num" upper bounds then we should cap the lower bounds as well. Fixes: 43ac0b824f1c ("crypto: octeontx2 - load microcode and create engine groups") Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 910e5e8ac5de270d9f1bebe095ec262ce387cc0a Author: Nathan Chancellor <[email protected]> Date: Wed Dec 22 09:30:41 2021 -0700 x86/boot/compressed: Move CLANG_FLAGS to beginning of KBUILD_CFLAGS [ Upstream commit 5fe392ff9d1f7254a1fbb3f72d9893088e4d23eb ] When cross compiling i386_defconfig on an arm64 host with clang, there are a few instances of '-Waddress-of-packed-member' and '-Wgnu-variable-sized-type-not-at-end' in arch/x86/boot/compressed/, which should both be disabled with the cc-disable-warning calls in that directory's Makefile, which indicates that cc-disable-warning is failing at the point of testing these flags. The cc-disable-warning calls fail because at the point that the flags are tested, KBUILD_CFLAGS has '-march=i386' without $(CLANG_FLAGS), which has the '--target=' flag to tell clang what architecture it is targeting. Without the '--target=' flag, the host architecture (arm64) is used and i386 is not a valid value for '-march=' in that case. This error can be seen by adding some logging to try-run: clang-14: error: the clang compiler does not support '-march=i386' Invoking the compiler has to succeed prior to calling cc-option or cc-disable-warning in order to accurately test whether or not the flag is supported; if it doesn't, the requested flag can never be added to the compiler flags. Move $(CLANG_FLAGS) to the beginning of KBUILD_FLAGS so that any new flags that might be added in the future can be accurately tested. Fixes: d5cbd80e302d ("x86/boot: Add $(CLANG_FLAGS) to compressed KBUILD_CFLAGS") Signed-off-by: Nathan Chancellor <[email protected]> Signed-off-by: Borislav Petkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 5639dcfc688943abe1c7d13d685e670e9a0056b4 Author: Panicker Harish <[email protected]> Date: Wed Dec 22 12:59:05 2021 +0530 Bluetooth: hci_qca: Stop IBS timer during BT OFF [ Upstream commit df1e5c51492fd93ffc293acdcc6f00698d19fedc ] The IBS timers are not stopped properly once BT OFF is triggered. we could see IBS commands being sent along with version command, so stopped IBS timers while Bluetooth is off. Fixes: 3e4be65eb82c ("Bluetooth: hci_qca: Add poweroff support during hci down for wcn3990") Signed-off-by: Panicker Harish <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 03dae5e3362e20fc726c730e270d1ab75ffd7083 Author: Clément Léger <[email protected]> Date: Mon Dec 20 22:05:33 2021 +0100 software node: fix wrong node passed to find nargs_prop [ Upstream commit c5fc5ba8b6b7bebc05e45036a33405b4c5036c2f ] nargs_prop refers to a property located in the reference that is found within the nargs property. Use the correct reference node in call to property_entry_read_int_array() to retrieve the correct nargs value. Fixes: b06184acf751 ("software node: Add software_node_get_reference_args()") Signed-off-by: Clément Léger <[email protected]> Reviewed-by: Sakari Ailus <[email protected]> Reviewed-by: Daniel Scally <[email protected]> Acked-by: Heikki Krogerus <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 7a4e6e087813c0245ce49ba9178034c1431a1fc3 Author: Marijn Suijten <[email protected]> Date: Mon Nov 15 21:34:59 2021 +0100 backlight: qcom-wled: Respect enabled-strings in set_brightness [ Upstream commit ec961cf3241153e0f27d850f1bf0f172e7d27a21 ] The hardware is capable of controlling any non-contiguous sequence of LEDs specified in the DT using qcom,enabled-strings as u32 array, and this also follows from the DT-bindings documentation. The numbers specified in this array represent indices of the LED strings that are to be enabled and disabled. Its value is appropriately used to setup and enable string modules, but completely disregarded in the set_brightness paths which only iterate over the number of strings linearly. Take an example where only string 2 is enabled with qcom,enabled_strings=<2>: this string is appropriately enabled but subsequent brightness changes would have only touched the zero'th brightness register because num_strings is 1 here. This is simply addressed by looking up the string for this index in the enabled_strings array just like the other codepaths that iterate over num_strings. Likewise enabled_strings is now also used in the autodetection path for consistent behaviour: when a list of strings is specified in DT only those strings will be probed for autodetection, analogous to how the number of strings that need to be probed is already bound by qcom,num-strings. After all autodetection uses the set_brightness helpers to set an initial value, which could otherwise end up changing brightness on a different set of strings. Fixes: 775d2ffb4af6 ("backlight: qcom-wled: Restructure the driver for WLED3") Fixes: 03b2b5e86986 ("backlight: qcom-wled: Add support for WLED4 peripheral") Signed-off-by: Marijn Suijten <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Reviewed-by: Daniel Thompson <[email protected]> Signed-off-by: Lee Jones <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 7abe05ef6648409b4866a7cfd0e481b553fa9b8b Author: Marijn Suijten <[email protected]> Date: Mon Nov 15 21:34:53 2021 +0100 backlight: qcom-wled: Use cpu_to_le16 macro to perform conversion [ Upstream commit 0a139358548968b2ff308257b4fbeec7badcc3e1 ] The kernel already provides appropriate primitives to perform endianness conversion which should be used in favour of manual bit-wrangling. Signed-off-by: Marijn Suijten <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Reviewed-by: Daniel Thompson <[email protected]> Signed-off-by: Lee Jones <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 18a8dd081b8161d3421a4ebaea3b3bd9f8631b05 Author: Marijn Suijten <[email protected]> Date: Mon Nov 15 21:34:55 2021 +0100 backlight: qcom-wled: Override default length with qcom,enabled-strings [ Upstream commit 2b4b49602f9feca7b7a84eaa33ad9e666c8aa695 ] The length of qcom,enabled-strings as property array is enough to determine the number of strings to be enabled, without needing to set qcom,num-strings to override the default number of strings when less than the default (which is also the maximum) is provided in DT. This also introduces an extra warning when qcom,num-strings is set, denoting that it is not necessary to set both anymore. It is usually more concise to set just qcom,num-length when a zero-based, contiguous range of strings is needed (the majority of the cases), or to only set qcom,enabled-strings when a specific set of indices is desired. Fixes: 775d2ffb4af6 ("backlight: qcom-wled: Restructure the driver for WLED3") Signed-off-by: Marijn Suijten <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Reviewed-by: Daniel Thompson <[email protected]> Signed-off-by: Lee Jones <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 37b61692f27b61d2c3d3ca3e7f444f5e8c6631bf Author: Marijn Suijten <[email protected]> Date: Mon Nov 15 21:34:54 2021 +0100 backlight: qcom-wled: Fix off-by-one maximum with default num_strings [ Upstream commit 5ada78b26f935f8751852dffa24f6b545b1d2517 ] When not specifying num-strings in the DT the default is used, but +1 is added to it which turns WLED3 into 4 and WLED4/5 into 5 strings instead of 3 and 4 respectively, causing out-of-bounds reads and register read/writes. This +1 exists for a deficiency in the DT parsing code, and is simply omitted entirely - solving this oob issue - by parsing the property separately much like qcom,enabled-strings. This also enables more stringent checks on the maximum value when qcom,enabled-strings is provided in the DT, by parsing num-strings after enabled-strings to allow it to check against (and in a subsequent patch override) the length of enabled-strings: it is invalid to set num-strings higher than that. The DT currently utilizes it to get around an incorrect fixed read of four elements from that array (has been addressed in a prior patch) by setting a lower num-strings where desired. Fixes: 93c64f1ea1e8 ("leds: add Qualcomm PM8941 WLED driver") Signed-off-by: Marijn Suijten <[email protected]> Reviewed-By: AngeloGioacchino Del Regno <[email protected]> Reviewed-by: Daniel Thompson <[email protected]> Signed-off-by: Lee Jones <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 219c7d18be5a818a830521aef397b8ad1846daaf Author: Marijn Suijten <[email protected]> Date: Mon Nov 15 21:34:52 2021 +0100 backlight: qcom-wled: Pass number of elements to read to read_u32_array [ Upstream commit e29e24bdabfeddbf8b1a4ecac1af439a85150438 ] of_property_read_u32_array takes the number of elements to read as last argument. This does not always need to be 4 (sizeof(u32)) but should instead be the size of the array in DT as read just above with of_property_count_elems_of_size. To not make such an error go unnoticed again the driver now bails accordingly when of_property_read_u32_array returns an error. Surprisingly the indentation of newlined arguments is lining up again after prepending `rc = `. Fixes: 775d2ffb4af6 ("backlight: qcom-wled: Restructure the driver for WLED3") Signed-off-by: Marijn Suijten <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Reviewed-by: Daniel Thompson <[email protected]> Signed-off-by: Lee Jones <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit f2bc76de284705432ea4b323cde3dada4892ed56 Author: Marijn Suijten <[email protected]> Date: Mon Nov 15 21:34:51 2021 +0100 backlight: qcom-wled: Validate enabled string indices in DT [ Upstream commit c05b21ebc5bce3ecc78c2c71afd76d92c790a2ac ] The strings passed in DT may possibly cause out-of-bounds register accesses and should be validated before use. Fixes: 775d2ffb4af6 ("backlight: qcom-wled: Restructure the driver for WLED3") Signed-off-by: Marijn Suijten <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Reviewed-by: Daniel Thompson <[email protected]> Signed-off-by: Lee Jones <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 77c5e99644af10d94c6ce32d580d72b81267c933 Author: Paul Chaignon <[email protected]> Date: Mon Dec 20 22:45:28 2021 +0100 bpftool: Enable line buffering for stdout [ Upstream commit 1a1a0b0364ad291bd8e509da104ac8b5b1afec5d ] The output of bpftool prog tracelog is currently buffered, which is inconvenient when piping the output into other commands. A simple tracelog | grep will typically not display anything. This patch fixes it by enabling line buffering on stdout for the whole bpftool binary. Fixes: 30da46b5dc3a ("tools: bpftool: add a command to dump the trace pipe") Signed-off-by: Quentin Monnet <[email protected]> Signed-off-by: Paul Chaignon <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]> Acked-by: Yonghong Song <[email protected]> Link: https://lore.kernel.org/bpf/20211220214528.GA11706@Mem Signed-off-by: Sasha Levin <[email protected]> commit 79d6a406df007a7dcd2fba828e7b28c9d880c34a Author: Luiz Augusto von Dentz <[email protected]> Date: Wed Dec 8 15:35:48 2021 -0800 Bluetooth: L2CAP: Fix using wrong mode [ Upstream commit 30d57722732d9736554f85f75f9d7ad5402d192e ] If user has a set to use SOCK_STREAM the socket would default to L2CAP_MODE_ERTM which later needs to be adjusted if the destination address is LE which doesn't support such mode. Fixes: 15f02b9105625 ("Bluetooth: L2CAP: Add initial code for Enhanced Credit Based Mode") Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit a3641f64a9d9ac2fb5e17b9ebd265e9bb8c0548d Author: Johannes Berg <[email protected]> Date: Thu Sep 16 13:09:22 2021 +0200 um: virtio_uml: Fix time-travel external time propagation [ Upstream commit 85e73968a040c642fd38f6cba5b73b61f5d0f052 ] When creating an external event, the current time needs to be propagated to other participants of a simulation. This is done in the places here where we kick a virtq etc. However, it must be done for _all_ external events, and that includes making the initial socket connection and later closing it. Call time_travel_propagate_time() to do this before making or closing the socket connection. Apparently, at least for the initial connection creation, due to the remote side in my use cases using microseconds (rather than nanoseconds), this wasn't a problem yet; only started failing between 5.14-rc1 and 5.15-rc1 (didn't test others much), or possibly depending on the configuration, where more delays happen before the virtio devices are initialized. Fixes: 88ce64249233 ("um: Implement time-travel=ext") Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Richard Weinberger <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 4e71908ba7cb581342205a9d3b4a8b56109e3ae8 Author: Johannes Berg <[email protected]> Date: Wed Sep 15 20:30:22 2021 +0200 lib/logic_iomem: Fix operation on 32-bit [ Upstream commit 4e8a5edac5010820e7c5303fc96f5a262e096bb6 ] On 32-bit, the first entry might be at 0/NULL, but that's strange and leads to issues, e.g. where we check "if (ret)". Use a IOREMAP_BIAS/IOREMAP_MASK of 0x80000000UL to avoid this. This then requires reducing the number of areas (via MAX_AREAS), but we still have 128 areas, which is enough. Fixes: ca2e334232b6 ("lib: add iomem emulation (logic_iomem)") Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Richard Weinberger <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 6c72a5bc4df4565164569d4833efc6f19c44dcbc Author: Johannes Berg <[email protected]> Date: Wed Sep 15 20:30:21 2021 +0200 lib/logic_iomem: Fix 32-bit build [ Upstream commit 4e84139e14af5ea60772cc4f33d7059aec76e0eb ] On a 32-bit build, the (unsigned long long) casts throw warnings (or errors) due to being to a different integer size. Cast to uintptr_t first (with the __force for sparse) and then further to get the consistent print on 32 and 64-bit. Fixes: ca2e334232b6 ("lib: add iomem emulation (logic_iomem)") Reported-by: Al Viro <[email protected]> Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Richard Weinberger <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit b53c2307b18c4fdcbb46b340c5a13aae49b2b369 Author: Johannes Berg <[email protected]> Date: Wed Sep 15 20:30:20 2021 +0200 um: virt-pci: Fix 32-bit compile [ Upstream commit d73820df6437b5d0a57be53faf39db46a0264b3a ] There were a few 32-bit compile warnings that of course turned into errors with -Werror, fix the 32-bit build. Fixes: 68f5d3f3b654 ("um: add PCI over virtio emulation driver") Reported-by: Al Viro <[email protected]> Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Richard Weinberger <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit c3d5f267696d01ed529416706d1cbffb6e49784b Author: Johannes Berg <[email protected]> Date: Tue Aug 31 09:11:15 2021 +0200 um: rename set_signals() to um_set_signals() [ Upstream commit bbe33504d4a7fdab9011211e55e262c869b3f6cc ] Rename set_signals() as there's at least one driver that uses the same name and can now be built on UM due to PCI support, and thus we can get symbol conflicts. Also rename set_signals_trace() to be consistent. Reported-by: kernel test robot <[email protected]> Fixes: 68f5d3f3b654 ("um: add PCI over virtio emulation driver") Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Richard Weinberger <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 2a2f4f3aeafd684d1f8d790ef1ccb663ec8eb844 Author: Johannes Berg <[email protected]> Date: Tue Aug 31 09:27:53 2021 +0200 um: fix ndelay/udelay defines [ Upstream commit 5f8539e2ff962e25b57742ca7106456403abbc94 ] Many places in the kernel use 'udelay' as an identifier, and are broken with the current "#define udelay um_udelay". Fix this by adding an argument to the macro, and do the same to 'ndelay' as well, just in case. Fixes: 0bc8fb4dda2b ("um: Implement ndelay/udelay in time-travel mode") Reported-by: kernel test robot <[email protected]> Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Richard Weinberger <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 3a45c47034918d5496e37eb3e2ffae9a1f30b7af Author: Bernard Zhao <[email protected]> Date: Fri Dec 10 04:03:58 2021 -0800 selinux: fix potential memleak in selinux_add_opt() [ Upstream commit 2e08df3c7c4e4e74e3dd5104c100f0bf6288aaa8 ] This patch try to fix potential memleak in error branch. Fixes: ba6418623385 ("selinux: new helper - selinux_add_opt()") Signed-off-by: Bernard Zhao <[email protected]> [PM: tweak the subject line, add Fixes tag] Signed-off-by: Paul Moore <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 7be5c25e31556f44bf7c4a2079184dcc93768c5d Author: Christoph Hellwig <[email protected]> Date: Tue Dec 21 17:18:51 2021 +0100 block: fix error unwinding in device_add_disk [ Upstream commit 99d8690aae4b2f0d1d90075de355ac087f820a66 ] One device_add is called disk->ev will be freed by disk_release, so we should free it twice. Fix this by allocating disk->ev after device_add so that the extra local unwinding can be removed entirely. Based on an earlier patch from Tetsuo Handa. Reported-by: syzbot <[email protected]> Tested-by: syzbot <[email protected]> Fixes: 83cbce9574462c6b ("block: add error handling for device_add_disk / add_disk") Signed-off-by: Christoph Hellwig <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 6c1d0447bf0d24e92def34cb429e967bd6fed131 Author: Sergey Shtylyov <[email protected]> Date: Fri Dec 17 23:27:17 2021 +0300 mmc: meson-mx-sdio: add IRQ check [ Upstream commit 8fc9a77bc64e1f23d07953439817d8402ac9706f ] The driver neglects to check the result of platform_get_irq()'s call and blithely passes the negative error codes to devm_request_threaded_irq() (which takes *unsigned* IRQ #), causing it to fail with -EINVAL, overriding an original error code. Stop calling devm_request_threaded_irq() with the invalid IRQ #s. Fixes: ed80a13bb4c4 ("mmc: meson-mx-sdio: Add a driver for the Amlogic Meson8 and Meson8b SoC") Signed-off-by: Sergey Shtylyov <[email protected]> Reviewed-by: Martin Blumenstingl <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 0d840e7e2e6c61b9d103b53ba0da9d1fb94dcbdb Author: Sergey Shtylyov <[email protected]> Date: Fri Dec 17 23:27:16 2021 +0300 mmc: meson-mx-sdhc: add IRQ check [ Upstream commit 77bed755e0f06135faccdd3948863703f9a6e640 ] The driver neglects to check the result of platform_get_irq()'s call and blithely passes the negative error codes to devm_request_threaded_irq() (which takes *unsigned* IRQ #), causing it to fail with -EINVAL, overriding an original error code. Stop calling devm_request_threaded_irq() with the invalid IRQ #s. Fixes: e4bf1b0970ef ("mmc: host: meson-mx-sdhc: new driver for the Amlogic Meson SDHC host") Signed-off-by: Sergey Shtylyov <[email protected]> Reviewed-by: Martin Blumenstingl <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 525c2a0763eee7a211dfbd909c784f15670347de Author: Avraham Stern <[email protected]> Date: Sun Dec 19 13:28:26 2021 +0200 iwlwifi: mvm: set protected flag only for NDP ranging [ Upstream commit 6bb2ea37c02db98cb677f978cfcb833ca608c5eb ] Don't use protected ranging negotiation for FTM ranging as responders that support only FTM ranging don't expect the FTM request to be protected. Signed-off-by: Avraham Stern <[email protected]> Fixes: 517a5eb9fab2 ("iwlwifi: mvm: when associated with PMF, use protected NDP ranging negotiation") Signed-off-by: Luca Coelho <[email protected]> Link: https://lore.kernel.org/r/iwlwifi.20211219132536.f50ed0e3c6b3.Ibff247ee9d4e6e0a1a2d08a3c8a4bbb37e6829dd@changeid Signed-off-by: Luca Coelho <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 39cb224bf6511628997c231b08dd47c67e369e36 Author: Avraham Stern <[email protected]> Date: Sun Dec 19 12:18:20 2021 +0200 iwlwifi: mvm: perform 6GHz passive scan after suspend [ Upstream commit f4745cbb17572209a7fa27a6796ed70e7ada860b ] The 6GHz passive scan is performed only once every 50 minutes. However, in case of suspend/resume, the regulatory information is reset, so 6GHz channels may become disabled. Fix it by performing a 6GHz passive scan within 60 seconds after suspend/resume even if the 50 minutes timeout did not expire yet. Signed-off-by: Avraham Stern <[email protected]> Fixes: e8fe3b41c3a3 ("iwlwifi: mvm: Add support for 6GHz passive scan") Signed-off-by: Luca Coelho <[email protected]> Link: https://lore.kernel.org/r/iwlwifi.20211219121514.6d5c043372cf.I251dd5618a3f0b8febbcca788eb861f1cd6039bc@changeid Signed-off-by: Luca Coelho <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit e895cfb085c64642a083cda439be46503ab9425a Author: Nathan Errera <[email protected]> Date: Sun Dec 19 12:18:15 2021 +0200 iwlwifi: mvm: test roc running status bits before removing the sta [ Upstream commit 998e1aba6e5eb35370eaf30ccc1823426ec11f90 ] In some cases the sta is being removed twice since we do not test the roc aux running before removing it. Start looking at the bit before removing the sta. Signed-off-by: Nathan Errera <[email protected]> Fixes: 2c2c3647cde4 ("iwlwifi: mvm: support ADD_STA_CMD_API_S ver 12") Signed-off-by: Luca Coelho <[email protected]> Link: https://lore.kernel.org/r/iwlwifi.20211219121514.d5376ac6bcb0.Ic5f8470ea60c072bde9d1503e5f528b65e301e20@changeid Signed-off-by: Luca Coelho <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 48338cf56eaa8cb5bd457d62ea239bccf6bdfc3c Author: Johannes Berg <[email protected]> Date: Sun Dec 19 11:14:18 2021 +0200 iwlwifi: mvm: fix 32-bit build in FTM [ Upstream commit 8b0f92549f2c2458200935c12a2e2a6e80234cf5 ] On a 32-bit build, the division here needs to be done using do_div(), otherwise the compiler will try to call a function that doesn't exist, thus failing to build. Fixes: b68bd2e3143a ("iwlwifi: mvm: Add FTM initiator RTT smoothing logic") Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Luca Coelho <[email protected]> Link: https://lore.kernel.org/r/iwlwifi.20211219111352.e56cbf614a4d.Ib98004ccd2c7a55fd883a8ea7eebd810f406dec6@changeid Signed-off-by: Luca Coelho <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 617339466fda09916c4b4151fa5e6a9c1fdae353 Author: Kai-Heng Feng <[email protected]> Date: Wed Dec 15 19:46:34 2021 +0800 rtw88: Disable PCIe ASPM while doing NAPI poll on 8821CE [ Upstream commit 24f5e38a13b5ae2b6105cda8bb47c19108e62a9a ] Many Intel based platforms face system random freeze after commit 9e2fd29864c5 ("rtw88: add napi support"). The commit itself shouldn't be the culprit. My guess is that the 8821CE only leaves ASPM L1 for a short period when IRQ is raised. Since IRQ is masked during NAPI polling, the PCIe link stays at L1 and makes RX DMA extremely slow. Eventually the RX ring becomes messed up: [ 1133.194697] rtw_8821ce 0000:02:00.0: pci bus timeout, check dma status Since the 8821CE hardware may fail to leave ASPM L1, manually do it in the driver to resolve the issue. Fixes: 9e2fd29864c5 ("rtw88: add napi support") Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215131 BugLink: https://bugs.launchpad.net/bugs/1927808 Signed-off-by: Kai-Heng Feng <[email protected]> Acked-by: Jian-Hong Pan <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 9b6b5f07702fa0970cdd767e85afc671b0d82c7d Author: Ping-Ke Shih <[email protected]> Date: Fri Nov 19 13:24:37 2021 +0800 rtw88: add quirk to disable pci caps on HP 250 G7 Notebook PC [ Upstream commit c81edb8dddaa36c4defa26240cc19127f147283f ] 8821CE causes random freezes on HP 250 G7 Notebook PC. Add a quirk to disable pci ASPM capability. Reported-by: rtl8821cerfe2 <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit b14e931c386f7cecc15aed970aee4bc4b326bae4 Author: Dan Carpenter <[email protected]> Date: Fri Dec 17 18:03:12 2021 +0300 wilc1000: fix double free error in probe() [ Upstream commit 4894edacfa93d7046bec4fc61fc402ac6a2ac9e8 ] Smatch complains that there is a double free in probe: drivers/net/wireless/microchip/wilc1000/spi.c:186 wilc_bus_probe() error: double free of 'spi_priv' drivers/net/wireless/microchip/wilc1000/sdio.c:163 wilc_sdio_probe() error: double free of 'sdio_priv' The problem is that wilc_netdev_cleanup() function frees "wilc->bus_data". That's confusing and a layering violation. Leave the frees in probe(), delete the free in wilc_netdev_cleanup(), and add some new frees to the remove() functions. Fixes: dc8b338f3bcd ("wilc1000: use goto labels on error path") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Claudiu Beznea <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/20211217150311.GC16611@kili Signed-off-by: Sasha Levin <[email protected]> commit 1a25b9c4ce2ab9602cbf9093f9860154d340974b Author: Sean Wang <[email protected]> Date: Fri Oct 29 06:29:58 2021 +0800 mt76: mt7921: drop offload_flags overwritten [ Upstream commit 2363b6a646b65a207345b9a9024dff0eff3fec44 ] offload_flags have to be dropped for mt7921 because mt76.omac_idx 0 would always run as station mode that would cause Tx encapsulation setting is not applied to mac80211. Also, drop IEEE80211_OFFLOAD_ENCAP_4ADDR too because it is not really being supported. Fixes: e0f9fdda81bd ("mt76: mt7921: add ieee80211_ops") Signed-off-by: Sean Wang <[email protected]> Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit e64a3ea17c19e5bec64e7d24b286422535f10556 Author: Marek Behún <[email protected]> Date: Tue Nov 9 17:46:04 2021 +0100 ARM: dts: armada-38x: Add generic compatible to UART nodes [ Upstream commit 62480772263ab6b52e758f2346c70a526abd1d28 ] Add generic compatible string "ns16550a" to serial port nodes of Armada 38x. This makes it possible to use earlycon. Fixes: 0d3d96ab0059 ("ARM: mvebu: add Device Tree description of the Armada 380/385 SoCs") Signed-off-by: Pali Rohár <[email protected]> Signed-off-by: Marek Behún <[email protected]> Signed-off-by: Gregory CLEMENT <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 4518f459c2c0fc30ba1c4a6c973b345a8524d062 Author: Robert Marko <[email protected]> Date: Fri Nov 12 14:44:03 2021 +0100 arm64: dts: marvell: cn9130: enable CP0 GPIO controllers [ Upstream commit 0734f8311ce72c9041e5142769eff2083889c172 ] CN9130 has a built-in CP115 which has 2 GPIO controllers, but unlike in Armada 7k and 8k both are left disabled by the SoC DTSI. This first of all makes no sense as they are always present due to being SoC built-in and its an issue as boards like CN9130-CRB use the CPO GPIO2 pins for regulators and SD card support without enabling them first. So, enable both of them like Armada 7k and 8k do. Fixes: 6b8970bd8d7a ("arm64: dts: marvell: Add support for Marvell CN9130 SoC support") Signed-off-by: Robert Marko <[email protected]> Signed-off-by: Gregory CLEMENT <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 864ac5f6bfbe7d2870d5b02e2f2c5ad2e1bd9296 Author: Robert Marko <[email protected]> Date: Fri Nov 12 14:44:02 2021 +0100 arm64: dts: marvell: cn9130: add GPIO and SPI aliases [ Upstream commit effd42600b987c1e95f946b14fefc1c7639e7439 ] CN9130 has one CP115 built in, which like the CP110 has 2 GPIO and 2 SPI controllers built-in. However, unlike the Armada 7k and 8k the SoC DTSI doesn't add the required aliases as both the Orion SPI driver and MVEBU GPIO drivers require the aliases to be present. So add the required aliases for GPIO and SPI controllers. Fixes: 6b8970bd8d7a ("arm64: dts: marvell: Add support for Marvell CN9130 SoC support") Signed-off-by: Robert Marko <[email protected]> Signed-off-by: Gregory CLEMENT <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 6d88a6849617c607960e79012fce36afd98c9d1a Author: Wei Yongjun <[email protected]> Date: Fri Dec 17 16:34:28 2021 +0800 usb: ftdi-elan: fix memory leak on device disconnect [ Upstream commit 1646566b5e0c556f779180a8514e521ac735de1e ] 'ftdi' is alloced when probe device, but not free on device disconnect, this cause a memory leak as follows: unreferenced object 0xffff88800d584000 (size 8400): comm "kworker/0:2", pid 3809, jiffies 4295453055 (age 13.784s) hex dump (first 32 bytes): 00 40 58 0d 80 88 ff ff 00 40 58 0d 80 88 ff ff .@X......@X..... 00 00 00 00 00 00 00 00 00 00 00 00 ad 4e ad de .............N.. backtrace: [<000000000d47f947>] kmalloc_order_trace+0x19/0x110 mm/slab_common.c:960 [<000000008548ac68>] ftdi_elan_probe+0x8c/0x880 drivers/usb/misc/ftdi-elan.c:2647 [<000000007f73e422>] usb_probe_interface+0x31b/0x800 drivers/usb/core/driver.c:396 [<00000000fe8d07fc>] really_probe+0x299/0xc30 drivers/base/dd.c:517 [<0000000005da7d32>] __driver_probe_device+0x357/0x500 drivers/base/dd.c:751 [<000000003c2c9579>] driver_probe_device+0x4e/0x140 drivers/base/dd.c:781 Fix it by freeing 'ftdi' after nobody use it. Fixes: a5c66e4b2418 ("USB: ftdi-elan: client driver for ELAN Uxxx adapters") Reported-by: Hulk Robot <[email protected]> Signed-off-by: Wei Yongjun <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 826501a17e98816647e294e14139eb05fbcc9ce9 Author: Andre Przywara <[email protected]> Date: Mon Nov 22 16:28:43 2021 +0100 ARM: 9159/1: decompressor: Avoid UNPREDICTABLE NOP encoding [ Upstream commit a92882a4d270fbcc021ee6848de5e48b7f0d27f3 ] In the decompressor's head.S we need to start with an instruction that is some kind of NOP, but also mimics as the PE/COFF header, when the kernel is linked as an UEFI application. The clever solution here is "tstne r0, #0x4d000", which in the worst case just clobbers the condition flags, and bears the magic "MZ" signature in the lowest 16 bits. However the encoding used (0x13105a4d) is actually not valid, since bits [15:12] are supposed to be 0 (written as "(0)" in the ARM ARM). Violating this is UNPREDICTABLE, and *can* trigger an UNDEFINED exception. Common Cortex cores seem to ignore those bits, but QEMU chooses to trap, so the code goes fishing because of a missing exception handler at this point. We are just saved by the fact that commonly (with -kernel or when running from U-Boot) the "Z" bit is set, so the instruction is never executed. See [0] for more details. To make things more robust and avoid UNPREDICTABLE behaviour in the kernel code, lets replace this with a "two-instruction NOP": The first instruction is an exclusive OR, the effect of which the second instruction reverts. This does not leave any trace, neither in a register nor in the condition flags. Also it's a perfectly valid encoding. Kudos to Peter Maydell for coming up with this gem. [0] https://lore.kernel.org/qemu-devel/YTPIdbUCmwagL5%[email protected]/T/ Link: https://lore.kernel.org/linux-arm-kernel/[email protected]/T/ Fixes: 81a0bc39ea19 ("ARM: add UEFI stub support") Signed-off-by: Andre Przywara <[email protected]> Reported-by: Adam Lackorzynski <[email protected]> Suggested-by: Peter Maydell <[email protected]> Reviewed-by: Ard Biesheuvel <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Signed-off-by: Russell King (Oracle) <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 851b00b478325667e79fe0dd33e797c953b1b296 Author: Antony Antony <[email protected]> Date: Sun Dec 12 11:35:00 2021 +0100 xfrm: state and policy should fail if XFRMA_IF_ID 0 [ Upstream commit 68ac0f3810e76a853b5f7b90601a05c3048b8b54 ] xfrm ineterface does not allow xfrm if_id = 0 fail to create or update xfrm state and policy. With this commit: ip xfrm policy add src 192.0.2.1 dst 192.0.2.2 dir out if_id 0 RTNETLINK answers: Invalid argument ip xfrm state add src 192.0.2.1 dst 192.0.2.2 proto esp spi 1 \ reqid 1 mode tunnel aead 'rfc4106(gcm(aes))' \ 0x1111111111111111111111111111111111111111 96 if_id 0 RTNETLINK answers: Invalid argument v1->v2 change: - add Fixes: tag Fixes: 9f8550e4bd9d ("xfrm: fix disable_xfrm sysctl when used on xfrm interfaces") Signed-off-by: Antony Antony <[email protected]> Signed-off-by: Steffen Klassert <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit eab7928527b524df787246c104a7a1a2326b0868 Author: Antony Antony <[email protected]> Date: Sun Dec 12 11:34:30 2021 +0100 xfrm: interface with if_id 0 should return error [ Upstream commit 8dce43919566f06e865f7e8949f5c10d8c2493f5 ] xfrm interface if_id = 0 would cause xfrm policy lookup errors since Commit 9f8550e4bd9d. Now explicitly fail to create an xfrm interface when if_id = 0 With this commit: ip link add ipsec0 type xfrm dev lo if_id 0 Error: if_id must be non zero. v1->v2 change: - add Fixes: tag Fixes: 9f8550e4bd9d ("xfrm: fix disable_xfrm sysctl when used on xfrm interfaces") Signed-off-by: Antony Antony <[email protected]> Reviewed-by: Eyal Birger <[email protected]> Signed-off-by: Steffen Klassert <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit afd9ebd40bda62abaf58451273552b187b2c948b Author: Jernej Skrabec <[email protected]> Date: Mon Nov 29 19:26:25 2021 +0100 media: hantro: Fix probe func error path [ Upstream commit 37af43b250fda6162005d47bf7c959c70d52b107 ] If clocks for some reason couldn't be enabled, probe function returns immediately, without disabling PM. This obviously leaves PM ref counters unbalanced. Fix that by jumping to appropriate error path, so effects of PM functions are reversed. Fixes: 775fec69008d ("media: add Rockchip VPU JPEG encoder driver") Signed-off-by: Jernej Skrabec <[email protected]> Acked-by: Andrzej Pietrasiewicz <[email protected]> Reviewed-by: Ezequiel Garcia <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 3ca9f14fe2799ec4b45b167c4d2de5dee7439a06 Author: Robin Murphy <[email protected]> Date: Fri Dec 10 17:54:44 2021 +0000 drm/tegra: vic: Fix DMA API misuse [ Upstream commit 5566174cb10a5167d59b0793871cab7990b149b8 ] Upon failure, dma_alloc_coherent() returns NULL. If that does happen, passing some uninitialised stack contents to dma_mapping_error() - which belongs to a different API in the first place - has precious little chance of detecting it. Also include the correct header, because the fragile transitive inclusion currently providing it is going to break soon. Fixes: 20e7dce255e9 ("drm/tegra: Remove memory allocation from Falcon library") CC: Thierry Reding <[email protected]> CC: Mikko Perttunen <[email protected]> CC: [email protected] Signed-off-by: Robin Murphy <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 0dbb2617c7137787595e809aa7f832d9bb641202 Author: Thierry Reding <[email protected]> Date: Thu Jul 8 16:37:36 2021 +0200 drm/tegra: gr2d: Explicitly control module reset [ Upstream commit 271fca025a6d43f1c18a48543c5aaf31a31e4694 ] As of commit 4782c0a5dd88 ("clk: tegra: Don't deassert reset on enabling clocks"), module resets are no longer automatically deasserted when the module clock is enabled. To make sure that the gr2d module continues to work, we need to explicitly control the module reset. Fixes: 4782c0a5dd88 ("clk: tegra: Don't deassert reset on enabling clocks") Signed-off-by: Thierry Reding <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 3b90135b03f3c160b36dcbfd19929dfb971ba56e Author: Arnd Bergmann <[email protected]> Date: Mon Sep 27 11:36:59 2021 +0200 gpu: host1x: select CONFIG_DMA_SHARED_BUFFER [ Upstream commit 6c7a388b62366f0de9936db3c1921d7f4e0011bc ] Linking fails when dma-buf is disabled: ld.lld: error: undefined symbol: dma_fence_release >>> referenced by fence.c >>> gpu/host1x/fence.o:(host1x_syncpt_fence_enable_signaling) in archive drivers/built-in.a >>> referenced by fence.c >>> gpu/host1x/fence.o:(host1x_fence_signal) in archive drivers/built-in.a >>> referenced by fence.c >>> gpu/host1x/fence.o:(do_fence_timeout) in archive drivers/built-in.a Fixes: 687db2207b1b ("gpu: host1x: Add DMA fence implementation") Signed-off-by: Arnd Bergmann <[email protected]> Reviewed-by: Mikko Perttunen <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit c0dc02dcfe6ba9d3ee290c761ede8c099876d9c4 Author: Stephen Boyd <[email protected]> Date: Tue Dec 14 16:25:29 2021 -0800 drm/bridge: ti-sn65dsi86: Set max register for regmap [ Upstream commit 0b665d4af35837f0a0ae63135b84a3c187c1db3b ] Set the maximum register to 0xff so we can dump the registers for this device in debugfs. Fixes: a095f15c00e2 ("drm/bridge: add support for sn65dsi86 bridge driver") Cc: Rob Clark <[email protected]> Cc: Douglas Anderson <[email protected]> Cc: Laurent Pinchart <[email protected]> Signed-off-by: Stephen Boyd <[email protected]> Reviewed-by: Robert Foss <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 602662de5f82a98ec840ee972c9b10317fc573b8 Author: Dmitry Baryshkov <[email protected]> Date: Thu Dec 2 01:26:27 2021 +0300 drm/msm/dpu: fix safe status debugfs file [ Upstream commit f31b0e24d31e18b4503eeaf0032baeacc0beaff6 ] Make safe_status debugfs fs file actually return safe status rather than danger status data. Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support") Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Rob Clark <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit be12d15a817b68ac345a96c368e29ed9292b1b86 Author: Baruch Siach <[email protected]> Date: Tue Dec 7 09:27:10 2021 +0200 arm64: dts: qcom: ipq6018: Fix gpio-ranges property [ Upstream commit 72cb4c48a46a7cfa58eb5842c0d3672ddd5bd9ad ] There must be three parameters in gpio-ranges property. Fixes this not very helpful error message: OF: /soc/pinctrl@1000000: (null) = 3 found 3 Fixes: 1e8277854b49 ("arm64: dts: Add ipq6018 SoC and CP01 board support") Cc: Sricharan R <[email protected]> Signed-off-by: Baruch Siach <[email protected]> Tested-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/8a744cfd96aff5754bfdcf7298d208ddca5b319a.1638862030.git.baruch@tkos.co.il Signed-off-by: Sasha Levin <[email protected]> commit 0c7ec53598a3496060cade7b1b002a7be4b0e182 Author: Srinivas Kandagatla <[email protected]> Date: Thu Dec 9 17:53:41 2021 +0000 arm64: dts: qcom: c630: Fix soundcard setup [ Upstream commit c02b360ca67ebeb9de07b47b2fe53f964c2561d1 ] Currently Soundcard has 1 rx device for headset and SoundWire Speaker Playback. This setup has issues, ex if we try to play on headset the audio stream is also sent to SoundWire Speakers and we will hear sound in both headsets and speakers. Make a separate device for Speakers and Headset so that the streams are different and handled properly. Fixes: 45021d35fcb2 ("arm64: dts: qcom: c630: Enable audio support") Signed-off-by: Srinivas Kandagatla <[email protected]> Tested-by: Steev Klimaszewski <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit c9fadfaf7b448b9873b13c19aaffe0709927e5f1 Author: Kurt Kanzenbach <[email protected]> Date: Tue Dec 14 14:45:08 2021 +0100 net: dsa: hellcreek: Add missing PTP via UDP rules [ Upstream commit 6cf01e451599da630ff1af529d61c5e4db4550ab ] The switch supports PTP for UDP transport too. Therefore, add the missing static FDB entries to ensure correct forwarding of these packets. Fixes: ddd56dfe52c9 ("net: dsa: hellcreek: Add PTP clock support") Signed-off-by: Kurt Kanzenbach <[email protected]> Acked-by: Richard Cochran <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit ae914fe9310e772e07b1396cae97c2e31cd603f9 Author: Kurt Kanzenbach <[email protected]> Date: Tue Dec 14 14:45:07 2021 +0100 net: dsa: hellcreek: Allow PTP P2P measurements on blocked ports [ Upstream commit cad1798d2d0811ded37d1e946c6796102e58013b ] Allow PTP peer delay measurements on blocked ports by STP. In case of topology changes the PTP stack can directly start with the correct delays. Fixes: ddd56dfe52c9 ("net: dsa: hellcreek: Add PTP clock support") Signed-off-by: Kurt Kanzenbach <[email protected]> Reviewed-by: Vladimir Oltean <[email protected]> Acked-by: Richard Cochran <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit c2be5908dd7c01607ba2bdb146a514e5b438b46b Author: Kurt Kanzenbach <[email protected]> Date: Tue Dec 14 14:45:06 2021 +0100 net: dsa: hellcreek: Add STP forwarding rule [ Upstream commit b7ade35eb53a2455f737a623c24e4b24455b2271 ] Treat STP as management traffic. STP traffic is designated for the CPU port only. In addition, STP traffic has to pass blocked ports. Fixes: e4b27ebc780f ("net: dsa: Add DSA driver for Hirschmann Hellcreek switches") Signed-off-by: Kurt Kanzenbach <[email protected]> Reviewed-by: Vladimir Oltean <[email protected]> Acked-by: Richard Cochran <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 06baf7c33cf3896e3f54285a71484791db99773b Author: Kurt Kanzenbach <[email protected]> Date: Tue Dec 14 14:45:05 2021 +0100 net: dsa: hellcreek: Fix insertion of static FDB entries [ Upstream commit 4db4c3ea56978086ca367a355e440de17d534827 ] The insertion of static FDB entries ignores the pass_blocked bit. That bit is evaluated with regards to STP. Add the missing functionality. Fixes: e4b27ebc780f ("net: dsa: Add DSA driver for Hirschmann Hellcreek switches") Signed-off-by: Kurt Kanzenbach <[email protected]> Reviewed-by: Vladimir Oltean <[email protected]> Acked-by: Richard Cochran <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 307ac652e9fb6f7757a5018e43b64bf05c9ac544 Author: Zhou Qingyang <[email protected]> Date: Mon Dec 13 11:53:07 2021 +0200 ath11k: Fix a NULL pointer dereference in ath11k_mac_op_hw_scan() [ Upstream commit eccd25136386a04ebf46a64f3a34e8e0fab6d9e1 ] In ath11k_mac_op_hw_scan(), the return value of kzalloc() is directly used in memcpy(), which may lead to a NULL pointer dereference on failure of kzalloc(). Fix this bug by adding a check of arg.extraie.ptr. This bug was found by a static analyzer. The analysis employs differential checking to identify inconsistent security operations (e.g., checks or kfrees) between two code paths and confirms that the inconsistent operations are not recovered in the current function or the callers, so they constitute bugs. Note that, as a bug found by static analysis, it can be a false positive or hard to trigger. Multiple researchers have cross-reviewed the bug. Builds with CONFIG_ATH11K=m show no new warnings, and our static analyzer no longer warns about this code. Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Signed-off-by: Zhou Qingyang <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit e935a4dd37e450d3c545d24c434fb2db23926b2d Author: Jiasheng Jiang <[email protected]> Date: Mon Dec 6 03:22:01 2021 +0100 media: coda/imx-vdoa: Handle dma_set_coherent_mask error codes [ Upstream commit 43f0633f89947df57fe0b5025bdd741768007708 ] The return value of dma_set_coherent_mask() is not always 0. To catch the exception in case that dma is not support the mask. Link: https://lore.kernel.org/linux-media/[email protected] Fixes: b0444f18e0b1 ("[media] coda: add i.MX6 VDOA driver") Signed-off-by: Jiasheng Jiang <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit f0fc76d6cc8085b7791b6d2231d7f3be860551a6 Author: Wang Hai <[email protected]> Date: Tue Oct 26 13:23:48 2021 +0200 media: msi001: fix possible null-ptr-deref in msi001_probe() [ Upstream commit 3d5831a40d3464eea158180eb12cbd81c5edfb6a ] I got a null-ptr-deref report: BUG: kernel NULL pointer dereference, address: 0000000000000060 ... RIP: 0010:v4l2_ctrl_auto_cluster+0x57/0x270 ... Call Trace: msi001_probe+0x13b/0x24b [msi001] spi_probe+0xeb/0x130 ... do_syscall_64+0x35/0xb0 In msi001_probe(), if the creation of control for bandwidth_auto fails, there will be a null-ptr-deref issue when it is used in v4l2_ctrl_auto_cluster(). Check dev->hdl.error before v4l2_ctrl_auto_cluster() to fix this bug. Link: https://lore.kernel.org/linux-media/[email protected] Fixes: 93203dd6c7c4 ("[media] msi001: Mirics MSi001 silicon tuner driver") Reported-by: Hulk Robot <[email protected]> Signed-off-by: Wang Hai <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 48225919434f911e3c7e9432e3faa9fdc0afbf64 Author: Anton Vasilyev <[email protected]> Date: Thu Aug 22 12:41:47 2019 +0200 media: dw2102: Fix use after free [ Upstream commit 589a9f0eb799f77de2c09583bf5bad221fa5d685 ] dvb_usb_device_init stores parts of properties at d->props and d->desc and uses it on dvb_usb_device_exit. Free of properties on module probe leads to use after free. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204597 The patch makes properties static instead of allocated on heap to prevent memleak and use after free. Also fixes s421_properties.devices initialization to have 2 element instead of 6 copied from p7500_properties. [mchehab: fix function call alignments] Link: https://lore.kernel.org/linux-media/[email protected] Signed-off-by: Anton Vasilyev <[email protected]> Fixes: 299c7007e936 ("media: dw2102: Fix memleak on sequence of probes") Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit f99f6ea71b55a09d344be9fb1d71a92560d6cb7b Author: Robin Murphy <[email protected]> Date: Fri Dec 3 11:44:50 2021 +0000 perf/arm-cmn: Fix CPU hotplug unregistration [ Upstream commit 56c7c6eaf3eb8ac1ec40d56096c0f2b27250da5f ] Attempting to migrate the PMU context after we've unregistered the PMU device, or especially if we never successfully registered it in the first place, is a woefully bad idea. It's also fundamentally pointless anyway. Make sure to unregister an instance from the hotplug handler *without* invoking the teardown callback. Fixes: 0ba64770a2f2 ("perf: Add Arm CMN-600 PMU driver") Signed-off-by: Robin Murphy <[email protected]> Link: https://lore.kernel.org/r/2c221d745544774e4b07583b65b5d4d94f7e0fe4.1638530442.git.robin.murphy@arm.com Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 70bf180fef8374e009b3d2164ab4fa3880330d5a Author: Christian Lamparter <[email protected]> Date: Mon Dec 6 01:43:34 2021 +0100 ARM: dts: gemini: NAS4220-B: fis-index-block with 128 KiB sectors [ Upstream commit 4754eab7e5a78bdefe7a960c5c260c95ebbb5fa6 ] Steven Maddox reported in the OpenWrt bugzilla, that his RaidSonic IB-NAS4220-B was no longer booting with the new OpenWrt 21.02 (uses linux 5.10's device-tree). However, it was working with the previous OpenWrt 19.07 series (uses 4.14). |[ 5.548038] No RedBoot partition table detected in 30000000.flash |[ 5.618553] Searching for RedBoot partition table in 30000000.flash at offset 0x0 |[ 5.739093] No RedBoot partition table detected in 30000000.flash |... |[ 7.039504] Waiting for root device /dev/mtdblock3... The provided bootlog shows that the RedBoot partition parser was looking for the partition table "at offset 0x0". Which is strange since the comment in the device-tree says it should be at 0xfe0000. Further digging on the internet led to a review site that took some useful PCB pictures of their review unit back in February 2009. Their picture shows a Spansion S29GL128N11TFI01 flash chip. >From Spansion's Datasheet: "S29GL128N: One hundred twenty-eight 64 Kword (128 Kbyte) sectors" Steven also provided a "cat /sys/class/mtd/mtd0/erasesize" from his unit: "131072". With the 128 KiB Sector/Erasesize in mind. This patch changes the fis-index-block property to (0xfe0000 / 0x20000) = 0x7f. Fixes: b5a923f8c739 ("ARM: dts: gemini: Switch to redboot partition parsing") Reported-by: Steven Maddox <[email protected]> Signed-off-by: Christian Lamparter <[email protected]> Signed-off-by: Linus Walleij <[email protected]> Tested-by: Steven Maddox <[email protected]> Link: https://lore.kernel.org/r/[email protected]' Bugzilla: https://bugs.openwrt.org/index.php?do=details&task_id=4137 Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 3d3fbbf05fe828bb0d94dbcb74390d790c7c07db Author: Hector Martin <[email protected]> Date: Sat Dec 11 02:05:34 2021 +0900 spi: Fix incorrect cs_setup delay handling [ Upstream commit 95c07247399536f83b89dc60cfe7b279d17e69f6 ] Move the cs_setup delay to the end of spi_set_cs. From include/linux/spi/spi.h: * @cs_setup: delay to be introduced by the controller after CS is asserted The cs_setup delay needs to happen *after* CS is asserted, that is, at the end of spi_set_cs, not at the beginning. Otherwise we're just delaying before the SPI transaction starts at all, which isn't very useful. No drivers use this right now, but that is likely to change soon with an upcoming Apple SPI HID transport driver. Fixes: 25093bdeb6bc ("spi: implement SW control for CS times") Signed-off-by: Hector Martin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 5d0933a65bbd5adcaf41d2b0ff3e847e9791c77b Author: Rameshkumar Sundaram <[email protected]> Date: Thu Dec 9 23:07:01 2021 +0530 ath11k: Fix deleting uninitialized kernel timer during fragment cache flush [ Upstream commit ba53ee7f7f38cf0592b8be1dcdabaf8f7535f8c1 ] frag_timer will be created & initialized for stations when they associate and will be deleted during every key installation while flushing old fragments. For AP interface self peer will be created and Group keys will be installed for this peer, but there will be no real Station entry & hence frag_timer won't be created and initialized, deleting such uninitialized kernel timers causes below warnings and backtraces printed with CONFIG_DEBUG_OBJECTS_TIMERS enabled. [ 177.828008] ODEBUG: assert_init not available (active state 0) object type: timer_list hint: 0x0 [ 177.836833] WARNING: CPU: 3 PID: 188 at lib/debugobjects.c:508 debug_print_object+0xb0/0xf0 [ 177.845185] Modules linked in: ath11k_pci ath11k qmi_helpers qrtr_mhi qrtr ns mhi [ 177.852679] CPU: 3 PID: 188 Comm: hostapd Not tainted 5.14.0-rc3-32919-g4034139e1838-dirty #14 [ 177.865805] pstate: 60000005 (nZCv daif -PAN -UAO -TCO BTYPE=--) [ 177.871804] pc : debug_print_object+0xb0/0xf0 [ 177.876155] lr : debug_print_object+0xb0/0xf0 [ 177.880505] sp : ffffffc01169b5a0 [ 177.883810] x29: ffffffc01169b5a0 x28: ffffff80081c2320 x27: ffffff80081c4078 [ 177.890942] x26: ffffff8003fe8f28 x25: ffffff8003de9890 x24: ffffffc01134d738 [ 177.898075] x23: ffffffc010948f20 x22: ffffffc010b2d2e0 x21: ffffffc01169b628 [ 177.905206] x20: ffffffc01134d700 x19: ffffffc010c80d98 x18: 00000000000003f6 [ 177.912339] x17: 203a657079742074 x16: 63656a626f202930 x15: 0000000000000152 [ 177.919471] x14: 0000000000000152 x13: 00000000ffffffea x12: ffffffc010d732e0 [ 177.926603] x11: 0000000000000003 x10: ffffffc010d432a0 x9 : ffffffc010d432f8 [ 177.933735] x8 : 000000000002ffe8 x7 : c0000000ffffdfff x6 : 0000000000000001 [ 177.940866] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000ffffffff [ 177.947997] x2 : ffffffc010c93240 x1 : ffffff80023624c0 x0 : 0000000000000054 [ 177.955130] Call trace: [ 177.957567] debug_print_object+0xb0/0xf0 [ 177.961570] debug_object_assert_init+0x124/0x178 [ 177.966269] try_to_del_timer_sync+0x1c/0x70 [ 177.970536] del_timer_sync+0x30/0x50 [ 177.974192] ath11k_peer_frags_flush+0x34/0x68 [ath11k] [ 177.979439] ath11k_mac_op_set_key+0x1e4/0x338 [ath11k] [ 177.984673] ieee80211_key_enable_hw_accel+0xc8/0x3d0 [ 177.989722] ieee80211_key_replace+0x360/0x740 [ 177.994160] ieee80211_key_link+0x16c/0x210 [ 177.998337] ieee80211_add_key+0x138/0x338 [ 178.002426] nl80211_new_key+0xfc/0x258 [ 178.006257] genl_family_rcv_msg_doit.isra.17+0xd8/0x120 [ 178.011565] genl_rcv_msg+0xd8/0x1c8 [ 178.015134] netlink_rcv_skb+0x38/0xf8 [ 178.018877] genl_rcv+0x34/0x48 [ 178.022012] netlink_unicast+0x174/0x230 [ 178.025928] netlink_sendmsg+0x188/0x388 [ 178.029845] ____sys_sendmsg+0x218/0x250 [ 178.033763] ___sys_sendmsg+0x68/0x90 [ 178.037418] __sys_sendmsg+0x44/0x88 [ 178.040988] __arm64_sys_sendmsg+0x20/0x28 [ 178.045077] invoke_syscall.constprop.5+0x54/0xe0 [ 178.049776] do_el0_svc+0x74/0xc0 [ 178.053084] el0_svc+0x10/0x18 [ 178.056133] el0t_64_sync_handler+0x88/0xb0 [ 178.060310] el0t_64_sync+0x148/0x14c [ 178.063966] ---[ end trace 8a5cf0bf9d34a058 ]--- Add changes to not to delete frag timer for peers during group key installation. Tested on: IPQ8074 hw2.0 AHB WLAN.HK.2.5.0.1-01092-QCAHKSWPL_SILICONZ-1 Fixes: c3944a562102 ("ath11k: Clear the fragment cache during key install") Signed-off-by: Rameshkumar Sundaram <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 8b2b88054961fbad4f82545e6100af336280bdba Author: Weili Qian <[email protected]> Date: Sat Dec 4 18:43:01 2021 +0800 crypto: hisilicon/qm - fix incorrect return value of hisi_qm_resume() [ Upstream commit 3f9dd4c802b96626e869b2d29c8e401dabadd23e ] When hisi_qm_resume() returns 0, it indicates that the device has started successfully. If the device fails to start, hisi_qm_resume() needs to return the actual error code to the caller instead of 0. Fixes: d7ea53395b72 ("crypto: hisilicon - add runtime PM ops") Signed-off-by: Weili Qian <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 5367147cb4f8c707d81eb84502cb4817c6779390 Author: Herbert Xu <[email protected]> Date: Wed Dec 1 17:30:41 2021 +1100 crypto: stm32 - Revert broken pm_runtime_resume_and_get changes [ Upstream commit 3d6b661330a7954d8136df98160d525eb04dcd6a ] We should not call pm_runtime_resume_and_get where the reference count is expected to be incremented unconditionally. This patch reverts these calls to the original unconditional get_sync call. Reported-by: Heiner Kallweit <[email protected]> Fixes: 747bf30fd944 ("crypto: stm32/cryp - Fix PM reference leak...") Fixes: 1cb3ad701970 ("crypto: stm32/hash - Fix PM reference leak...") Signed-off-by: Herbert Xu <[email protected]> Acked-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 2383a52088b6ef3581686bdfc8a11a1c07d17cab Author: Nicolas Toromanoff <[email protected]> Date: Tue Nov 30 08:55:00 2021 +0100 crypto: stm32/cryp - fix bugs and crash in tests [ Upstream commit 4b898d5cfa4d9a0ad5bc82cb5eafdc092394c6a9 ] Extra crypto manager auto test were crashing or failling due to 2 reasons: - block in a dead loop (dues to issues in cipher end process management) - crash due to read/write unmapped memory (this crash was also reported when using openssl afalg engine) Rework interrupt management, interrupts are masked as soon as they are no more used: if input buffer is fully consumed, "Input FIFO not full" interrupt is masked and if output buffer is full, "Output FIFO not empty" interrupt is masked. And crypto request finish when input *and* outpout buffer are fully read/write. About the crash due to unmapped memory, using scatterwalk_copychunks() that will map and copy each block fix the issue. Using this api and copying full block will also fix unaligned data access, avoid early copy of in/out buffer, and make useless the extra alignment constraint. Fixes: 9e054ec21ef8 ("crypto: stm32 - Support for STM32 CRYP crypto module") Reported-by: Marek Vasut <[email protected]> Signed-off-by: Nicolas Toromanoff <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 4e3043d247e62d3ae10d89edb299b348ad420dba Author: Nicolas Toromanoff <[email protected]> Date: Tue Nov 30 08:54:59 2021 +0100 crypto: stm32/cryp - fix lrw chaining mode [ Upstream commit fa97dc2d48b476ea98199d808d3248d285987e99 ] This fixes the lrw autotest if lrw uses the CRYP as the AES block cipher provider (as ecb(aes)). At end of request, CRYP should not update the IV in case of ECB chaining mode. Indeed the ECB chaining mode never uses the IV, but the software LRW chaining mode uses the IV field as a counter and due to the (unexpected) update done by CRYP while the AES block process, the counter get a wrong value when the IV overflow. Fixes: 5f49f18d27cd ("crypto: stm32/cryp - update to return iv_out") Signed-off-by: Nicolas Toromanoff <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 0ba9b34ec6e5359b004ac03a8c123339701b157d Author: Nicolas Toromanoff <[email protected]> Date: Tue Nov 30 08:54:58 2021 +0100 crypto: stm32/cryp - fix double pm exit [ Upstream commit 6c12e742785bf9333faf60bfb96575bdd763448e ] Delete extraneous lines in probe error handling code: pm was disabled twice. Fixes: 65f9aa36ee47 ("crypto: stm32/cryp - Add power management support") Reported-by: Marek Vasut <[email protected]> Signed-off-by: Nicolas Toromanoff <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit ef416e0614af6a423890aa4a04eb7da41d0e5a2b Author: Nicolas Toromanoff <[email protected]> Date: Tue Nov 30 08:54:57 2021 +0100 crypto: stm32/cryp - check early input data [ Upstream commit 39e6e699c7fb92bdb2617b596ca4a4ea35c5d2a7 ] Some auto tests failed because driver wasn't returning the expected error with some input size/iv value/tag size. Now: Return 0 early for empty buffer. (We don't need to start the engine for an empty input buffer). Accept any valid authsize for gcm(aes). Return -EINVAL if iv for ccm(aes) is invalid. Return -EINVAL if buffer size is a not a multiple of algorithm block size. Fixes: 9e054ec21ef8 ("crypto: stm32 - Support for STM32 CRYP crypto module") Signed-off-by: Nicolas Toromanoff <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 4a62c2b32c4104d29044eb2e931e751f044c1b37 Author: Nicolas Toromanoff <[email protected]> Date: Tue Nov 30 08:54:56 2021 +0100 crypto: stm32/cryp - fix xts and race condition in crypto_engine requests [ Upstream commit d703c7a994ee34b7fa89baf21631fca0aa9f17fc ] Don't erase key: If key is erased before the crypto_finalize_.*_request() call, some pending process will run with a key={ 0 }. Moreover if the key is reset at end of request, it breaks xts chaining mode, as for last xts block (in case input len is not a multiple of block) a new AES request is started without calling again set_key(). Fixes: 9e054ec21ef8 ("crypto: stm32 - Support for STM32 CRYP crypto module") Signed-off-by: Nicolas Toromanoff <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 4671521de2774bc86668e9b10f1fbe6c97e7dc1a Author: Nicolas Toromanoff <[email protected]> Date: Tue Nov 30 08:54:55 2021 +0100 crypto: stm32/cryp - fix CTR counter carry [ Upstream commit 41c76690b0990efacd15d35cfb4e77318cd80ebb ] STM32 CRYP hardware doesn't manage CTR counter bigger than max U32, as a workaround, at each block the current IV is saved, if the saved IV lower u32 is 0xFFFFFFFF, the full IV is manually incremented, and set in hardware. Fixes: bbb2832620ac ("crypto: stm32 - Fix sparse warnings") Signed-off-by: Nicolas Toromanoff <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit f857f6cc5fbf9783b3df5354e18e9d0e55f03802 Author: Jakub Kicinski <[email protected]> Date: Wed Nov 24 14:39:16 2021 -0800 selftests: harness: avoid false negatives if test has no ASSERTs [ Upstream commit 3abedf4646fdc0036fcb8ebbc3b600667167fafe ] Test can fail either immediately when ASSERT() failed or at the end if one or more EXPECT() was not met. The exact return code is decided based on the number of successful ASSERT()s. If test has no ASSERT()s, however, the return code will be 0, as if the test did not fail. Start counting ASSERT()s from 1. Fixes: 369130b63178 ("selftests: Enhance kselftest_harness.h to print which assert failed") Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Shuah Khan <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit c0dbfef7e63fa1760e96eca45e32a400e1de661c Author: Anders Roxell <[email protected]> Date: Wed Nov 3 21:13:50 2021 +0100 selftests: clone3: clone3: add case CLONE3_ARGS_NO_TEST [ Upstream commit a531b0c23c0fc68ad758cc31a74cf612a4dafeb0 ] Building selftests/clone3 with clang warns about enumeration not handled in switch case: clone3.c:54:10: warning: enumeration value 'CLONE3_ARGS_NO_TEST' not handled in switch [-Wswitch] switch (test_mode) { ^ Add the missing switch case with a comment. Fixes: 17a810699c18 ("selftests: add tests for clone3()") Signed-off-by: Anders Roxell <[email protected]> Acked-by: Christian Brauner <[email protected]> Signed-off-by: Shuah Khan <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit fa8db0f53fc1619390ba3f404e8b668228f10239 Author: Kees Cook <[email protected]> Date: Wed Dec 8 20:34:56 2021 -0800 x86/uaccess: Move variable into switch case statement [ Upstream commit 61646ca83d3889696f2772edaff122dd96a2935e ] When building with automatic stack variable initialization, GCC 12 complains about variables defined outside of switch case statements. Move the variable into the case that uses it, which silences the warning: ./arch/x86/include/asm/uaccess.h:317:23: warning: statement will never be executed [-Wswitch-unreachable] 317 | unsigned char x_u8__; \ | ^~~~~~ Fixes: 865c50e1d279 ("x86/uaccess: utilize CONFIG_CC_HAS_ASM_GOTO_OUTPUT") Signed-off-by: Kees Cook <[email protected]> Signed-off-by: Dave Hansen <[email protected]> Signed-off-by: Borislav Petkov <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 097d4aeea0fcfe569e53a19e8d13fae2888d4abf Author: Eric Dumazet <[email protected]> Date: Wed Dec 8 12:20:19 2021 -0800 xfrm: fix a small bug in xfrm_sa_len() [ Upstream commit 7770a39d7c63faec6c4f33666d49a8cb664d0482 ] copy_user_offload() will actually push a struct struct xfrm_user_offload, which is different than (struct xfrm_state *)->xso (struct xfrm_state_offload) Fixes: d77e38e612a01 ("xfrm: Add an IPsec hardware offloading API") Signed-off-by: Eric Dumazet <[email protected]> Cc: Steffen Klassert <[email protected]> Signed-off-by: Steffen Klassert <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 7a95f5d9b80f40073608bdec3e9fdbbd29da56de Author: Brian Norris <[email protected]> Date: Mon Nov 29 16:47:34 2021 -0800 mwifiex: Fix possible ABBA deadlock [ Upstream commit 1b8bb8919ef81bfc8873d223b9361f1685f2106d ] Quoting Jia-Ju Bai <[email protected]>: mwifiex_dequeue_tx_packet() spin_lock_bh(&priv->wmm.ra_list_spinlock); --> Line 1432 (Lock A) mwifiex_send_addba() spin_lock_bh(&priv->sta_list_spinlock); --> Line 608 (Lock B) mwifiex_process_sta_tx_pause() spin_lock_bh(&priv->sta_list_spinlock); --> Line 398 (Lock B) mwifiex_update_ralist_tx_pause() spin_lock_bh(&priv->wmm.ra_list_spinlock); --> Line 941 (Lock A) Similar report for mwifiex_process_uap_tx_pause(). While the locking expectations in this driver are a bit unclear, the Fixed commit only intended to protect the sta_ptr, so we can drop the lock as soon as we're done with it. IIUC, this deadlock cannot actually happen, because command event processing (which calls mwifiex_process_sta_tx_pause()) is sequentialized with TX packet processing (e.g., mwifiex_dequeue_tx_packet()) via the main loop (mwifiex_main_process()). But it's good not to leave this potential issue lurking. Fixes: f0f7c2275fb9 ("mwifiex: minor cleanups w/ sta_list_spinlock in cfg80211.c") Cc: Douglas Anderson <[email protected]> Reported-by: TOTE Robot <[email protected]> Link: https://lore.kernel.org/linux-wireless/[email protected]/ Signed-off-by: Brian Norris <[email protected]> Reviewed-by: Douglas Anderson <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/YaV0pllJ5p/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 4e6ad76d340fb8bc919d3c5e57f3810747a74c7b Author: Dmitry Baryshkov <[email protected]> Date: Thu Nov 25 21:01:14 2021 +0300 drm/msm/dsi: fix initialization in the bonded DSI case [ Upstream commit 92cb1bedde9dba78d802fe2510949743a2581aed ] Commit 739b4e7756d3 ("drm/msm/dsi: Fix an error code in msm_dsi_modeset_init()") changed msm_dsi_modeset_init() to return an error code in case msm_dsi_manager_validate_current_config() returns false. However this is not an error case, but a slave DSI of the bonded DSI link. In this case msm_dsi_modeset_init() should return 0, but just skip connector and bridge initialization. To reduce possible confusion, drop the msm_dsi_manager_validate_current_config() function, and specif 'bonded && !master' condition directly in the msm_dsi_modeset_init(). Fixes: 739b4e7756d3 ("drm/msm/dsi: Fix an error code in msm_dsi_modeset_init()") Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Rob Clark <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 5c2eaa606feb5228f6c7d44d7a39a83d721bae7d Author: Loic Poulain <[email protected]> Date: Thu Dec 2 10:02:12 2021 +0100 wcn36xx: Fix max channels retrieval [ Upstream commit 09cab4308bf9b8076ee4a3c56015daf9ef9cb23e ] Kernel test robot reported:drivers/net/wireless/ath/wcn36xx/smd.c:943:33: sparse: sparse: cast truncates bits from constant value (780 becomes 80) The 'channels' field is not a simple u8 array but an array of channel_params. Using sizeof for retrieving the max number of channels is then wrong. In practice, it was not an issue, because the sizeof returned value is 780, which is truncated in min_t (u8) to 80, which is the value we expect... Fix that properly using ARRAY_SIZE instead of sizeof. Fixes: d707f812bb05 ("wcn36xx: Channel list update before hardware scan") Reported-by: kernel test robot <[email protected]> Signed-off-by: Loic Poulain <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit ef93cc02cafb3aa4df559572e22b8d034ce7a516 Author: Frederic Weisbecker <[email protected]> Date: Tue Nov 30 17:21:08 2021 +0100 rcu/exp: Mark current CPU as exp-QS in IPI loop second pass [ Upstream commit 81f6d49cce2d2fe507e3fddcc4a6db021d9c2e7b ] Expedited RCU grace periods invoke sync_rcu_exp_select_node_cpus(), which takes two passes over the leaf rcu_node structure's CPUs. The first pass gathers up the current CPU and CPUs that are in dynticks idle mode. The workqueue will report a quiescent state on their behalf later. The second pass sends IPIs to the rest of the CPUs, but excludes the current CPU, incorrectly assuming it has been included in the first pass's list of CPUs. Unfortunately the current CPU may have changed between the first and second pass, due to the fact that the various rcu_node structures' ->lock fields have been dropped, thus momentarily enabling preemption. This means that if the second pass's CPU was not on the first pass's list, it will be ignored completely. There will be no IPI sent to it, and there will be no reporting of quiescent states on its behalf. Unfortunately, the expedited grace period will nevertheless be waiting for that CPU to report a quiescent state, but with that CPU having no reason to believe that such a report is needed. The result will be an expedited grace period stall. Fix this by no longer excluding the current CPU from consideration during the second pass. Fixes: b9ad4d6ed18e ("rcu: Avoid self-IPI in sync_rcu_exp_select_node_cpus()") Reviewed-by: Neeraj Upadhyay <[email protected]> Signed-off-by: Frederic Weisbecker <[email protected]> Cc: Uladzislau Rezki <[email protected]> Cc: Neeraj Upadhyay <[email protected]> Cc: Boqun Feng <[email protected]> Cc: Josh Triplett <[email protected]> Cc: Joel Fernandes <[email protected]> Signed-off-by: Paul E. McKenney <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 87472bebedbbf773adc1aded260c3dd7bf30513a Author: Jackie Liu <[email protected]> Date: Wed Nov 10 15:09:49 2021 +0800 drm/msm/dp: displayPort driver need algorithm rational [ Upstream commit 53d22794711ad630f40d59dd726bd260d77d585f ] Let's select RATIONAL with dp driver. avoid like: [...] x86_64-linux-gnu-ld: drivers/gpu/drm/msm/dp/dp_catalog.o: in function `dp_catalog_ctrl_config_msa': dp_catalog.c:(.text+0x57e): undefined reference to `rational_best_approximation' Fixes: c943b4948b58 ("drm/msm/dp: add displayPort driver support") Reported-by: kernelbot <[email protected]> Signed-off-by: Jackie Liu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Rob Clark <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit e5d61c5b9c9cc0f08fc7ca47f15153e35e3059f5 Author: Rob Clark <[email protected]> Date: Mon Nov 29 10:23:44 2021 -0800 drm/msm/gpu: Don't allow zero fence_id [ Upstream commit ca3ffcbeb0c866d9b0cb38eaa2bd4416597b5966 ] Elsewhere we treat zero as "no fence" and __msm_gem_submit_destroy() skips removal from fence_idr. We could alternately change this to use negative values for "no fence" but I think it is more clear to not allow zero as a valid fence_id. Signed-off-by: Rob Clark <[email protected]> Fixes: a61acbbe9cf8 ("drm/msm: Track "seqno" fences by idr") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Rob Clark <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 89166801f80dc64083212eef1308bfc62f6844f1 Author: Nicholas Kazlauskas <[email protected]> Date: Tue Dec 7 09:46:39 2021 -0500 drm/amd/display: Fix out of bounds access on DNC31 stream encoder regs [ Upstream commit d374d3b493215d637b9e7be12a93f22caf4c1f97 ] [Why] During dcn31_stream_encoder_create, if PHYC/D get remapped to F/G on B0 then we'll index 5 or 6 into a array of length 5 - leading to an access violation on some configs during device creation. [How] Software won't be touching PHYF/PHYG directly, so just extend the array to cover all possible engine IDs. Even if it does by try to access one of these registers by accident the offset will be 0 and we'll get a warning during the access. Fixes: 2fe9a0e1173f ("drm/amd/display: Fix DCN3 B0 DP Alt Mapping") Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Nicholas Kazlauskas <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 6dcc6706dab10744d277bdc2613fb135c6a632dd Author: Wayne Lin <[email protected]> Date: Fri Nov 26 15:19:57 2021 +0800 drm/amd/display: Fix bug in debugfs crc_win_update entry [ Upstream commit 4bef85d4c9491415b7931407b07f24841c1e0390 ] [Why] crc_rd_wrk shouldn't be null in crc_win_update_set(). Current programming logic is inconsistent in crc_win_update_set(). [How] Initially, return if crc_rd_wrk is NULL. Later on, we can use member of crc_rd_wrk safely. Reported-by: kernel test robot <[email protected]> Reported-by: Dan Carpenter <[email protected]> Fixes: 9a65df193108 ("drm/amd/display: Use PSP TA to read out crc") Reviewed-by: Rodrigo Siqueira <[email protected]> Acked-by: Pavle Kotarac <[email protected]> Signed-off-by: Wayne Lin <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit d41946e82718c3a4023ada6583ce026c21159021 Author: Mark Chen <[email protected]> Date: Tue Dec 7 01:33:42 2021 +0800 Bluetooth: btusb: Handle download_firmware failure cases [ Upstream commit 00c0ee9850b7b0cb7c40b8daba806ae2245e59d4 ] For Mediatek chipset, it can not enabled if there are something wrong in btmtk_setup_firmware_79xx(). Thus, the process must be terminated and returned error code. Fixes: fc342c4dc4087 ("Bluetooth: btusb: Add protocol support for MediaTek MT7921U USB devices") Co-developed-by: Sean Wang <[email protected]> Signed-off-by: Sean Wang <[email protected]> Signed-off-by: Mark Chen <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 006157d575d146255963ffbc81855929accb5993 Author: Luiz Augusto von Dentz <[email protected]> Date: Wed Dec 1 11:49:49 2021 -0800 Bluetooth: MGMT: Use hci_dev_test_and_{set,clear}_flag [ Upstream commit 6f59f991b4e735323f099ac6490e725ae8c750a5 ] This make use of hci_dev_test_and_{set,clear}_flag instead of doing 2 operations in a row. Fixes: cbbdfa6f33198 ("Bluetooth: Enable controller RPA resolution using Experimental feature") Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 749fc99daa1300d79d6f7d32467aca301dc5cf39 Author: Joseph Hwang <[email protected]> Date: Sun Aug 15 20:17:15 2021 +0800 Bluetooth: refactor set_exp_feature with a feature table [ Upstream commit 93fb70bc112e922def6e50b37e20ccfce0c67c0a ] This patch refactors the set_exp_feature with a feature table consisting of UUIDs and the corresponding callback functions. In this way, a new experimental feature setting function can be simply added with its UUID and callback function. Signed-off-by: Joseph Hwang <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit d3f45f4ee17f72cea98b433c952c418810b47c4d Author: Fabio Estevam <[email protected]> Date: Wed Nov 24 10:10:47 2021 -0300 ath10k: Fix the MTU size on QCA9377 SDIO [ Upstream commit 09b8cd69edcf2be04a781e1781e98e52a775c9ad ] On an imx6dl-pico-pi board with a QCA9377 SDIO chip, simply trying to connect via ssh to another machine causes: [ 55.824159] ath10k_sdio mmc1:0001:1: failed to transmit packet, dropping: -12 [ 55.832169] ath10k_sdio mmc1:0001:1: failed to submit frame: -12 [ 55.838529] ath10k_sdio mmc1:0001:1: failed to push frame: -12 [ 55.905863] ath10k_sdio mmc1:0001:1: failed to transmit packet, dropping: -12 [ 55.913650] ath10k_sdio mmc1:0001:1: failed to submit frame: -12 [ 55.919887] ath10k_sdio mmc1:0001:1: failed to push frame: -12 , leading to an ssh connection failure. One user inspected the size of frames on Wireshark and reported the followig: "I was able to narrow the issue down to the mtu. If I set the mtu for the wlan0 device to 1486 instead of 1500, the issue does not happen. The size of frames that I see on Wireshark is exactly 1500 after setting it to 1486." Clearing the HI_ACS_FLAGS_ALT_DATA_CREDIT_SIZE avoids the problem and the ssh command works successfully after that. Introduce a 'credit_size_workaround' field to ath10k_hw_params for the QCA9377 SDIO, so that the HI_ACS_FLAGS_ALT_DATA_CREDIT_SIZE is not set in this case. Tested with QCA9377 SDIO with firmware WLAN.TF.1.1.1-00061-QCATFSWPZ-1. Fixes: 2f918ea98606 ("ath10k: enable alt data of TX path for sdio") Signed-off-by: Fabio Estevam <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 378723bd01b28085a72708e010afbda480cb5782 Author: Li Hua <[email protected]> Date: Fri Dec 3 03:36:18 2021 +0000 sched/rt: Try to restart rt period timer when rt runtime exceeded [ Upstream commit 9b58e976b3b391c0cf02e038d53dd0478ed3013c ] When rt_runtime is modified from -1 to a valid control value, it may cause the task to be throttled all the time. Operations like the following will trigger the bug. E.g: 1. echo -1 > /proc/sys/kernel/sched_rt_runtime_us 2. Run a FIFO task named A that executes while(1) 3. echo 950000 > /proc/sys/kernel/sched_rt_runtime_us When rt_runtime is -1, The rt period timer will not be activated when task A enqueued. And then the task will be throttled after setting rt_runtime to 950,000. The task will always be throttled because the rt period timer is not activated. Fixes: d0b27fa77854 ("sched: rt-group: synchonised bandwidth period") Reported-by: Hulk Robot <[email protected]> Signed-off-by: Li Hua <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 9a664557effecd59704eccd9a0501dcc6663d1b9 Author: Lv Yunlong <[email protected]> Date: Fri Apr 2 22:47:55 2021 -0700 wireless: iwlwifi: Fix a double free in iwl_txq_dyn_alloc_dma [ Upstream commit f973795a8d19cbf3d03807704eb7c6ff65788d5a ] In iwl_txq_dyn_alloc_dma, txq->tfds is freed at first time by: iwl_txq_alloc()->goto err_free_tfds->dma_free_coherent(). But it forgot to set txq->tfds to NULL. Then the txq->tfds is freed again in iwl_txq_dyn_alloc_dma by: goto error->iwl_txq_gen2_free_memory()->dma_free_coherent(). My patch sets txq->tfds to NULL after the first free to avoid the double free. Fixes: 0cd1ad2d7fd41 ("iwlwifi: move all bus-independent TX functions to common code") Signed-off-by: Lv Yunlong <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Luca Coelho <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 643af6932580f0c8e9c21d191ff1923dca0b9d47 Author: Robert Schlabbach <[email protected]> Date: Wed Dec 1 22:08:43 2021 +0100 media: si2157: Fix "warm" tuner state detection [ Upstream commit a6441ea29cb2c9314654e093a1cd8020b9b851c8 ] Commit e955f959ac52 ("media: si2157: Better check for running tuner in init") completely broke the "warm" tuner detection of the si2157 driver due to a simple endian error: The Si2157 CRYSTAL_TRIM property code is 0x0402 and needs to be transmitted LSB first. However, it was inserted MSB first, causing the warm detection to always fail and spam the kernel log with tuner initialization messages each time the DVB frontend device was closed and reopened: [ 312.215682] si2157 16-0060: found a 'Silicon Labs Si2157-A30' [ 312.264334] si2157 16-0060: firmware version: 3.0.5 [ 342.248593] si2157 16-0060: found a 'Silicon Labs Si2157-A30' [ 342.295743] si2157 16-0060: firmware version: 3.0.5 [ 372.328574] si2157 16-0060: found a 'Silicon Labs Si2157-A30' [ 372.385035] si2157 16-0060: firmware version: 3.0.5 Also, the reinitializations were observed disturb _other_ tuners on multi-tuner cards such as the Hauppauge WinTV-QuadHD, leading to missed or errored packets when one of the other DVB frontend devices on that card was opened. Fix the order of the property code bytes to make the warm detection work again, also reducing the tuner initialization message in the kernel log to once per power-on, as well as fixing the interference with other tuners. Link: https://lore.kernel.org/linux-media/trinity-2a86eb9d-6264-4387-95e1-ba7b79a4050f-1638392923493@3c-app-gmx-bap03 Fixes: e955f959ac52 ("media: si2157: Better check for running tuner in init") Reported-by: Robert Schlabbach <[email protected]> Signed-off-by: Robert Schlabbach <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit d8904d2f628383147a037b9a409936d122d4b7c9 Author: Zhou Qingyang <[email protected]> Date: Tue Nov 30 17:34:44 2021 +0100 media: saa7146: mxb: Fix a NULL pointer dereference in mxb_attach() [ Upstream commit 0407c49ebe330333478440157c640fffd986f41b ] In mxb_attach(dev, info), saa7146_vv_init() is called to allocate a new memory for dev->vv_data. saa7146_vv_release() will be called on failure of mxb_probe(dev). There is a dereference of dev->vv_data in saa7146_vv_release(), which could lead to a NULL pointer dereference on failure of saa7146_vv_init(). Fix this bug by adding a check of saa7146_vv_init(). This bug was found by a static analyzer. The analysis employs differential checking to identify inconsistent security operations (e.g., checks or kfrees) between two code paths and confirms that the inconsistent operations are not recovered in the current function or the callers, so they constitute bugs. Note that, as a bug found by static analysis, it can be a false positive or hard to trigger. Multiple researchers have cross-reviewed the bug. Builds with CONFIG_VIDEO_MXB=m show no new warnings, and our static analyzer no longer warns about this code. Fixes: 03b1930efd3c ("V4L/DVB: saa7146: fix regression of the av7110/budget-av driver") Signed-off-by: Zhou Qingyang <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 6f2d3249b98d9a5f349c8c6840a35ff1175b42a1 Author: Zhou Qingyang <[email protected]> Date: Tue Nov 30 16:38:05 2021 +0100 media: dib8000: Fix a memleak in dib8000_init() [ Upstream commit 8dbdcc7269a83305ee9d677b75064d3530a48ee2 ] In dib8000_init(), the variable fe is not freed or passed out on the failure of dib8000_identify(&state->i2c), which could lead to a memleak. Fix this bug by adding a kfree of fe in the error path. This bug was found by a static analyzer. The analysis employs differential checking to identify inconsistent security operations (e.g., checks or kfrees) between two code paths and confirms that the inconsistent operations are not recovered in the current function or the callers, so they constitute bugs. Note that, as a bug found by static analysis, it can be a false positive or hard to trigger. Multiple researchers have cross-reviewed the bug. Builds with CONFIG_DVB_DIB8000=m show no new warnings, and our static analyzer no longer warns about this code. Fixes: 77e2c0f5d471 ("V4L/DVB (12900): DiB8000: added support for DiBcom ISDB-T/ISDB-Tsb demodulator DiB8000") Signed-off-by: Zhou Qingyang <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 1a51d9d60325e0642419d0b6b42df9183fbcaacd Author: Alexander Lobakin <[email protected]> Date: Fri Dec 3 20:50:04 2021 +0100 samples: bpf: Fix 'unknown warning group' build warning on Clang [ Upstream commit 6f670d06e47c774bc065aaa84a527a4838f34bd8 ] Clang doesn't have 'stringop-truncation' group like GCC does, and complains about it when building samples which use xdp_sample_user infra: samples/bpf/xdp_sample_user.h:48:32: warning: unknown warning group '-Wstringop-truncation', ignored [-Wunknown-warning-option] #pragma GCC diagnostic ignored "-Wstringop-truncation" ^ [ repeat ] Those are harmless, but avoidable when guarding it with ifdef. I could guard push/pop as well, but this would require one more ifdef cruft around a single line which I don't think is reasonable. Fixes: 156f886cf697 ("samples: bpf: Add basic infrastructure for XDP samples") Signed-off-by: Alexander Lobakin <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]> Acked-by: Kumar Kartikeya Dwivedi <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit d891664e39adcee2f3c3b4988b3c7d5991324e2b Author: Alexander Lobakin <[email protected]> Date: Fri Dec 3 20:50:03 2021 +0100 samples: bpf: Fix xdp_sample_user.o linking with Clang [ Upstream commit e64fbcaa7a666f16329b1c67af15ea501bc84586 ] Clang (13) doesn't get the jokes about specifying libraries to link in cclags of individual .o objects: clang-13: warning: -lm: 'linker' input unused [-Wunused-command-line-argument] [ ... ] LD samples/bpf/xdp_redirect_cpu LD samples/bpf/xdp_redirect_map_multi LD samples/bpf/xdp_redirect_map LD samples/bpf/xdp_redirect LD samples/bpf/xdp_monitor /usr/bin/ld: samples/bpf/xdp_sample_user.o: in function `sample_summary_print': xdp_sample_user.c:(.text+0x84c): undefined reference to `floor' /usr/bin/ld: xdp_sample_user.c:(.text+0x870): undefined reference to `ceil' /usr/bin/ld: xdp_sample_user.c:(.text+0x8cf): undefined reference to `floor' /usr/bin/ld: xdp_sample_user.c:(.text+0x8f3): undefined reference to `ceil' [ more ] Specify '-lm' as ldflags for all xdp_sample_user.o users in the main Makefile and remove it from ccflags of ^ in Makefile.target -- just like it's done for all other samples. This works with all compilers. Fixes: 6e1051a54e31 ("samples: bpf: Convert xdp_monitor to XDP samples helper") Fixes: b926c55d856c ("samples: bpf: Convert xdp_redirect to XDP samples helper") Fixes: e531a220cc59 ("samples: bpf: Convert xdp_redirect_cpu to XDP samples helper") Fixes: bbe65865aa05 ("samples: bpf: Convert xdp_redirect_map to XDP samples helper") Fixes: 594a116b2aa1 ("samples: bpf: Convert xdp_redirect_map_multi to XDP samples helper") Signed-off-by: Alexander Lobakin <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]> Acked-by: Kumar Kartikeya Dwivedi <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit c7d36c19cf30f8639d35506bc57bba9483d7741c Author: Andrii Nakryiko <[email protected]> Date: Wed Dec 1 15:28:22 2021 -0800 samples/bpf: Clean up samples/bpf build failes [ Upstream commit 527024f7aeb683ce7ef49b07ef7ce9ecf015288d ] Remove xdp_samples_user.o rule redefinition which generates Makefile warning and instead override TPROGS_CFLAGS. This seems to work fine when building inside selftests/bpf. That was one big head-scratcher before I found that generic Makefile.target hid this surprising specialization for for xdp_samples_user.o. Main change is to use actual locally installed libbpf headers. Also drop printk macro re-definition (not even used!). Signed-off-by: Andrii Nakryiko <[email protected]> Signed-off-by: Alexei Starovoitov <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 7b4a30bbf8ca59ffb1f0d501d73971658d6c3fdf Author: Quentin Monnet <[email protected]> Date: Thu Oct 7 20:44:35 2021 +0100 samples/bpf: Install libbpf headers when building [ Upstream commit 3f7a3318a7c60947e27be372950840a5eab976d0 ] API headers from libbpf should not be accessed directly from the source directory. Instead, they should be exported with "make install_headers". Make sure that samples/bpf/Makefile installs the headers properly when building. The object compiled from and exported by libbpf are now placed into a subdirectory of sample/bpf/ instead of remaining in tools/lib/bpf/. We attempt to remove this directory on "make clean". However, the "clean" target re-enters the samples/bpf/ directory from the root of the repository ("$(MAKE) -C ../../ M=$(CURDIR) clean"), in such a way that $(srctree) and $(src) are not defined, making it impossible to use $(LIBBPF_OUTPUT) and $(LIBBPF_DESTDIR) in the recipe. So we only attempt to clean $(CURDIR)/libbpf, which is the default value. Add a dependency on libbpf's headers for the $(TRACE_HELPERS). We also change the output directory for bpftool, to place the generated objects under samples/bpf/bpftool/ instead of building in bpftool's directory directly. Doing so, we make sure bpftool reuses the libbpf library previously compiled and installed. Signed-off-by: Quentin Monnet <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit c7f0c087d483b586516520bd88deb712d3b31925 Author: Reiji Watanabe <[email protected]> Date: Sun Dec 5 16:47:36 2021 -0800 arm64: mte: DC {GVA,GZVA} shouldn't be used when DCZID_EL0.DZP == 1 [ Upstream commit 685e2564daa1493053fcd7f1dbed38b35ee2f3cb ] Currently, mte_set_mem_tag_range() and mte_zero_clear_page_tags() use DC {GVA,GZVA} unconditionally. But, they should make sure that DCZID_EL0.DZP, which indicates whether or not use of those instructions is prohibited, is zero when using those instructions. Use ST{G,ZG,Z2G} instead when DCZID_EL0.DZP == 1. Fixes: 013bb59dbb7c ("arm64: mte: handle tags zeroing at page allocation time") Fixes: 3d0cca0b02ac ("kasan: speed up mte_set_mem_tag_range") Signed-off-by: Reiji Watanabe <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Catalin Marinas <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 338c297e08851387d26eca98b6069fb5c812fad1 Author: Reiji Watanabe <[email protected]> Date: Sun Dec 5 16:47:35 2021 -0800 arm64: clear_page() shouldn't use DC ZVA when DCZID_EL0.DZP == 1 [ Upstream commit f0616abd4e67143b45b04b565839148458857347 ] Currently, clear_page() uses DC ZVA instruction unconditionally. But it should make sure that DCZID_EL0.DZP, which indicates whether or not use of DC ZVA instruction is prohibited, is zero when using the instruction. Use STNP instead when DCZID_EL0.DZP == 1. Fixes: f27bb139c387 ("arm64: Miscellaneous library functions") Signed-off-by: Reiji Watanabe <[email protected]> Reviewed-by: Robin Murphy <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Catalin Marinas <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 33fcd00e0aa04b1efbf3b4b09153560a0dab3176 Author: Kajol Jain <[email protected]> Date: Mon Dec 6 13:03:15 2021 +0530 bpf: Remove config check to enable bpf support for branch records [ Upstream commit db52f57211b4e45f0ebb274e2c877b211dc18591 ] Branch data available to BPF programs can be very useful to get stack traces out of userspace application. Commit fff7b64355ea ("bpf: Add bpf_read_branch_records() helper") added BPF support to capture branch records in x86. Enable this feature also for other architectures as well by removing checks specific to x86. If an architecture doesn't support branch records, bpf_read_branch_records() still has appropriate checks and it will return an -EINVAL in that scenario. Based on UAPI helper doc in include/uapi/linux/bpf.h, unsupported architectures should return -ENOENT in such case. Hence, update the appropriate check to return -ENOENT instead. Selftest 'perf_branches' result on power9 machine which has the branch stacks support: - Before this patch: [command]# ./test_progs -t perf_branches #88/1 perf_branches/perf_branches_hw:FAIL #88/2 perf_branches/perf_branches_no_hw:OK #88 perf_branches:FAIL Summary: 0/1 PASSED, 0 SKIPPED, 1 FAILED - After this patch: [command]# ./test_progs -t perf_branches #88/1 perf_branches/perf_branches_hw:OK #88/2 perf_branches/perf_branches_no_hw:OK #88 perf_branches:OK Summary: 1/2 PASSED, 0 SKIPPED, 0 FAILED Selftest 'perf_branches' result on power9 machine which doesn't have branch stack report: - After this patch: [command]# ./test_progs -t perf_branches #88/1 perf_branches/perf_branches_hw:SKIP #88/2 perf_branches/perf_branches_no_hw:OK #88 perf_branches:OK Summary: 1/1 PASSED, 1 SKIPPED, 0 FAILED Fixes: fff7b64355eac ("bpf: Add bpf_read_branch_records() helper") Suggested-by: Peter Zijlstra <[email protected]> Signed-off-by: Kajol Jain <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 832d478ccd06a0cff33e942b2e6baf159f8a1d85 Author: Hou Tao <[email protected]> Date: Fri Dec 3 13:30:01 2021 +0800 bpf: Disallow BPF_LOG_KERNEL log level for bpf(BPF_BTF_LOAD) [ Upstream commit 866de407444398bc8140ea70de1dba5f91cc34ac ] BPF_LOG_KERNEL is only used internally, so disallow bpf_btf_load() to set log level as BPF_LOG_KERNEL. The same checking has already been done in bpf_check(), so factor out a helper to check the validity of log attributes and use it in both places. Fixes: 8580ac9404f6 ("bpf: Process in-kernel BTF") Signed-off-by: Hou Tao <[email protected]> Signed-off-by: Alexei Starovoitov <[email protected]> Acked-by: Yonghong Song <[email protected]> Acked-by: Martin KaFai Lau <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 2571173d3e115c4a79875ae6d820b5986d861004 Author: Alexei Starovoitov <[email protected]> Date: Wed Dec 1 10:10:29 2021 -0800 bpf: Adjust BTF log size limit. [ Upstream commit c5a2d43e998a821701029f23e25b62f9188e93ff ] Make BTF log size limit to be the same as the verifier log size limit. Otherwise tools that progressively increase log size and use the same log for BTF loading and program loading will be hitting hard to debug EINVAL. Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit d3c4b3c801c0f13deef2b04d7d93dac338dd9552 Author: Vincent Donnefort <[email protected]> Date: Mon Nov 29 17:31:15 2021 +0000 sched/fair: Fix per-CPU kthread and wakee stacking for asym CPU capacity [ Upstream commit 014ba44e8184e1acf93e0cbb7089ee847802f8f0 ] select_idle_sibling() has a special case for tasks woken up by a per-CPU kthread where the selected CPU is the previous one. For asymmetric CPU capacity systems, the assumption was that the wakee couldn't have a bigger utilization during task placement than it used to have during the last activation. That was not considering uclamp.min which can completely change between two task activations and as a consequence mandates the fitness criterion asym_fits_capacity(), even for the exit path described above. Fixes: b4c9c9f15649 ("sched/fair: Prefer prev cpu in asymmetric wakeup path") Signed-off-by: Vincent Donnefort <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Valentin Schneider <[email protected]> Reviewed-by: Dietmar Eggemann <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 00c10519538fd739312a9ee3acdee264873e126e Author: Vincent Donnefort <[email protected]> Date: Wed Dec 1 14:34:50 2021 +0000 sched/fair: Fix detection of per-CPU kthreads waking a task [ Upstream commit 8b4e74ccb582797f6f0b0a50372ebd9fd2372a27 ] select_idle_sibling() has a special case for tasks woken up by a per-CPU kthread, where the selected CPU is the previous one. However, the current condition for this exit path is incomplete. A task can wake up from an interrupt context (e.g. hrtimer), while a per-CPU kthread is running. A such scenario would spuriously trigger the special case described above. Also, a recent change made the idle task like a regular per-CPU kthread, hence making that situation more likely to happen (is_per_cpu_kthread(swapper) being true now). Checking for task context makes sure select_idle_sibling() will not interpret a wake up from any other context as a wake up by a per-CPU kthread. Fixes: 52262ee567ad ("sched/fair: Allow a per-CPU kthread waking a task to stack on the same CPU, to fix XFS performance regression") Signed-off-by: Vincent Donnefort <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Vincent Guittot <[email protected]> Reviewed-by: Valentin Schneider <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 48419bc90e4399ded6e6a2f3d0fbdf9faf40a308 Author: Maxim Mikityanskiy <[email protected]> Date: Tue Nov 30 20:18:11 2021 +0200 bpf: Fix the test_task_vma selftest to support output shorter than 1 kB [ Upstream commit da54ab14953c38d98cb3e34c564c06c3739394b2 ] The test for bpf_iter_task_vma assumes that the output will be longer than 1 kB, as the comment above the loop says. Due to this assumption, the loop becomes infinite if the output turns to be shorter than 1 kB. The return value of read_fd_into_buffer is 0 when the end of file was reached, and len isn't being increased any more. This commit adds a break on EOF to handle short output correctly. For the reference, this is the contents that I get when running test_progs under vmtest.sh, and it's shorter than 1 kB: 00400000-00401000 r--p 00000000 fe:00 25867 /root/bpf/test_progs 00401000-00674000 r-xp 00001000 fe:00 25867 /root/bpf/test_progs 00674000-0095f000 r--p 00274000 fe:00 25867 /root/bpf/test_progs 0095f000-00983000 r--p 0055e000 fe:00 25867 /root/bpf/test_progs 00983000-00a8a000 rw-p 00582000 fe:00 25867 /root/bpf/test_progs 00a8a000-0484e000 rw-p 00000000 00:00 0 7f6c64000000-7f6c64021000 rw-p 00000000 00:00 0 7f6c64021000-7f6c68000000 ---p 00000000 00:00 0 7f6c6ac8f000-7f6c6ac90000 r--s 00000000 00:0d 8032 anon_inode:bpf-map 7f6c6ac90000-7f6c6ac91000 ---p 00000000 00:00 0 7f6c6ac91000-7f6c6b491000 rw-p 00000000 00:00 0 7f6c6b491000-7f6c6b492000 r--s 00000000 00:0d 8032 anon_inode:bpf-map 7f6c6b492000-7f6c6b493000 rw-s 00000000 00:0d 8032 anon_inode:bpf-map 7ffc1e23d000-7ffc1e25e000 rw-p 00000000 00:00 0 7ffc1e3b8000-7ffc1e3bc000 r--p 00000000 00:00 0 7ffc1e3bc000-7ffc1e3bd000 r-xp 00000000 00:00 0 7fffffffe000-7ffffffff000 --xp 00000000 00:00 0 Fixes: e8168840e16c ("selftests/bpf: Add test for bpf_iter_task_vma") Signed-off-by: Maxim Mikityanskiy <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 35a89caf518ef60941a05ed8a78d36dbfc0f3917 Author: Sean Wang <[email protected]> Date: Thu Dec 2 02:02:47 2021 +0800 Bluetooth: btmtksdio: fix resume failure [ Upstream commit 561ae1d46a8ddcbc13162d5771f5ed6c8249e730 ] btmtksdio have to rely on MMC_PM_KEEP_POWER in pm_flags to avoid that SDIO power is being shut off during the device is in suspend. That fixes the SDIO command fails to access the bus after the device is resumed. Fixes: 7f3c563c575e7 ("Bluetooth: btmtksdio: Add runtime PM support to SDIO based Bluetooth") Co-developed-by: Mark-yw Chen <[email protected]> Signed-off-by: Mark-yw Chen <[email protected]> Signed-off-by: Sean Wang <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 0cad9c0c81bee687b92d5b2753a0fd7cf47d9383 Author: Yang Yingliang <[email protected]> Date: Thu Dec 2 11:07:03 2021 +0800 staging: rtl8192e: rtllib_module: fix error handle case in alloc_rtllib() [ Upstream commit e730cd57ac2dfe94bca0f14a3be8e1b21de41a9c ] Some variables are leaked in the error handling in alloc_rtllib(), free the variables in the error path. Fixes: 94a799425eee ("From: wlanfae <[email protected]>") Reviewed-by: Dan Carpenter <[email protected]> Reviewed-by: Pavel Skripkin <[email protected]> Signed-off-by: Yang Yingliang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 90d96a14c558b3c7ada219a4029fad29214a4657 Author: Yang Yingliang <[email protected]> Date: Thu Dec 2 11:07:02 2021 +0800 staging: rtl8192e: return error code from rtllib_softmac_init() [ Upstream commit 68bf78ff59a0891eb1239948e94ce10f73a9dd30 ] If it fails to allocate 'dot11d_info', rtllib_softmac_init() should return error code. And remove unneccessary error message. Fixes: 94a799425eee ("From: wlanfae <[email protected]>") Reviewed-by: Dan Carpenter <[email protected]> Reviewed-by: Pavel Skripkin <[email protected]> Signed-off-by: Yang Yingliang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit ff732e9bf68b07fb73d449dacce11e632670e1ae Author: Tasos Sahanidis <[email protected]> Date: Fri Sep 3 09:47:58 2021 +0300 floppy: Fix hang in watchdog when disk is ejected [ Upstream commit fb48febce7e30baed94dd791e19521abd2c3fd83 ] When the watchdog detects a disk change, it calls cancel_activity(), which in turn tries to cancel the fd_timer delayed work. In the above scenario, fd_timer_fn is set to fd_watchdog(), meaning it is trying to cancel its own work. This results in a hang as cancel_delayed_work_sync() is waiting for the watchdog (itself) to return, which never happens. This can be reproduced relatively consistently by attempting to read a broken floppy, and ejecting it while IO is being attempted and retried. To resolve this, this patch calls cancel_delayed_work() instead, which cancels the work without waiting for the watchdog to return and finish. Before this regression was introduced, the code in this section used del_timer(), and not del_timer_sync() to delete the watchdog timer. Link: https://lore.kernel.org/r/[email protected] Fixes: 070ad7e793dc ("floppy: convert to delayed work and single-thread wq") Signed-off-by: Tasos Sahanidis <[email protected]> Signed-off-by: Denis Efremov <[email protected]> Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 31d60f528238797fbb5afd6bbb695528496d31d3 Author: Michael Walle <[email protected]> Date: Thu Nov 4 14:48:43 2021 +0100 mtd: core: provide unique name for nvmem device [ Upstream commit c048b60d39e109c201d31ed5ad3a4f939064d6c4 ] If there is more than one mtd device which supports OTP, there will be a kernel warning about duplicated sysfs entries and the probing will fail. This is because the nvmem device name is not unique. Make it unique by prepending the name of the mtd. E.g. before the name was "user-otp", now it will be "mtd0-user-otp". For reference the kernel splash is: [ 4.665531] sysfs: cannot create duplicate filename '/bus/nvmem/devices/user-otp' [ 4.673056] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.0-next-20211101+ #1296 [ 4.680565] Hardware name: Kontron SMARC-sAL28 (Single PHY) on SMARC Eval 2.0 carrier (DT) [ 4.688856] Call trace: [ 4.691303] dump_backtrace+0x0/0x1bc [ 4.694984] show_stack+0x24/0x30 [ 4.698306] dump_stack_lvl+0x68/0x84 [ 4.701980] dump_stack+0x18/0x34 [ 4.705302] sysfs_warn_dup+0x70/0x90 [ 4.708973] sysfs_do_create_link_sd+0x144/0x150 [ 4.713603] sysfs_create_link+0x2c/0x50 [ 4.717535] bus_add_device+0x74/0x120 [ 4.721293] device_add+0x330/0x890 [ 4.724791] device_register+0x2c/0x40 [ 4.728550] nvmem_register+0x240/0x9f0 [ 4.732398] mtd_otp_nvmem_register+0xb0/0x10c [ 4.736854] mtd_device_parse_register+0x28c/0x2b4 [ 4.741659] spi_nor_probe+0x20c/0x2e0 [ 4.745418] spi_mem_probe+0x78/0xbc [ 4.749001] spi_probe+0x90/0xf0 [ 4.752237] really_probe.part.0+0xa4/0x320 .. [ 4.873936] mtd mtd1: Failed to register OTP NVMEM device [ 4.894468] spi-nor: probe of spi0.0 failed with error -17 Fixes: 4b361cfa8624 ("mtd: core: add OTP nvmem provider support") Signed-off-by: Michael Walle <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Link: https://lore.kernel.org/linux-mtd/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit aee7ef0305b1cfefbdb44732e001072cc10975b2 Author: Lino Sanfilippo <[email protected]> Date: Mon Nov 29 18:42:38 2021 +0100 serial: amba-pl011: do not request memory region twice [ Upstream commit d1180405c7b5c7a1c6bde79d5fc24fe931430737 ] With commit 3873e2d7f63a ("drivers: PL011: refactor pl011_probe()") the function devm_ioremap() called from pl011_setup_port() was replaced with devm_ioremap_resource(). Since this function not only remaps but also requests the ports io memory region it now collides with the .config_port() callback which requests the same region at uart port registration. Since devm_ioremap_resource() already claims the memory successfully, the request in .config_port() fails. Later at uart port deregistration the attempt to release the unclaimed memory also fails. The failure results in a “Trying to free nonexistent resource" warning. Fix these issues by removing the callbacks that implement the redundant memory allocation/release. Also make sure that changing the drivers io memory base address via TIOCSSERIAL is not allowed any more. Fixes: 3873e2d7f63a ("drivers: PL011: refactor pl011_probe()") Signed-off-by: Lino Sanfilippo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 7b54c975798d10199021548210f5934feafad2d3 Author: Lizhi Hou <[email protected]> Date: Mon Nov 29 12:23:02 2021 -0800 tty: serial: uartlite: allow 64 bit address [ Upstream commit 3672fb65155530b5eea6225685c75329b6debec3 ] The base address of uartlite registers could be 64 bit address which is from device resource. When ulite_probe() calls ulite_assign(), this 64 bit address is casted to 32-bit. The fix is to replace "u32" type with "phys_addr_t" type for the base address in ulite_assign() argument list. Fixes: 8fa7b6100693 ("[POWERPC] Uartlite: Separate the bus binding from the driver proper") Signed-off-by: Lizhi Hou <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit aca61190ec82fd94fc88a3e4726aad265c7ed4b9 Author: Nishanth Menon <[email protected]> Date: Fri Nov 12 22:26:40 2021 -0600 arm64: dts: ti: k3-j7200: Correct the d-cache-sets info [ Upstream commit a172c86931709d6663318609d71a811333bdf4b0 ] A72 Cluster (chapter 1.3.1 [1]) has 48KB Icache, 32KB Dcache and 1MB L2 Cache - ICache is 3-way set-associative - Dcache is 2-way set-associative - Line size are 64bytes 32KB (Dcache)/64 (fixed line length of 64 bytes) = 512 ways 512 ways / 2 (Dcache is 2-way per set) = 256 sets. So, correct the d-cache-sets info. [1] https://www.ti.com/lit/pdf/spruiu1 Fixes: d361ed88455f ("arm64: dts: ti: Add support for J7200 SoC") Reported-by: Peng Fan <[email protected]> Signed-off-by: Nishanth Menon <[email protected]> Reviewed-by: Pratyush Yadav <[email protected]> Reviewed-by: Kishon Vijay Abraham I <[email protected]> Signed-off-by: Vignesh Raghavendra <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 1e2847f9d910ad513f40d9d998f4797caa1ce895 Author: Nishanth Menon <[email protected]> Date: Fri Nov 12 22:36:39 2021 -0600 arm64: dts: ti: k3-j721e: Fix the L2 cache sets [ Upstream commit e9ba3a5bc6fdc2c796c69fdaf5ed6c9957cf9f9d ] A72's L2 cache[1] on J721e[2] is 1MB. A72's L2 is fixed line length of 64 bytes and 16-way set-associative cache structure. 1MB of L2 / 64 (line length) = 16384 ways 16384 ways / 16 = 1024 sets Fix the l2 cache-sets. [1] https://developer.arm.com/documentation/100095/0003/Level-2-Memory-System/About-the-L2-memory-system [2] http://www.ti.com/lit/pdf/spruil1 Fixes: 2d87061e70de ("arm64: dts: ti: Add Support for J721E SoC") Reported-by: Peng Fan <[email protected]> Signed-off-by: Nishanth Menon <[email protected]> Reviewed-by: Pratyush Yadav <[email protected]> Signed-off-by: Vignesh Raghavendra <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit f1f0039956fb43af9443c14a5a53a9e364663368 Author: Nishanth Menon <[email protected]> Date: Fri Nov 12 22:36:38 2021 -0600 arm64: dts: ti: k3-j7200: Fix the L2 cache sets [ Upstream commit d0c826106f3fc11ff97285102b576b65576654ae ] A72's L2 cache[1] on J7200[2] is 1MB. A72's L2 is fixed line length of 64 bytes and 16-way set-associative cache structure. 1MB of L2 / 64 (line length) = 16384 ways 16384 ways / 16 = 1024 sets Fix the l2 cache-sets. [1] https://developer.arm.com/documentation/100095/0003/Level-2-Memory-System/About-the-L2-memory-system [2] https://www.ti.com/lit/pdf/spruiu1 Fixes: d361ed88455f ("arm64: dts: ti: Add support for J7200 SoC") Reported-by: Peng Fan <[email protected]> Signed-off-by: Nishanth Menon <[email protected]> Reviewed-by: Pratyush Yadav <[email protected]> Signed-off-by: Vignesh Raghavendra <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 10d3b165877fabb63e4095302f87dcf11441f3d3 Author: Nishanth Menon <[email protected]> Date: Fri Nov 12 22:36:35 2021 -0600 arm64: dts: ti: k3-am642: Fix the L2 cache sets [ Upstream commit a27a93bf70045be54b594fa8482959ffb84166d7 ] A53's L2 cache[1] on AM642[2] is 256KB. A53's L2 is fixed line length of 64 bytes and 16-way set-associative cache structure. 256KB of L2 / 64 (line length) = 4096 ways 4096 ways / 16 = 256 sets Fix the l2 cache-sets. [1] https://developer.arm.com/documentation/ddi0500/j/Level-2-Memory-System/About-the-L2-memory-system?lang=en [2] https://www.ti.com/lit/pdf/spruim2 Fixes: 8abae9389bdb ("arm64: dts: ti: Add support for AM642 SoC") Reported-by: Peng Fan <[email protected]> Signed-off-by: Nishanth Menon <[email protected]> Reviewed-by: Pratyush Yadav <[email protected]> Signed-off-by: Vignesh Raghavendra <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 2efa4dd4600d68cca61bcc6372fa79419434bebb Author: Gaurav Jain <[email protected]> Date: Mon Nov 22 17:02:34 2021 +0530 crypto: caam - save caam memory to support crypto engine retry mechanism. [ Upstream commit 087e1d715bccf25dc0e83294576e416b0386ba20 ] When caam queue is full (-ENOSPC), caam frees descriptor memory. crypto-engine checks if retry support is true and h/w queue is full(-ENOSPC), then requeue the crypto request. During processing the requested descriptor again, caam gives below error. (caam_jr 30902000.jr: 40000006: DECO: desc idx 0: Invalid KEY Command). This patch adds a check to return when caam input ring is full and retry support is true. so descriptor memory is not freed and requeued request can be processed again. Fixes: 2d653936eb2cf ("crypto: caam - enable crypto-engine retry mechanism") Signed-off-by: Gaurav Jain <[email protected]> Reviewed-by: Horia Geantă <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit db3c2121d191ab82d68d54c02f6e90aeac33226f Author: Alexei Starovoitov <[email protected]> Date: Wed Dec 1 10:10:34 2021 -0800 libbpf: Clean gen_loader's attach kind. [ Upstream commit 19250f5fc0c283892a61f3abf9d65e6325f63897 ] The gen_loader has to clear attach_kind otherwise the programs without attach_btf_id will fail load if they follow programs with attach_btf_id. Fixes: 67234743736a ("libbpf: Generate loader program out of BPF ELF file.") Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]> Acked-by: Andrii Nakryiko <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit e833ef0b545e1a5b3eaf00af391c4fd1fb47ffd8 Author: Zhou Qingyang <[email protected]> Date: Wed Dec 1 23:13:10 2021 +0800 drm/radeon/radeon_kms: Fix a NULL pointer dereference in radeon_driver_open_kms() [ Upstream commit ab50cb9df8896b39aae65c537a30de2c79c19735 ] In radeon_driver_open_kms(), radeon_vm_bo_add() is assigned to vm->ib_bo_va and passes and used in radeon_vm_bo_set_addr(). In radeon_vm_bo_set_addr(), there is a dereference of vm->ib_bo_va, which could lead to a NULL pointer dereference on failure of radeon_vm_bo_add(). Fix this bug by adding a check of vm->ib_bo_va. This bug was found by a static analyzer. The analysis employs differential checking to identify inconsistent security operations (e.g., checks or kfrees) between two code paths and confirms that the inconsistent operations are not recovered in the current function or the callers, so they constitute bugs. Note that, as a bug found by static analysis, it can be a false positive or hard to trigger. Multiple researchers have cross-reviewed the bug. Builds with CONFIG_DRM_RADEON=m show no new warnings, and our static analyzer no longer warns about this code. Fixes: cc9e67e3d700 ("drm/radeon: fix VM IB handling") Reviewed-by: Christian König <[email protected]> Signed-off-by: Zhou Qingyang <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 1e22b51876fa786c0b972e327ffb5cc686873cd1 Author: Zhou Qingyang <[email protected]> Date: Fri Dec 3 00:17:36 2021 +0800 drm/amdgpu: Fix a NULL pointer dereference in amdgpu_connector_lcd_native_mode() [ Upstream commit b220110e4cd442156f36e1d9b4914bb9e87b0d00 ] In amdgpu_connector_lcd_native_mode(), the return value of drm_mode_duplicate() is assigned to mode, and there is a dereference of it in amdgpu_connector_lcd_native_mode(), which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Fix this bug add a check of mode. This bug was found by a static analyzer. The analysis employs differential checking to identify inconsistent security operations (e.g., checks or kfrees) between two code paths and confirms that the inconsistent operations are not recovered in the current function or the callers, so they constitute bugs. Note that, as a bug found by static analysis, it can be a false positive or hard to trigger. Multiple researchers have cross-reviewed the bug. Builds with CONFIG_DRM_AMDGPU=m show no new warnings, and our static analyzer no longer warns about this code. Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)") Signed-off-by: Zhou Qingyang <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 4c12feec2dfde62dea8dabe1d2dd78ee340ba048 Author: Paul Gerber <[email protected]> Date: Mon Nov 22 12:42:25 2021 +0100 thermal/drivers/imx8mm: Enable ADC when enabling monitor [ Upstream commit 3de89d8842a2b5d3dd22ebf97dd561ae0a330948 ] The i.MX 8MP has a ADC_PD bit in the TMU_TER register that controls the operating mode of the ADC: * 0 means normal operating mode * 1 means power down mode When enabling/disabling the TMU, the ADC operating mode must be set accordingly. i.MX 8M Mini & Nano are lacking this bit. Signed-off-by: Paul Gerber <[email protected]> Signed-off-by: Alexander Stein <[email protected]> Fixes: 2b8f1f0337c5 ("thermal: imx8mm: Add i.MX8MP support") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Daniel Lezcano <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 68bf3b2f95ee9338722c133d0f7de64be85d6fdf Author: Rafael J. Wysocki <[email protected]> Date: Tue Nov 23 19:36:51 2021 +0100 ACPI: EC: Rework flushing of EC work while suspended to idle [ Upstream commit 4a9af6cac050dce2e895ec3205c4615383ad9112 ] The flushing of pending work in the EC driver uses drain_workqueue() to flush the event handling work that can requeue itself via advance_transaction(), but this is problematic, because that work may also be requeued from the query workqueue. Namely, if an EC transaction is carried out during the execution of a query handler, it involves calling advance_transaction() which may queue up the event handling work again. This causes the kernel to complain about attempts to add a work item to the EC event workqueue while it is being drained and worst-case it may cause a valid event to be skipped. To avoid this problem, introduce two new counters, events_in_progress and queries_in_progress, incremented when a work item is queued on the event workqueue or the query workqueue, respectively, and decremented at the end of the corresponding work function, and make acpi_ec_dispatch_gpe() the workqueues in a loop until the both of these counters are zero (or system wakeup is pending) instead of calling acpi_ec_flush_work(). At the same time, change __acpi_ec_flush_work() to call flush_workqueue() instead of drain_workqueue() to flush the event workqueue. While at it, use the observation that the work item queued in acpi_ec_query() cannot be pending at that time, because it is used only once, to simplify the code in there. Additionally, clean up a comment in acpi_ec_query() and adjust white space in acpi_ec_event_processor(). Fixes: f0ac20c3f613 ("ACPI: EC: Fix flushing of pending work") Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 1fb3838db45cd5f3ce62dcd58df85f26dbec6149 Author: William Kucharski <[email protected]> Date: Wed Dec 1 09:56:58 2021 -0700 cgroup: Trace event cgroup id fields should be u64 [ Upstream commit e14da77113bb890d7bf9e5d17031bdd476a7ce5e ] Various trace event fields that store cgroup IDs were declared as ints, but cgroup_id(() returns a u64 and the structures and associated TP_printk() calls were not updated to reflect this. Fixes: 743210386c03 ("cgroup: use cgrp->kn->id as the cgroup ID") Signed-off-by: William Kucharski <[email protected]> Reviewed-by: Steven Rostedt (VMware) <[email protected]> Signed-off-by: Tejun Heo <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 2d93f960dc7e05c54bc5d3d7edcc0f4ee57e7006 Author: Zack Rusin <[email protected]> Date: Fri Nov 5 15:38:44 2021 -0400 drm/vmwgfx: Fail to initialize on broken configs [ Upstream commit c451af78f301ff5156998d571c37cab329c10051 ] Some of our hosts have a bug where rescaning a pci bus results in stale fifo memory being mapped on the host. This makes any fifo communication impossible resulting in various kernel crashes. Instead of unexpectedly crashing, predictably fail to load the driver which will preserve the system. Fixes: fb1d9738ca05 ("drm/vmwgfx: Add DRM driver for VMware Virtual GPU") Signed-off-by: Zack Rusin <[email protected]> Reviewed-by: Martin Krastev <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit a6f53731f3bbecf8e2abdc4fcca8caf849009d7c Author: Zack Rusin <[email protected]> Date: Fri Nov 5 15:38:42 2021 -0400 drm/vmwgfx: Remove the deprecated lower mem limit [ Upstream commit 826c387d015247df396a91eadbaca94f0394853c ] TTM during the transition to the new page allocator lost the ability to constrain the allocations via the lower_mem_limit. The code has been unused since the change: 256dd44bd897 ("drm/ttm: nuke old page allocator") and there's no reason to keep it. Fixes: 256dd44bd897 ("drm/ttm: nuke old page allocator") Signed-off-by: Zack Rusin <[email protected]> Reviewed-by: Martin Krastev <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 4aa40bf38f716b0ad0d7f890d3f299066e82c7e0 Author: Dmitry Baryshkov <[email protected]> Date: Wed Dec 1 05:05:59 2021 +0300 arm64: dts: qcom: msm8916: fix MMC controller aliases [ Upstream commit b0293c19d42f6d6951c2fab9a47fed50baf2c14d ] Change sdhcN aliases to mmcN to make them actually work. Currently the board uses non-standard aliases sdhcN, which do not work, resulting in mmc0 and mmc1 hosts randomly changing indices between boots. Fixes: c4da5a561627 ("arm64: dts: qcom: Add msm8916 sdhci configuration nodes") Signed-off-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 0c1cf578a8822cc1a92c955b87a4b2cd27caed9a Author: Mark Rutland <[email protected]> Date: Mon Nov 29 13:06:51 2021 +0000 powerpc: Avoid discarding flags in system_call_exception() [ Upstream commit 08b0af5b2affbe7419853e8dd1330e4b3fe27125 ] Some thread flags can be set remotely, and so even when IRQs are disabled, the flags can change under our feet. Thus, when setting flags we must use an atomic operation rather than a plain read-modify-write sequence, as a plain read-modify-write may discard flags which are concurrently set by a remote thread, e.g. // task A // task B tmp = A->thread_info.flags; set_tsk_thread_flag(A, NEWFLAG_B); tmp |= NEWFLAG_A; A->thread_info.flags = tmp; arch/powerpc/kernel/interrupt.c's system_call_exception() sets _TIF_RESTOREALL in the thread info flags with a read-modify-write, which may result in other flags being discarded. Elsewhere in the file it uses clear_bits() to atomically remove flag bits, so use set_bits() here for consistency with those. There may be reasons (e.g. instrumentation) that prevent the use of set_thread_flag() and clear_thread_flag() here, which would otherwise be preferable. Fixes: ae7aaecc3f2f78b7 ("powerpc/64s: system call rfscv workaround for TM bugs") Signed-off-by: Mark Rutland <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Cc: Eirik Fuller <[email protected]> Cc: Michael Ellerman <[email protected]> Cc: Nicholas Piggin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit f38d669aab337e496e803d56ab22d09b309a902f Author: Florian Westphal <[email protected]> Date: Tue Nov 23 12:50:31 2021 +0100 netfilter: bridge: add support for pppoe filtering [ Upstream commit 28b78ecffea8078d81466b2e01bb5a154509f1ba ] This makes 'bridge-nf-filter-pppoe-tagged' sysctl work for bridged traffic. Looking at the original commit it doesn't appear this ever worked: static unsigned int br_nf_post_routing(unsigned int hook, struct sk_buff **pskb, [..] if (skb->protocol == htons(ETH_P_8021Q)) { skb_pull(skb, VLAN_HLEN); skb->network_header += VLAN_HLEN; + } else if (skb->protocol == htons(ETH_P_PPP_SES)) { + skb_pull(skb, PPPOE_SES_HLEN); + skb->network_header += PPPOE_SES_HLEN; } [..] NF_HOOK(... POST_ROUTING, ...) ... but the adjusted offsets are never restored. The alternative would be to rip this code out for good, but otoh we'd have to keep this anyway for the vlan handling (which works because vlan tag info is in the skb, not the packet payload). Reported-and-tested-by: Amish Chana <[email protected]> Fixes: 516299d2f5b6f97 ("[NETFILTER]: bridge-nf: filter bridged IPv4/IPv6 encapsulated in pppoe traffic") Signed-off-by: Florian Westphal <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 3f32b8ca8e26a8cffc08ee3e9235c675f5931c0e Author: Jesper Dangaard Brouer <[email protected]> Date: Mon Nov 15 21:36:25 2021 +0100 igc: AF_XDP zero-copy metadata adjust breaks SKBs on XDP_PASS [ Upstream commit 4fa8fcd3440101dbacf4fae91de69877ef751977 ] Driver already implicitly supports XDP metadata access in AF_XDP zero-copy mode, as xsk_buff_pool's xp_alloc() naturally set xdp_buff data_meta equal data. This works fine for XDP and AF_XDP, but if a BPF-prog adjust via bpf_xdp_adjust_meta() and choose to call XDP_PASS, then igc function igc_construct_skb_zc() will construct an invalid SKB packet. The function correctly include the xdp->data_meta area in the memcpy, but forgot to pull header to take metasize into account. Fixes: fc9df2a0b520 ("igc: Enable RX via AF_XDP zero-copy") Signed-off-by: Jesper Dangaard Brouer <[email protected]> Tested-by: Nechama Kraus <[email protected]> Acked-by: Maciej Fijalkowski <[email protected]> Signed-off-by: Tony Nguyen <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 94821ce188c2b37551ee9bdcfa282801e736207f Author: Oleksij Rempel <[email protected]> Date: Wed Nov 17 11:34:26 2021 +0100 thermal/drivers/imx: Implement runtime PM support [ Upstream commit 4cf2ddf16e175ee18c5c29865c32da7d6269cf44 ] Starting with commit d92ed2c9d3ff ("thermal: imx: Use driver's local data to decide whether to run a measurement") this driver stared using irq_enabled flag to make decision to power on/off the thermal core. This triggered a regression, where after reaching critical temperature, alarm IRQ handler set irq_enabled to false, disabled thermal core and was not able read temperature and disable cooling sequence. In case the cooling device is "CPU/GPU freq", the system will run with reduce performance until next reboot. To solve this issue, we need to move all parts implementing hand made runtime power management and let it handle actual runtime PM framework. Fixes: d92ed2c9d3ff ("thermal: imx: Use driver's local data to decide whether to run a measurement") Signed-off-by: Oleksij Rempel <[email protected]> Tested-by: Petr Beneš <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Daniel Lezcano <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit b588858c09a5c4a894cbbf974e7ae1d6c72469df Author: Bhupesh Sharma <[email protected]> Date: Mon Nov 29 01:28:54 2021 +0530 net: stmmac: Add platform level debug register dump feature [ Upstream commit 4047b9db1aa7512a10ba3560a3f63821c8c40235 ] dwmac-qcom-ethqos currently exposes a mechanism to dump rgmii registers after the 'stmmac_dvr_probe()' returns. However with commit 5ec55823438e ("net: stmmac: add clocks management for gmac driver"), we now let 'pm_runtime_put()' disable the clocks before returning from 'stmmac_dvr_probe()'. This causes a crash when 'rgmii_dump()' register dumps are enabled, as the clocks are already off. Since other dwmac drivers (possible future users as well) might require a similar register dump feature, introduce a platform level callback to allow the same. This fixes the crash noticed while enabling rgmii_dump() dumps in dwmac-qcom-ethqos driver as well. It also allows future changes to keep a invoking the register dump callback from the correct place inside 'stmmac_dvr_probe()'. Fixes: 5ec55823438e ("net: stmmac: add clocks management for gmac driver") Cc: Joakim Zhang <[email protected]> Cc: David S. Miller <[email protected]> Signed-off-by: Bhupesh Sharma <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 0bc65fcb2b8909de9996319102ea97f5337d67ca Author: Christophe JAILLET <[email protected]> Date: Thu Aug 19 22:05:28 2021 +0200 media: venus: core: Fix a resource leak in the error handling path of 'venus_probe()' [ Upstream commit 8cc7a1b2aca067397a016cdb971a5e6ad9b640c7 ] A successful 'of_platform_populate()' call should be balanced by a corresponding 'of_platform_depopulate()' call in the error handling path of the probe, as already done in the remove function. A successful 'venus_firmware_init()' call should be balanced by a corresponding 'venus_firmware_deinit()' call in the error handling path of the probe, as already done in the remove function. Update the error handling path accordingly. Fixes: f9799fcce4bb ("media: venus: firmware: register separate platform_device for firmware loader") Signed-off-by: Christophe JAILLET <[email protected]> Signed-off-by: Stanimir Varbanov <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 4a8a8ff652930515ba209d86b0a2756ea8b0384c Author: Christophe JAILLET <[email protected]> Date: Thu Aug 12 07:14:22 2021 +0200 media: venus: core: Fix a potential NULL pointer dereference in an error handling path [ Upstream commit e4debea9be7d5db52bc6a565a4c02c3c6560d093 ] The normal path of the function makes the assumption that 'pm_ops->core_power' may be NULL. We should make the same assumption in the error handling path or a NULL pointer dereference may occur. Add the missing test before calling 'pm_ops->core_power' Fixes: 9e8efdb57879 ("media: venus: core: vote for video-mem path") Signed-off-by: Christophe JAILLET <[email protected]> Signed-off-by: Stanimir Varbanov <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit e0d8c693a9d2884ab62ad5ee85abebf9418bdf2e Author: Mansur Alisha Shaik <[email protected]> Date: Wed Oct 27 08:21:12 2021 +0200 media: venus: correct low power frequency calculation for encoder [ Upstream commit b1f9bb8020783a48151e3a2864fbdc70548566dd ] In exististing implimentation, in min_loaded_core() for low_power vpp frequency value is considering as vpp_freq instead of low_power_freq. Fixed this by correcting vpp frequency calculation for encoder. Fixes: 3cfe5815ce0e (media: venus: Enable low power setting for encoder) Signed-off-by: Mansur Alisha Shaik <[email protected]> Signed-off-by: Stanimir Varbanov <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 64bfc5673415c1a11a8bb056f43412d6b7bef61b Author: Philipp Zabel <[email protected]> Date: Fri Nov 19 11:41:20 2021 +0100 media: coda: fix CODA960 JPEG encoder buffer overflow [ Upstream commit 1a59cd88f55068710f6549bee548846661673780 ] Stop the CODA960 JPEG encoder from overflowing capture buffers. The bitstream buffer overflow interrupt doesn't seem to be connected, so this has to be handled via timeout instead. Reported-by: Martin Weber <[email protected]> Fixes: 96f6f62c4656 ("media: coda: jpeg: add CODA960 JPEG encoder support") Tested-by: Martin Weber <[email protected]> Signed-off-by: Philipp Zabel <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit b85906f919ea2eab27f87a1738cc4639d594d66f Author: Chen-Yu Tsai <[email protected]> Date: Fri Nov 19 08:46:54 2021 +0100 media: hantro: Hook up RK3399 JPEG encoder output [ Upstream commit 230d683ae04894933720425c8dead9508a09ebc3 ] The JPEG encoder found in the Hantro H1 encoder block only produces a raw entropy-encoded scan. The driver is responsible for building a JPEG compliant bitstream and placing the entropy-encoded scan in it. Right now the driver uses a bounce buffer for the hardware to output the raw scan to. In commit e765dba11ec2 ("hantro: Move hantro_enc_buf_finish to JPEG codec_ops.done"), the code that copies the raw scan from the bounce buffer to the capture buffer was moved, but was only hooked up for the Hantro H1 (then RK3288) variant. The RK3399 variant was broken, producing a JPEG bitstream without the scan, and the capture buffer's .bytesused field unset. Fix this by duplicating the code that is executed when the JPEG encoder finishes encoding a frame. As the encoded length is read back from hardware, and the variants having different register layouts, the code is duplicated rather than shared. Fixes: e765dba11ec2 ("hantro: Move hantro_enc_buf_finish to JPEG codec_ops.done") Signed-off-by: Chen-Yu Tsai <[email protected]> Tested-by: Nicolas Dufresne <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit a49171d86d5e8ca237a30c8443f9eda6542ddcbf Author: Dafna Hirschfeld <[email protected]> Date: Wed Nov 17 14:06:30 2021 +0100 media: mtk-vcodec: call v4l2_m2m_ctx_release first when file is released [ Upstream commit 9f89c881bffbdffe4060ffaef3489a2830a6dd9c ] The func v4l2_m2m_ctx_release waits for currently running jobs to finish and then stop streaming both queues and frees the buffers. All this should be done before the call to mtk_vcodec_enc_release which frees the encoder handler. This fixes null-pointer dereference bug: [ 638.028076] Mem abort info: [ 638.030932] ESR = 0x96000004 [ 638.033978] EC = 0x25: DABT (current EL), IL = 32 bits [ 638.039293] SET = 0, FnV = 0 [ 638.042338] EA = 0, S1PTW = 0 [ 638.045474] FSC = 0x04: level 0 translation fault [ 638.050349] Data abort info: [ 638.053224] ISV = 0, ISS = 0x00000004 [ 638.057055] CM = 0, WnR = 0 [ 638.060018] user pgtable: 4k pages, 48-bit VAs, pgdp=000000012b6db000 [ 638.066485] [00000000000001a0] pgd=0000000000000000, p4d=0000000000000000 [ 638.073277] Internal error: Oops: 96000004 [#1] SMP [ 638.078145] Modules linked in: rfkill mtk_vcodec_dec mtk_vcodec_enc uvcvideo mtk_mdp mtk_vcodec_common videobuf2_dma_contig v4l2_h264 cdc_ether v4l2_mem2mem videobuf2_vmalloc usbnet videobuf2_memops videobuf2_v4l2 r8152 videobuf2_common videodev cros_ec_sensors cros_ec_sensors_core industrialio_triggered_buffer kfifo_buf elan_i2c elants_i2c sbs_battery mc cros_usbpd_charger cros_ec_chardev cros_usbpd_logger crct10dif_ce mtk_vpu fuse ip_tables x_tables ipv6 [ 638.118583] CPU: 0 PID: 212 Comm: kworker/u8:5 Not tainted 5.15.0-06427-g58a1d4dcfc74-dirty #109 [ 638.127357] Hardware name: Google Elm (DT) [ 638.131444] Workqueue: mtk-vcodec-enc mtk_venc_worker [mtk_vcodec_enc] [ 638.137974] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 638.144925] pc : vp8_enc_encode+0x34/0x2b0 [mtk_vcodec_enc] [ 638.150493] lr : venc_if_encode+0xac/0x1b0 [mtk_vcodec_enc] [ 638.156060] sp : ffff8000124d3c40 [ 638.159364] x29: ffff8000124d3c40 x28: 0000000000000000 x27: 0000000000000000 [ 638.166493] x26: 0000000000000000 x25: ffff0000e7f252d0 x24: ffff8000124d3d58 [ 638.173621] x23: ffff8000124d3d58 x22: ffff8000124d3d60 x21: 0000000000000001 [ 638.180750] x20: ffff80001137e000 x19: 0000000000000000 x18: 0000000000000001 [ 638.187878] x17: 000000040044ffff x16: 00400032b5503510 x15: 0000000000000000 [ 638.195006] x14: ffff8000118536c0 x13: ffff8000ee1da000 x12: 0000000030d4d91d [ 638.202134] x11: 0000000000000000 x10: 0000000000000980 x9 : ffff8000124d3b20 [ 638.209262] x8 : ffff0000c18d4ea0 x7 : ffff0000c18d44c0 x6 : ffff0000c18d44c0 [ 638.216391] x5 : ffff80000904a3b0 x4 : ffff8000124d3d58 x3 : ffff8000124d3d60 [ 638.223519] x2 : ffff8000124d3d78 x1 : 0000000000000001 x0 : ffff80001137efb8 [ 638.230648] Call trace: [ 638.233084] vp8_enc_encode+0x34/0x2b0 [mtk_vcodec_enc] [ 638.238304] venc_if_encode+0xac/0x1b0 [mtk_vcodec_enc] [ 638.243525] mtk_venc_worker+0x110/0x250 [mtk_vcodec_enc] [ 638.248918] process_one_work+0x1f8/0x498 [ 638.252923] worker_thread+0x140/0x538 [ 638.256664] kthread+0x148/0x158 [ 638.259884] ret_from_fork+0x10/0x20 [ 638.263455] Code: f90023f9 2a0103f5 aa0303f6 aa0403f8 (f940d277) [ 638.269538] ---[ end trace e374fc10f8e181f5 ]--- [gst-master] root@debian:~/gst-build# [ 638.019193] Unable to handle kernel NULL pointer dereference at virtual address 00000000000001a0 Fixes: 4e855a6efa547 ("[media] vcodec: mediatek: Add Mediatek V4L2 Video Encoder Driver") Signed-off-by: Dafna Hirschfeld <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 893a766ac8fe3bfe93b110e5de6db29fd01599ba Author: Yang Yingliang <[email protected]> Date: Fri Oct 15 11:58:55 2021 +0200 media: si470x-i2c: fix possible memory leak in si470x_i2c_probe() [ Upstream commit ef054e345ed8c79ce1121a3599b5a2dfd78e57a0 ] n the 'radio->hdl.error' error handling, ctrl handler allocated by v4l2_ctrl_new_std() does not released, and caused memory leak as follows: unreferenced object 0xffff888033d54200 (size 256): comm "i2c-si470x-19", pid 909, jiffies 4294914203 (age 8.072s) hex dump (first 32 bytes): e8 69 11 03 80 88 ff ff 00 46 d5 33 80 88 ff ff .i.......F.3.... 10 42 d5 33 80 88 ff ff 10 42 d5 33 80 88 ff ff .B.3.....B.3.... backtrace: [<00000000086bd4ed>] __kmalloc_node+0x1eb/0x360 [<00000000bdb68871>] kvmalloc_node+0x66/0x120 [<00000000fac74e4c>] v4l2_ctrl_new+0x7b9/0x1c60 [videodev] [<00000000693bf940>] v4l2_ctrl_new_std+0x19b/0x270 [videodev] [<00000000c0cb91bc>] si470x_i2c_probe+0x2d3/0x9a0 [radio_si470x_i2c] [<0000000056a6f01f>] i2c_device_probe+0x4d8/0xbe0 Fix the error handling path to avoid memory leak. Reported-by: Hulk Robot <[email protected]> Fixes: 8c081b6f9a9b ("media: radio: Critical v4l2 registration...") Signed-off-by: Yang Yingliang <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit b38f3570f909e57139e772d77292fc356c21cd00 Author: Fabio Estevam <[email protected]> Date: Fri Oct 8 15:10:14 2021 +0200 media: imx-pxp: Initialize the spinlock prior to using it [ Upstream commit ed2f97ad4b21072f849cf4ae6645d1f2b1d3f550 ] After devm_request_threaded_irq() is called there is a chance that an interrupt may occur before the spinlock is initialized, which will trigger a kernel oops. To prevent that, move the initialization of the spinlock prior to requesting the interrupts. Fixes: 51abcf7fdb70 ("media: imx-pxp: add i.MX Pixel Pipeline driver") Signed-off-by: Fabio Estevam <[email protected]> Reviewed-by: Philipp Zabel <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 92cb150c3ec8b88819fecd43461aab55e2d16e91 Author: Suresh Udipi <[email protected]> Date: Fri Aug 13 17:07:54 2021 +0200 media: rcar-csi2: Correct the selection of hsfreqrange [ Upstream commit cee44d4fbacbbdfe62697ec94e76c6e4f726c5df ] hsfreqrange should be chosen based on the calculated mbps which is closer to the default bit rate and within the range as per table[1]. But current calculation always selects first value which is greater than or equal to the calculated mbps which may lead to chosing a wrong range in some cases. For example for 360 mbps for H3/M3N Existing logic selects Calculated value 360Mbps : Default 400Mbps Range [368.125 -433.125 mbps] This hsfreqrange is out of range. The logic is changed to get the default value which is closest to the calculated value [1] Calculated value 360Mbps : Default 350Mbps Range [320.625 -380.625 mpbs] [1] specs r19uh0105ej0200-r-car-3rd-generation.pdf [Table 25.9] Please note that According to Renesas in Table 25.9 the range for 220 default value is corrected as below |Range (Mbps) | Default Bit rate (Mbps) | ----------------------------------------------- | 197.125-244.125 | 220 | ----------------------------------------------- Fixes: 769afd212b16 ("media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver driver") Signed-off-by: Suresh Udipi <[email protected]> Signed-off-by: Kazuyoshi Akiyama <[email protected]> Signed-off-by: Michael Rodin <[email protected]> Reviewed-by: Niklas Söderlund <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 842a240666536c98f6a95012a35f4d69cb0fdfca Author: Hans de Goede <[email protected]> Date: Tue Nov 23 01:00:02 2021 +0100 media: i2c: ov8865: Fix lockdep error [ Upstream commit 6e1c9bc9ae96e57bcd8807174f2c0f44f9ef7938 ] ov8865_state_init() calls ov8865_state_mipi_configure() which uses __v4l2_ctrl_s_ctrl[_int64](). This means that sensor->mutex (which is also sensor->ctrls.handler.lock) must be locked before calling ov8865_state_init(). Note ov8865_state_mipi_configure() is also used in other places where the lock is already held so it cannot be changed itself. This fixes the following lockdep kernel WARN: [ 13.233421] WARNING: CPU: 0 PID: 8 at drivers/media/v4l2-core/v4l2-ctrls-api.c:833 __v4l2_ctrl_s_ctrl+0x4d/0x60 [videodev] ... [ 13.234063] Call Trace: [ 13.234074] ov8865_state_configure+0x98b/0xc00 [ov8865] [ 13.234095] ov8865_probe+0x4b1/0x54c [ov8865] [ 13.234117] i2c_device_probe+0x13c/0x2d0 Fixes: 11c0d8fdccc5 ("media: i2c: Add support for the OV8865 image sensor") Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 9a11fe9e4467e38b1e6c5049d9e086809e287040 Author: Daniel Scally <[email protected]> Date: Tue Nov 23 01:00:01 2021 +0100 media: i2c: Re-order runtime pm initialisation [ Upstream commit d2484fbf780762f6f9cc3abb7a07ee42dca2eaa3 ] The kerneldoc for pm_runtime_set_suspended() says: "It is not valid to call this function for devices with runtime PM enabled" To satisfy that requirement, re-order the calls so that pm_runtime_enable() is the last one. Fixes: 11c0d8fdccc5 ("media: i2c: Add support for the OV8865 image sensor") Signed-off-by: Daniel Scally <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit adf57b861e7f01765cbc376b13fe88c2a942299b Author: Eugen Hristev <[email protected]> Date: Wed Nov 17 16:40:09 2021 +0100 media: i2c: imx274: fix s_frame_interval runtime resume not requested [ Upstream commit da653498c20ba5b185214d8ae43b4e8e9594f520 ] pm_runtime_resume_and_get should be called when the s_frame_interval is called. The driver will try to access device registers to configure VMAX, coarse time and exposure. Currently if the runtime is not resumed, this fails: # media-ctl -d /dev/media0 --set-v4l2 '"IMX274 1-001a":0[fmt:SRGGB10_1X10/3840x2 160@1/10]' IMX274 1-001a: imx274_binning_goodness: ask 3840x2160, size 3840x2160, goodness 0 IMX274 1-001a: imx274_binning_goodness: ask 3840x2160, size 1920x1080, goodness -3000 IMX274 1-001a: imx274_binning_goodness: ask 3840x2160, size 1280x720, goodness -4000 IMX274 1-001a: imx274_binning_goodness: ask 3840x2160, size 1280x540, goodness -4180 IMX274 1-001a: __imx274_change_compose: selected 1x1 binning IMX274 1-001a: imx274_set_frame_interval: input frame interval = 1 / 10 IMX274 1-001a: imx274_read_mbreg : addr 0x300e, val=0x1 (2 bytes) IMX274 1-001a: imx274_set_frame_interval : register SVR = 1 IMX274 1-001a: imx274_read_mbreg : addr 0x30f6, val=0x6a8 (2 bytes) IMX274 1-001a: imx274_set_frame_interval : register HMAX = 1704 IMX274 1-001a: imx274_set_frame_length : input length = 2112 IMX274 1-001a: imx274_write_mbreg : i2c bulk write failed, 30f8 = 884 (3 bytes) IMX274 1-001a: imx274_set_frame_length error = -121 IMX274 1-001a: imx274_set_frame_interval error = -121 Unable to setup formats: Remote I/O error (121) The device is not resumed thus the remote I/O error. Setting the frame interval works at streaming time, because pm_runtime_resume_and_get is called at s_stream time before sensor setup. The failure happens when only the s_frame_interval is called separately independently on streaming time. Fixes: ad97bc37426c ("media: i2c: imx274: Add IMX274 power on and off sequence") Signed-off-by: Eugen Hristev <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 300b973af40f37e9e6a247e4d9f5f5e3aacc3e8b Author: Alan Maguire <[email protected]> Date: Mon Nov 29 10:00:40 2021 +0000 libbpf: Silence uninitialized warning/error in btf_dump_dump_type_data [ Upstream commit 43174f0d4597325cb91f1f1f55263eb6e6101036 ] When compiling libbpf with gcc 4.8.5, we see: CC staticobjs/btf_dump.o btf_dump.c: In function ‘btf_dump_dump_type_data.isra.24’: btf_dump.c:2296:5: error: ‘err’ may be used uninitialized in this function [-Werror=maybe-uninitialized] if (err < 0) ^ cc1: all warnings being treated as errors make: *** [staticobjs/btf_dump.o] Error 1 While gcc 4.8.5 is too old to build the upstream kernel, it's possible it could be used to build standalone libbpf which suffers from the same problem. Silence the error by initializing 'err' to 0. The warning/error seems to be a false positive since err is set early in the function. Regardless we shouldn't prevent libbpf from building for this. Fixes: 920d16af9b42 ("libbpf: BTF dumper support for typed data") Signed-off-by: Alan Maguire <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 162bc7bd73a101635eb0664a5888d33a07d84d36 Author: Jan Kara <[email protected]> Date: Thu Nov 25 14:36:41 2021 +0100 bfq: Do not let waker requests skip proper accounting [ Upstream commit c65e6fd460b4df796ecd6ea22e132076ed1f2820 ] Commit 7cc4ffc55564 ("block, bfq: put reqs of waker and woken in dispatch list") added a condition to bfq_insert_request() which added waker's requests directly to dispatch list. The rationale was that completing waker's IO is needed to get more IO for the current queue. Although this rationale is valid, there is a hole in it. The waker does not necessarily serve the IO only for the current queue and maybe it's current IO is not needed for current queue to make progress. Furthermore injecting IO like this completely bypasses any service accounting within bfq and thus we do not properly track how much service is waker's queue getting or that the waker is actually doing any IO. Depending on the conditions this can result in the waker getting too much or too few service. Consider for example the following job file: [global] directory=/mnt/repro/ rw=write size=8g time_based runtime=30 ramp_time=10 blocksize=1m direct=0 ioengine=sync [slowwriter] numjobs=1 prioclass=2 prio=7 fsync=200 [fastwriter] numjobs=1 prioclass=2 prio=0 fsync=200 Despite processes have very different IO priorities, they get the same about of service. The reason is that bfq identifies these processes as having waker-wakee relationship and once that happens, IO from fastwriter gets injected during slowwriter's time slice. As a result bfq is not aware that fastwriter has any IO to do and constantly schedules only slowwriter's queue. Thus fastwriter is forced to compete with slowwriter's IO all the time instead of getting its share of time based on IO priority. Drop the special injection condition from bfq_insert_request(). As a result, requests will be tracked and queued in a normal way and on next dispatch bfq_select_queue() can decide whether the waker's inserted requests should be injected during the current queue's timeslice or not. Fixes: 7cc4ffc55564 ("block, bfq: put reqs of waker and woken in dispatch list") Acked-by: Paolo Valente <[email protected]> Signed-off-by: Jan Kara <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 6b6e7150c18becf39038245123ee07931149a105 Author: Claudiu Beznea <[email protected]> Date: Thu Oct 28 16:51:38 2021 +0300 mfd: atmel-flexcom: Use .resume_noirq [ Upstream commit 5d051cf94fd5834a1513aa77e542c49fd973988a ] Flexcom IP embeds 3 other IPs: usart, i2c, spi and selects the operation mode (usart, i2c, spi) via mode register (FLEX_MR). On i2c bus there might be connected critical devices (like PMIC) which on suspend/resume should be suspended/resumed at the end/beginning. i2c uses .suspend_noirq/.resume_noirq for this kind of purposes. Align flexcom to use .resume_noirq as it should be resumed before the embedded IPs. Otherwise the embedded devices might behave badly. Fixes: 7fdec11015c3 ("atmel_flexcom: Support resuming after a chip reset") Signed-off-by: Claudiu Beznea <[email protected]> Tested-by: Codrin Ciubotariu <[email protected]> Acked-by: Nicolas Ferre <[email protected]> Signed-off-by: Lee Jones <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 8aa5209e54aaca8ac97211683727f7d8c2276034 Author: Claudiu Beznea <[email protected]> Date: Thu Oct 28 16:51:37 2021 +0300 mfd: atmel-flexcom: Remove #ifdef CONFIG_PM_SLEEP [ Upstream commit 8c0fad75dcaa650e3f3145a2c35847bc6a65cb7f ] Remove compilation flag and use __maybe_unused and pm_ptr instead. Signed-off-by: Claudiu Beznea <[email protected]> Acked-by: Nicolas Ferre <[email protected]> Signed-off-by: Lee Jones <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 1b1620dd224be9b4202015321c7ff1308970abfb Author: Tudor Ambarus <[email protected]> Date: Thu Nov 25 11:00:18 2021 +0200 tty: serial: atmel: Call dma_async_issue_pending() [ Upstream commit 4f4b9b5895614eb2e2b5f4cab7858f44bd113e1b ] The driver wrongly assummed that tx_submit() will start the transfer, which is not the case, now that the at_xdmac driver is fixed. tx_submit is supposed to push the current transaction descriptor to a pending queue, waiting for issue_pending to be called. issue_pending must start the transfer, not tx_submit. Fixes: 34df42f59a60 ("serial: at91: add rx dma support") Fixes: 08f738be88bb ("serial: at91: add tx dma support") Signed-off-by: Tudor Ambarus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit d249a70251cefe4c2ce89c835f1ad914962d9e84 Author: Tudor Ambarus <[email protected]> Date: Thu Nov 25 11:00:17 2021 +0200 tty: serial: atmel: Check return code of dmaengine_submit() [ Upstream commit 1e67bd2b8cb90b66e89562598e9c2046246832d3 ] The tx_submit() method of struct dma_async_tx_descriptor is entitled to do sanity checks and return errors if encountered. It's not the case for the DMA controller drivers that this client is using (at_h/xdmac), because they currently don't do sanity checks and always return a positive cookie at tx_submit() method. In case the controller drivers will implement sanity checks and return errors, print a message so that the client will be informed that something went wrong at tx_submit() level. Fixes: 08f738be88bb ("serial: at91: add tx dma support") Signed-off-by: Tudor Ambarus <[email protected]> Acked-by: Richard Genoud <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 32307d1b94ae02ea0365c0ccd99e85486bc374c6 Author: Peng Fan <[email protected]> Date: Fri Nov 12 14:31:55 2021 +0800 arm64: dts: ti: k3-j721e: correct cache-sets info [ Upstream commit 7a0df1f969c14939f60a7f9a6af72adcc314675f ] A72 Cluster has 48KB Icache, 32KB Dcache and 1MB L2 Cache - ICache is 3-way set-associative - Dcache is 2-way set-associative - Line size are 64bytes So correct the cache-sets info. Fixes: 2d87061e70dea ("arm64: dts: ti: Add Support for J721E SoC") Signed-off-by: Peng Fan <[email protected]> Reviewed-by: Nishanth Menon <[email protected]> Signed-off-by: Vignesh Raghavendra <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 920e0e6f0e39f84c171ded17b44bd2d845fe0f82 Author: Anilkumar Kolli <[email protected]> Date: Wed Nov 24 19:11:31 2021 +0200 ath11k: Use host CE parameters for CE interrupts configuration [ Upstream commit b689f091aafd1a874b2f88137934276ab0fca480 ] CE interrupt configuration uses host ce parameters to assign/free interrupts. Use host ce parameters to enable/disable interrupts. This patch fixes below BUG, BUG: KASAN: global-out-of-bounds in 0xffffffbffdfb035c at addr ffffffbffde6eeac Read of size 4 by task kworker/u8:2/132 Address belongs to variable ath11k_core_qmi_firmware_ready+0x1b0/0x5bc [ath11k] OOB is due to ath11k_ahb_ce_irqs_enable() iterates ce_count(which is 12) times and accessing 12th element in target_ce_config (which has only 11 elements) from ath11k_ahb_ce_irq_enable(). With this change host ce configs are used to enable/disable interrupts. Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.5.0.1-00471-QCAHKSWPL_SILICONZ-1 Fixes: 967c1d1131fa ("ath11k: move target ce configs to hw_params") Signed-off-by: Anilkumar Kolli <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 72b905fb39f0fca334ffbe8587ad10f180a1dd3f Author: Giovanni Cabiddu <[email protected]> Date: Wed Nov 17 14:30:35 2021 +0000 crypto: qat - fix undetected PFVF timeout in ACK loop [ Upstream commit 5002200b4fedd7e90e4fbc2e5c42a4b3351df814 ] If the remote function did not ACK the reception of a message, the function __adf_iov_putmsg() could detect it as a collision. This was due to the fact that the collision and the timeout checks after the ACK loop were in the wrong order. The timeout must be checked at the end of the loop, so fix by swapping the order of the two checks. Fixes: 9b768e8a3909 ("crypto: qat - detect PFVF collision after ACK") Signed-off-by: Giovanni Cabiddu <[email protected]> Co-developed-by: Marco Chiappero <[email protected]> Signed-off-by: Marco Chiappero <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 348210fd7765d70b4bf2107e3e40d51727aab27b Author: Marco Chiappero <[email protected]> Date: Tue Sep 28 12:44:35 2021 +0100 crypto: qat - make pfvf send message direction agnostic [ Upstream commit 6e680f94bc31d0fd0ff01123c964d895ea8040fa ] The functions adf_iov_putmsg() and __adf_iov_putmsg() are shared by both PF and VF. Any logging or documentation should not refer to any specific direction. Make comments and log messages direction agnostic by replacing PF2VF with PFVF. Also fix the wording for some related comments. Signed-off-by: Marco Chiappero <[email protected]> Co-developed-by: Giovanni Cabiddu <[email protected]> Signed-off-by: Giovanni Cabiddu <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 6c58dd967389e472b5c97b534ab60020f9d7b634 Author: Marco Chiappero <[email protected]> Date: Tue Sep 28 12:44:31 2021 +0100 crypto: qat - remove unnecessary collision prevention step in PFVF [ Upstream commit e17f49bb244a281fe39bfdad0306a38b3a02e7bf ] The initial version of the PFVF protocol included an initial "carrier sensing" to get ownership of the channel. Collisions can happen anyway, the extra wait and test does not prevent collisions, it instead slows the communication down, so remove it. Signed-off-by: Marco Chiappero <[email protected]> Reviewed-by: Giovanni Cabiddu <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit ef89212783a29df9c5fe89551596d6a904a559fa Author: Andrii Nakryiko <[email protected]> Date: Tue Nov 23 16:23:18 2021 -0800 libbpf: Fix using invalidated memory in bpf_linker [ Upstream commit 593835377f24ca1bb98008ec1dc3baefe491ad6e ] add_dst_sec() can invalidate bpf_linker's section index making dst_symtab pointer pointing into unallocated memory. Reinitialize dst_symtab pointer on each iteration to make sure it's always valid. Fixes: faf6ed321cf6 ("libbpf: Add BPF static linker APIs") Signed-off-by: Andrii Nakryiko <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 9b616ae0bf98146fe50c4cc6d068fbe421b1ca82 Author: Andrii Nakryiko <[email protected]> Date: Tue Nov 23 16:23:17 2021 -0800 libbpf: Fix glob_syms memory leak in bpf_linker [ Upstream commit 8cb125566c40b7141d8842c534f0ea5820ee3d5c ] glob_syms array wasn't freed on bpf_link__free(). Fix that. Fixes: a46349227cd8 ("libbpf: Add linker extern resolution support for functions and global variables") Signed-off-by: Andrii Nakryiko <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit f8ca67f3fc9e11a0faee67993991d105c6025835 Author: Andrii Nakryiko <[email protected]> Date: Tue Nov 23 16:23:14 2021 -0800 libbpf: Fix potential misaligned memory access in btf_ext__new() [ Upstream commit 401891a9debaf0a684502f2aaecf53448cee9414 ] Perform a memory copy before we do the sanity checks of btf_ext_hdr. This prevents misaligned memory access if raw btf_ext data is not 4-byte aligned ([0]). While at it, also add missing const qualifier. [0] Closes: https://github.com/libbpf/libbpf/issues/391 Fixes: 2993e0515bb4 ("tools/bpf: add support to read .BTF.ext sections") Reported-by: Evgeny Vereshchagin <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit ae38d31443240ed5dfcebf71b9ca6c0528667896 Author: Dillon Min <[email protected]> Date: Sat Jul 24 11:44:02 2021 +0800 ARM: dts: stm32: fix dtbs_check warning on ili9341 dts binding on stm32f429 disco [ Upstream commit b046049e59dca5e5830dc75ed16acf7657a95161 ] Since the compatible string defined from ilitek,ili9341.yaml is "st,sf-tc240t-9370-t", "ilitek,ili9341" so, append "ilitek,ili9341" to avoid the below dtbs_check warning. arch/arm/boot/dts/stm32f429-disco.dt.yaml: display@1: compatible: ['st,sf-tc240t-9370-t'] is too short Fixes: a726e2f000ec ("ARM: dts: stm32: enable ltdc binding with ili9341, gyro l3gd20 on stm32429-disco board") Signed-off-by: Dillon Min <[email protected]> Reported-by: kernel test robot <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Signed-off-by: Alexandre Torgue <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 9f670292c08033212f007ff1c8050b19c2a3b938 Author: Vladimir Zapolskiy <[email protected]> Date: Thu Nov 11 17:48:07 2021 +0200 cpufreq: qcom-hw: Fix probable nested interrupt handling [ Upstream commit e0e27c3d4e20dab861566f1c348ae44e4b498630 ] Re-enabling an interrupt from its own interrupt handler may cause an interrupt storm, if there is a pending interrupt and because its handling is disabled due to already done entrance into the handler above in the stack. Also, apparently it is improper to lock a mutex in an interrupt contex. Fixes: 275157b367f4 ("cpufreq: qcom-cpufreq-hw: Add dcvs interrupt support") Signed-off-by: Vladimir Zapolskiy <[email protected]> Reviewed-by: Matthias Kaehlcke <[email protected]> Reviewed-by: Bjorn Andersson <[email protected]> Signed-off-by: Viresh Kumar <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 929205dc3a0f18c1f9178db245ffb6bdbf235fbb Author: Lukasz Luba <[email protected]> Date: Tue Nov 9 19:57:12 2021 +0000 cpufreq: qcom-cpufreq-hw: Update offline CPUs per-cpu thermal pressure [ Upstream commit 93d9e6f93e1586fcc97498c764be2e8c8401f4bd ] The thermal pressure signal gives information to the scheduler about reduced CPU capacity due to thermal. It is based on a value stored in a per-cpu 'thermal_pressure' variable. The online CPUs will get the new value there, while the offline won't. Unfortunately, when the CPU is back online, the value read from per-cpu variable might be wrong (stale data). This might affect the scheduler decisions, since it sees the CPU capacity differently than what is actually available. Fix it by making sure that all online+offline CPUs would get the proper value in their per-cpu variable when there is throttling or throttling is removed. Fixes: 275157b367f479 ("cpufreq: qcom-cpufreq-hw: Add dcvs interrupt support") Reviewed-by: Thara Gopinath <[email protected]> Signed-off-by: Lukasz Luba <[email protected]> Signed-off-by: Viresh Kumar <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 5d39cd2059ba8a554538b734c359a9b51ca9897b Author: George G. Davis <[email protected]> Date: Fri Jul 16 16:49:35 2021 -0400 mtd: hyperbus: rpc-if: fix bug in rpcif_hb_remove [ Upstream commit baaf965f94308301d2dc554d72a87d7432cd5ce6 ] The following KASAN BUG is observed when testing the rpc-if driver on rcar-gen3: root@rcar-gen3:~# modprobe -r rpc-if [ 101.930146] ================================================================== [ 101.937408] BUG: KASAN: slab-out-of-bounds in __lock_acquire+0x518/0x25d0 [ 101.944240] Read of size 8 at addr ffff0004c5be2750 by task modprobe/664 [ 101.950959] [ 101.952466] CPU: 2 PID: 664 Comm: modprobe Not tainted 5.14.0-rc1-00342-g1a1464d7aa31 #1 [ 101.960578] Hardware name: Renesas H3ULCB board based on r8a77951 (DT) [ 101.967120] Call trace: [ 101.969580] dump_backtrace+0x0/0x2c0 [ 101.973275] show_stack+0x1c/0x30 [ 101.976616] dump_stack_lvl+0x9c/0xd8 [ 101.980301] print_address_description.constprop.0+0x74/0x2b8 [ 101.986071] kasan_report+0x1f4/0x26c [ 101.989757] __asan_load8+0x98/0xd4 [ 101.993266] __lock_acquire+0x518/0x25d0 [ 101.997215] lock_acquire.part.0+0x18c/0x360 [ 102.001506] lock_acquire+0x74/0x90 [ 102.005013] _raw_spin_lock_irq+0x98/0x130 [ 102.009131] __pm_runtime_disable+0x30/0x210 [ 102.013427] rpcif_hb_remove+0x5c/0x70 [rpc_if] [ 102.018001] platform_remove+0x40/0x80 [ 102.021771] __device_release_driver+0x234/0x350 [ 102.026412] driver_detach+0x158/0x20c [ 102.030179] bus_remove_driver+0xa0/0x140 [ 102.034212] driver_unregister+0x48/0x80 [ 102.038153] platform_driver_unregister+0x18/0x24 [ 102.042879] rpcif_platform_driver_exit+0x1c/0x34 [rpc_if] [ 102.048400] __arm64_sys_delete_module+0x210/0x310 [ 102.053212] invoke_syscall+0x60/0x190 [ 102.056986] el0_svc_common+0x12c/0x144 [ 102.060844] do_el0_svc+0x88/0xac [ 102.064181] el0_svc+0x24/0x3c [ 102.067257] el0t_64_sync_handler+0x1a8/0x1b0 [ 102.071634] el0t_64_sync+0x198/0x19c [ 102.075315] [ 102.076815] Allocated by task 628: [ 102.080781] [ 102.082280] Last potentially related work creation: [ 102.087524] [ 102.089022] The buggy address belongs to the object at ffff0004c5be2000 [ 102.089022] which belongs to the cache kmalloc-2k of size 2048 [ 102.101555] The buggy address is located 1872 bytes inside of [ 102.101555] 2048-byte region [ffff0004c5be2000, ffff0004c5be2800) [ 102.113486] The buggy address belongs to the page: [ 102.118409] [ 102.119908] Memory state around the buggy address: [ 102.124711] ffff0004c5be2600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 102.131947] ffff0004c5be2680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 102.139181] >ffff0004c5be2700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 102.146412] ^ [ 102.152257] ffff0004c5be2780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 102.159491] ffff0004c5be2800: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 102.166723] ================================================================== The above bug is caused by use of the wrong pointer in the rpcif_disable_rpm() call. Fix the bug by using the correct pointer. Fixes: 5de15b610f78 ("mtd: hyperbus: add Renesas RPC-IF driver") Signed-off-by: George G. Davis <[email protected]> Signed-off-by: Vignesh Raghavendra <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 869eee39b330f525c6280730d944074c8989f5d9 Author: Prasad Malisetty <[email protected]> Date: Tue Nov 16 16:31:46 2021 +0530 arm64: dts: qcom: sc7280: Fix incorrect clock name [ Upstream commit fa09b2248714c64644576d8064e9bd292a504a0e ] Replace pcie_1_pipe-clk clock name with pcie_1_pipe_clk To match with dt binding. Fixes: ab7772de8612 ("arm64: dts: qcom: SC7280: Add rpmhcc clock controller node") Signed-off-by: Prasad Malisetty <[email protected]> Reviewed-by: Stephen Boyd <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 38a721f609267788bbdbcc8bee3299f3ec8b4428 Author: Chengfeng Ye <[email protected]> Date: Thu Nov 4 06:46:42 2021 -0700 crypto: qce - fix uaf on qce_skcipher_register_one [ Upstream commit e9c195aaeed1b45c9012adbe29dedb6031e85aa8 ] Pointer alg points to sub field of tmpl, it is dereferenced after tmpl is freed. Fix this by accessing alg before free tmpl. Fixes: ec8f5d8f ("crypto: qce - Qualcomm crypto engine driver") Signed-off-by: Chengfeng Ye <[email protected]> Acked-by: Thara Gopinath <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 561030c55120893b4d8c939c7891907144fb0bee Author: Chengfeng Ye <[email protected]> Date: Thu Nov 4 06:38:31 2021 -0700 crypto: qce - fix uaf on qce_ahash_register_one [ Upstream commit b4cb4d31631912842eb7dce02b4350cbb7562d5e ] Pointer base points to sub field of tmpl, it is dereferenced after tmpl is freed. Fix this by accessing base before free tmpl. Fixes: ec8f5d8f ("crypto: qce - Qualcomm crypto engine driver") Signed-off-by: Chengfeng Ye <[email protected]> Acked-by: Thara Gopinath <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit cf984b11cdecf54816540de99dcca559ff8fab7d Author: Chengfeng Ye <[email protected]> Date: Thu Nov 4 06:28:07 2021 -0700 crypto: qce - fix uaf on qce_aead_register_one [ Upstream commit 4a9dbd021970ffe1b92521328377b699acba7c52 ] Pointer alg points to sub field of tmpl, it is dereferenced after tmpl is freed. Fix this by accessing alg before free tmpl. Fixes: 9363efb4 ("crypto: qce - Add support for AEAD algorithms") Signed-off-by: Chengfeng Ye <[email protected]> Acked-by: Thara Gopinath <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit cb353b68846439e12e79f79d1fb7810a9644c1a0 Author: Tudor Ambarus <[email protected]> Date: Wed Oct 27 16:30:01 2021 +0300 crypto: atmel-aes - Reestablish the correct tfm context at dequeue [ Upstream commit 6d48de655917a9d782953eba65de4e3db593ddf0 ] In case there were more requests from different tfms in the crypto queue, only the context of the last initialized tfm was considered. Fixes: ec2088b66f7a ("crypto: atmel-aes - Allocate aes dev at tfm init time") Reported-by: Wolfgang Ocker <[email protected]> Signed-off-by: Tudor Ambarus <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 4d6a558bde10896f2041e0aa5b3b7eca78b1834c Author: Wang Hai <[email protected]> Date: Fri Oct 15 16:57:41 2021 +0800 media: dmxdev: fix UAF when dvb_register_device() fails [ Upstream commit ab599eb11882f834951c436cc080c3455ba32b9b ] I got a use-after-free report: dvbdev: dvb_register_device: failed to create device dvb1.dvr0 (-12) ... ================================================================== BUG: KASAN: use-after-free in dvb_dmxdev_release+0xce/0x2f0 ... Call Trace: dump_stack_lvl+0x6c/0x8b print_address_description.constprop.0+0x48/0x70 kasan_report.cold+0x82/0xdb __asan_load4+0x6b/0x90 dvb_dmxdev_release+0xce/0x2f0 ... Allocated by task 7666: kasan_save_stack+0x23/0x50 __kasan_kmalloc+0x83/0xa0 kmem_cache_alloc_trace+0x22e/0x470 dvb_register_device+0x12f/0x980 dvb_dmxdev_init+0x1f3/0x230 ... Freed by task 7666: kasan_save_stack+0x23/0x50 kasan_set_track+0x20/0x30 kasan_set_free_info+0x24/0x40 __kasan_slab_free+0xf2/0x130 kfree+0xd1/0x5c0 dvb_register_device.cold+0x1ac/0x1fa dvb_dmxdev_init+0x1f3/0x230 ... When dvb_register_device() in dvb_dmxdev_init() fails, dvb_dmxdev_init() does not return a failure, and the memory pointed to by dvbdev or dvr_dvbdev is invalid at this point. If they are used subsequently, it will result in UFA or null-ptr-deref. If dvb_register_device() in dvb_dmxdev_init() fails, fix the bug by making dvb_dmxdev_init() return an error as well. Link: https://lore.kernel.org/linux-media/[email protected] Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Hulk Robot <[email protected]> Signed-off-by: Wang Hai <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 87a413e3d8c93208a737fa1c2f51c91835c1df99 Author: Biju Das <[email protected]> Date: Mon Nov 15 14:28:30 2021 +0000 arm64: dts: renesas: cat875: Add rx/tx delays [ Upstream commit e1a9faddffe7e555304dc2e3284c84fbee0679ee ] The CAT875 sub board from Silicon Linux uses a Realtek PHY. The phy driver commit bbc4d71d63549bcd003 ("net: phy: realtek: fix rtl8211e rx/tx delay config") introduced NFS mount failures. Now it needs both rx/tx delays for the NFS mount to work. This patch fixes the NFS mount failure issue by adding "rgmii-id" mode to the avb device node. Signed-off-by: Biju Das <[email protected]> Fixes: bbc4d71d63549bcd ("net: phy: realtek: fix rtl8211e rx/tx delay config") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 7bce2027778404cb7b2887cd2114a50936d8b906 Author: Dan Carpenter <[email protected]> Date: Thu Nov 18 14:12:33 2021 +0300 drm/vboxvideo: fix a NULL vs IS_ERR() check [ Upstream commit cebbb5c46d0cb0615fd0c62dea9b44273d0a9780 ] The devm_gen_pool_create() function never returns NULL, it returns error pointers. Fixes: 4cc9b565454b ("drm/vboxvideo: Use devm_gen_pool_create") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20211118111233.GA1147@kili Signed-off-by: Sasha Levin <[email protected]> commit 56339a5546a7f66333f9d3c55e3fd1424caa4879 Author: Lyude Paul <[email protected]> Date: Fri Nov 5 14:33:40 2021 -0400 drm/dp: Don't read back backlight mode in drm_edp_backlight_enable() [ Upstream commit 646596485e1ed2182adf293dfd5aec4a96c46330 ] As it turns out, apparently some machines will actually leave additional backlight functionality like dynamic backlight control on before the OS loads. Currently we don't take care to disable unsupported features when writing back the backlight mode, which can lead to some rather strange looking behavior when adjusting the backlight. So, let's fix this by just not reading back the current backlight mode on initial enable. I don't think there should really be any downsides to this, and this will ensure we don't leave any unsupported functionality enabled. This should fix at least one (but not all) of the issues seen with DPCD backlight support on fi-bdw-samus v5: * Just avoid reading back DPCD register - Doug Anderson Signed-off-by: Lyude Paul <[email protected]> Fixes: 867cf9cd73c3 ("drm/dp: Extract i915's eDP backlight code into DRM helpers") Reviewed-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 25f2b49f65c6d5d2930bf8142aec24955b2a9653 Author: Alexander Aring <[email protected]> Date: Wed Nov 17 09:20:43 2021 -0500 fs: dlm: fix build with CONFIG_IPV6 disabled [ Upstream commit 1b9beda83e27a0c2cd75d1cb743c297c7b36c844 ] This patch will surround the AF_INET6 case in sk_error_report() of dlm with a #if IS_ENABLED(CONFIG_IPV6). The field sk->sk_v6_daddr is not defined when CONFIG_IPV6 is disabled. If CONFIG_IPV6 is disabled, the socket creation with AF_INET6 should already fail because a runtime check if AF_INET6 is registered. However if there is the possibility that AF_INET6 is set as sk_family the sk_error_report() callback will print then an invalid family type error. Reported-by: kernel test robot <[email protected]> Fixes: 4c3d90570bcc ("fs: dlm: don't call kernel_getpeername() in error_report()") Signed-off-by: Alexander Aring <[email protected]> Signed-off-by: David Teigland <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 815570353f6bcd1cedf0aec0a572f53deed88020 Author: Jens Wiklander <[email protected]> Date: Tue Jun 15 22:23:50 2021 +0200 tee: fix put order in teedev_close_context() [ Upstream commit f18397ab3ae23e8e43bba9986e66af6d4497f2ad ] Prior to this patch was teedev_close_context() calling tee_device_put() before teedev_ctx_put() leading to teedev_ctx_release() accessing ctx->teedev just after the reference counter was decreased on the teedev. Fix this by calling teedev_ctx_put() before tee_device_put(). Fixes: 217e0250cccb ("tee: use reference counting for tee_context") Reviewed-by: Sumit Garg <[email protected]> Signed-off-by: Jens Wiklander <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit d46f937233b15422cbb8ab1d53a3278d58965ad8 Author: oujiefeng <[email protected]> Date: Wed Nov 17 09:21:19 2021 +0800 spi: hisi-kunpeng: Fix the debugfs directory name incorrect [ Upstream commit 40fafc8eca3f0d41b9dade5c10afb2dad723aad7 ] Change the debugfs directory name from hisi_spi65535 to hisi_spi0. Fixes: 2b2142f247eb ("spi: hisi-kunpeng: Add debugfs support") Signed-off-by: oujiefeng <[email protected]> Signed-off-by: Jay Fang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 50dab89c25dd68c472a8a6f3132416fa7d96ee8f Author: Karthikeyan Kathirvel <[email protected]> Date: Mon Nov 15 11:04:41 2021 +0100 ath11k: reset RSN/WPA present state for open BSS [ Upstream commit 64bc3aa02ae78b1fcb1b850e0eb1f0622002bfaa ] The ath11k driver is caching the information about RSN/WPA IE in the configured beacon template. The cached information is used during associations to figure out whether 4-way PKT/2-way GTK peer flags need to be set or not. But the code never cleared the state when no such IE was found. This can for example happen when moving from an WPA/RSN to an open setup. The (seemingly connected) peer was then not able to communicate over the link because the firmware assumed a different (encryption enabled) state for the peer. Tested-on: IPQ6018 hw1.0 AHB WLAN.HK.2.5.0.1-01100-QCAHKSWPL_SILICONZ-1 Fixes: 01e34233c645 ("ath11k: fix wmi peer flags in peer assoc command") Cc: Venkateswara Naralasetty <[email protected]> Reported-by: Sven Eckelmann <[email protected]> Signed-off-by: Karthikeyan Kathirvel <[email protected]> [[email protected]: split into separate patches, clean up commit message] Signed-off-by: Sven Eckelmann <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 4ca3ffff349f0d633abbb322153dc26d837a5b5f Author: Karthikeyan Kathirvel <[email protected]> Date: Mon Nov 15 11:04:40 2021 +0100 ath11k: clear the keys properly via DISABLE_KEY [ Upstream commit 436a4e88659842a7cf634d7cc088c8f2cc94ebf5 ] DISABLE_KEY sets the key_len to 0, firmware will not delete the keys if key_len is 0. Changing from security mode to open mode will cause mcast to be still encrypted without vdev restart. Set the proper key_len for DISABLE_KEY cmd to clear the keys in firmware. Tested-on: IPQ6018 hw1.0 AHB WLAN.HK.2.5.0.1-01100-QCAHKSWPL_SILICONZ-1 Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Reported-by: Sven Eckelmann <[email protected]> Signed-off-by: Karthikeyan Kathirvel <[email protected]> [[email protected]: split into separate patches, clean up commit message] Signed-off-by: Sven Eckelmann <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit dff606fc5068d763c13b9dc6a966d34870dbe891 Author: Sven Eckelmann <[email protected]> Date: Mon Nov 15 11:29:55 2021 +0200 ath11k: Fix ETSI regd with weather radar overlap [ Upstream commit 086c921a354089f209318501038d43c98d3f409f ] Some ETSI countries have a small overlap in the wireless-regdb with an ETSI channel (5590-5650). A good example is Australia: country AU: DFS-ETSI (2400 - 2483.5 @ 40), (36) (5150 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW (5250 - 5350 @ 80), (20), NO-OUTDOOR, AUTO-BW, DFS (5470 - 5600 @ 80), (27), DFS (5650 - 5730 @ 80), (27), DFS (5730 - 5850 @ 80), (36) (57000 - 66000 @ 2160), (43), NO-OUTDOOR If the firmware (or the BDF) is shipped with these rules then there is only a 10 MHz overlap with the weather radar: * below: 5470 - 5590 * weather radar: 5590 - 5600 * above: (none for the rule "5470 - 5600 @ 80") There are several wrong assumption in the ath11k code: * there is always a valid range below the weather radar (actually: there could be no range below the weather radar range OR range could be smaller than 20 MHz) * intersected range in the weather radar range is valid (actually: the range could be smaller than 20 MHz) * range above weather radar is either empty or valid (actually: the range could be smaller than 20 MHz) These wrong assumption will lead in this example to a rule (5590 - 5600 @ 20), (N/A, 27), (600000 ms), DFS, AUTO-BW which is invalid according to is_valid_reg_rule() because the freq_diff is only 10 MHz but the max_bandwidth is set to 20 MHz. Which results in a rejection like: WARNING: at backports-20210222_001-4.4.60-b157d2276/net/wireless/reg.c:3984 [...] Call trace: [<ffffffbffc3d2e50>] reg_get_max_bandwidth+0x300/0x3a8 [cfg80211] [<ffffffbffc3d3d0c>] regulatory_set_wiphy_regd_sync+0x3c/0x98 [cfg80211] [<ffffffbffc651598>] ath11k_regd_update+0x1a8/0x210 [ath11k] [<ffffffbffc652108>] ath11k_regd_update_work+0x18/0x20 [ath11k] [<ffffffc0000a93e0>] process_one_work+0x1f8/0x340 [<ffffffc0000a9784>] worker_thread+0x25c/0x448 [<ffffffc0000aedc8>] kthread+0xd0/0xd8 [<ffffffc000085550>] ret_from_fork+0x10/0x40 ath11k c000000.wifi: failed to perform regd update : -22 Invalid regulatory domain detected To avoid this, the algorithm has to be changed slightly. Instead of splitting a rule which overlaps with the weather radar range into 3 pieces and accepting the first two parts blindly, it must actually be checked for each piece whether it is a valid range. And only if it is valid, add it to the output array. When these checks are in place, the processed rules for AU would end up as country AU: DFS-ETSI (2400 - 2483 @ 40), (N/A, 36), (N/A) (5150 - 5250 @ 80), (6, 23), (N/A), NO-OUTDOOR, AUTO-BW (5250 - 5350 @ 80), (6, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW (5470 - 5590 @ 80), (6, 27), (0 ms), DFS, AUTO-BW (5650 - 5730 @ 80), (6, 27), (0 ms), DFS, AUTO-BW (5730 - 5850 @ 80), (6, 36), (N/A), AUTO-BW and will be accepted by the wireless regulatory code. Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Signed-off-by: Sven Eckelmann <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 2de0e6a71ceb056e17e4684dce8b7640367996f9 Author: Pavel Skripkin <[email protected]> Date: Mon Nov 1 10:12:12 2021 +0300 Bluetooth: stop proccessing malicious adv data [ Upstream commit 3a56ef719f0b9682afb8a86d64b2399e36faa4e6 ] Syzbot reported slab-out-of-bounds read in hci_le_adv_report_evt(). The problem was in missing validaion check. We should check if data is not malicious and we can read next data block. If we won't check ptr validness, code can read a way beyond skb->end and it can cause problems, of course. Fixes: e95beb414168 ("Bluetooth: hci_le_adv_report_evt code refactoring") Reported-and-tested-by: [email protected] Signed-off-by: Pavel Skripkin <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 63811bf4f5722acbb2a9594c87d289df3eee3ee6 Author: Lad Prabhakar <[email protected]> Date: Mon Oct 25 21:56:29 2021 +0100 memory: renesas-rpc-if: Return error in case devm_ioremap_resource() fails [ Upstream commit 818fdfa89baac77a8df5a2c30f4fb798cc937aa0 ] Make sure we return error in case devm_ioremap_resource() fails for dirmap resource. Fixes: ca7d8b980b67 ("memory: add Renesas RPC-IF driver") Signed-off-by: Lad Prabhakar <[email protected]> Reviewed-by: Biju Das <[email protected]> Reviewed-by: Wolfram Sang <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit dba0aea5727ce2ba21a2388be3f86523c112d9df Author: Alexander Aring <[email protected]> Date: Mon Nov 15 08:57:05 2021 -0500 fs: dlm: don't call kernel_getpeername() in error_report() [ Upstream commit 4c3d90570bcc2b338f70f61f01110268e281ca3c ] In some cases kernel_getpeername() will held the socket lock which is already held when the socket layer calls error_report() callback. Since commit 9dfc685e0262 ("inet: remove races in inet{6}_getname()") this problem becomes more likely because the socket lock will be held always. You will see something like: bob9-u5 login: [ 562.316860] BUG: spinlock recursion on CPU#7, swapper/7/0 [ 562.318562] lock: 0xffff8f2284720088, .magic: dead4ead, .owner: swapper/7/0, .owner_cpu: 7 [ 562.319522] CPU: 7 PID: 0 Comm: swapper/7 Not tainted 5.15.0+ #135 [ 562.320346] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.13.0-2.module+el8.3.0+7353+9de0a3cc 04/01/2014 [ 562.321277] Call Trace: [ 562.321529] <IRQ> [ 562.321734] dump_stack_lvl+0x33/0x42 [ 562.322282] do_raw_spin_lock+0x8b/0xc0 [ 562.322674] lock_sock_nested+0x1e/0x50 [ 562.323057] inet_getname+0x39/0x110 [ 562.323425] ? sock_def_readable+0x80/0x80 [ 562.323838] lowcomms_error_report+0x63/0x260 [dlm] [ 562.324338] ? wait_for_completion_interruptible_timeout+0xd2/0x120 [ 562.324949] ? lock_timer_base+0x67/0x80 [ 562.325330] ? do_raw_spin_unlock+0x49/0xc0 [ 562.325735] ? _raw_spin_unlock_irqrestore+0x1e/0x40 [ 562.326218] ? del_timer+0x54/0x80 [ 562.326549] sk_error_report+0x12/0x70 [ 562.326919] tcp_validate_incoming+0x3c8/0x530 [ 562.327347] ? kvm_clock_read+0x14/0x30 [ 562.327718] ? ktime_get+0x3b/0xa0 [ 562.328055] tcp_rcv_established+0x121/0x660 [ 562.328466] tcp_v4_do_rcv+0x132/0x260 [ 562.328835] tcp_v4_rcv+0xcea/0xe20 [ 562.329173] ip_protocol_deliver_rcu+0x35/0x1f0 [ 562.329615] ip_local_deliver_finish+0x54/0x60 [ 562.330050] ip_local_deliver+0xf7/0x110 [ 562.330431] ? inet_rtm_getroute+0x211/0x840 [ 562.330848] ? ip_protocol_deliver_rcu+0x1f0/0x1f0 [ 562.331310] ip_rcv+0xe1/0xf0 [ 562.331603] ? ip_local_deliver+0x110/0x110 [ 562.332011] __netif_receive_skb_core+0x46a/0x1040 [ 562.332476] ? inet_gro_receive+0x263/0x2e0 [ 562.332885] __netif_receive_skb_list_core+0x13b/0x2c0 [ 562.333383] netif_receive_skb_list_internal+0x1c8/0x2f0 [ 562.333896] ? update_load_avg+0x7e/0x5e0 [ 562.334285] gro_normal_list.part.149+0x19/0x40 [ 562.334722] napi_complete_done+0x67/0x160 [ 562.335134] virtnet_poll+0x2ad/0x408 [virtio_net] [ 562.335644] __napi_poll+0x28/0x140 [ 562.336012] net_rx_action+0x23d/0x300 [ 562.336414] __do_softirq+0xf2/0x2ea [ 562.336803] irq_exit_rcu+0xc1/0xf0 [ 562.337173] common_interrupt+0xb9/0xd0 It is and was always forbidden to call kernel_getpeername() in context of error_report(). To get rid of the problem we access the destination address for the peer over the socket structure. While on it we fix to print out the destination port of the inet socket. Fixes: 1a31833d085a ("DLM: Replace nodeid_to_addr with kernel_getpeername") Reported-by: Bob Peterson <[email protected]> Signed-off-by: Alexander Aring <[email protected]> Signed-off-by: David Teigland <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit ba43bd2be16b4d93281d51ce6ddf8746147ff7d8 Author: Christian Hewitt <[email protected]> Date: Tue Oct 12 05:25:21 2021 +0000 arm64: dts: meson-gxbb-wetek: fix missing GPIO binding [ Upstream commit c019abb2feba3cbbd7cf7178f8e6499c4fa6fced ] The absence of this binding appears to be harmless in Linux but it breaks Ethernet support in mainline u-boot. So add the binding (which is present in all other u-boot supported GXBB device-trees). Fixes: fb72c03e0e32 ("ARM64: dts: meson-gxbb-wetek: add a wetek specific dtsi to cleanup hub and play2") Signed-off-by: Christian Hewitt <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 0a7dd2ec89b24bd2adfc27bf3d370f1fe6bdc4be Author: Christian Hewitt <[email protected]> Date: Tue Oct 12 05:25:20 2021 +0000 arm64: dts: meson-gxbb-wetek: fix HDMI in early boot [ Upstream commit 8182a35868db5f053111d5d9d4da8fcb3f99259d ] Mark the VDDIO_AO18 regulator always-on and set hdmi-supply for the hdmi_tx node to ensure HDMI is powered in the early stages of boot. Fixes: fb72c03e0e32 ("ARM64: dts: meson-gxbb-wetek: add a wetek specific dtsi to cleanup hub and play2") Signed-off-by: Christian Hewitt <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 74ad053d7338d20ab72b6cb02de5b94d1f7e2d7f Author: Alexander Stein <[email protected]> Date: Tue Oct 26 20:28:13 2021 +0200 arm64: dts: amlogic: Fix SPI NOR flash node name for ODROID N2/N2+ [ Upstream commit 95d35256b564aca33fb661eac77dc94bfcffc8df ] Fix the schema warning: "spi-flash@0: $nodename:0: 'spi-flash@0' does not match '^flash(@.*)?$'" from jedec,spi-nor.yaml Fixes: a084eaf3096c ("arm64: dts: meson-g12b-odroid-n2: add SPIFC controller node") Reviewed-by: Neil Armstrong <[email protected]> Signed-off-by: Alexander Stein <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 3cebbcbf91984e68cf1014de73a5ad51c9dbcd52 Author: Alexander Stein <[email protected]> Date: Tue Oct 26 20:28:12 2021 +0200 arm64: dts: amlogic: meson-g12: Fix GPU operating point table node name [ Upstream commit bb98a6fd0b0e227cefb2ba91cea2b55455f203b7 ] Starting with commit 94274f20f6bf ("dt-bindings: opp: Convert to DT schema") the opp node name has a mandatory pattern. This change fixes the dtbs_check warning: gpu-opp-table: $nodename:0: 'gpu-opp-table' does not match '^opp-table(-[a-z0-9]+)?$' Put the 'gpu' part at the end to match the pattern. Fixes: 916a0edc43f0 ("arm64: dts: amlogic: meson-g12: add the Mali OPP table and use DVFS") Reviewed-by: Neil Armstrong <[email protected]> Signed-off-by: Alexander Stein <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 82515555873e3ae426fdf63e5141748d5710b64d Author: Jammy Huang <[email protected]> Date: Tue Nov 9 03:12:27 2021 +0000 media: aspeed: Update signal status immediately to ensure sane hw state [ Upstream commit af6d1bde395cac174ee71adcd3fa43f6435c7206 ] If res-chg, VE_INTERRUPT_MODE_DETECT_WD irq will be raised. But v4l2_input_status won't be updated to no-signal immediately until aspeed_video_get_resolution() in aspeed_video_resolution_work(). During the period of time, aspeed_video_start_frame() could be called because it doesn't know signal becomes unstable now. If it goes with aspeed_video_init_regs() of aspeed_video_irq_res_change() simultaneously, it will mess up hw state. To fix this problem, v4l2_input_status is updated to no-signal immediately for VE_INTERRUPT_MODE_DETECT_WD irq. Fixes: d2b4387f3bdf ("media: platform: Add Aspeed Video Engine driver") Signed-off-by: Jammy Huang <[email protected]> Acked-by: Paul Menzel <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 85d5345bd861bf04b5c65ec401735c190bd3786f Author: Dongliang Mu <[email protected]> Date: Mon Nov 1 09:55:39 2021 +0000 media: em28xx: fix memory leak in em28xx_init_dev [ Upstream commit 22be5a10d0b24eec9e45decd15d7e6112b25f080 ] In the em28xx_init_rev, if em28xx_audio_setup fails, this function fails to deallocate the media_dev allocated in the em28xx_media_device_init. Fix this by adding em28xx_unregister_media_device to free media_dev. BTW, this patch is tested in my local syzkaller instance, and it can prevent the memory leak from occurring again. CC: Pavel Skripkin <[email protected]> Fixes: 37ecc7b1278f ("[media] em28xx: add media controller support") Signed-off-by: Dongliang Mu <[email protected]> Reported-by: syzkaller <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit c4f0f1608727d2d96050ffe77010ba0648431b45 Author: Jammy Huang <[email protected]> Date: Wed Nov 3 08:23:54 2021 +0000 media: aspeed: fix mode-detect always time out at 2nd run [ Upstream commit 62cea52ad4bead0ae4be2cfe1142eb0aae0e9fbd ] aspeed_video_get_resolution() will try to do res-detect again if the timing got in last try is invalid. But it will always time out because VE_SEQ_CTRL_TRIG_MODE_DET is only cleared after 1st mode-detect. To fix the problem, just clear VE_SEQ_CTRL_TRIG_MODE_DET before setting it in aspeed_video_enable_mode_detect(). Fixes: d2b4387f3bdf ("media: platform: Add Aspeed Video Engine driver") Signed-off-by: Jammy Huang <[email protected]> Acked-by: Paul Menzel <[email protected]> Reviewed-by: Joel Stanley <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 7fd4b0e1890331876e05b676ae6979ec0a0d62d3 Author: Dan Carpenter <[email protected]> Date: Tue Oct 12 09:21:50 2021 +0100 media: atomisp: fix uninitialized bug in gmin_get_pmic_id_and_addr() [ Upstream commit cb4d67a998e97365afdf34965b069601da1dae60 ] The "power" pointer is not initialized on the else path and that would lead to an Oops. Link: https://lore.kernel.org/linux-media/20211012082150.GA31086@kili Fixes: c30f4cb2d4c7 ("media: atomisp: Refactor PMIC detection to a separate function") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Kieran Bingham <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 37d7ebf0179be9685fcd80fea1dcb4a8b19602a8 Author: Mauro Carvalho Chehab <[email protected]> Date: Mon Oct 25 09:06:52 2021 +0100 media: atomisp: fix enum formats logic [ Upstream commit fae46cb0531b45c789e39128f676f2bafa3a7b47 ] Changeset 374d62e7aa50 ("media: v4l2-subdev: Verify v4l2_subdev_call() pad config argument") added an extra verification for a pads parameter for enum mbus format code. Such change broke atomisp, because now the V4L2 core refuses to enum MBUS formats if the state is empty. So, add .which field in order to select the active formats, in order to make it work again. While here, improve error messages. Fixes: 374d62e7aa50 ("media: v4l2-subdev: Verify v4l2_subdev_call() pad config argument") Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit a030bcd96ef464b2aa8aa059f21b4d0396428a8c Author: Tsuchiya Yuto <[email protected]> Date: Mon Oct 18 01:23:34 2021 +0900 media: atomisp: add NULL check for asd obtained from atomisp_video_pipe [ Upstream commit c10bcb13462e9cf43111d17f1e08b4bb4d4401b0 ] This is almost a BUG report with RFC patch that just avoids kernel oopses. Thus, prefixed with [BUG][RFC]. Here is the kernel log after running `v4l2-compliance -d /dev/video4` with this patch applied: kern :err : [25507.580392] atomisp-isp2 0000:00:03.0: can't change power state from D3cold to D0 (config space inaccessible) kern :warn : [25507.592343] isys dma store at addr(0xcd408) val(0) kern :err : [25507.592995] atomisp-isp2 0000:00:03.0: atomisp_queryctl(): asd is NULL, device is ATOMISP ISP ACC kern :err : [25507.593685] atomisp-isp2 0000:00:03.0: atomisp_g_input(): asd is NULL, device is ATOMISP ISP ACC kern :err : [25507.593719] atomisp-isp2 0000:00:03.0: atomisp_g_parm(): asd is NULL, device is ATOMISP ISP ACC kern :err : [25507.593727] atomisp-isp2 0000:00:03.0: atomisp_queryctl(): asd is NULL, device is ATOMISP ISP ACC [omitting 42 same messages] kern :err : [25507.593976] atomisp-isp2 0000:00:03.0: atomisp_queryctl(): asd is NULL, device is ATOMISP ISP ACC kern :err : [25507.594191] atomisp-isp2 0000:00:03.0: atomisp_g_input(): asd is NULL, device is ATOMISP ISP ACC kern :err : [25507.594449] atomisp-isp2 0000:00:03.0: atomisp_queryctl(): asd is NULL, device is ATOMISP ISP ACC [omitting 43 same messages] kern :err : [25507.594756] atomisp-isp2 0000:00:03.0: atomisp_queryctl(): asd is NULL, device is ATOMISP ISP ACC kern :err : [25507.594779] atomisp-isp2 0000:00:03.0: atomisp_g_ctrl(): asd is NULL, device is ATOMISP ISP ACC kern :err : [25507.594787] atomisp-isp2 0000:00:03.0: atomisp_s_ctrl(): asd is NULL, device is ATOMISP ISP ACC kern :err : [25507.594803] atomisp-isp2 0000:00:03.0: atomisp_camera_g_ext_ctrls(): asd is NULL, device is ATOMISP ISP ACC kern :err : [25507.594880] atomisp-isp2 0000:00:03.0: atomisp_enum_fmt_cap(): asd is NULL, device is ATOMISP ISP ACC kern :err : [25507.594915] atomisp-isp2 0000:00:03.0: atomisp_g_parm(): asd is NULL, device is ATOMISP ISP ACC kern :err : [25507.595058] atomisp-isp2 0000:00:03.0: atomisp_try_fmt(): asd is NULL, device is ATOMISP ISP ACC kern :err : [25507.595089] atomisp-isp2 0000:00:03.0: atomisp_set_fmt(): asd is NULL, device is ATOMISP ISP ACC kern :err : [25507.595124] atomisp-isp2 0000:00:03.0: atomisp_set_fmt(): asd is NULL, device is ATOMISP ISP ACC kern :err : [25507.595221] atomisp-isp2 0000:00:03.0: atomisp_set_fmt(): asd is NULL, device is ATOMISP ISP ACC kern :err : [25507.595241] atomisp-isp2 0000:00:03.0: atomisp_set_fmt(): asd is NULL, device is ATOMISP ISP ACC kern :err : [25507.601571] atomisp-isp2 0000:00:03.0: can't change power state from D3cold to D0 (config space inaccessible) kern :warn : [25507.607496] isys dma store at addr(0xcd408) val(0) kern :err : [25507.608604] atomisp-isp2 0000:00:03.0: atomisp_queryctl(): asd is NULL, device is ATOMISP ISP ACC kern :err : [25507.611988] atomisp-isp2 0000:00:03.0: can't change power state from D3cold to D0 (config space inaccessible) kern :warn : [25507.617420] isys dma store at addr(0xcd408) val(0) kern :err : [25507.618429] atomisp-isp2 0000:00:03.0: atomisp_queryctl(): asd is NULL, device is ATOMISP ISP ACC kern :err : [25507.618811] atomisp-isp2 0000:00:03.0: atomisp_g_parm(): asd is NULL, device is ATOMISP ISP ACC kern :err : [25507.622193] atomisp-isp2 0000:00:03.0: can't change power state from D3cold to D0 (config space inaccessible) kern :warn : [25507.627355] isys dma store at addr(0xcd408) val(0) kern :err : [25507.628391] atomisp-isp2 0000:00:03.0: atomisp_queryctl(): asd is NULL, device is ATOMISP ISP ACC kern :err : [25507.631143] atomisp-isp2 0000:00:03.0: can't change power state from D3cold to D0 (config space inaccessible) kern :warn : [25507.635813] isys dma store at addr(0xcd408) val(0) kern :err : [25507.636489] atomisp-isp2 0000:00:03.0: atomisp_queryctl(): asd is NULL, device is ATOMISP ISP ACC kern :err : [25507.636504] atomisp-isp2 0000:00:03.0: atomisp_s_input(): asd is NULL, device is ATOMISP ISP ACC kern :err : [25507.636516] atomisp-isp2 0000:00:03.0: atomisp_set_fmt(): asd is NULL, device is ATOMISP ISP ACC kern :err : [25507.639111] atomisp-isp2 0000:00:03.0: can't change power state from D3cold to D0 (config space inaccessible) kern :warn : [25507.646152] isys dma store at addr(0xcd408) val(0) kern :err : [25507.646831] atomisp-isp2 0000:00:03.0: atomisp_queryctl(): asd is NULL, device is ATOMISP ISP ACC kern :err : [25507.646847] atomisp-isp2 0000:00:03.0: atomisp_s_input(): asd is NULL, device is ATOMISP ISP ACC kern :err : [25507.650079] atomisp-isp2 0000:00:03.0: can't change power state from D3cold to D0 (config space inaccessible) kern :warn : [25507.657476] isys dma store at addr(0xcd408) val(0) kern :err : [25507.658741] atomisp-isp2 0000:00:03.0: atomisp_queryctl(): asd is NULL, device is ATOMISP ISP ACC kern :err : [25507.658759] atomisp-isp2 0000:00:03.0: atomisp_s_input(): asd is NULL, device is ATOMISP ISP ACC kern :err : [25507.658771] atomisp-isp2 0000:00:03.0: atomisp_set_fmt(): asd is NULL, device is ATOMISP ISP ACC kern :err : [25507.660959] atomisp-isp2 0000:00:03.0: can't change power state from D3cold to D0 (config space inaccessible) kern :warn : [25507.666665] isys dma store at addr(0xcd408) val(0) kern :err : [25507.667397] atomisp-isp2 0000:00:03.0: atomisp_queryctl(): asd is NULL, device is ATOMISP ISP ACC [mchehab: fix coding style] Signed-off-by: Tsuchiya Yuto <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 124fd314c5fed5826f586b142eba39f451e8eda8 Author: Tsuchiya Yuto <[email protected]> Date: Mon Oct 18 01:19:47 2021 +0900 media: atomisp: fix ifdefs in sh_css.c [ Upstream commit 5a1b2725558f8a3b4cbf0504f53cffae8e163034 ] ## `if (pipe->stream->config.mode == IA_CSS_INPUT_MODE_TPG) {` case The intel-aero atomisp has `#if defined(IS_ISP_2400_SYSTEM)` [1]. It is to be defined in the following two places [2]: - css/hive_isp_css_common/system_global.h - css/css_2401_csi2p_system/system_global.h and the former file is to be included on ISP2400 devices, too. So, it is to be defined for both ISP2400 and ISP2401 devices. Because the upstreamed atomisp driver now supports only ISP2400 and ISP2401, just remove the ISP version test again. This matches the other upstream commits like 3c0538fbad9f ("media: atomisp: get rid of most checks for ISP2401 version"). While here, moved the comment for define GP_ISEL_TPG_MODE to the appropriate place. [1] https://github.com/intel-aero/linux-kernel/blob/a1b673258feb915268377275130c5c5df0eafc82/drivers/media/pci/atomisp/css/sh_css.c#L552-L558 [2] https://github.com/intel-aero/linux-kernel/search?q=IS_ISP_2400_SYSTEM ## `isys_stream_descr->polling_mode` case This does not exist on the intel-aero atomisp. This is because it is based on css version irci_stable_candrpv_0415_20150521_0458. On the other hand, the upstreamed atomisp is based on the following css version depending on the ISP version using ifdefs: - ISP2400: irci_stable_candrpv_0415_20150521_0458 - ISP2401: irci_master_20150911_0724 The `isys_stream_descr->polling_mode` usage was added on updating css version to irci_master_20150701_0213 [3]. So, it is not a ISP version specific thing, but css version specific thing. Because the upstreamed atomisp driver uses irci_master_20150911_0724 for ISP2401, re-add the ISP version check for now. I say "for now" because ISP2401 should eventually use the same css version with ISP2400 (i.e., irci_stable_candrpv_0415_20150521_0458) [3] https://raw.githubusercontent.com/intel/ProductionKernelQuilts/cht-m1stable-2016_ww31/uefi/cht-m1stable/patches/cam-0439-atomisp2-css2401-and-2401_legacy-irci_master_2015070.patch ("atomisp2: css2401 and 2401_legacy-irci_master_20150701_0213") Link to Intel's Android kernel patch. ## `coord = &me->config.internal_frame_origin_bqs_on_sctbl;` case it was added on commit 4f744a573db3 ("media: atomisp: make sh_css_sp_init_pipeline() ISP version independent") for ISP2401. Because the upstreamed atomisp for the ISP2401 part is based on irci_master_20150911_0724, hence the difference. Because the upstreamed atomisp driver uses irci_master_20150911_0724 for ISP2401, revert the test back to `if (IS_ISP2401)`. Fixes: 27333dadef57 ("media: atomisp: adjust some code at sh_css that could be broken") Signed-off-by: Tsuchiya Yuto <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 0224641992e1669c9da04eada919d66b9a20f2b0 Author: Tsuchiya Yuto <[email protected]> Date: Mon Oct 18 01:19:45 2021 +0900 media: atomisp: fix inverted error check for ia_css_mipi_is_source_port_valid() [ Upstream commit d21ce8c2f7bf6d737b60c09f86db141b9e8e47f0 ] The function ia_css_mipi_is_source_port_valid() returns true if the port is valid. So, we can't use the existing err variable as is. To fix this issue while reusing that variable, invert the return value when assigning it to the variable. Fixes: 3c0538fbad9f ("media: atomisp: get rid of most checks for ISP2401 version") Signed-off-by: Tsuchiya Yuto <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 4de485f6d5fedc00c3b98ac38587afdbd61c28c6 Author: Tsuchiya Yuto <[email protected]> Date: Mon Oct 18 01:19:44 2021 +0900 media: atomisp: do not use err var when checking port validity for ISP2400 [ Upstream commit 9f6b4fa2d2dfbff4b8a57eeb39b1128a6094ee20 ] Currently, the `port >= N_CSI_PORTS || err` checks for ISP2400 are always evaluated as true because the err variable is set to `-EINVAL` on declaration but the variable is never used until the evaluation. Looking at the diff of commit 3c0538fbad9f ("media: atomisp: get rid of most checks for ISP2401 version"), the `port >= N_CSI_PORTS` check is for ISP2400 and the err variable check is for ISP2401. Fix this issue by adding ISP version test there accordingly. Fixes: 3c0538fbad9f ("media: atomisp: get rid of most checks for ISP2401 version") Signed-off-by: Tsuchiya Yuto <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit b7033740e36783e54d83984dd4c00c4e535de004 Author: Tsuchiya Yuto <[email protected]> Date: Mon Oct 18 01:19:43 2021 +0900 media: atomisp: fix inverted logic in buffers_needed() [ Upstream commit e1921cd14640f0f4d1fad5eb8e448c58a536415d ] When config.mode is IA_CSS_INPUT_MODE_BUFFERED_SENSOR, it rather needs buffers. Fix it by inverting the return value. Fixes: 3c0538fbad9f ("media: atomisp: get rid of most checks for ISP2401 version") Signed-off-by: Tsuchiya Yuto <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit bb8ac1ec5a8266f7ff4894330f7a8fc0124ae4bf Author: Tsuchiya Yuto <[email protected]> Date: Mon Oct 18 01:19:42 2021 +0900 media: atomisp: fix punit_ddr_dvfs_enable() argument for mrfld_power up case [ Upstream commit 5bfbf65fcca7325e4d89d289b3c286e11220e386 ] When comparing with intel-aero atomisp [1], it looks like punit_ddr_dvfs_enable() should take `false` as an argument on mrfld_power up case. Code from the intel-aero kernel [1]: int atomisp_mrfld_power_down(struct atomisp_device *isp) { [...] /*WA:Enable DVFS*/ if (IS_CHT) punit_ddr_dvfs_enable(true); int atomisp_mrfld_power_up(struct atomisp_device *isp) { [...] /*WA for PUNIT, if DVFS enabled, ISP timeout observed*/ if (IS_CHT) punit_ddr_dvfs_enable(false); This patch fixes the inverted argument as per the intel-aero code, as well as its comment. While here, fix space issues for comments in atomisp_mrfld_power(). Note that it does not seem to be possible to unify the up/down cases for punit_ddr_dvfs_enable(), i.e., we can't do something like the following: if (IS_CHT) punit_ddr_dvfs_enable(!enable); because according to the intel-aero code [1], the DVFS is disabled before "writing 0x0 to ISPSSPM0 bit[1:0]" and the DVFS is enabled after "writing 0x3 to ISPSSPM0 bit[1:0]". [1] https://github.com/intel-aero/linux-kernel/blob/a1b673258feb915268377275130c5c5df0eafc82/drivers/media/pci/atomisp/atomisp_driver/atomisp_v4l2.c#L431-L514 Fixes: 0f441fd70b1e ("media: atomisp: simplify the power down/up code") Signed-off-by: Tsuchiya Yuto <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 6c3547e103e4c68199df678a676ca45f55da1248 Author: Tsuchiya Yuto <[email protected]> Date: Mon Oct 18 01:19:41 2021 +0900 media: atomisp: add missing media_device_cleanup() in atomisp_unregister_entities() [ Upstream commit ce3015b7212e96db426d0c36f80fd159c91155d1 ] After the commit 9832e155f1ed ("[media] media-device: split media initialization and registration"), calling media_device_cleanup() is needed it seems. However, currently it is missing for the module unload path. Note that for the probe failure path, it is already added in atomisp_register_entities(). This patch adds the missing call of media_device_cleanup() in atomisp_unregister_entities(). Fixes: a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2") Signed-off-by: Tsuchiya Yuto <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 26e8cd84d7d2cd8529092bae62549c33d60f2624 Author: Dillon Min <[email protected]> Date: Tue Oct 19 09:43:19 2021 +0100 media: videobuf2: Fix the size printk format [ Upstream commit c9ee220d76775e42f35d634479c978d9350077d3 ] Since the type of parameter size is unsigned long, it should printk by %lu, instead of %ld, fix it. Fixes: 7952be9b6ece ("media: drivers/media/common/videobuf2: rename from videobuf") Signed-off-by: Dillon Min <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 6b3a83a450ddc2c8de5eeae2fd18e713b328627e Author: Lad Prabhakar <[email protected]> Date: Mon Oct 25 21:56:28 2021 +0100 mtd: hyperbus: rpc-if: Check return value of rpcif_sw_init() [ Upstream commit 981387ed06b96908223a607f5fba6efa42728fc2 ] rpcif_sw_init() can fail so make sure we check the return value of it and on error exit rpcif_hb_probe() callback with error code. Fixes: 5de15b610f78 ("mtd: hyperbus: add Renesas RPC-IF driver") Signed-off-by: Lad Prabhakar <[email protected]> Signed-off-by: Vignesh Raghavendra <[email protected]> Reviewed-by: Biju Das <[email protected]> Reviewed-by: Wolfram Sang <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 77d19bad301facba3fdb33da69584e000c6985f1 Author: Quentin Monnet <[email protected]> Date: Wed Nov 10 11:46:27 2021 +0000 bpftool: Fix memory leak in prog_dump() [ Upstream commit ebbd7f64a3fbe9e0f235e39fc244ee9735e2a52a ] Following the extraction of prog_dump() from do_dump(), the struct btf allocated in prog_dump() is no longer freed on error; the struct bpf_prog_linfo is not freed at all. Make sure we release them before exiting the function. Fixes: ec2025095cf6 ("bpftool: Match several programs with same tag") Signed-off-by: Quentin Monnet <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 9f3cbc3ba5adf9973e7252039f5ca2cae945baed Author: Rameshkumar Sundaram <[email protected]> Date: Wed Nov 10 17:10:48 2021 +0200 ath11k: Send PPDU_STATS_CFG with proper pdev mask to firmware [ Upstream commit 16a2c3d5406f95ef6139de52669c60a39443f5f7 ] HTT_PPDU_STATS_CFG_PDEV_ID bit mask for target FW PPDU stats request message was set as bit 8 to 15. Bit 8 is reserved for soc stats and pdev id starts from bit 9. Hence change the bitmask as bit 9 to 15 and fill the proper pdev id in the request message. In commit 701e48a43e15 ("ath11k: add packet log support for QCA6390"), both HTT_PPDU_STATS_CFG_PDEV_ID and pdev_mask were changed, but this pdev_mask calculation is not valid for platforms which has multiple pdevs with 1 rxdma per pdev, as this is writing same value(i.e. 2) for all pdevs. Hence fixed it to consider pdev_idx as well, to make it compatible for both single and multi pd cases. Tested on: IPQ8074 hw2.0 AHB WLAN.HK.2.5.0.1-01092-QCAHKSWPL_SILICONZ-1 Tested on: IPQ6018 hw1.0 WLAN.HK.2.5.0.1-01067-QCAHKSWPL_SILICONZ-1 Fixes: 701e48a43e15 ("ath11k: add packet log support for QCA6390") Co-developed-by: Sathishkumar Muruganandam <[email protected]> Signed-off-by: Sathishkumar Muruganandam <[email protected]> Signed-off-by: Rameshkumar Sundaram <[email protected]> Signed-off-by: Jouni Malinen <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 26b9d4ac42abaebaefc67a5fe583e764f770f44f Author: Benjamin Li <[email protected]> Date: Wed Nov 3 18:05:48 2021 -0700 wcn36xx: fix RX BD rate mapping for 5GHz legacy rates [ Upstream commit cfdf6b19e750f7de8ae71a26932f63b52e3bf74c ] The linear mapping between the BD rate field and the driver's 5GHz legacy rates table (wcn_5ghz_rates) does not only apply for the latter four rates -- it applies to all eight rates. Fixes: 6ea131acea98 ("wcn36xx: Fix warning due to bad rate_idx") Signed-off-by: Benjamin Li <[email protected]> Tested-by: Loic Poulain <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 3913db56e47147742d6dc84ebd06f50ed3688bb9 Author: Benjamin Li <[email protected]> Date: Wed Nov 3 18:05:47 2021 -0700 wcn36xx: populate band before determining rate on RX [ Upstream commit c9c5608fafe4dae975c9644c7d14c51ad3b0ed73 ] status.band is used in determination of status.rate -- for 5GHz on legacy rates there is a linear shift between the BD descriptor's rate field and the wcn36xx driver's rate table (wcn_5ghz_rates). We have a special clause to populate status.band for hardware scan offload frames. However, this block occurs after status.rate is already populated. Correctly handle this dependency by moving the band block before the rate block. This patch addresses kernel warnings & missing scan results for 5GHz APs that send their beacons/probe responses at the higher four legacy rates (24-54 Mbps), when using hardware scan offload: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at net/mac80211/rx.c:4532 ieee80211_rx_napi+0x744/0x8d8 Modules linked in: wcn36xx [...] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 4.19.107-g73909fa #1 Hardware name: Square, Inc. T2 (all variants) (DT) Call trace: dump_backtrace+0x0/0x148 show_stack+0x14/0x1c dump_stack+0xb8/0xf0 __warn+0x2ac/0x2d8 warn_slowpath_null+0x44/0x54 ieee80211_rx_napi+0x744/0x8d8 ieee80211_tasklet_handler+0xa4/0xe0 tasklet_action_common+0xe0/0x118 tasklet_action+0x20/0x28 __do_softirq+0x108/0x1ec irq_exit+0xd4/0xd8 __handle_domain_irq+0x84/0xbc gic_handle_irq+0x4c/0xb8 el1_irq+0xe8/0x190 lpm_cpuidle_enter+0x220/0x260 cpuidle_enter_state+0x114/0x1c0 cpuidle_enter+0x34/0x48 do_idle+0x150/0x268 cpu_startup_entry+0x20/0x24 rest_init+0xd4/0xe0 start_kernel+0x398/0x430 ---[ end trace ae28cb759352b403 ]--- Fixes: 8a27ca394782 ("wcn36xx: Correct band/freq reporting on RX") Signed-off-by: Benjamin Li <[email protected]> Tested-by: Loic Poulain <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit d97aa008ebc0bde2d96a7097ef8ba1a188fafbb3 Author: Bryan O'Donoghue <[email protected]> Date: Fri Nov 5 12:21:52 2021 +0000 wcn36xx: Put DXE block into reset before freeing memory [ Upstream commit ed04ea76e69e7194f7489cebe23a32a68f39218d ] When deiniting the DXE hardware we should reset the block to ensure there is no spurious DMA write transaction from the downstream WCNSS to upstream MSM at a skbuff address we will have released. Fixes: 8e84c2582169 ("wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 hardware") Signed-off-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 514c1df9dfa9357238f9aefebc74667fa5ea741e Author: Bryan O'Donoghue <[email protected]> Date: Fri Nov 5 12:21:51 2021 +0000 wcn36xx: Release DMA channel descriptor allocations [ Upstream commit 3652096e5263ad67604b0323f71d133485f410e5 ] When unloading the driver we are not releasing the DMA descriptors which we previously allocated. Fixes: 8e84c2582169 ("wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 hardware") Signed-off-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 8da7a0e26c4a283e9097a4b1413a7b8a2e628fbf Author: Bryan O'Donoghue <[email protected]> Date: Fri Nov 5 12:21:50 2021 +0000 wcn36xx: Fix DMA channel enable/disable cycle [ Upstream commit 89dcb1da611d9b3ff0728502d58372fdaae9ebff ] Right now we have a broken sequence where we enable DMA channel interrupts which can be left enabled and never disabled if we hit an error path. Worse still when we unload the driver, the DMA channel interrupt bits are left intact. About the only saving grace here is that we do remember to disable the wcnss interrupt when unload the driver. Fixes: 8e84c2582169 ("wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 hardware") Signed-off-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit a3ec2b9456eb8155772dadef6411985be876b188 Author: Andrii Nakryiko <[email protected]> Date: Sun Nov 7 08:55:14 2021 -0800 libbpf: Free up resources used by inner map definition [ Upstream commit 8f7b239ea8cfdc8e64c875ee417fed41431a1f37 ] It's not enough to just free(map->inner_map), as inner_map itself can have extra memory allocated, like map name. Fixes: 646f02ffdd49 ("libbpf: Add BTF-defined map-in-map support") Signed-off-by: Andrii Nakryiko <[email protected]> Signed-off-by: Alexei Starovoitov <[email protected]> Reviewed-by: Hengqi Chen <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 620a2ee5505921521f47da78db01f846a818fab0 Author: Maxime Ripard <[email protected]> Date: Mon Oct 25 17:29:02 2021 +0200 drm/vc4: hdmi: Enable the scrambler on reconnection [ Upstream commit b7551457c5d0b3505b0be247d47919c1ee30506d ] If we have a state already and disconnect/reconnect the display, the SCDC messages won't be sent again since we didn't go through a disable / enable cycle. In order to fix this, let's call the vc4_hdmi_enable_scrambling function in the detect callback if there is a mode and it needs the scrambler to be enabled. Fixes: c85695a2016e ("drm/vc4: hdmi: Enable the scrambler") Signed-off-by: Maxime Ripard <[email protected]> Reviewed-by: Dave Stevenson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 23d2c4eb76d680f6df7733083e080b16bd9ae8ff Author: Bryan O'Donoghue <[email protected]> Date: Thu Oct 28 00:25:29 2021 +0100 wcn36xx: Indicate beacon not connection loss on MISSED_BEACON_IND [ Upstream commit 588b45c88ae130fe373a8c50edaf54735c3f4fe3 ] Firmware can trigger a missed beacon indication, this is not the same as a lost signal. Flag to Linux the missed beacon and let the WiFi stack decide for itself if the link is up or down by sending its own probe to determine this. We should only be signalling the link is lost when the firmware indicates Fixes: 8e84c2582169 ("wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 hardware") Signed-off-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit a33fc07affe582f2263f8ee8fbcb9778888e48b3 Author: Benjamin Li <[email protected]> Date: Wed Oct 27 10:03:05 2021 -0700 wcn36xx: ensure pairing of init_scan/finish_scan and start_scan/end_scan [ Upstream commit 8f1ba8b0ee2679f0b3d22d2a5c1bc70c436fd872 ] An SMD capture from the downstream prima driver on WCN3680B shows the following command sequence for connected scans: - init_scan_req - start_scan_req, channel 1 - end_scan_req, channel 1 - start_scan_req, channel 2 - ... - end_scan_req, channel 3 - finish_scan_req - init_scan_req - start_scan_req, channel 4 - ... - end_scan_req, channel 6 - finish_scan_req - ... - end_scan_req, channel 165 - finish_scan_req Upstream currently never calls wcn36xx_smd_end_scan, and in some cases[1] still sends finish_scan_req twice in a row or before init_scan_req. A typical connected scan looks like this: - init_scan_req - start_scan_req, channel 1 - finish_scan_req - init_scan_req - start_scan_req, channel 2 - ... - start_scan_req, channel 165 - finish_scan_req - finish_scan_req This patch cleans up scanning so that init/finish and start/end are always paired together and correctly nested. - init_scan_req - start_scan_req, channel 1 - end_scan_req, channel 1 - finish_scan_req - init_scan_req - start_scan_req, channel 2 - end_scan_req, channel 2 - ... - start_scan_req, channel 165 - end_scan_req, channel 165 - finish_scan_req Note that upstream will not do batching of 3 active-probe scans before returning to the operating channel, and this patch does not change that. To match downstream in this aspect, adjust IEEE80211_PROBE_DELAY and/or the 125ms max off-channel time in ieee80211_scan_state_decision. [1]: commit d195d7aac09b ("wcn36xx: Ensure finish scan is not requested before start scan") addressed one case of finish_scan_req being sent without a preceding init_scan_req (the case of the operating channel coinciding with the first scan channel); two other cases are: 1) if SW scan is started and aborted immediately, without scanning any channels, we send a finish_scan_req without ever sending init_scan_req, and 2) as SW scan logic always returns us to the operating channel before calling wcn36xx_sw_scan_complete, finish_scan_req is always sent twice at the end of a SW scan Fixes: 8e84c2582169 ("wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 hardware") Signed-off-by: Benjamin Li <[email protected]> Tested-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 8c3830446ccc6073140fa80056f361c65083db11 Author: Maxime Ripard <[email protected]> Date: Thu Sep 23 20:50:13 2021 +0200 drm/vc4: crtc: Make sure the HDMI controller is powered when disabling [ Upstream commit bca10db67bdaf15997a5a2a276e7aa9b6eea1393 ] Since commit 875a4d536842 ("drm/vc4: drv: Disable the CRTC at boot time"), during the initial setup of the driver we call into the VC4 HDMI controller hooks to make sure the controller is properly disabled. However, we were never making sure that the device was properly powered while doing so. This never resulted in any (reported) issue in practice, but since the introduction of commit 4209f03fcb8e ("drm/vc4: hdmi: Warn if we access the controller while disabled") we get a loud complaint when we do that kind of access. Let's make sure we have the HDMI controller properly powered while disabling it. Fixes: 875a4d536842 ("drm/vc4: drv: Disable the CRTC at boot time") Signed-off-by: Maxime Ripard <[email protected]> Reviewed-by: Nicolas Saenz Julienne <[email protected]> Tested-by: Nicolas Saenz Julienne <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 2bba39feaa3e9c029d882cc8b5715740ebbcda0f Author: Maxime Ripard <[email protected]> Date: Thu Aug 19 15:59:28 2021 +0200 drm/vc4: hdmi: Rework the pre_crtc_configure error handling [ Upstream commit caa51a4c11f1cadba9bcf61ed9e0105711952ce7 ] Since our pre_crtc_configure hook returned void, we didn't implement a goto-based error path handling, leading to errors like failing to put back the device in pm_runtime in all the error paths, but also failing to disable the pixel clock if clk_set_min_rate on the HSM clock fails. Move to a goto-based implementation to have an easier consitency. Fixes: 4f6e3d66ac52 ("drm/vc4: Add runtime PM support to the HDMI encoder driver") Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Dave Stevenson <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit a26aa0f3982f8bb3f8630cd0db81f9cd4d55f14d Author: Maxime Ripard <[email protected]> Date: Thu Aug 19 15:59:27 2021 +0200 drm/vc4: hdmi: Make sure the controller is powered up during bind [ Upstream commit 9c6e4f6ed1d61d5f46946e5c151ceb279eedadb1 ] In the bind hook, we actually need the device to have the HSM clock running during the final part of the display initialisation where we reset the controller and initialise the CEC component. Failing to do so will result in a complete, silent, hang of the CPU. Fixes: 411efa18e4b0 ("drm/vc4: hdmi: Move the HSM clock enable to runtime_pm") Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Dave Stevenson <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit e3e8f46f36e057404657d1b9858fa7473a967d81 Author: Maxime Ripard <[email protected]> Date: Wed Sep 22 14:54:19 2021 +0200 drm/vc4: hdmi: Make sure the controller is powered in detect [ Upstream commit 0f5251339eda7f7eb7bd4467607ae1d01b24e129 ] If the HPD GPIO is not available and drm_probe_ddc fails, we end up reading the HDMI_HOTPLUG register, but the controller might be powered off resulting in a CPU hang. Make sure we have the power domain and the HSM clock powered during the detect cycle to prevent the hang from happening. Fixes: 4f6e3d66ac52 ("drm/vc4: Add runtime PM support to the HDMI encoder driver") Signed-off-by: Maxime Ripard <[email protected]> Reviewed-by: Dave Stevenson <[email protected]> Reviewed-by: Nicolas Saenz Julienne <[email protected]> Tested-by: Nicolas Saenz Julienne <[email protected]> Tested-by: Michael Stapelberg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit b9b1fbe61ff1b9c9715804c0d5ef9e26a2b20f86 Author: Maxime Ripard <[email protected]> Date: Wed Sep 22 14:54:18 2021 +0200 drm/vc4: hdmi: Move the HSM clock enable to runtime_pm [ Upstream commit c86b41214362e8e715e1343e16d5d6af0562db05 ] In order to access the HDMI controller, we need to make sure the HSM clock is enabled. If we were to access it with the clock disabled, the CPU would completely hang, resulting in an hard crash. Since we have different code path that would require it, let's move that clock enable / disable to runtime_pm that will take care of the reference counting for us. Since we also want to change the HSM clock rate and it's only valid while the clock is disabled, we need to move the clk_set_min_rate() call on the HSM clock above pm_runtime_get_and_sync(). Fixes: 4f6e3d66ac52 ("drm/vc4: Add runtime PM support to the HDMI encoder driver") Signed-off-by: Maxime Ripard <[email protected]> Reviewed-by: Dave Stevenson <[email protected]> Reviewed-by: Nicolas Saenz Julienne <[email protected]> Tested-by: Nicolas Saenz Julienne <[email protected]> Tested-by: Michael Stapelberg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Link: https://lore.kernel.org/linux-arm-kernel/[email protected]/ Signed-off-by: Sasha Levin <[email protected]> commit 2d717d82267550260e4a31e6980d42585dc2f745 Author: Maxime Ripard <[email protected]> Date: Wed Sep 22 14:54:17 2021 +0200 drm/vc4: hdmi: Set a default HSM rate [ Upstream commit 3e85b81591609bb794bb00cd619b20965b5b38cd ] When the firmware doesn't setup the HSM rate (such as when booting without an HDMI cable plugged in), its rate is 0 and thus any register access results in a CPU stall, even though HSM is enabled. Let's enforce a minimum rate at boot to avoid this issue. Fixes: 4f6e3d66ac52 ("drm/vc4: Add runtime PM support to the HDMI encoder driver") Signed-off-by: Maxime Ripard <[email protected]> Reviewed-by: Nicolas Saenz Julienne <[email protected]> Tested-by: Nicolas Saenz Julienne <[email protected]> Tested-by: Michael Stapelberg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 49b570f5d2e4c8ec6f83d2d92fa0a523a367db86 Author: Maxime Ripard <[email protected]> Date: Wed Sep 22 14:54:16 2021 +0200 clk: bcm-2835: Remove rounding up the dividers [ Upstream commit 8ca011ef4af48a7af7b15afd8a4a44039dd04cea ] The driver, once it found a divider, tries to round it up by increasing the least significant bit of the fractional part by one when the round_up argument is set and there's a remainder. However, since it increases the divider it will actually reduce the clock rate below what we were asking for, leading to issues with clk_set_min_rate() that will complain that our rounded clock rate is below the minimum of the rate. Since the dividers are fairly precise already, let's remove that part so that we can have clk_set_min_rate() working. This is effectively a revert of 9c95b32ca093 ("clk: bcm2835: add a round up ability to the clock divisor"). Fixes: 9c95b32ca093 ("clk: bcm2835: add a round up ability to the clock divisor") Signed-off-by: Maxime Ripard <[email protected]> Acked-by: Stephen Boyd <[email protected]> Reviewed-by: Nicolas Saenz Julienne <[email protected]> Tested-by: Nicolas Saenz Julienne <[email protected]> # boot and basic functionality Tested-by: Michael Stapelberg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 2ff7b32f6b3efbf021c151c01208386e62618aac Author: Maxime Ripard <[email protected]> Date: Wed Sep 22 14:54:15 2021 +0200 clk: bcm-2835: Pick the closest clock rate [ Upstream commit 5517357a4733d7cf7c17fc79d0530cfa47add372 ] The driver currently tries to pick the closest rate that is lower than the rate being requested. This causes an issue with clk_set_min_rate() since it actively checks for the rounded rate to be above the minimum that was just set. Let's change the logic a bit to pick the closest rate to the requested rate, no matter if it's actually higher or lower. Fixes: 6d18b8adbe67 ("clk: bcm2835: Support for clock parent selection") Signed-off-by: Maxime Ripard <[email protected]> Acked-by: Stephen Boyd <[email protected]> Reviewed-by: Nicolas Saenz Julienne <[email protected]> Tested-by: Nicolas Saenz Julienne <[email protected]> # boot and basic functionality Tested-by: Michael Stapelberg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit d2e7a4d20f7c5c6157901c231b6c71ecc6943d24 Author: Wang Hai <[email protected]> Date: Mon Oct 25 21:10:12 2021 +0800 Bluetooth: cmtp: fix possible panic when cmtp_init_sockets() fails [ Upstream commit 2a7ca7459d905febf519163bd9e3eed894de6bb7 ] I got a kernel BUG report when doing fault injection test: ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:45! ... RIP: 0010:__list_del_entry_valid.cold+0x12/0x4d ... Call Trace: proto_unregister+0x83/0x220 cmtp_cleanup_sockets+0x37/0x40 [cmtp] cmtp_exit+0xe/0x1f [cmtp] do_syscall_64+0x35/0xb0 entry_SYSCALL_64_after_hwframe+0x44/0xae If cmtp_init_sockets() in cmtp_init() fails, cmtp_init() still returns success. This will cause a kernel bug when accessing uncreated ctmp related data when the module exits. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Hulk Robot <[email protected]> Signed-off-by: Wang Hai <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 1f2270e161f978912100dd7acdfe1894bebcd4f6 Author: Soenke Huster <[email protected]> Date: Wed Oct 20 10:14:44 2021 +0200 Bluetooth: virtio_bt: fix memory leak in virtbt_rx_handle() [ Upstream commit 1d0688421449718c6c5f46e458a378c9b530ba18 ] On the reception of packets with an invalid packet type, the memory of the allocated socket buffers is never freed. Add a default case that frees these to avoid a memory leak. Fixes: afd2daa26c7a ("Bluetooth: Add support for virtio transport driver") Signed-off-by: Soenke Huster <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit f28d819f17d35a4ac603157dcbfaf20c16346bcb Author: Brian Norris <[email protected]> Date: Tue Sep 28 14:35:50 2021 -0700 drm/rockchip: dsi: Reconfigure hardware on resume() commit e584cdc1549932f87a2707b56bc588cfac5d89e0 upstream. Since commit 43c2de1002d2 ("drm/rockchip: dsi: move all lane config except LCDC mux to bind()"), we perform most HW configuration in the bind() function. This configuration may be lost on suspend/resume, so we need to call it again. That may lead to errors like this after system suspend/resume: dw-mipi-dsi-rockchip ff968000.mipi: failed to write command FIFO panel-kingdisplay-kd097d04 ff960000.mipi.0: failed write init cmds: -110 Tested on Acer Chromebook Tab 10 (RK3399 Gru-Scarlet). Note that early mailing list versions of this driver borrowed Rockchip's downstream/BSP solution, to do HW configuration in mode_set() (which *is* called at the appropriate pre-enable() times), but that was discarded along the way. I've avoided that still, because mode_set() documentation doesn't suggest this kind of purpose as far as I can tell. Fixes: 43c2de1002d2 ("drm/rockchip: dsi: move all lane config except LCDC mux to bind()") Cc: <[email protected]> Signed-off-by: Brian Norris <[email protected]> Reviewed-by: Chen-Yu Tsai <[email protected]> Tested-by: Nícolas F. R. A. Prado <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20210928143413.v3.2.I4e9d93aadb00b1ffc7d506e3186a25492bf0b732@changeid Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 506bae94333b67d54f38d4021c2bbb32d8c58fa5 Author: Brian Norris <[email protected]> Date: Tue Sep 28 14:35:52 2021 -0700 drm/rockchip: dsi: Disable PLL clock on bind error [ Upstream commit 5a614570172e1c9f59035d259dd735acd4f1c01b ] Fix some error handling here noticed in review of other changes. Fixes: 2d4f7bdafd70 ("drm/rockchip: dsi: migrate to use dw-mipi-dsi bridge driver") Signed-off-by: Brian Norris <[email protected]> Reported-by: Chen-Yu Tsai <[email protected]> Reviewed-by: Chen-Yu Tsai <[email protected]> Tested-by: Nícolas F. R. A. Prado <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20210928143413.v3.4.I8bb7a91ecc411d56bc155763faa15f289d7fc074@changeid Signed-off-by: Sasha Levin <[email protected]> commit 4f005cef1d5a7fb332d6b8998c7c758578d72d45 Author: Brian Norris <[email protected]> Date: Tue Sep 28 14:35:49 2021 -0700 drm/rockchip: dsi: Hold pm-runtime across bind/unbind commit 514db871922f103886ad4d221cf406b4fcc5e74a upstream. In commit 43c2de1002d2 ("drm/rockchip: dsi: move all lane config except LCDC mux to bind()"), we moved most HW configuration to bind(), but we didn't move the runtime PM management. Therefore, depending on initial boot state, runtime-PM workqueue delays, and other timing factors, we may disable our power domain in between the hardware configuration (bind()) and when we enable the display. This can cause us to lose hardware state and fail to configure our display. For example: dw-mipi-dsi-rockchip ff968000.mipi: failed to write command FIFO panel-innolux-p079zca ff960000.mipi.0: failed to write command 0 or: dw-mipi-dsi-rockchip ff968000.mipi: failed to write command FIFO panel-kingdisplay-kd097d04 ff960000.mipi.0: failed write init cmds: -110 We should match the runtime PM to the lifetime of the bind()/unbind() cycle. Tested on Acer Chrometab 10 (RK3399 Gru-Scarlet), with panel drivers built either as modules or built-in. Side notes: it seems one is more likely to see this problem when the panel driver is built into the kernel. I've also seen this problem bisect down to commits that simply changed Kconfig dependencies, because it changed the order in which driver init functions were compiled into the kernel, and therefore the ordering and timing of built-in device probe. Fixes: 43c2de1002d2 ("drm/rockchip: dsi: move all lane config except LCDC mux to bind()") Link: https://lore.kernel.org/linux-rockchip/[email protected]/ Reported-by: <[email protected]> Cc: <[email protected]> Signed-off-by: Brian Norris <[email protected]> Tested-by: Nícolas F. R. A. Prado <[email protected]> Reviewed-by: Chen-Yu Tsai <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20210928143413.v3.1.Ic2904d37f30013a7f3d8476203ad3733c186827e@changeid Signed-off-by: Greg Kroah-Hartman <[email protected]> commit dd0ed218c0bf2f81f508db4611e274ab64691c1b Author: Brian Norris <[email protected]> Date: Tue Sep 28 14:35:51 2021 -0700 drm/rockchip: dsi: Fix unbalanced clock on probe error [ Upstream commit 251888398753924059f3bb247a44153a2853137f ] Our probe() function never enabled this clock, so we shouldn't disable it if we fail to probe the bridge. Noted by inspection. Fixes: 2d4f7bdafd70 ("drm/rockchip: dsi: migrate to use dw-mipi-dsi bridge driver") Signed-off-by: Brian Norris <[email protected]> Reviewed-by: Chen-Yu Tsai <[email protected]> Tested-by: Nícolas F. R. A. Prado <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20210928143413.v3.3.Ie8ceefb51ab6065a1151869b6fcda41a467d4d2c@changeid Signed-off-by: Sasha Levin <[email protected]> commit 1a943d8ad9c022e1aedf3329660a7ad51949986b Author: Brian Norris <[email protected]> Date: Thu Sep 23 17:33:54 2021 -0700 drm/panel: innolux-p079zca: Delete panel on attach() failure [ Upstream commit 32a267e9c057e1636e7afdd20599aa5741a73079 ] If we fail to attach (e.g., because 1 of 2 dual-DSI controllers aren't ready), we leave a dangling drm_panel reference to freed memory. Clean that up on failure. This problem exists since the driver's introduction, but is especially relevant after refactored for dual-DSI variants. Fixes: 14c8f2e9f8ea ("drm/panel: add Innolux P079ZCA panel driver") Fixes: 7ad4e4636c54 ("drm/panel: p079zca: Refactor panel driver to support multiple panels") Signed-off-by: Brian Norris <[email protected]> Signed-off-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20210923173336.2.I9023cf8811a3abf4964ed84eb681721d8bb489d6@changeid Signed-off-by: Sasha Levin <[email protected]> commit 92082e300373e445d07338ed6acdf77997a836fb Author: Brian Norris <[email protected]> Date: Thu Sep 23 17:33:53 2021 -0700 drm/panel: kingdisplay-kd097d04: Delete panel on attach() failure [ Upstream commit 5f31dbeae8a88f31c3eb4eb526ab4807c40da241 ] If we fail to attach (e.g., because 1 of 2 dual-DSI controllers aren't ready), we leave a dangling drm_panel reference to freed memory. Clean that up on failure. Fixes: 2a994cbed6b2 ("drm/panel: Add Kingdisplay KD097D04 panel driver") Signed-off-by: Brian Norris <[email protected]> Signed-off-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20210923173336.1.Icb4d9dbc1817f4e826361a4f1cea7461541668f0@changeid Signed-off-by: Sasha Levin <[email protected]> commit 52e1bf49e3e25358519719284028334cb31ab543 Author: Wang Hai <[email protected]> Date: Wed Oct 13 19:41:39 2021 +0800 drm: fix null-ptr-deref in drm_dev_init_release() [ Upstream commit acf20ed020ffa4d6cc8347e8d356509b95df3cbe ] I got a null-ptr-deref report: [drm:drm_dev_init [drm]] *ERROR* Cannot allocate anonymous inode: -12 ================================================================== BUG: KASAN: null-ptr-deref in iput+0x3c/0x4a0 ... Call Trace: dump_stack_lvl+0x6c/0x8b kasan_report.cold+0x64/0xdb __asan_load8+0x69/0x90 iput+0x3c/0x4a0 drm_dev_init_release+0x39/0xb0 [drm] drm_managed_release+0x158/0x2d0 [drm] drm_dev_init+0x3a7/0x4c0 [drm] __devm_drm_dev_alloc+0x55/0xd0 [drm] mi0283qt_probe+0x8a/0x2b5 [mi0283qt] spi_probe+0xeb/0x130 ... entry_SYSCALL_64_after_hwframe+0x44/0xae If drm_fs_inode_new() fails in drm_dev_init(), dev->anon_inode will point to PTR_ERR(...) instead of NULL. This will result in null-ptr-deref when drm_fs_inode_free(dev->anon_inode) is called. drm_dev_init() drm_fs_inode_new() // fail, dev->anon_inode = PTR_ERR(...) drm_managed_release() drm_dev_init_release() drm_fs_inode_free() // access non-existent anon_inode Define a temp variable and assign it to dev->anon_inode if the temp variable is not PTR_ERR. Fixes: 2cbf7fc6718b ("drm: Use drmm_ for drm_dev_init cleanup") Reported-by: Hulk Robot <[email protected]> Signed-off-by: Wang Hai <[email protected]> Signed-off-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 11182d953e64a16ea9f3b05e504a8bf3e36e173e Author: Dan Carpenter <[email protected]> Date: Wed Oct 13 11:08:25 2021 +0300 drm/bridge: display-connector: fix an uninitialized pointer in probe() [ Upstream commit 189723fbe9aca18d6f7d638c59a40288030932b5 ] The "label" pointer is used for debug output. The code assumes that it is either NULL or valid, but it is never set to NULL. It is either valid or uninitialized. Fixes: 0c275c30176b ("drm/bridge: Add bridge driver for display connectors") Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20211013080825.GE6010@kili Signed-off-by: Sasha Levin <[email protected]> commit 6c1ad4aeeab4d04b538efddeb84c5b51919526bb Author: Luiz Augusto von Dentz <[email protected]> Date: Thu Oct 7 13:26:25 2021 -0700 Bluetooth: L2CAP: Fix not initializing sk_peer_pid [ Upstream commit f5ff291098f70a70b344df1e388596755c3c8315 ] In order to group sockets being connected using L2CAP_MODE_EXT_FLOWCTL the pid is used but sk_peer_pid was not being initialized as it is currently only done for af_unix. Fixes: b48596d1dc25 ("Bluetooth: L2CAP: Add get_peer_pid callback") Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 0da09030aae4a3c9de4699e7ce71085639f8c378 Author: xinhui pan <[email protected]> Date: Wed Nov 10 12:31:48 2021 +0800 drm/ttm: Put BO in its memory manager's lru list commit 781050b0a3164934857c300bb0bc291e38c26b6f upstream. After we move BO to a new memory region, we should put it to the new memory manager's lru list regardless we unlock the resv or not. Cc: [email protected] Reviewed-by: Christian König <[email protected]> Signed-off-by: xinhui pan <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Christian König <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 19f76690fe68f3bc3e8dade01a5acd56938d19f1 Author: Gang Li <[email protected]> Date: Fri Jan 14 14:05:23 2022 -0800 shmem: fix a race between shmem_unused_huge_shrink and shmem_evict_inode commit 62c9827cbb996c2c04f615ecd783ce28bcea894b upstream. Fix a data race in commit 779750d20b93 ("shmem: split huge pages beyond i_size under memory pressure"). Here are call traces causing race: Call Trace 1: shmem_unused_huge_shrink+0x3ae/0x410 ? __list_lru_walk_one.isra.5+0x33/0x160 super_cache_scan+0x17c/0x190 shrink_slab.part.55+0x1ef/0x3f0 shrink_node+0x10e/0x330 kswapd+0x380/0x740 kthread+0xfc/0x130 ? mem_cgroup_shrink_node+0x170/0x170 ? kthread_create_on_node+0x70/0x70 ret_from_fork+0x1f/0x30 Call Trace 2: shmem_evict_inode+0xd8/0x190 evict+0xbe/0x1c0 do_unlinkat+0x137/0x330 do_syscall_64+0x76/0x120 entry_SYSCALL_64_after_hwframe+0x3d/0xa2 A simple explanation: Image there are 3 items in the local list (@list). In the first traversal, A is not deleted from @list. 1) A->B->C ^ | pos (leave) In the second traversal, B is deleted from @list. Concurrently, A is deleted from @list through shmem_evict_inode() since last reference counter of inode is dropped by other thread. Then the @list is corrupted. 2) A->B->C ^ ^ | | evict pos (drop) We should make sure the inode is either on the global list or deleted from any local list before iput(). Fixed by moving inodes back to global list before we put them. [[email protected]: coding style fixes] Link: https://lkml.kernel.org/r/[email protected] Fixes: 779750d20b93 ("shmem: split huge pages beyond i_size under memory pressure") Signed-off-by: Gang Li <[email protected]> Reviewed-by: Muchun Song <[email protected]> Acked-by: Kirill A. Shutemov <[email protected]> Cc: Hugh Dickins <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 6292bd6f654eb5ac6f45879fdb2af4d080e9c054 Author: Wen Gong <[email protected]> Date: Mon Nov 15 11:29:55 2021 +0200 ath11k: add string type to search board data in board-2.bin for WCN6855 commit fc95d10ac41d75c14a81afcc8722333d8b2cf80f upstream. Currently ath11k only support string type with bus, chip id and board id such as "bus=ahb,qmi-chip-id=1,qmi-board-id=4" for ahb bus chip and "bus=pci,qmi-chip-id=0,qmi-board-id=255" for PCIe bus chip in board-2.bin. For WCN6855, it is not enough to distinguish all different chips. This is to add a new string type which include bus, chip id, board id, vendor, device, subsystem-vendor and subsystem-device for WCN6855. ath11k will first load board-2.bin and search in it for the board data with the above parameters, if matched one board data, then download it to firmware, if not matched any one, then ath11k will download the file board.bin to firmware. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Signed-off-by: Wen Gong <[email protected]> Signed-off-by: Jouni Malinen <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Cc: "Limonciello, Mario" <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit e363ab33575144b73f9db71889ac642b37fc11d1 Author: Baoquan He <[email protected]> Date: Fri Jan 14 14:07:44 2022 -0800 mm/page_alloc.c: do not warn allocation failure on zone DMA if no managed pages commit c4dc63f0032c77464fbd4e7a6afc22fa6913c4a7 upstream. In kdump kernel of x86_64, page allocation failure is observed: kworker/u2:2: page allocation failure: order:0, mode:0xcc1(GFP_KERNEL|GFP_DMA), nodemask=(null),cpuset=/,mems_allowed=0 CPU: 0 PID: 55 Comm: kworker/u2:2 Not tainted 5.16.0-rc4+ #5 Hardware name: AMD Dinar/Dinar, BIOS RDN1505B 06/05/2013 Workqueue: events_unbound async_run_entry_fn Call Trace: <TASK> dump_stack_lvl+0x48/0x5e warn_alloc.cold+0x72/0xd6 __alloc_pages_slowpath.constprop.0+0xc69/0xcd0 __alloc_pages+0x1df/0x210 new_slab+0x389/0x4d0 ___slab_alloc+0x58f/0x770 __slab_alloc.constprop.0+0x4a/0x80 kmem_cache_alloc_trace+0x24b/0x2c0 sr_probe+0x1db/0x620 ...... device_add+0x405/0x920 ...... __scsi_add_device+0xe5/0x100 ata_scsi_scan_host+0x97/0x1d0 async_run_entry_fn+0x30/0x130 process_one_work+0x1e8/0x3c0 worker_thread+0x50/0x3b0 ? rescuer_thread+0x350/0x350 kthread+0x16b/0x190 ? set_kthread_struct+0x40/0x40 ret_from_fork+0x22/0x30 </TASK> Mem-Info: ...... The above failure happened when calling kmalloc() to allocate buffer with GFP_DMA. It requests to allocate slab page from DMA zone while no managed pages at all in there. sr_probe() --> get_capabilities() --> buffer = kmalloc(512, GFP_KERNEL | GFP_DMA); Because in the current kernel, dma-kmalloc will be created as long as CONFIG_ZONE_DMA is enabled. However, kdump kernel of x86_64 doesn't have managed pages on DMA zone since commit 6f599d84231f ("x86/kdump: Always reserve the low 1M when the crashkernel option is specified"). The failure can be always reproduced. For now, let's mute the warning of allocation failure if requesting pages from DMA zone while no managed pages. [[email protected]: fix warning] Link: https://lkml.kernel.org/r/[email protected] Fixes: 6f599d84231f ("x86/kdump: Always reserve the low 1M when the crashkernel option is specified") Signed-off-by: Baoquan He <[email protected]> Acked-by: John Donnelly <[email protected]> Reviewed-by: Hyeonggon Yoo <[email protected]> Cc: Christoph Lameter <[email protected]> Cc: Pekka Enberg <[email protected]> Cc: David Rientjes <[email protected]> Cc: Joonsoo Kim <[email protected]> Cc: Vlastimil Babka <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: David Hildenbrand <[email protected]> Cc: David Laight <[email protected]> Cc: Marek Szyprowski <[email protected]> Cc: Robin Murphy <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit bcf64fb327c8ded638ebd72cb44fd80e3dd28d03 Author: Baoquan He <[email protected]> Date: Fri Jan 14 14:07:41 2022 -0800 dma/pool: create dma atomic pool only if dma zone has managed pages commit a674e48c5443d12a8a43c3ac42367aa39505d506 upstream. Currently three dma atomic pools are initialized as long as the relevant kernel codes are built in. While in kdump kernel of x86_64, this is not right when trying to create atomic_pool_dma, because there's no managed pages in DMA zone. In the case, DMA zone only has low 1M memory presented and locked down by memblock allocator. So no pages are added into buddy of DMA zone. Please check commit f1d4d47c5851 ("x86/setup: Always reserve the first 1M of RAM"). Then in kdump kernel of x86_64, it always prints below failure message: DMA: preallocated 128 KiB GFP_KERNEL pool for atomic allocations swapper/0: page allocation failure: order:5, mode:0xcc1(GFP_KERNEL|GFP_DMA), nodemask=(null),cpuset=/,mems_allowed=0 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.13.0-0.rc5.20210611git929d931f2b40.42.fc35.x86_64 #1 Hardware name: Dell Inc. PowerEdge R910/0P658H, BIOS 2.12.0 06/04/2018 Call Trace: dump_stack+0x7f/0xa1 warn_alloc.cold+0x72/0xd6 __alloc_pages_slowpath.constprop.0+0xf29/0xf50 __alloc_pages+0x24d/0x2c0 alloc_page_interleave+0x13/0xb0 atomic_pool_expand+0x118/0x210 __dma_atomic_pool_init+0x45/0x93 dma_atomic_pool_init+0xdb/0x176 do_one_initcall+0x67/0x320 kernel_init_freeable+0x290/0x2dc kernel_init+0xa/0x111 ret_from_fork+0x22/0x30 Mem-Info: ...... DMA: failed to allocate 128 KiB GFP_KERNEL|GFP_DMA pool for atomic allocation DMA: preallocated 128 KiB GFP_KERNEL|GFP_DMA32 pool for atomic allocations Here, let's check if DMA zone has managed pages, then create atomic_pool_dma if yes. Otherwise just skip it. Link: https://lkml.kernel.org/r/[email protected] Fixes: 6f599d84231f ("x86/kdump: Always reserve the low 1M when the crashkernel option is specified") Signed-off-by: Baoquan He <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Acked-by: John Donnelly <[email protected]> Reviewed-by: David Hildenbrand <[email protected]> Cc: Marek Szyprowski <[email protected]> Cc: Robin Murphy <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Christoph Lameter <[email protected]> Cc: David Laight <[email protected]> Cc: David Rientjes <[email protected]> Cc: Hyeonggon Yoo <[email protected]> Cc: Joonsoo Kim <[email protected]> Cc: Pekka Enberg <[email protected]> Cc: Vlastimil Babka <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 240e8d331a9b1e261e19cf9fda1a10981b5618cb Author: Baoquan He <[email protected]> Date: Fri Jan 14 14:07:37 2022 -0800 mm_zone: add function to check if managed dma zone exists commit 62b3107073646e0946bd97ff926832bafb846d17 upstream. Patch series "Handle warning of allocation failure on DMA zone w/o managed pages", v4. **Problem observed: On x86_64, when crash is triggered and entering into kdump kernel, page allocation failure can always be seen. --------------------------------- DMA: preallocated 128 KiB GFP_KERNEL pool for atomic allocations swapper/0: page allocation failure: order:5, mode:0xcc1(GFP_KERNEL|GFP_DMA), nodemask=(null),cpuset=/,mems_allowed=0 CPU: 0 PID: 1 Comm: swapper/0 Call Trace: dump_stack+0x7f/0xa1 warn_alloc.cold+0x72/0xd6 ...... __alloc_pages+0x24d/0x2c0 ...... dma_atomic_pool_init+0xdb/0x176 do_one_initcall+0x67/0x320 ? rcu_read_lock_sched_held+0x3f/0x80 kernel_init_freeable+0x290/0x2dc ? rest_init+0x24f/0x24f kernel_init+0xa/0x111 ret_from_fork+0x22/0x30 Mem-Info: ------------------------------------ ***Root cause: In the current kernel, it assumes that DMA zone must have managed pages and try to request pages if CONFIG_ZONE_DMA is enabled. While this is not always true. E.g in kdump kernel of x86_64, only low 1M is presented and locked down at very early stage of boot, so that this low 1M won't be added into buddy allocator to become managed pages of DMA zone. This exception will always cause page allocation failure if page is requested from DMA zone. ***Investigation: This failure happens since below commit merged into linus's tree. 1a6a9044b967 x86/setup: Remove CONFIG_X86_RESERVE_LOW and reservelow= options 23721c8e92f7 x86/crash: Remove crash_reserve_low_1M() f1d4d47c5851 x86/setup: Always reserve the first 1M of RAM 7c321eb2b843 x86/kdump: Remove the backup region handling 6f599d84231f x86/kdump: Always reserve the low 1M when the crashkernel option is specified Before them, on x86_64, the low 640K area will be reused by kdump kernel. So in kdump kernel, the content of low 640K area is copied into a backup region for dumping before jumping into kdump. Then except of those firmware reserved region in [0, 640K], the left area will be added into buddy allocator to become available managed pages of DMA zone. However, after above commits applied, in kdump kernel of x86_64, the low 1M is reserved by memblock, but not released to buddy allocator. So any later page allocation requested from DMA zone will fail. At the beginning, if crashkernel is reserved, the low 1M need be locked down because AMD SME encrypts memory making the old backup region mechanims impossible when switching into kdump kernel. Later, it was also observed that there are BIOSes corrupting memory under 1M. To solve this, in commit f1d4d47c5851, the entire region of low 1M is always reserved after the real mode trampoline is allocated. Besides, recently, Intel engineer mentioned their TDX (Trusted domain extensions) which is under development in kernel also needs to lock down the low 1M. So we can't simply revert above commits to fix the page allocation failure from DMA zone as someone suggested. ***Solution: Currently, only DMA atomic pool and dma-kmalloc will initialize and request page allocation with GFP_DMA during bootup. So only initializ DMA atomic pool when DMA zone has available managed pages, otherwise just skip the initialization. For dma-kmalloc(), for the time being, let's mute the warning of allocation failure if requesting pages from DMA zone while no manged pages. Meanwhile, change code to use dma_alloc_xx/dma_map_xx API to replace kmalloc(GFP_DMA), or do not use GFP_DMA when calling kmalloc() if not necessary. Christoph is posting patches to fix those under drivers/scsi/. Finally, we can remove the need of dma-kmalloc() as people suggested. This patch (of 3): In some places of the current kernel, it assumes that dma zone must have managed pages if CONFIG_ZONE_DMA is enabled. While this is not always true. E.g in kdump kernel of x86_64, only low 1M is presented and locked down at very early stage of boot, so that there's no managed pages at all in DMA zone. This exception will always cause page allocation failure if page is requested from DMA zone. Here add function has_managed_dma() and the relevant helper functions to check if there's DMA zone with managed pages. It will be used in later patches. Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Fixes: 6f599d84231f ("x86/kdump: Always reserve the low 1M when the crashkernel option is specified") Signed-off-by: Baoquan He <[email protected]> Reviewed-by: David Hildenbrand <[email protected]> Acked-by: John Donnelly <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: Christoph Lameter <[email protected]> Cc: Hyeonggon Yoo <[email protected]> Cc: Pekka Enberg <[email protected]> Cc: David Rientjes <[email protected]> Cc: Joonsoo Kim <[email protected]> Cc: Vlastimil Babka <[email protected]> Cc: David Laight <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Marek Szyprowski <[email protected]> Cc: Robin Murphy <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 55bd26fd08dadb571226c0cbcd748cadbe22975b Author: Yifeng Li <[email protected]> Date: Thu Dec 2 06:35:21 2021 +0000 PCI: Add function 1 DMA alias quirk for Marvell 88SE9125 SATA controller commit e445375882883f69018aa669b67cbb37ec873406 upstream. Like other SATA controller chips in the Marvell 88SE91xx series, the Marvell 88SE9125 has the same DMA requester ID hardware bug that prevents it from working under IOMMU. Add it to the list of devices that need the quirk. Without this patch, device initialization fails with DMA errors: ata8: softreset failed (1st FIS failed) DMAR: DRHD: handling fault status reg 2 DMAR: [DMA Write NO_PASID] Request device [03:00.1] fault addr 0xfffc0000 [fault reason 0x02] Present bit in context entry is clear DMAR: DRHD: handling fault status reg 2 DMAR: [DMA Read NO_PASID] Request device [03:00.1] fault addr 0xfffc0000 [fault reason 0x02] Present bit in context entry is clear After applying the patch, the controller can be successfully initialized: ata8: SATA link up 1.5 Gbps (SStatus 113 SControl 330) ata8.00: ATAPI: PIONEER BD-RW BDR-207M, 1.21, max UDMA/100 ata8.00: configured for UDMA/100 scsi 7:0:0:0: CD-ROM PIONEER BD-RW BDR-207M 1.21 PQ: 0 ANSI: 5 Link: https://lore.kernel.org/r/YahpKVR+McJVDdkD@work Reported-by: Sam Bingner <[email protected]> Tested-by: Sam Bingner <[email protected]> Tested-by: Yifeng Li <[email protected]> Signed-off-by: Yifeng Li <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Krzysztof Wilczyński <[email protected]> Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 484654a6f6ed38edc59cdb173a801528e70529a7 Author: Thomas Hellström <[email protected]> Date: Mon Nov 29 16:27:27 2021 +0100 dma_fence_array: Fix PENDING_ERROR leak in dma_fence_array_signaled() commit 95d35838880fb040ccb9fe4a48816bd0c8b62df5 upstream. If a dma_fence_array is reported signaled by a call to dma_fence_is_signaled(), it may leak the PENDING_ERROR status. Fix this by clearing the PENDING_ERROR status if we return true in dma_fence_array_signaled(). v2: - Update Cc list, and add R-b. Fixes: 1f70b8b812f3 ("dma-fence: Propagate errors to dma-fence-array container") Cc: Chris Wilson <[email protected]> Cc: Sumit Semwal <[email protected]> Cc: Gustavo Padovan <[email protected]> Cc: Christian König <[email protected]> Cc: "Christian König" <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: <[email protected]> # v5.4+ Signed-off-by: Thomas Hellström <[email protected]> Reviewed-by: Christian König <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 03e964ad35ac99e5e01cd077f9368f3b7ecfffeb Author: Peng Hao <[email protected]> Date: Wed Dec 22 09:12:25 2021 +0800 virtio/virtio_mem: handle a possible NULL as a memcpy parameter commit cf4a4493ff70874f8af26d75d4346c591c298e89 upstream. There is a check for vm->sbm.sb_states before, and it should check it here as well. Signed-off-by: Peng Hao <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Michael S. Tsirkin <[email protected]> Fixes: 5f1f79bbc9e2 ("virtio-mem: Paravirtualized memory hotplug") Cc: [email protected] # v5.8+ Signed-off-by: Greg Kroah-Hartman <[email protected]> commit b9a524d6ec03a9c74f6547fe87d78d84a7e00608 Author: Dmitry Osipenko <[email protected]> Date: Sat Dec 4 17:58:49 2021 +0300 drm/tegra: Add back arm_iommu_detach_device() commit d210919dbdc8a82c676cc3e3c370b1802be63124 upstream. DMA buffers of 2D/3D engines aren't mapped properly when CONFIG_ARM_DMA_USE_IOMMU=y. The memory management code of Tegra DRM driver has a longstanding overhaul overdue and it's not obvious where the problem is in this case. Hence let's add back the old workaround which we already had sometime before. It explicitly detaches DRM devices from the offending implicit IOMMU domain. This fixes a completely broken 2d/3d drivers in case of ARM32 multiplatform kernel config. Cc: [email protected] Fixes: fa6661b7aa0b ("drm/tegra: Optionally attach clients to the IOMMU") Signed-off-by: Dmitry Osipenko <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 3ff8942bb8ab930250065df68b8f7ac575d8b041 Author: Dmitry Osipenko <[email protected]> Date: Sat Dec 4 17:58:48 2021 +0300 gpu: host1x: Add back arm_iommu_detach_device() commit d5185965c3b59073c4520bad7dd2adf725b9abba upstream. Host1x DMA buffer isn't mapped properly when CONFIG_ARM_DMA_USE_IOMMU=y. The memory management code of Host1x driver has a longstanding overhaul overdue and it's not obvious where the problem is in this case. Hence let's add back the old workaround which we already had sometime before. It explicitly detaches Host1x device from the offending implicit IOMMU domain. This fixes a completely broken Host1x DMA in case of ARM32 multiplatform kernel config. Cc: [email protected] Fixes: af1cbfb9bf0f ("gpu: host1x: Support DMA mapping of buffers") Signed-off-by: Dmitry Osipenko <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 03c8e18f3c14a8e32fed76d22e0305032360ee6e Author: Yunfei Wang <[email protected]> Date: Tue Dec 7 19:33:15 2021 +0800 iommu/io-pgtable-arm-v7s: Add error handle for page table allocation failure commit a556cfe4cabc6d79cbb7733f118bbb420b376fe6 upstream. In __arm_v7s_alloc_table function: iommu call kmem_cache_alloc to allocate page table, this function allocate memory may fail, when kmem_cache_alloc fails to allocate table, call virt_to_phys will be abnomal and return unexpected phys and goto out_free, then call kmem_cache_free to release table will trigger KE, __get_free_pages and free_pages have similar problem, so add error handle for page table allocation failure. Fixes: 29859aeb8a6e ("iommu/io-pgtable-arm-v7s: Abort allocation when table address overflows the PTE") Signed-off-by: Yunfei Wang <[email protected]> Cc: <[email protected]> # 5.10.* Acked-by: Robin Murphy <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit bed344b54daa7d3ebf827b391c88d0d7160afc1e Author: Hari Prasath <[email protected]> Date: Wed Dec 8 12:05:53 2021 +0530 ARM: dts: at91: update alternate function of signal PD20 commit 12f332d2dd3187472f595b678246adb10d886bd0 upstream. The alternate function of PD20 is 4 as per the datasheet of sama7g5 and not 5 as defined earlier. Signed-off-by: Hari Prasath <[email protected]> Fixes: 7540629e2fc7 ("ARM: dts: at91: add sama7g5 SoC DT and sama7g5-ek") Cc: <[email protected]> # v5.15+ Signed-off-by: Nicolas Ferre <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit c77a4529ca38577495450bee556bdc1ad8f40328 Author: D Scott Phillips <[email protected]> Date: Mon Dec 20 15:41:14 2021 -0800 arm64: errata: Fix exec handling in erratum 1418040 workaround commit 38e0257e0e6f4fef2aa2966b089b56a8b1cfb75c upstream. The erratum 1418040 workaround enables CNTVCT_EL1 access trapping in EL0 when executing compat threads. The workaround is applied when switching between tasks, but the need for the workaround could also change at an exec(), when a non-compat task execs a compat binary or vice versa. Apply the workaround in arch_setup_new_exec(). This leaves a small window of time between SET_PERSONALITY and arch_setup_new_exec where preemption could occur and confuse the old workaround logic that compares TIF_32BIT between prev and next. Instead, we can just read cntkctl to make sure it's in the state that the next task needs. I measured cntkctl read time to be about the same as a mov from a general-purpose register on N1. Update the workaround logic to examine the current value of cntkctl instead of the previous task's compat state. Fixes: d49f7d7376d0 ("arm64: Move handling of erratum 1418040 into C code") Cc: <[email protected]> # 5.9.x Signed-off-by: D Scott Phillips <[email protected]> Reviewed-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Catalin Marinas <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 181c78d6c12dc5623aecc4c7576922adf5e8f4fb Author: Dan Williams <[email protected]> Date: Fri Oct 29 12:55:47 2021 -0700 cxl/pmem: Fix reference counting for delayed work commit 08b9e0ab8af48895337192e683de44ab1e1b7427 upstream. There is a potential race between queue_work() returning and the queued-work running that could result in put_device() running before get_device(). Introduce the cxl_nvdimm_bridge_state_work() helper that takes the reference unconditionally, but drops it if no new work was queued, to keep the references balanced. Fixes: 8fdcb1704f61 ("cxl/pmem: Add initial infrastructure for pmem support") Cc: <[email protected]> Reviewed-by: Jonathan Cameron <[email protected]> Reviewed-by: Ben Widawsky <[email protected]> Link: https://lore.kernel.org/r/163553734757.2509761.3305231863616785470.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit bc95dbf5502c9034fee75de34e5e49902e791e4b Author: Manivannan Sadhasivam <[email protected]> Date: Thu Dec 16 13:42:24 2021 +0530 bus: mhi: core: Fix race while handling SYS_ERR at power up commit d651ce8e917fa1bf6cfab8dca74c512edffc35d3 upstream. During SYS_ERR condition, as a response to the MHI_RESET from host, some devices tend to issue BHI interrupt without clearing the SYS_ERR state in the device. This creates a race condition and causes a failure in booting up the device. The issue is seen on the Sierra Wireless EM9191 modem during SYS_ERR handling in mhi_async_power_up(). Once the host detects that the device is in SYS_ERR state, it issues MHI_RESET and waits for the device to process the reset request. During this time, the device triggers the BHI interrupt to the host without clearing SYS_ERR condition. So the host starts handling the SYS_ERR condition again. To fix this issue, let's register the IRQ handler only after handling the SYS_ERR check to avoid getting spurious IRQs from the device. Fixes: e18d4e9fa79b ("bus: mhi: core: Handle syserr during power_up") Cc: [email protected] Reported-by: Aleksander Morgado <[email protected]> Tested-by: Aleksander Morgado <[email protected]> Tested-by: Thomas Perrot <[email protected]> Signed-off-by: Manivannan Sadhasivam <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit c8aa11642478a50f4b6ead300ffa8bda4db228bd Author: Bhaumik Bhatt <[email protected]> Date: Thu Dec 16 13:42:23 2021 +0530 bus: mhi: core: Fix reading wake_capable channel configuration commit 42c4668f7efe1485dfc382517b412c0c6ab102b8 upstream. The 'wake-capable' entry in channel configuration is not set when parsing the configuration specified by the controller driver. Add the missing entry to ensure channel is correctly specified as a 'wake-capable' channel. Link: https://lore.kernel.org/r/[email protected] Fixes: 0cbf260820fa ("bus: mhi: core: Add support for registering MHI controllers") Cc: [email protected] Reviewed-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Bhaumik Bhatt <[email protected]> Signed-off-by: Manivannan Sadhasivam <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 2075d9f4fdc5dd39780cc21a01943db2d141357a Author: Loic Poulain <[email protected]> Date: Thu Dec 16 13:42:19 2021 +0530 bus: mhi: pci_generic: Graceful shutdown on freeze commit f77097ec8c0141a4b5cf3722a246be0cb5677e29 upstream. There is no reason for shutting down MHI ungracefully on freeze, this causes the MHI host stack & device stack to not be aligned anymore since the proper MHI reset sequence is not performed for ungraceful shutdown. Link: https://lore.kernel.org/r/[email protected] Fixes: 5f0c2ee1fe8d ("bus: mhi: pci-generic: Fix hibernation") Cc: [email protected] Suggested-by: Bhaumik Bhatt <[email protected]> Reviewed-by: Bhaumik Bhatt <[email protected]> Reviewed-by: Hemant Kumar <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Loic Poulain <[email protected]> Signed-off-by: Manivannan Sadhasivam <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit acb5a8bee27bf820e50316a328ceec9e24e0d92b Author: Christophe Leroy <[email protected]> Date: Fri Oct 8 18:58:40 2021 +0200 lkdtm: Fix content of section containing lkdtm_rodata_do_nothing() commit bc93a22a19eb2b68a16ecf04cdf4b2ed65aaf398 upstream. On a kernel without CONFIG_STRICT_KERNEL_RWX, running EXEC_RODATA test leads to "Illegal instruction" failure. Looking at the content of rodata_objcopy.o, we see that the function content zeroes only: Disassembly of section .rodata: 0000000000000000 <.lkdtm_rodata_do_nothing>: 0: 00 00 00 00 .long 0x0 Add the contents flag in order to keep the content of the section while renaming it. Disassembly of section .rodata: 0000000000000000 <.lkdtm_rodata_do_nothing>: 0: 4e 80 00 20 blr Fixes: e9e08a07385e ("lkdtm: support llvm-objcopy") Cc: [email protected] Cc: Kees Cook <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Nick Desaulniers <[email protected]> Cc: Nathan Chancellor <[email protected]> Signed-off-by: Christophe Leroy <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]> Signed-off-by: Kees Cook <[email protected]> Link: https://lore.kernel.org/r/8900731fbc05fb8b0de18af7133a8fc07c3c53a1.1633712176.git.christophe.leroy@csgroup.eu Signed-off-by: Greg Kroah-Hartman <[email protected]> commit a18aeac73c0f692ba40964f5f56e182312ae843b Author: Jonathan Cameron <[email protected]> Date: Sun Oct 17 18:22:09 2021 +0100 iio: trigger: Fix a scheduling whilst atomic issue seen on tsc2046 commit 9020ef659885f2622cfb386cc229b6d618362895 upstream. IIO triggers are software IRQ chips that split an incoming IRQ into separate IRQs routed to all devices using the trigger. When all consumers are done then a trigger callback reenable() is called. There are a few circumstances under which this can happen in atomic context. 1) A single user of the trigger that calls the iio_trigger_done() function from interrupt context. 2) A race between disconnecting the last device from a trigger and the trigger itself sucessfully being disabled. To avoid a resulting scheduling whilst atomic, close this second corner by using schedule_work() to ensure the reenable is not done in atomic context. Note that drivers must be careful to manage the interaction of set_state() and reenable() callbacks to ensure appropriate reference counting if they are relying on the same hardware controls. Deliberately taking this the slow path rather than via a fixes tree because the error has hard to hit and I would like it to soak for a while before hitting a release kernel. Signed-off-by: Jonathan Cameron <[email protected]> Cc: Pengutronix Kernel Team <[email protected]> Cc: Dmitry Torokhov <[email protected]> Tested-by: Oleksij Rempel <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 5c397420c0e2e51581bdca5292c75bef8824e8c6 Author: Jonathan Cameron <[email protected]> Date: Sun Dec 5 17:27:28 2021 +0000 iio: adc: ti-adc081c: Partial revert of removal of ACPI IDs commit c9791a94384af07592d29504004d2255dbaf8663 upstream. Unfortuanately a non standards compliant ACPI ID is known to be in the wild on some AAEON boards. Partly revert the removal of these IDs so that ADC081C will again work + add a comment to that affect for future reference. Whilst here use generic firmware properties rather than the ACPI specific handling previously found in this driver. Reported-by: Kunyang Fan <[email protected]> Fixes: c458b7ca3fd0 ("iio:adc:ti-adc081c: Drop ACPI ids that seem very unlikely to be official.") Signed-off-by: Jonathan Cameron <[email protected]> Cc: Andy Shevchenko <[email protected]> Tested-by: Kunyang Fan <[email protected]> #UP-extremei11 Link: https://lore.kernel.org/r/[email protected] Cc: <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 702c89045230b99b3e2f11658ee5f1e85464ab46 Author: Alexander Usyskin <[email protected]> Date: Tue Dec 28 10:20:47 2021 +0200 mei: hbm: fix client dma reply status commit 6b0b80ac103b2a40c72a47c301745fd1f4ef4697 upstream. Don't blindly copy status value received from the firmware into internal client status field, It may be positive and ERR_PTR(ret) will translate it into an invalid address and the caller will crash. Put the error code into the client status on failure. Fixes: 369aea845951 ("mei: implement client dma setup.") Cc: <[email protected]> # v5.11+ Reported-by: Emmanuel Grumbach <[email protected]> Tested-by: : Emmanuel Grumbach <[email protected]> Acked-by: Tomas Winkler <[email protected]> Signed-off-by: Alexander Usyskin <[email protected]> Signed-off-by: Tomas Winkler <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 697c4137573948a94fd6e9856ce4a3e551ecdc1e Author: Johan Hovold <[email protected]> Date: Wed Dec 22 11:48:43 2021 +0100 can: softing_cs: softingcs_probe(): fix memleak on registration failure commit ced4913efb0acc844ed65cc01d091a85d83a2082 upstream. In case device registration fails during probe, the driver state and the embedded platform device structure needs to be freed using platform_device_put() to properly free all resources (e.g. the device name). Fixes: 0a0b7a5f7a04 ("can: add driver for Softing card") Link: https://lore.kernel.org/all/[email protected] Cc: [email protected] # 2.6.38 Signed-off-by: Johan Hovold <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 61eb4ad9ae468190a6e0499586efbe6e7dde1893 Author: Hans Verkuil <[email protected]> Date: Wed Dec 1 13:41:25 2021 +0100 media: cec-pin: fix interrupt en/disable handling commit 713bdfa10b5957053811470d298def9537d9ff13 upstream. The en/disable_irq() functions keep track of the 'depth': i.e. if interrupts are disabled twice, then it needs to enable_irq() calls to enable them again. The cec-pin framework didn't take this into accound and could disable irqs multiple times, and it expected that a single enable_irq() would enable them again. Move all calls to en/disable_irq() to the kthread where it is easy to keep track of the current irq state and ensure that multiple en/disable_irq calls never happen. If interrupts where disabled twice, then they would never turn on again, leaving the CEC adapter in a dead state. Signed-off-by: Hans Verkuil <[email protected]> Fixes: 865463fc03ed (media: cec-pin: add error injection support) Cc: <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 1baebfdf19b093e052e017fa6b3bb70150437e42 Author: Johan Hovold <[email protected]> Date: Mon Oct 25 13:16:41 2021 +0100 media: stk1160: fix control-message timeouts commit 6aa6e70cdb5b863a57bad61310bf89b6617a5d2d upstream. USB control-message timeouts are specified in milliseconds and should specifically not vary with CONFIG_HZ. Fixes: 9cb2173e6ea8 ("[media] media: Add stk1160 new driver (easycap replacement)") Cc: [email protected] # 3.7 Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit b208a386572acabbf8c43313bcbe0c104a6f174a Author: Johan Hovold <[email protected]> Date: Mon Oct 25 13:16:39 2021 +0100 media: pvrusb2: fix control-message timeouts commit b82bf9b9dc305d7d3d93eab106d70dbf2171b43e upstream. USB control-message timeouts are specified in milliseconds and should specifically not vary with CONFIG_HZ. Fixes: d855497edbfb ("V4L/DVB (4228a): pvrusb2 to kernel 2.6.18") Cc: [email protected] # 2.6.18 Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 8b8dbc22b9f74d3fac1a145325d673449ed6b379 Author: Johan Hovold <[email protected]> Date: Mon Oct 25 13:16:35 2021 +0100 media: redrat3: fix control-message timeouts commit 2adc965c8bfa224e11ecccf9c92fd458c4236428 upstream. USB control-message timeouts are specified in milliseconds and should specifically not vary with CONFIG_HZ. Fixes: 2154be651b90 ("[media] redrat3: new rc-core IR transceiver device driver") Cc: [email protected] # 3.0 Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 821e5abd21980a01042f54701c97d9a68b781f9c Author: Michael Kuron <[email protected]> Date: Sun Sep 26 21:51:26 2021 +0100 media: dib0700: fix undefined behavior in tuner shutdown commit f7b77ebe6d2f49c7747b2d619586d1aa33f9ea91 upstream. This fixes a problem where closing the tuner would leave it in a state where it would not tune to any channel when reopened. This problem was discovered as part of https://github.com/hselasky/webcamd/issues/16. Since adap->id is 0 or 1, this bit-shift overflows, which is undefined behavior. The driver still worked in practice as the overflow would in most environments result in 0, which rendered the line a no-op. When running the driver as part of webcamd however, the overflow could lead to 0xff due to optimizations by the compiler, which would, in the end, improperly shut down the tuner. The bug is a regression introduced in the commit referenced below. The present patch causes identical behavior to before that commit for adap->id equal to 0 or 1. The driver does not contain support for dib0700 devices with more adapters, assuming such even exist. Tests have been performed with the Xbox One Digital TV Tuner on amd64. Not all dib0700 devices are expected to be affected by the regression; this code path is only taken by those with incorrect endpoint numbers. Link: https://lore.kernel.org/linux-media/1d2fc36d94ced6f67c7cc21dcc469d5e5bdd8201.1632689033.git.mchehab+huawei@kernel.org Cc: [email protected] Fixes: 7757ddda6f4f ("[media] DiB0700: add function to change I2C-speed") Signed-off-by: Michael Kuron <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 4e56a231210f29ac080788c8d5937f642ce4d1b5 Author: Johan Hovold <[email protected]> Date: Mon Oct 25 13:16:40 2021 +0100 media: s2255: fix control-message timeouts commit f71d272ad4e354097020a4e6b1dc6e4b59feb50f upstream. USB control-message timeouts are specified in milliseconds and should specifically not vary with CONFIG_HZ. Use the common control-message timeout define for the five-second timeouts. Fixes: 38f993ad8b1f ("V4L/DVB (8125): This driver adds support for the Sensoray 2255 devices.") Cc: [email protected] # 2.6.27 Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 15955a24fa8e33382f544f729ca1e400719e4d21 Author: Johan Hovold <[email protected]> Date: Mon Oct 25 13:16:37 2021 +0100 media: cpia2: fix control-message timeouts commit 10729be03327f53258cb196362015ad5c6eabe02 upstream. USB control-message timeouts are specified in milliseconds and should specifically not vary with CONFIG_HZ. Fixes: ab33d5071de7 ("V4L/DVB (3376): Add cpia2 camera support") Cc: [email protected] # 2.6.17 Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 198e0c619f4610df84ad4cb7e298a07242285d01 Author: Johan Hovold <[email protected]> Date: Mon Oct 25 13:16:38 2021 +0100 media: em28xx: fix control-message timeouts commit d9b7e8df3aa9b8c10708aab60e72e79ac08237e4 upstream. USB control-message timeouts are specified in milliseconds and should specifically not vary with CONFIG_HZ. Fixes: a6c2ba283565 ("[PATCH] v4l: 716: support for em28xx board family") Cc: [email protected] # 2.6.16 Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 2516fab22e655d9f56e842d278d51059a8905ef4 Author: Johan Hovold <[email protected]> Date: Mon Oct 25 13:16:34 2021 +0100 media: mceusb: fix control-message timeouts commit 16394e998cbb050730536bdf7e89f5a70efbd974 upstream. USB control-message timeouts are specified in milliseconds and should specifically not vary with CONFIG_HZ. Fixes: 66e89522aff7 ("V4L/DVB: IR: add mceusb IR receiver driver") Cc: [email protected] # 2.6.36 Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit a16e2eff80fa9a95c86c289768416a8793e949ce Author: Johan Hovold <[email protected]> Date: Mon Oct 25 13:16:36 2021 +0100 media: flexcop-usb: fix control-message timeouts commit cd1798a387825cc4a51282f5a611ad05bb1ad75f upstream. USB control-message timeouts are specified in milliseconds and should specifically not vary with CONFIG_HZ. Note that the driver was multiplying some of the timeout values with HZ twice resulting in 3000-second timeouts with HZ=1000. Also note that two of the timeout defines are currently unused. Fixes: 2154be651b90 ("[media] redrat3: new rc-core IR transceiver device driver") Cc: [email protected] # 3.0 Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 1bde26972360c3cd4c52bc25322ee28a225fad78 Author: Hans Verkuil <[email protected]> Date: Wed Nov 3 12:28:31 2021 +0000 media: v4l2-ioctl.c: readbuffers depends on V4L2_CAP_READWRITE commit cd9d9377ed235b294a492a094e1666178a5e78fd upstream. If V4L2_CAP_READWRITE is not set, then readbuffers must be set to 0, otherwise v4l2-compliance will complain. A note on the Fixes tag below: this patch does not really fix that commit, but it can be applied from that commit onwards. For older code there is no guarantee that device_caps is set, so even though this patch would apply, it will not work reliably. Signed-off-by: Hans Verkuil <[email protected]> Fixes: 049e684f2de9 (media: v4l2-dev: fix WARN_ON(!vdev->device_caps)) Cc: <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 9aaf99b4a8b060028ea1d4b7ee846b96a2b2bdf9 Author: Sakari Ailus <[email protected]> Date: Wed Dec 15 09:38:48 2021 +0100 media: ov8865: Disable only enabled regulators on error path commit cbe0b3af73bf72fad197756f026084404e2bcdc7 upstream. If powering on the sensor failed, the entire power-off sequence was run independently of how far the power-on sequence proceeded before the error. This lead to disabling regulators and/or clock that was not enabled. Fix this by disabling only clocks and regulators that were enabled previously. Fixes: 11c0d8fdccc5 ("media: i2c: Add support for the OV8865 image sensor") Cc: [email protected] Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit a0d6e64b3413cfe8e3839444eb45b26b9426d3c7 Author: Hans Verkuil <[email protected]> Date: Wed Dec 1 13:41:26 2021 +0100 media: cec: fix a deadlock situation commit a9e6107616bb8108aa4fc22584a05e69761a91f7 upstream. The cec_devnode struct has a lock meant to serialize access to the fields of this struct. This lock is taken during device node (un)registration and when opening or releasing a filehandle to the device node. When the last open filehandle is closed the cec adapter might be disabled by calling the adap_enable driver callback with the devnode.lock held. However, if during that callback a message or event arrives then the driver will call one of the cec_queue_event() variants in cec-adap.c, and those will take the same devnode.lock to walk the open filehandle list. This obviously causes a deadlock. This is quite easy to reproduce with the cec-gpio driver since that uses the cec-pin framework which generated lots of events and uses a kernel thread for the processing, so when adap_enable is called the thread is still running and can generate events. But I suspect that it might also happen with other drivers if an interrupt arrives signaling e.g. a received message before adap_enable had a chance to disable the interrupts. This patch adds a new mutex to serialize access to the fhs list. When adap_enable() is called the devnode.lock mutex is held, but not devnode.lock_fhs. The event functions in cec-adap.c will now use devnode.lock_fhs instead of devnode.lock, ensuring that it is safe to call those functions from the adap_enable callback. This specific issue only happens if the last open filehandle is closed and the physical address is invalid. This is not something that happens during normal operation, but it does happen when monitoring CEC traffic (e.g. cec-ctl --monitor) with an unconfigured CEC adapter. Signed-off-by: Hans Verkuil <[email protected]> Cc: <[email protected]> # for v5.13 and up Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 8202aa60f077be8977bda2ecd5bd4350a0a5ab1e Author: Namjae Jeon <[email protected]> Date: Thu Jan 6 10:30:31 2022 +0900 ksmbd: add reserved room in ipc request/response commit 41dbda16a0902798e732abc6599de256b9dc3b27 upstream. Whenever new parameter is added to smb configuration, It is possible to break the execution of the IPC daemon by mismatch size of request/response. This patch tries to reserve space in ipc request/response in advance to prevent that. Signed-off-by: Namjae Jeon <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit d7004f0cc4a739e315f620773392b8d867993fe8 Author: Namjae Jeon <[email protected]> Date: Fri Dec 31 09:26:25 2021 +0900 ksmbd: limits exceeding the maximum allowable outstanding requests commit b589f5db6d4af8f14d70e31e1276b4c017668a26 upstream. If the client ignores the CreditResponse received from the server and continues to send the request, ksmbd limits the requests if it exceeds smb2 max credits. Signed-off-by: Namjae Jeon <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 0aadd32bebc9506b1fc88ab43c6174c2e371ad7b Author: Namjae Jeon <[email protected]> Date: Wed Dec 29 23:10:03 2021 +0900 ksmbd: move credit charge deduction under processing request commit 914d7e5709ac59ded70bea7956d408fe2acd7c3c upstream. Moves the credit charge deduction from total_credits under the processing a request. When repeating smb2 lock request and other command request, there will be a problem that ->total_credits does not decrease. Signed-off-by: Namjae Jeon <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 40fc68aeeb240afb25d7f63bb746f62b8d1f7ec9 Author: Namjae Jeon <[email protected]> Date: Wed Dec 29 23:08:46 2021 +0900 ksmbd: add support for smb2 max credit parameter commit 004443b3f6d722b455cf963ed7c3edd7f4772405 upstream. Add smb2 max credits parameter to adjust maximum credits value to limit number of outstanding requests. Signed-off-by: Namjae Jeon <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 0a8347db70a65202205e7653a1fe31580ad30098 Author: Namjae Jeon <[email protected]> Date: Mon Jan 17 22:16:01 2022 +0900 ksmbd: fix guest connection failure with nautilus commit ac090d9c90b087d6fb714e54b2a6dd1e6c373ed6 upstream. MS-SMB2 describe session sign like the following. Session.SigningRequired MUST be set to TRUE under the following conditions: - If the SMB2_NEGOTIATE_SIGNING_REQUIRED bit is set in the SecurityMode field of the client request. - If the SMB2_SESSION_FLAG_IS_GUEST bit is not set in the SessionFlags field and Session.IsAnonymous is FALSE and either Connection.ShouldSign or global RequireMessageSigning is TRUE. When trying guest account connection using nautilus, The login failure happened on session setup. ksmbd does not allow this connection when the user is a guest and the connection sign is set. Just do not set session sign instead of error response as described in the specification. And this change improves the guest connection in Nautilus. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Cc: [email protected] # v5.15+ Signed-off-by: Namjae Jeon <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit bbba4a0b8efab2bc8708fc8db2e94745bcd29cc9 Author: Dan Carpenter <[email protected]> Date: Sat Jan 15 14:49:00 2022 +0300 ksmbd: uninitialized variable in create_socket() commit b207602fb04537cb21ac38fabd7577eca2fa05ae upstream. The "ksmbd_socket" variable is not initialized on this error path. Cc: [email protected] Fixes: 0626e6641f6b ("cifsd: add server handler for central processing and tranport layers") Signed-off-by: Dan Carpenter <[email protected]> Acked-by: Namjae Jeon <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 893dfb14cac13676fbcd877853f256a063ee4cf3 Author: Mohammad Athari Bin Ismail <[email protected]> Date: Sat Jan 15 17:25:15 2022 +0800 net: phy: marvell: add Marvell specific PHY loopback commit 020a45aff1190c32b1087cd75b57fbf6bff46ea6 upstream. Existing genphy_loopback() is not applicable for Marvell PHY. Besides configuring bit-6 and bit-13 in Page 0 Register 0 (Copper Control Register), it is also required to configure same bits in Page 2 Register 21 (MAC Specific Control Register 2) according to speed of the loopback is operating. Tested working on Marvell88E1510 PHY for all speeds (1000/100/10Mbps). FIXME: Based on trial and error test, it seem 1G need to have delay between soft reset and loopback enablement. Fixes: 014068dcb5b1 ("net: phy: genphy_loopback: add link speed configuration") Cc: <[email protected]> # 5.15.x Signed-off-by: Mohammad Athari Bin Ismail <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit e428c89717ff941ac7486523160845561295ec82 Author: Mateusz Jończyk <[email protected]> Date: Fri Dec 10 21:01:23 2021 +0100 rtc: cmos: take rtc_lock while reading from CMOS commit 454f47ff464325223129b9b5b8d0b61946ec704d upstream. Reading from the CMOS involves writing to the index register and then reading from the data register. Therefore access to the CMOS has to be serialized with rtc_lock. This invocation of CMOS_READ was not serialized, which could cause trouble when other code is accessing CMOS at the same time. Use spin_lock_irq() like the rest of the function. Nothing in kernel modifies the RTC_DM_BINARY bit, so there could be a separate pair of spin_lock_irq() / spin_unlock_irq() before doing the math. Signed-off-by: Mateusz Jończyk <[email protected]> Reviewed-by: Nobuhiro Iwamatsu <[email protected]> Cc: Alessandro Zummo <[email protected]> Cc: Alexandre Belloni <[email protected]> Cc: [email protected] Signed-off-by: Alexandre Belloni <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 9899cea59121b0ede7f9e8c20db58609384682eb Author: Willy Tarreau <[email protected]> Date: Sun Oct 24 19:28:16 2021 +0200 tools/nolibc: fix incorrect truncation of exit code commit de0244ae40ae91145faaf164a4252347607c3711 upstream. Ammar Faizi reported that our exit code handling is wrong. We truncate it to the lowest 8 bits but the syscall itself is expected to take a regular 32-bit signed integer, not an unsigned char. It's the kernel that later truncates it to the lowest 8 bits. The difference is visible in strace, where the program below used to show exit(255) instead of exit(-1): int main(void) { return -1; } This patch applies the fix to all archs. x86_64, i386, arm64, armv7 and mips were all tested and confirmed to work fine now. Risc-v was not tested but the change is trivial and exactly the same as for other archs. Reported-by: Ammar Faizi <[email protected]> Cc: [email protected] Signed-off-by: Willy Tarreau <[email protected]> Signed-off-by: Paul E. McKenney <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 72191715afeebd6a43de25b7cc52d3398ad62cd7 Author: Willy Tarreau <[email protected]> Date: Sun Oct 24 19:28:15 2021 +0200 tools/nolibc: i386: fix initial stack alignment commit ebbe0d8a449d183fa43b42d84fcb248e25303985 upstream. After re-checking in the spec and comparing stack offsets with glibc, The last pushed argument must be 16-byte aligned (i.e. aligned before the call) so that in the callee esp+4 is multiple of 16, so the principle is the 32-bit equivalent to what Ammar fixed for x86_64. It's possible that 32-bit code using SSE2 or MMX could have been affected. In addition the frame pointer ought to be zero at the deepest level. Link: https://gitlab.com/x86-psABIs/i386-ABI/-/wikis/Intel386-psABI Cc: Ammar Faizi <[email protected]> Cc: [email protected] Signed-off-by: Willy Tarreau <[email protected]> Signed-off-by: Paul E. McKenney <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 9dc4c4e19084803e3791e06b9acb151291d25543 Author: Jakub Kicinski <[email protected]> Date: Tue Dec 21 07:06:11 2021 -0800 crypto: x86/aesni - don't require alignment of data commit d480a26bdf872529919e7c30e17f79d0d7b8c4da upstream. x86 AES-NI routines can deal with unaligned data. Crypto context (key, iv etc.) have to be aligned but we take care of that separately by copying it onto the stack. We were feeding unaligned data into crypto routines up until commit 83c83e658863 ("crypto: aesni - refactor scatterlist processing") switched to use the full skcipher API which uses cra_alignmask to decide data alignment. This fixes 21% performance regression in kTLS. Tested by booting with CONFIG_CRYPTO_MANAGER_EXTRA_TESTS=y (and running thru various kTLS packets). CC: [email protected] # 5.15+ Fixes: 83c83e658863 ("crypto: aesni - refactor scatterlist processing") Signed-off-by: Jakub Kicinski <[email protected]> Acked-by: Ard Biesheuvel <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 132cb7f64697dc93d8ca98c2a690b88f20e5e008 Author: Ammar Faizi <[email protected]> Date: Sun Oct 24 19:28:14 2021 +0200 tools/nolibc: x86-64: Fix startup code bug commit 937ed91c712273131de6d2a02caafd3ee84e0c72 upstream. Before this patch, the `_start` function looks like this: ``` 0000000000001170 <_start>: 1170: pop %rdi 1171: mov %rsp,%rsi 1174: lea 0x8(%rsi,%rdi,8),%rdx 1179: and $0xfffffffffffffff0,%rsp 117d: sub $0x8,%rsp 1181: call 1000 <main> 1186: movzbq %al,%rdi 118a: mov $0x3c,%rax 1191: syscall 1193: hlt 1194: data16 cs nopw 0x0(%rax,%rax,1) 119f: nop ``` Note the "and" to %rsp with $-16, it makes the %rsp be 16-byte aligned, but then there is a "sub" with $0x8 which makes the %rsp no longer 16-byte aligned, then it calls main. That's the bug! What actually the x86-64 System V ABI mandates is that right before the "call", the %rsp must be 16-byte aligned, not after the "call". So the "sub" with $0x8 here breaks the alignment. Remove it. An example where this rule matters is when the callee needs to align its stack at 16-byte for aligned move instruction, like `movdqa` and `movaps`. If the callee can't align its stack properly, it will result in segmentation fault. x86-64 System V ABI also mandates the deepest stack frame should be zero. Just to be safe, let's zero the %rbp on startup as the content of %rbp may be unspecified when the program starts. Now it looks like this: ``` 0000000000001170 <_start>: 1170: pop %rdi 1171: mov %rsp,%rsi 1174: lea 0x8(%rsi,%rdi,8),%rdx 1179: xor %ebp,%ebp # zero the %rbp 117b: and $0xfffffffffffffff0,%rsp # align the %rsp 117f: call 1000 <main> 1184: movzbq %al,%rdi 1188: mov $0x3c,%rax 118f: syscall 1191: hlt 1192: data16 cs nopw 0x0(%rax,%rax,1) 119d: nopl (%rax) ``` Cc: Bedirhan KURT <[email protected]> Cc: Louvian Lyndal <[email protected]> Reported-by: Peter Cordes <[email protected]> Signed-off-by: Ammar Faizi <[email protected]> [wt: I did this on purpose due to a misunderstanding of the spec, other archs will thus have to be rechecked, particularly i386] Cc: [email protected] Signed-off-by: Willy Tarreau <[email protected]> Signed-off-by: Paul E. McKenney <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 850bc1262a2b5eb74699f36ccd43595a3d1329f4 Author: Lucas De Marchi <[email protected]> Date: Thu Jan 13 16:28:39 2022 -0800 x86/gpu: Reserve stolen memory for first integrated Intel GPU commit 9c494ca4d3a535f9ca11ad6af1813983c1c6cbdd upstream. "Stolen memory" is memory set aside for use by an Intel integrated GPU. The intel_graphics_quirks() early quirk reserves this memory when it is called for a GPU that appears in the intel_early_ids[] table of integrated GPUs. Previously intel_graphics_quirks() was marked as QFLAG_APPLY_ONCE, so it was called only for the first Intel GPU found. If a discrete GPU happened to be enumerated first, intel_graphics_quirks() was called for it but not for any integrated GPU found later. Therefore, stolen memory for such an integrated GPU was never reserved. For example, this problem occurs in this Alderlake-P (integrated) + DG2 (discrete) topology where the DG2 is found first, but stolen memory is associated with the integrated GPU: - 00:01.0 Bridge `- 03:00.0 DG2 discrete GPU - 00:02.0 Integrated GPU (with stolen memory) Remove the QFLAG_APPLY_ONCE flag and call intel_graphics_quirks() for every Intel GPU. Reserve stolen memory for the first GPU that appears in intel_early_ids[]. [bhelgaas: commit log, add code comment, squash in https://lore.kernel.org/r/20220118190558.2ququ4vdfjuahicm@ldmartin-desk2] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lucas De Marchi <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 07c1c8e3202e04f65f663848cd1d18d44f0c87d4 Author: Jisheng Zhang <[email protected]> Date: Thu Dec 2 23:36:41 2021 +0800 riscv: mm: fix wrong phys_ram_base value for RV64 commit b0fd4b1bf995172b9efcee23600d4f69571c321c upstream. Currently, if 64BIT and !XIP_KERNEL, the phys_ram_base is always 0, no matter the real start of dram reported by memblock is. Fixes: 6d7f91d914bc ("riscv: Get rid of CONFIG_PHYS_RAM_BASE in kernel physical address conversion") Signed-off-by: Jisheng Zhang <[email protected]> Reviewed-by: Alexandre Ghiti <[email protected]> Cc: [email protected] Signed-off-by: Palmer Dabbelt <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit a2389e4f54e5acdde7e6266df0c1fed9bed70eec Author: Nick Kossifidis <[email protected]> Date: Fri Nov 26 20:04:10 2021 +0200 riscv: use hart id instead of cpu id on machine_kexec commit 0e105f1d0037d677dff3c697d22f9551e6c39af8 upstream. raw_smp_processor_id() doesn't return the hart id as stated in arch/riscv/include/asm/smp.h, use smp_processor_id() instead to get the cpu id, and cpuid_to_hartid_map() to pass the hart id to the next kernel. This fixes kexec on HiFive Unleashed/Unmatched where cpu ids and hart ids don't match (on qemu-virt they match). Fixes: fba8a8674f68 ("RISC-V: Add kexec support") Signed-off-by: Nick Kossifidis <[email protected]> Cc: [email protected] Signed-off-by: Palmer Dabbelt <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit b9f3e769ecf57ce4ad098dd270ab452e072febfa Author: Nick Kossifidis <[email protected]> Date: Fri Nov 26 20:04:09 2021 +0200 riscv: Don't use va_pa_offset on kdump commit a11c07f032a0e9a562a32ece73af96b0e754c4b3 upstream. On kdump instead of using an intermediate step to relocate the kernel, that lives in a "control buffer" outside the current kernel's mapping, we jump to the crash kernel directly by calling riscv_kexec_norelocate(). The current implementation uses va_pa_offset while switching to physical addressing, however since we moved the kernel outside the linear mapping this won't work anymore since riscv_kexec_norelocate() is part of the kernel mapping and we should use kernel_map.va_kernel_pa_offset, and also take XIP kernel into account. We don't really need to use va_pa_offset on riscv_kexec_norelocate, we can just set STVEC to the physical address of the new kernel instead and let the hart jump to the new kernel on the next instruction after setting SATP to zero. This fixes kdump and is also simpler/cleaner. I tested this on the latest qemu and HiFive Unmatched and works as expected. Fixes: 2bfc6cd81bd1 ("riscv: Move kernel mapping outside of linear mapping") Signed-off-by: Nick Kossifidis <[email protected]> Reviewed-by: Alexandre Ghiti <[email protected]> Cc: [email protected] Signed-off-by: Palmer Dabbelt <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 9550c6f0b2a65a09dded5ab8d4bd8b1040bcb9d7 Author: Nick Kossifidis <[email protected]> Date: Fri Nov 26 20:04:11 2021 +0200 riscv: try to allocate crashkern region from 32bit addressible memory commit decf89f86ecd3c3c3de81c562010d5797bea3de1 upstream. When allocating crash kernel region without explicitly specifying its base address/size, memblock_phys_alloc_range will attempt to allocate memory top to bottom (memblock.bottom_up is false), so the crash kernel region will end up in highmem on 64bit systems. This way swiotlb can't work on the crash kernel, since there won't be any 32bit addressible memory available for the bounce buffers. Try to allocate 32bit addressible memory if available, for the crash kernel by restricting the top search address to be less than SZ_4G. If that fails fallback to the previous behavior. I tested this on HiFive Unmatched where the pci-e controller needs swiotlb to work, with this patch it's possible to access the pci-e controller on crash kernel and mount the rootfs from the nvme. Signed-off-by: Nick Kossifidis <[email protected]> Fixes: e53d28180d4d ("RISC-V: Add kdump support") Cc: [email protected] Signed-off-by: Palmer Dabbelt <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 1402857bf15ff820f970142d69cb2931d1e04718 Author: Sean Christopherson <[email protected]> Date: Mon Nov 29 21:43:42 2021 +0000 RISC-V: Use common riscv_cpuid_to_hartid_mask() for both SMP=y and SMP=n commit 869c70609248102f3a2e95a39b6233ff6ea2c932 upstream. Use what is currently the SMP=y version of riscv_cpuid_to_hartid_mask() for both SMP=y and SMP=n to fix a build failure with KVM=m and SMP=n due to boot_cpu_hartid not being exported. This also fixes a second bug where the SMP=n version assumes the sole CPU in the system is in the incoming mask, which may not hold true in kvm_riscv_vcpu_sbi_ecall() if the KVM guest VM has multiple vCPUs (on a SMP=n system). Fixes: 1ef46c231df4 ("RISC-V: Implement new SBI v0.2 extensions") Reported-by: Adam Borowski <[email protected]> Reviewed-by: Anup Patel <[email protected]> Signed-off-by: Sean Christopherson <[email protected]> Cc: [email protected] Signed-off-by: Palmer Dabbelt <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 6250ecf5ba42292b652cd01c9fcb2239010c5c44 Author: Alexandre Ghiti <[email protected]> Date: Mon Jan 17 10:57:16 2022 +0100 riscv: Get rid of MAXPHYSMEM configs commit db1503d355a79d1d4255a9996f20e72848b74a56 upstream. CONFIG_MAXPHYSMEM_* are actually never used, even the nommu defconfigs selecting the MAXPHYSMEM_2GB had no effects on PAGE_OFFSET since it was preempted by !MMU case right before. In addition, the move of the kernel mapping at the end of the address space broke the use of MAXPHYSMEM_2G with MMU since it defines PAGE_OFFSET at the same address as the kernel mapping. Reported-by: Geert Uytterhoeven <[email protected]> Fixes: 2bfc6cd81bd1 ("riscv: Move kernel mapping outside of linear mapping") Signed-off-by: Alexandre Ghiti <[email protected]> Tested-by: Geert Uytterhoeven <[email protected]> Tested-by: Conor Dooley <[email protected]> Cc: [email protected] Signed-off-by: Palmer Dabbelt <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit cee8830146cf8a53746ab5aaf83aa36dd96d706a Author: Paul Cercueil <[email protected]> Date: Sat Oct 16 14:22:28 2021 +0100 mtd: rawnand: ingenic: JZ4740 needs 'oob_first' read page function commit 0171480007d64f663aae9226303f1b1e4621229e upstream. The ECC engine on the JZ4740 SoC requires the ECC data to be read before the page; using the default page reading function does not work. Indeed, the old JZ4740 NAND driver (removed in 5.4) did use the 'OOB first' flag that existed back then. Use the newly created nand_read_page_hwecc_oob_first() to address this issue. This issue was not found when the new ingenic-nand driver was developed, most likely because the Device Tree used had the nand-ecc-mode set to "hw_oob_first", which seems to not be supported anymore. Cc: <[email protected]> # v5.2 Fixes: a0ac778eb82c ("mtd: rawnand: ingenic: Add support for the JZ4740") Signed-off-by: Paul Cercueil <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Link: https://lore.kernel.org/linux-mtd/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit abf8c8712b6d75335a89459389e41d26e04ef4ac Author: Paul Cercueil <[email protected]> Date: Sat Oct 16 14:22:27 2021 +0100 mtd: rawnand: Export nand_read_page_hwecc_oob_first() commit d8466f73010faf71effb21228ae1cbf577dab130 upstream. Move the function nand_read_page_hwecc_oob_first() (previously nand_davinci_read_page_hwecc_oob_first()) to nand_base.c, and export it as a GPL symbol, so that it can be used by more modules. Cc: <[email protected]> # v5.2 Fixes: a0ac778eb82c ("mtd: rawnand: ingenic: Add support for the JZ4740") Signed-off-by: Paul Cercueil <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Link: https://lore.kernel.org/linux-mtd/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 26aa92a7f93120ba056c27b8d02f9dc48e513e68 Author: Paul Cercueil <[email protected]> Date: Sat Oct 16 14:22:26 2021 +0100 mtd: rawnand: davinci: Rewrite function description commit 0697f8441faad552fbeb02d74454b5e7bcc956a2 upstream. The original comment that describes the function nand_davinci_read_page_hwecc_oob_first() is very obscure and it is hard to understand what it is for. Cc: <[email protected]> # v5.2 Fixes: a0ac778eb82c ("mtd: rawnand: ingenic: Add support for the JZ4740") Signed-off-by: Paul Cercueil <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Link: https://lore.kernel.org/linux-mtd/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 3f5eb2d8903216b14be26ca98bc477dbf7522f1c Author: Paul Cercueil <[email protected]> Date: Sat Oct 16 14:22:25 2021 +0100 mtd: rawnand: davinci: Avoid duplicated page read commit 9c9d709965385de5a99f84b14bd5860e1541729e upstream. The function nand_davinci_read_page_hwecc_oob_first() first reads the OOB data, extracts the ECC information, programs the ECC hardware before reading the actual data in a loop. Right after the OOB data was read, it called nand_read_page_op() to reset the read cursor to the beginning of the page. This caused the first page to be read twice: in that call, and later in the loop. Address that issue by changing the call to nand_read_page_op() to nand_change_read_column_op(), which will only reset the read cursor. Cc: <[email protected]> # v5.2 Fixes: a0ac778eb82c ("mtd: rawnand: ingenic: Add support for the JZ4740") Signed-off-by: Paul Cercueil <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Link: https://lore.kernel.org/linux-mtd/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit eebc910e09d48f1f47670993c29389f728c5e4c6 Author: Paul Cercueil <[email protected]> Date: Sat Oct 16 14:22:24 2021 +0100 mtd: rawnand: davinci: Don't calculate ECC when reading page commit 71e89591502d737c10db2bd4d8fcfaa352552afb upstream. The function nand_davinci_read_page_hwecc_oob_first() does read the ECC data from the OOB area. Therefore it does not need to calculate the ECC as it is already available. Cc: <[email protected]> # v5.2 Fixes: a0ac778eb82c ("mtd: rawnand: ingenic: Add support for the JZ4740") Signed-off-by: Paul Cercueil <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Link: https://lore.kernel.org/linux-mtd/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 5794c37d2a98c2a6817a3da47c8b4defe47bf41e Author: Andreas Oetken <[email protected]> Date: Tue Nov 2 18:26:04 2021 +0100 mtd: Fixed breaking list in __mtd_del_partition. commit 2966daf7d253d9904b337b040dd7a43472858b8a upstream. Not the child partition should be removed from the partition list but the partition itself. Otherwise the partition list gets broken and any subsequent remove operations leads to a kernel panic. Fixes: 46b5889cc2c5 ("mtd: implement proper partition handling") Signed-off-by: Andreas Oetken <[email protected]> Cc: [email protected] Signed-off-by: Miquel Raynal <[email protected]> Link: https://lore.kernel.org/linux-mtd/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit bb969ffe1d0e9faa6499326dea297be0450e6b5b Author: Stefan Riedmueller <[email protected]> Date: Tue Nov 2 21:20:21 2021 +0100 mtd: rawnand: gpmi: Remove explicit default gpmi clock setting for i.MX6 commit aa1baa0e6c1aa4872e481dce4fc7fd6f3dd8496b upstream. There is no need to explicitly set the default gpmi clock rate during boot for the i.MX 6 since this is done during nand_detect anyway. Signed-off-by: Stefan Riedmueller <[email protected]> Cc: [email protected] Acked-by: Han Xu <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Link: https://lore.kernel.org/linux-mtd/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 0fe08bf9909f02eb487af2cc829f2853ea69bc96 Author: Christian Eggers <[email protected]> Date: Tue Nov 2 21:20:22 2021 +0100 mtd: rawnand: gpmi: Add ERR007117 protection for nfc_apply_timings commit f53d4c109a666bf1a4883b45d546fba079258717 upstream. gpmi_io clock needs to be gated off when changing the parent/dividers of enfc_clk_root (i.MX6Q/i.MX6UL) respectively qspi2_clk_root (i.MX6SX). Otherwise this rate change can lead to an unresponsive GPMI core which results in DMA timeouts and failed driver probe: [ 4.072318] gpmi-nand 112000.gpmi-nand: DMA timeout, last DMA ... [ 4.370355] gpmi-nand 112000.gpmi-nand: Chip: 0, Error -110 ... [ 4.375988] gpmi-nand 112000.gpmi-nand: Chip: 0, Error -22 [ 4.381524] gpmi-nand 112000.gpmi-nand: Error in ECC-based read: -22 [ 4.387988] gpmi-nand 112000.gpmi-nand: Chip: 0, Error -22 [ 4.393535] gpmi-nand 112000.gpmi-nand: Chip: 0, Error -22 ... Other than stated in i.MX 6 erratum ERR007117, it should be sufficient to gate only gpmi_io because all other bch/nand clocks are derived from different clock roots. The i.MX6 reference manuals state that changing clock muxers can cause glitches but are silent about changing dividers. But tests showed that these glitches can definitely happen on i.MX6ULL. For i.MX7D/8MM in turn, the manual guarantees that no glitches can happen when changing dividers. Co-developed-by: Stefan Riedmueller <[email protected]> Signed-off-by: Stefan Riedmueller <[email protected]> Signed-off-by: Christian Eggers <[email protected]> Cc: [email protected] Acked-by: Han Xu <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Link: https://lore.kernel.org/linux-mtd/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit f4dfc52a1eab74ea15d8eb8181fe530f1365f529 Author: Krzysztof Kozlowski <[email protected]> Date: Wed Jan 19 08:48:16 2022 +0100 nfc: llcp: fix NULL error pointer dereference on sendmsg() after failed bind() commit dded08927ca3c31a5c37f8e7f95fe98770475dd4 upstream. Syzbot detected a NULL pointer dereference of nfc_llcp_sock->dev pointer (which is a 'struct nfc_dev *') with calls to llcp_sock_sendmsg() after a failed llcp_sock_bind(). The message being sent is a SOCK_DGRAM. KASAN report: BUG: KASAN: null-ptr-deref in nfc_alloc_send_skb+0x2d/0xc0 Read of size 4 at addr 00000000000005c8 by task llcp_sock_nfc_a/899 CPU: 5 PID: 899 Comm: llcp_sock_nfc_a Not tainted 5.16.0-rc6-next-20211224-00001-gc6437fbf18b0 #125 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x45/0x59 ? nfc_alloc_send_skb+0x2d/0xc0 __kasan_report.cold+0x117/0x11c ? mark_lock+0x480/0x4f0 ? nfc_alloc_send_skb+0x2d/0xc0 kasan_report+0x38/0x50 nfc_alloc_send_skb+0x2d/0xc0 nfc_llcp_send_ui_frame+0x18c/0x2a0 ? nfc_llcp_send_i_frame+0x230/0x230 ? __local_bh_enable_ip+0x86/0xe0 ? llcp_sock_connect+0x470/0x470 ? llcp_sock_connect+0x470/0x470 sock_sendmsg+0x8e/0xa0 ____sys_sendmsg+0x253/0x3f0 ... The issue was visible only with multiple simultaneous calls to bind() and sendmsg(), which resulted in most of the bind() calls to fail. The bind() was failing on checking if there is available WKS/SDP/SAP (respective bit in 'struct nfc_llcp_local' fields). When there was no available WKS/SDP/SAP, the bind returned error but the sendmsg() to such socket was able to trigger mentioned NULL pointer dereference of nfc_llcp_sock->dev. The code looks simply racy and currently it protects several paths against race with checks for (!nfc_llcp_sock->local) which is NULL-ified in error paths of bind(). The llcp_sock_sendmsg() did not have such check but called function nfc_llcp_send_ui_frame() had, although not protected with lock_sock(). Therefore the race could look like (same socket is used all the time): CPU0 CPU1 ==== ==== llcp_sock_bind() - lock_sock() - success - release_sock() - return 0 llcp_sock_sendmsg() - lock_sock() - release_sock() llcp_sock_bind(), same socket - lock_sock() - error - nfc_llcp_send_ui_frame() - if (!llcp_sock->local) - llcp_sock->local = NULL - nfc_put_device(dev) - dereference llcp_sock->dev - release_sock() - return -ERRNO The nfc_llcp_send_ui_frame() checked llcp_sock->local outside of the lock, which is racy and ineffective check. Instead, its caller llcp_sock_sendmsg(), should perform the check inside lock_sock(). Reported-and-tested-by: [email protected] Fixes: b874dec21d1c ("NFC: Implement LLCP connection less Tx path") Cc: <[email protected]> Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit c9cd02cb7a26924037ec893bfbad2c367cec9445 Author: Jaegeuk Kim <[email protected]> Date: Thu Dec 9 10:25:43 2021 -0800 f2fs: avoid EINVAL by SBI_NEED_FSCK when pinning a file commit 19bdba5265624ba6b9d9dd936a0c6ccc167cfe80 upstream. Android OTA failed due to SBI_NEED_FSCK flag when pinning the file. Let's avoid it since we can do in-place-updates. Cc: [email protected] Signed-off-by: Jaegeuk Kim <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit dd88a805d2d0ffc68b03302c9302e9d3d8d10172 Author: Chao Yu <[email protected]> Date: Mon Dec 6 22:44:21 2021 +0800 f2fs: fix to do sanity check in is_alive() commit 77900c45ee5cd5da63bd4d818a41dbdf367e81cd upstream. In fuzzed image, SSA table may indicate that a data block belongs to invalid node, which node ID is out-of-range (0, 1, 2 or max_nid), in order to avoid migrating inconsistent data in such corrupted image, let's do sanity check anyway before data block migration. Cc: [email protected] Signed-off-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 0ddbdc0b7f0cec3815ac05a30b2c2f6457be3050 Author: Chao Yu <[email protected]> Date: Mon Dec 6 22:44:19 2021 +0800 f2fs: fix to do sanity check on inode type during garbage collection commit 9056d6489f5a41cfbb67f719d2c0ce61ead72d9f upstream. As report by Wenqing Liu in bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215231 - Overview kernel NULL pointer dereference triggered in folio_mark_dirty() when mount and operate on a crafted f2fs image - Reproduce tested on kernel 5.16-rc3, 5.15.X under root 1. mkdir mnt 2. mount -t f2fs tmp1.img mnt 3. touch tmp 4. cp tmp mnt F2FS-fs (loop0): sanity_check_inode: inode (ino=49) extent info [5942, 4294180864, 4] is incorrect, run fsck to fix F2FS-fs (loop0): f2fs_check_nid_range: out-of-range nid=31340049, run fsck to fix. BUG: kernel NULL pointer dereference, address: 0000000000000000 folio_mark_dirty+0x33/0x50 move_data_page+0x2dd/0x460 [f2fs] do_garbage_collect+0xc18/0x16a0 [f2fs] f2fs_gc+0x1d3/0xd90 [f2fs] f2fs_balance_fs+0x13a/0x570 [f2fs] f2fs_create+0x285/0x840 [f2fs] path_openat+0xe6d/0x1040 do_filp_open+0xc5/0x140 do_sys_openat2+0x23a/0x310 do_sys_open+0x57/0x80 The root cause is for special file: e.g. character, block, fifo or socket file, f2fs doesn't assign address space operations pointer array for mapping->a_ops field, so, in a fuzzed image, SSA table indicates a data block belong to special file, when f2fs tries to migrate that block, it causes NULL pointer access once move_data_page() calls a_ops->set_dirty_page(). Cc: [email protected] Reported-by: Wenqing Liu <[email protected]> Signed-off-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 7f6e3cbbd60044102373f5a7f86d5f4e89a99747 Author: Takashi Iwai <[email protected]> Date: Sun Jan 16 09:28:38 2022 +0100 ALSA: core: Fix SSID quirk lookup for subvendor=0 commit 5576c4f24c56722a2d9fb9c447d896e5b312078b upstream. Some weird devices set the codec SSID vendor ID 0, and snd_pci_quirk_lookup_id() loop aborts at the point although it should still try matching with the SSID device ID. This resulted in a missing quirk for some old Macs. Fix the loop termination condition to check both subvendor and subdevice. Fixes: 73355ddd8775 ("ALSA: hda: Code refactoring snd_hda_pick_fixup()") Cc: <[email protected]> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=215495 Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 8877331177deabbb1561a43ec5c2d94c3c68766d Author: Jason Gerecke <[email protected]> Date: Tue Jan 18 14:38:41 2022 -0800 HID: wacom: Avoid using stale array indicies to read contact count commit 20f3cf5f860f9f267a6a6e5642d3d0525edb1814 upstream. If we ever see a touch report with contact count data we initialize several variables used to read the contact count in the pre-report phase. These variables are never reset if we process a report which doesn't contain a contact count, however. This can cause the pre- report function to trigger a read of arbitrary memory (e.g. NULL if we're lucky) and potentially crash the driver. This commit restores resetting of the variables back to default "none" values that were used prior to the commit mentioned below. Link: https://github.com/linuxwacom/input-wacom/issues/276 Fixes: 003f50ab673c (HID: wacom: Update last_slot_field during pre_report phase) CC: [email protected] Signed-off-by: Jason Gerecke <[email protected]> Reviewed-by: Ping Cheng <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit c965ad71a05d5f3b44dcd11213682705666ba9e0 Author: Jason Gerecke <[email protected]> Date: Tue Jan 18 14:37:56 2022 -0800 HID: wacom: Ignore the confidence flag when a touch is removed commit df03e9bd6d4806619b4cdc91a3d7695818a8e2b7 upstream. AES hardware may internally re-classify a contact that it thought was intentional as a palm. Intentional contacts are reported as "down" with the confidence bit set. When this re-classification occurs, however, the state transitions to "up" with the confidence bit cleared. This kind of transition appears to be legal according to Microsoft docs, but we do not handle it correctly. Because the confidence bit is clear, we don't call `wacom_wac_finger_slot` and update userspace. This causes hung touches that confuse userspace and interfere with pen arbitration. This commit adds a special case to ignore the confidence flag if a contact is reported as removed. This ensures we do not leave a hung touch if one of these re-classification events occured. Ideally we'd have some way to also let userspace know that the touch has been re-classified as a palm and needs to be canceled, but that's not possible right now :) Link: https://github.com/linuxwacom/input-wacom/issues/288 Fixes: 7fb0413baa7f (HID: wacom: Use "Confidence" flag to prevent reporting invalid contacts) CC: [email protected] Signed-off-by: Jason Gerecke <[email protected]> Reviewed-by: Ping Cheng <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit f9f16383d59620c800de933b355c071dc6ea10b8 Author: Jason Gerecke <[email protected]> Date: Tue Jan 18 14:37:55 2022 -0800 HID: wacom: Reset expected and received contact counts at the same time commit 546e41ac994cc185ef3de610ca849a294b5df3ba upstream. These two values go hand-in-hand and must be valid for the driver to behave correctly. We are currently lazy about updating the values and rely on the "expected" code flow to take care of making sure they're valid at the point they're needed. The "expected" flow changed somewhat with commit f8b6a74719b5 ("HID: wacom: generic: Support multiple tools per report"), however. This led to problems with the DTH-2452 due (in part) to *all* contacts being fully processed -- even those past the expected contact count. Specifically, the received count gets reset to 0 once all expected fingers are processed, but not the expected count. The rest of the contacts in the report are then *also* processed since now the driver thinks we've only processed 0 of N expected contacts. Later commits such as 7fb0413baa7f (HID: wacom: Use "Confidence" flag to prevent reporting invalid contacts) worked around the DTH-2452 issue by skipping the invalid contacts at the end of the report, but this is not a complete fix. The confidence flag cannot be relied on when a contact is removed (see the following patch), and dealing with that condition re-introduces the DTH-2452 issue unless we also address this contact count laziness. By resetting expected and received counts at the same time we ensure the driver understands that there are 0 more contacts expected in the report. Similarly, we also make sure to reset the received count if for some reason we're out of sync in the pre-report phase. Link: https://github.com/linuxwacom/input-wacom/issues/288 Fixes: f8b6a74719b5 ("HID: wacom: generic: Support multiple tools per report") CC: [email protected] Signed-off-by: Jason Gerecke <[email protected]> Reviewed-by: Ping Cheng <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 6a4ec6f2429eb19b90ab63d18a51c5b08c18f61e Author: Jann Horn <[email protected]> Date: Fri Jan 14 14:33:30 2022 +0100 HID: uhid: Fix worker destroying device without any protection commit 4ea5763fb79ed89b3bdad455ebf3f33416a81624 upstream. uhid has to run hid_add_device() from workqueue context while allowing parallel use of the userspace API (which is protected with ->devlock). But hid_add_device() can fail. Currently, that is handled by immediately destroying the associated HID device, without using ->devlock - but if there are concurrent requests from userspace, that's wrong and leads to NULL dereferences and/or memory corruption (via use-after-free). Fix it by leaving the HID device as-is in the worker. We can clean it up later, either in the UHID_DESTROY command handler or in the ->release() handler. Cc: [email protected] Fixes: 67f8ecc550b5 ("HID: uhid: fix timeout when probe races with IO") Signed-off-by: Jann Horn <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 47b5c189d6a481d22dea24ab99eee439245ebf2e Author: Karl Kurbjun <[email protected]> Date: Sun Jan 9 20:49:35 2022 -0700 HID: Ignore battery for Elan touchscreen on HP Envy X360 15t-dr100 commit f3193ea1b6779023334faa72b214ece457e02656 upstream. Battery status on Elan tablet driver is reported for the HP ENVY x360 15t-dr100. There is no separate battery for the Elan controller resulting in a battery level report of 0% or 1% depending on whether a stylus has interacted with the screen. These low battery level reports causes a variety of bad behavior in desktop environments. This patch adds the appropriate quirk to indicate that the batery status is unused for this target. Cc: [email protected] Signed-off-by: Karl Kurbjun <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 91b7cbea9efc99328752f414e61cfd0d77e99b79 Author: Marcelo Tosatti <[email protected]> Date: Tue Jan 18 04:34:43 2022 -0500 KVM: VMX: switch blocked_vcpu_on_cpu_lock to raw spinlock commit 5f02ef741a785678930f3ff0a8b6b2b0ef1bb402 upstream. blocked_vcpu_on_cpu_lock is taken from hard interrupt context (pi_wakeup_handler), therefore it cannot sleep. Switch it to a raw spinlock. Fixes: [41297.066254] BUG: scheduling while atomic: CPU 0/KVM/635218/0x00010001 [41297.066323] Preemption disabled at: [41297.066324] [<ffffffff902ee47f>] irq_enter_rcu+0xf/0x60 [41297.066339] Call Trace: [41297.066342] <IRQ> [41297.066346] dump_stack_lvl+0x34/0x44 [41297.066353] ? irq_enter_rcu+0xf/0x60 [41297.066356] __schedule_bug.cold+0x7d/0x8b [41297.066361] __schedule+0x439/0x5b0 [41297.066365] ? task_blocks_on_rt_mutex.constprop.0.isra.0+0x1b0/0x440 [41297.066369] schedule_rtlock+0x1e/0x40 [41297.066371] rtlock_slowlock_locked+0xf1/0x260 [41297.066374] rt_spin_lock+0x3b/0x60 [41297.066378] pi_wakeup_handler+0x31/0x90 [kvm_intel] [41297.066388] sysvec_kvm_posted_intr_wakeup_ipi+0x9d/0xd0 [41297.066392] </IRQ> [41297.066392] asm_sysvec_kvm_posted_intr_wakeup_ipi+0x12/0x20 ... Signed-off-by: Marcelo Tosatti <[email protected]> Cc: [email protected] Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit a88ebc49c63378376f7535b585dd989e0a0f7285 Author: David Matlack <[email protected]> Date: Thu Jan 13 23:30:17 2022 +0000 KVM: x86/mmu: Fix write-protection of PTs mapped by the TDP MMU commit 7c8a4742c4abe205ec9daf416c9d42fd6b406e8e upstream. When the TDP MMU is write-protection GFNs for page table protection (as opposed to for dirty logging, or due to the HVA not being writable), it checks if the SPTE is already write-protected and if so skips modifying the SPTE and the TLB flush. This behavior is incorrect because it fails to check if the SPTE is write-protected for page table protection, i.e. fails to check that MMU-writable is '0'. If the SPTE was write-protected for dirty logging but not page table protection, the SPTE could locklessly be made writable, and vCPUs could still be running with writable mappings cached in their TLB. Fix this by only skipping setting the SPTE if the SPTE is already write-protected *and* MMU-writable is already clear. Technically, checking only MMU-writable would suffice; a SPTE cannot be writable without MMU-writable being set. But check both to be paranoid and because it arguably yields more readable code. Fixes: 46044f72c382 ("kvm: x86/mmu: Support write protection for nesting in tdp MMU") Cc: [email protected] Signed-off-by: David Matlack <[email protected]> Message-Id: <[email protected]> Reviewed-by: Sean Christopherson <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>