commit c348c856d084e8facc952ec9e0a60219da4eeee1 Author: Alexandre Frade Date: Thu May 20 16:03:03 2021 +0000 Linux 5.12.5-xanmod1-cacule Signed-off-by: Alexandre Frade commit c4a941048cffc6537d834f9614b4c43cc65769ec Author: Alexandre Frade Date: Wed May 19 16:32:52 2021 +0000 Linux 5.12.5-xanmod1 Signed-off-by: Alexandre Frade commit abeacc7d98828a1289f6ab2b50959203450a941d Author: Alexey Avramov Date: Wed May 12 15:36:56 2021 +0000 mm/vmscan: add sysctl knobs for protecting clean cache The patch provides sysctl knobs for protecting the specified amount of clean file pages (CFP) under memory pressure. The kernel does not have a mechanism for selectively protecting clean file pages. A certain amount of the CFP is required by the userspace for normal operation. First of all, you need a cache of shared libraries and executable files. If the volume of the CFP cache falls below a certain level, thrashing and even livelock occurs. Protection of CFP may be used to prevent thrashing and reducing I/O under memory pressure. Hard protection of CFP may be used to avoid high latency and prevent livelock in near-OOM conditions. The patch provides sysctl knobs for protecting the specified amount of clean file cache under memory pressure. The vm.clean_low_kbytes sysctl knob provides *best-effort* protection of CFP. The CFP on the current node won't be reclaimed uder memory pressure when their amount is below vm.clean_low_kbytes *unless* we threaten to OOM or have no free swap space or vm.swappiness=0. Setting it to a high value may result in a early eviction of anonymous pages into the swap space by attempting to hold the protected amount of clean file pages in memory. The default value is defined by CONFIG_CLEAN_LOW_KBYTES (suggested 150000 in Kconfig). The vm.clean_min_kbytes sysctl knob provides *hard* protection of CFP. The CFP on the current node won't be reclaimed under memory pressure when their amount is below vm.clean_min_kbytes. Setting it to a high value may result in a early out-of-memory condition due to the inability to reclaim the protected amount of CFP when other types of pages cannot be reclaimed. The default value is defined by CONFIG_CLEAN_MIN_KBYTES (suggested 0 in Kconfig). Added compatibility with Multigenerational LRU Framework patchset v2. Signed-off-by: Alexey Avramov Signed-off-by: Alexandre Frade commit cc0596b627c91682aaa21b42656063ffdb650379 Author: Alexandre Frade Date: Wed May 19 16:31:40 2021 +0000 Revert "mm/vmscan: protect file mappings under memory pressure" This reverts commit c29b192fc0e2dbb9c4a553ea713e2fc9a7d9a022. commit 60d71a0a1e7cc1f258b818a5f2c1686a256cb94b Merge: 37c9848cd7f3 761ea31e416a Author: Alexandre Frade Date: Thu May 20 14:20:50 2021 +0000 Merge tag 'v5.12.5' into 5.12-cacule This is the 5.12.5 stable release commit 37c9848cd7f3844792e7665795e4085fa8fc2a55 Merge: b15210162d6d 4bcf3b752d59 Author: Alexandre Frade Date: Thu May 20 14:20:44 2021 +0000 Merge tag 'v5.12.4' into 5.12-cacule This is the 5.12.4 stable release commit 761ea31e416adf1291edf31c8daa0f9b1b94f03d Author: Greg Kroah-Hartman Date: Wed May 19 10:56:45 2021 +0200 Linux 5.12.5 Tested-by: Florian Fainelli Tested-by: Jon Hunter Tested-by: Shuah Khan Tested-by: Fox Chen Tested-by: Jason Self Tested-by: Linux Kernel Functional Testing Tested-by: Rudi Heitbaum Link: https://lore.kernel.org/r/20210517140302.508966430@linuxfoundation.org Tested-by: Rudi Heitbaum Tested-by: Florian Fainelli Tested-by: Jon Hunter Tested-by: Guenter Roeck Tested-by: Shuah Khan Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Link: https://lore.kernel.org/r/20210518135831.445321364@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit 7a7739b266d434a69de9d09f1be63ff6fc44a3e3 Author: Vladimir Oltean Date: Wed Apr 21 21:44:20 2021 +0300 net: bridge: fix error in br_multicast_add_port when CONFIG_NET_SWITCHDEV=n commit 68f5c12abbc9b6f8c5eea16c62f8b7be70793163 upstream. When CONFIG_NET_SWITCHDEV is disabled, the shim for switchdev_port_attr_set inside br_mc_disabled_update returns -EOPNOTSUPP. This is not caught, and propagated to the caller of br_multicast_add_port, preventing ports from joining the bridge. Reported-by: Christian Borntraeger Fixes: ae1ea84b33da ("net: bridge: propagate error code and extack from br_mc_disabled_update") Signed-off-by: Vladimir Oltean Acked-by: Florian Fainelli Tested-by: Christian Borntraeger Acked-by: Nikolay Aleksandrov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit ef43e4db6e875c6d899a65352b872be994c20a14 Author: Kuninori Morimoto Date: Thu Apr 8 13:28:47 2021 +0900 ASoC: rsnd: check all BUSIF status when error commit a4856e15e58b54977f1c0c0299309ad4d1f13365 upstream. commit 66c705d07d784 ("SoC: rsnd: add interrupt support for SSI BUSIF buffer") adds __rsnd_ssi_interrupt() checks for BUSIF status, but is using "break" at for loop. This means it is not checking all status. Let's check all BUSIF status. Fixes: commit 66c705d07d784 ("SoC: rsnd: add interrupt support for SSI BUSIF buffer") Signed-off-by: Kuninori Morimoto Link: https://lore.kernel.org/r/874kgh1jsw.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 6e3a85b8aa01f5752813ee865eea517c97953830 Author: Christoph Hellwig Date: Fri Apr 9 11:46:12 2021 +0200 nvme: do not try to reconfigure APST when the controller is not live commit 53fe2a30bc168db9700e00206d991ff934973cf1 upstream. Do not call nvme_configure_apst when the controller is not live, given that nvme_configure_apst will fail due the lack of an admin queue when the controller is being torn down and nvme_set_latency_tolerance is called from dev_pm_qos_hide_latency_tolerance. Fixes: 510a405d945b("nvme: fix memory leak for power latency tolerance") Reported-by: Peng Liu Signed-off-by: Christoph Hellwig Reviewed-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit 6d4db577853328df8c72c60eb00cbb90d0091a77 Author: Arnd Bergmann Date: Fri Apr 9 22:12:05 2021 +0200 ext4: fix debug format string warning commit fcdf3c34b7abdcbb49690c94c7fa6ce224dc9749 upstream. Using no_printk() for jbd_debug() revealed two warnings: fs/jbd2/recovery.c: In function 'fc_do_one_pass': fs/jbd2/recovery.c:256:30: error: format '%d' expects a matching 'int' argument [-Werror=format=] 256 | jbd_debug(3, "Processing fast commit blk with seq %d"); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ fs/ext4/fast_commit.c: In function 'ext4_fc_replay_add_range': fs/ext4/fast_commit.c:1732:30: error: format '%d' expects argument of type 'int', but argument 2 has type 'long unsigned int' [-Werror=format=] 1732 | jbd_debug(1, "Converting from %d to %d %lld", The first one was added incorrectly, and was also missing a few newlines in debug output, and the second one happened when the type of an argument changed. Reported-by: kernel test robot Fixes: d556435156b7 ("jbd2: avoid -Wempty-body warnings") Fixes: 6db074618969 ("ext4: use BIT() macro for BH_** state bits") Fixes: 5b849b5f96b4 ("jbd2: fast commit recovery path") Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20210409201211.1866633-1-arnd@kernel.org Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 1ba874161ac34c0d1e8e4d4c6db8911b78896a91 Author: Kees Cook Date: Mon Apr 5 14:39:59 2021 -0700 debugfs: Make debugfs_allow RO after init commit 312723a0b34d6d110aa4427a982536bb36ab8471 upstream. Since debugfs_allow is only set at boot time during __init, make it read-only after being set. Fixes: a24c6f7bc923 ("debugfs: Add access restriction option") Cc: Peter Enderborg Reviewed-by: Peter Enderborg Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20210405213959.3079432-1-keescook@chromium.org Signed-off-by: Greg Kroah-Hartman commit d9df1dce5090f087e55cee15c822be66b5c05fce Author: Geert Uytterhoeven Date: Thu Apr 29 14:44:09 2021 +0200 dt-bindings: PCI: rcar-pci-host: Document missing R-Car H1 support commit 62b3b3660aff66433d71f142ab6ed2baaea25025 upstream. scripts/checkpatch.pl -f drivers/pci/controller/pcie-rcar-host.c: WARNING: DT compatible string "renesas,pcie-r8a7779" appears un-documented -- check ./Documentation/devicetree/bindings/ #853: FILE: drivers/pci/controller/pcie-rcar-host.c:853: + { .compatible = "renesas,pcie-r8a7779", Re-add the compatible value for R-Car H1, which was lost during the json-schema conversion. Make the "resets" property optional on R-Car H1, as it is not present yet on R-Car Gen1 SoCs. Fixes: 0d69ce3c2c63d4db ("dt-bindings: PCI: rcar-pci-host: Convert bindings to json-schema") Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/fb0bb969cd0e5872ab5eac70e070242c0d8a5b81.1619700202.git.geert+renesas@glider.be Signed-off-by: Rob Herring Signed-off-by: Greg Kroah-Hartman commit eb9488079f064b94d5288a021046854b50c63d9a Author: Zhen Lei Date: Thu Apr 22 17:08:57 2021 +0800 dt-bindings: serial: 8250: Remove duplicated compatible strings commit a7277a73984114b38dcb62c8548850800ffe864e upstream. The compatible strings "mediatek,*" appears two times, remove one of them. Fixes: e69f5dc623f9 ("dt-bindings: serial: Convert 8250 to json-schema") Signed-off-by: Zhen Lei Link: https://lore.kernel.org/r/20210422090857.583-1-thunder.leizhen@huawei.com Signed-off-by: Rob Herring Signed-off-by: Greg Kroah-Hartman commit 561fc5bb53dd96bd81657063157f84fbbe415287 Author: Dmitry Baryshkov Date: Wed Mar 31 18:16:08 2021 +0300 dt-bindings: phy: qcom,qmp-usb3-dp-phy: move usb3 compatibles back to qcom,qmp-phy.yaml commit 94c34600b6173a2b9dd7d9694a42d86fb8768e62 upstream. The commit 724fabf5df13 ("dt-bindings: phy: qcom,qmp-usb3-dp: Add DP phy information") has support for DP part of USB3+DP combo PHYs. However this change is not backwards compatible, placing additional requirements onto qcom,sc7180-qmp-usb3-phy and qcom,sdm845-qmp-usb3-phy device nodes (to include separate DP part, etc). However the aforementioned nodes do not inclue DP part, they strictly follow the schema defined in the qcom,qmp-phy.yaml file. Move those compatibles, leaving qcom,qmp-usb3-dp-phy.yaml to describe only real "combo" USB3+DP device nodes. Fixes: 724fabf5df13 ("dt-bindings: phy: qcom,qmp-usb3-dp: Add DP phy information") Cc: Stephen Boyd Cc: Sandeep Maheswaram Signed-off-by: Dmitry Baryshkov Acked-by: Rob Herring Reviewed-by: Stephen Boyd Reviewed-by: Bjorn Andersson Link: https://lore.kernel.org/r/20210331151614.3810197-2-dmitry.baryshkov@linaro.org Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 60ee44221fe97373c2fc32bb01641ad5885bc3fc Author: Geert Uytterhoeven Date: Tue Mar 16 16:47:03 2021 +0100 arm64: dts: renesas: falcon: Move console config to CPU board DTS commit e86ff34cc44a49aeae2af74444560b17a0a96c78 upstream. The serial console is located on the Falcon CPU board. Hence move serial console configuration from the main Falcon DTS file to the DTS file that describes the CPU board. Fixes: 63070d7c2270e8de ("arm64: dts: renesas: Add Renesas Falcon boards support") Signed-off-by: Geert Uytterhoeven Reviewed-by: Wolfram Sang Tested-by: Wolfram Sang Reviewed-by: Niklas Söderlund Link: https://lore.kernel.org/r/20210316154705.2433528-2-geert+renesas@glider.be Signed-off-by: Greg Kroah-Hartman commit 045228c6d17ec9d27a9ee42fdee18691eac1fd65 Author: Niklas Söderlund Date: Wed Mar 10 12:07:16 2021 +0100 dt-bindings: thermal: rcar-gen3-thermal: Support five TSC nodes on r8a779a0 commit 9468e7b031876935230182628f8d5f216c071784 upstream. When adding support for V3U (r8a779a0) it was incorrectly recorded it supports four nodes, while in fact it supports five. The fifth node is named TSC0 and breaks the existing naming schema starting at 1. Work around this by separately defining the reg property for V3U and others. Restore the maximum number of nodes to three for other compatibles as it was before erroneously increasing it for V3U. Fixes: d7fdfb6541f3be88 ("dt-bindings: thermal: rcar-gen3-thermal: Add r8a779a0 support") Signed-off-by: Niklas Söderlund Reviewed-by: Geert Uytterhoeven Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20210310110716.3297544-1-niklas.soderlund+renesas@ragnatech.se Signed-off-by: Greg Kroah-Hartman commit 26f3b85a9ee128f3aa472c543c592eae11597e71 Author: Geert Uytterhoeven Date: Thu Apr 29 14:45:52 2021 +0200 dt-bindings: media: renesas,vin: Make resets optional on R-Car Gen1 commit 7935bb56e21b2add81149f4def8e59b4133fe57c upstream. The "resets" property is not present on R-Car Gen1 SoCs. Supporting it would require migrating from renesas,cpg-clocks to renesas,cpg-mssr. Fixes: 905fc6b1bfb4a631 ("dt-bindings: rcar-vin: Convert bindings to json-schema") Signed-off-by: Geert Uytterhoeven Reviewed-by: Niklas Söderlund Link: https://lore.kernel.org/r/217c8197efaee7d803b22d433abb0ea8e33b84c6.1619700314.git.geert+renesas@glider.be Signed-off-by: Rob Herring Signed-off-by: Greg Kroah-Hartman commit 5bf7dfa40ae42ea635c3f0bb7f3707f035b2492a Author: Qii Wang Date: Sat Apr 17 14:46:50 2021 +0800 i2c: mediatek: Fix send master code at more than 1MHz commit 63ce8e3df8f6deca2da52eaf064751ad4018b46e upstream. There are some omissions in the previous patch about replacing I2C_MAX_FAST_MODE__FREQ with I2C_MAX_FAST_MODE_PLUS_FREQ and need to fix it. Fixes: b44658e755b5("i2c: mediatek: Send i2c master code at more than 1MHz") Signed-off-by: Qii Wang Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit c36f6f6b4ddd78f7eb1732706084c2ae1999b0bc Author: Fabio Estevam Date: Sat Mar 20 13:21:52 2021 +0100 media: rkvdec: Remove of_match_ptr() commit c2357dd9cbafc8ed37156e32c24884cfa8380b2f upstream. When building with CONFIG_OF not set, the following clang build warning is seen: >> drivers/staging/media/rkvdec/rkvdec.c:967:34: warning: unused variable 'of_rkvdec_match' [-Wunused-const-variable] Fix the warning by removing the unnecessary of_match_ptr(). Reported-by: kernel test robot Fixes: cd33c830448b ("media: rkvdec: Add the rkvdec driver") Signed-off-by: Fabio Estevam Reviewed-by: Ezequiel Garcia Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit eb68304c8771d793ba9edb6e2eb50b940c3de7a4 Author: Enric Balletbo i Serra Date: Thu Feb 25 18:49:59 2021 +0100 soc: mediatek: pm-domains: Add a power domain names for mt8192 commit 3edc01bc53c639b1c98f57e7f1c026aae6a25a62 upstream. Add the power domains names for the mt8192 SoC. Fixes: a49d5e7a89d6 ("soc: mediatek: pm-domains: Add support for mt8192") Signed-off-by: Enric Balletbo i Serra Reviewed-by: Hsin-Yi Wang Link: https://lore.kernel.org/r/20210225175000.824661-3-enric.balletbo@collabora.com Signed-off-by: Matthias Brugger Signed-off-by: Greg Kroah-Hartman commit 6858b67769a8554753b8e542761ec9dd061c8d38 Author: Enric Balletbo i Serra Date: Thu Feb 25 18:49:58 2021 +0100 soc: mediatek: pm-domains: Add a power domain names for mt8183 commit e57b8112258ed46dff23b49d6e400f54a8dbf1c3 upstream. Add the power domains names for the mt8183 SoC. This removes the debugfs errors like the following: debugfs: Directory 'power-domain' with parent 'pm_genpd' already present! Fixes: eb9fa767fbe1 ("soc: mediatek: pm-domains: Add support for mt8183") Signed-off-by: Enric Balletbo i Serra Reviewed-by: Hsin-Yi Wang Link: https://lore.kernel.org/r/20210225175000.824661-2-enric.balletbo@collabora.com Signed-off-by: Matthias Brugger Signed-off-by: Greg Kroah-Hartman commit 0a84ada8aa8af7dc32fabb36cda12dba39ac60ae Author: Enric Balletbo i Serra Date: Thu Feb 25 18:49:57 2021 +0100 soc: mediatek: pm-domains: Add a meaningful power domain name commit 022b02b4505ecea5eda02b18683531e49f7d8eb7 upstream. Add the power domains names to the power domain struct so we have meaningful name for every power domain. This also removes the following debugfs error message. [ 2.242068] debugfs: Directory 'power-domain' with parent 'pm_genpd' already present! [ 2.249949] debugfs: Directory 'power-domain' with parent 'pm_genpd' already present! [ 2.257784] debugfs: Directory 'power-domain' with parent 'pm_genpd' already present! ... Fixes: 59b644b01cf4 ("soc: mediatek: Add MediaTek SCPSYS power domains") Signed-off-by: Enric Balletbo i Serra Reviewed-by: Hsin-Yi Wang Link: https://lore.kernel.org/r/20210225175000.824661-1-enric.balletbo@collabora.com Signed-off-by: Matthias Brugger Signed-off-by: Greg Kroah-Hartman commit 14ed485c318049aa3c4ffd64e55584fd88dd0ea0 Author: Paweł Chmiel Date: Sat Oct 24 17:43:46 2020 +0200 clk: exynos7: Mark aclk_fsys1_200 as critical commit 34138a59b92c1a30649a18ec442d2e61f3bc34dd upstream. This clock must be always enabled to allow access to any registers in fsys1 CMU. Until proper solution based on runtime PM is applied (similar to what was done for Exynos5433), mark that clock as critical so it won't be disabled. It was observed on Samsung Galaxy S6 device (based on Exynos7420), where UFS module is probed before pmic used to power that device. In this case defer probe was happening and that clock was disabled by UFS driver, causing whole boot to hang on next CMU access. Fixes: 753195a749a6 ("clk: samsung: exynos7: Correct CMU_FSYS1 clocks names") Signed-off-by: Paweł Chmiel Acked-by: Krzysztof Kozlowski Link: https://lore.kernel.org/linux-clk/20201024154346.9589-1-pawel.mikolaj.chmiel@gmail.com [s.nawrocki: Added comment in the code] Signed-off-by: Sylwester Nawrocki Signed-off-by: Greg Kroah-Hartman commit f7520970d5353cb1fa4d9089a1b23669c5da97fe Author: Stéphane Marchesin Date: Thu Apr 29 03:10:21 2021 +0000 drm/i915: Fix crash in auto_retire commit 402be8a101190969fc7ff122d07e262df86e132b upstream. The retire logic uses the 2 lower bits of the pointer to the retire function to store flags. However, the auto_retire function is not guaranteed to be aligned to a multiple of 4, which causes crashes as we jump to the wrong address, for example like this: 2021-04-24T18:03:53.804300Z WARNING kernel: [ 516.876901] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI 2021-04-24T18:03:53.804310Z WARNING kernel: [ 516.876906] CPU: 7 PID: 146 Comm: kworker/u16:6 Tainted: G U 5.4.105-13595-g3cd84167b2df #1 2021-04-24T18:03:53.804311Z WARNING kernel: [ 516.876907] Hardware name: Google Volteer2/Volteer2, BIOS Google_Volteer2.13672.76.0 02/22/2021 2021-04-24T18:03:53.804312Z WARNING kernel: [ 516.876911] Workqueue: events_unbound active_work 2021-04-24T18:03:53.804313Z WARNING kernel: [ 516.876914] RIP: 0010:auto_retire+0x1/0x20 2021-04-24T18:03:53.804314Z WARNING kernel: [ 516.876916] Code: e8 01 f2 ff ff eb 02 31 db 48 89 d8 5b 5d c3 0f 1f 44 00 00 55 48 89 e5 f0 ff 87 c8 00 00 00 0f 88 ab 47 4a 00 31 c0 5d c3 0f <1f> 44 00 00 55 48 89 e5 f0 ff 8f c8 00 00 00 0f 88 9a 47 4a 00 74 2021-04-24T18:03:53.804319Z WARNING kernel: [ 516.876918] RSP: 0018:ffff9b4d809fbe38 EFLAGS: 00010286 2021-04-24T18:03:53.804320Z WARNING kernel: [ 516.876919] RAX: 0000000000000007 RBX: ffff927915079600 RCX: 0000000000000007 2021-04-24T18:03:53.804320Z WARNING kernel: [ 516.876921] RDX: ffff9b4d809fbe40 RSI: 0000000000000286 RDI: ffff927915079600 2021-04-24T18:03:53.804321Z WARNING kernel: [ 516.876922] RBP: ffff9b4d809fbe68 R08: 8080808080808080 R09: fefefefefefefeff 2021-04-24T18:03:53.804321Z WARNING kernel: [ 516.876924] R10: 0000000000000010 R11: ffffffff92e44bd8 R12: ffff9279150796a0 2021-04-24T18:03:53.804322Z WARNING kernel: [ 516.876925] R13: ffff92791c368180 R14: ffff927915079640 R15: 000000001c867605 2021-04-24T18:03:53.804323Z WARNING kernel: [ 516.876926] FS: 0000000000000000(0000) GS:ffff92791ffc0000(0000) knlGS:0000000000000000 2021-04-24T18:03:53.804323Z WARNING kernel: [ 516.876928] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 2021-04-24T18:03:53.804324Z WARNING kernel: [ 516.876929] CR2: 0000239514955000 CR3: 00000007f82da001 CR4: 0000000000760ee0 2021-04-24T18:03:53.804325Z WARNING kernel: [ 516.876930] PKRU: 55555554 2021-04-24T18:03:53.804325Z WARNING kernel: [ 516.876931] Call Trace: 2021-04-24T18:03:53.804326Z WARNING kernel: [ 516.876935] __active_retire+0x77/0xcf 2021-04-24T18:03:53.804326Z WARNING kernel: [ 516.876939] process_one_work+0x1da/0x394 2021-04-24T18:03:53.804327Z WARNING kernel: [ 516.876941] worker_thread+0x216/0x375 2021-04-24T18:03:53.804327Z WARNING kernel: [ 516.876944] kthread+0x147/0x156 2021-04-24T18:03:53.804335Z WARNING kernel: [ 516.876946] ? pr_cont_work+0x58/0x58 2021-04-24T18:03:53.804335Z WARNING kernel: [ 516.876948] ? kthread_blkcg+0x2e/0x2e 2021-04-24T18:03:53.804336Z WARNING kernel: [ 516.876950] ret_from_fork+0x1f/0x40 2021-04-24T18:03:53.804336Z WARNING kernel: [ 516.876952] Modules linked in: cdc_mbim cdc_ncm cdc_wdm xt_cgroup rfcomm cmac algif_hash algif_skcipher af_alg xt_MASQUERADE uinput snd_soc_rt5682_sdw snd_soc_rt5682 snd_soc_max98373_sdw snd_soc_max98373 snd_soc_rl6231 regmap_sdw snd_soc_sof_sdw snd_soc_hdac_hdmi snd_soc_dmic snd_hda_codec_hdmi snd_sof_pci snd_sof_intel_hda_common intel_ipu6_psys snd_sof_xtensa_dsp soundwire_intel soundwire_generic_allocation soundwire_cadence snd_sof_intel_hda snd_sof snd_soc_hdac_hda snd_soc_acpi_intel_match snd_soc_acpi snd_hda_ext_core soundwire_bus snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hwdep snd_hda_core intel_ipu6_isys videobuf2_dma_contig videobuf2_v4l2 videobuf2_common videobuf2_memops mei_hdcp intel_ipu6 ov2740 ov8856 at24 sx9310 dw9768 v4l2_fwnode cros_ec_typec intel_pmc_mux roles acpi_als typec fuse iio_trig_sysfs cros_ec_light_prox cros_ec_lid_angle cros_ec_sensors cros_ec_sensors_core industrialio_triggered_buffer cros_ec_sensors_ring kfifo_buf industrialio cros_ec_sensorhub 2021-04-24T18:03:53.804337Z WARNING kernel: [ 516.876972] cdc_ether usbnet iwlmvm lzo_rle lzo_compress iwl7000_mac80211 iwlwifi zram cfg80211 r8152 mii btusb btrtl btintel btbcm bluetooth ecdh_generic ecc joydev 2021-04-24T18:03:53.804337Z EMERG kernel: [ 516.879169] gsmi: Log Shutdown Reason 0x03 This change fixes this by aligning the function. Signed-off-by: Stéphane Marchesin Fixes: 229007e02d69 ("drm/i915: Wrap i915_active in a simple kreffed struct") Signed-off-by: Tvrtko Ursulin Link: https://patchwork.freedesktop.org/patch/msgid/20210429031021.1218091-1-marcheu@chromium.org (cherry picked from commit ca419f407b43cc89942ebc297c7a63d94abbcae4) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 7d88c1e740ea774309ee244b42238cd6a402a065 Author: Tvrtko Ursulin Date: Thu Apr 29 09:35:29 2021 +0100 drm/i915/overlay: Fix active retire callback alignment commit a915fe5e9601c632417ef5261af70788d7d23a8a upstream. __i915_active_call annotation is required on the retire callback to ensure correct function alignment. Signed-off-by: Tvrtko Ursulin Fixes: a21ce8ad12d2 ("drm/i915/overlay: Switch to using i915_active tracking") Cc: Chris Wilson Cc: Matthew Auld Reviewed-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20210429083530.849546-1-tvrtko.ursulin@linux.intel.com (cherry picked from commit d8e44e4dd221ee283ea60a6fb87bca08807aa0ab) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit f3ea4506674c91303af9cac767cf3b26265ebabe Author: Ville Syrjälä Date: Wed Apr 21 18:33:59 2021 +0300 drm/i915: Read C0DRB3/C1DRB3 as 16 bits again commit 04d019961fd15de92874575536310243a0d4c5c5 upstream. We've defined C0DRB3/C1DRB3 as 16 bit registers, so access them as such. Fixes: 1c8242c3a4b2 ("drm/i915: Use unchecked writes for setting up the fences") Reviewed-by: Chris Wilson Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20210421153401.13847-3-ville.syrjala@linux.intel.com (cherry picked from commit f765a5b48c667bdada5e49d5e0f23f8c0687b21b) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 628cf5277a3579dc80c937127a77b8fc27ed7997 Author: Kuogee Hsieh Date: Wed Apr 21 16:37:35 2021 -0700 drm/msm/dp: check sink_count before update is_connected status commit d9aa6571b28ba0022de1e48801ff03a1854c7ef2 upstream. Link status is different from display connected status in the case of something like an Apple dongle where the type-c plug can be connected, and therefore the link is connected, but no sink is connected until an HDMI cable is plugged into the dongle. The sink_count of DPCD of dongle will increase to 1 once an HDMI cable is plugged into the dongle so that display connected status will become true. This checking also apply at pm_resume. Changes in v4: -- none Fixes: 94e58e2d06e3 ("drm/msm/dp: reset dp controller only at boot up and pm_resume") Reported-by: Stephen Boyd Reviewed-by: Stephen Boyd Tested-by: Stephen Boyd Signed-off-by: Kuogee Hsieh Fixes: 8ede2ecc3e5e ("drm/msm/dp: Add DP compliance tests on Snapdragon Chipsets") Link: https://lore.kernel.org/r/1619048258-8717-2-git-send-email-khsieh@codeaurora.org Signed-off-by: Rob Clark Signed-off-by: Greg Kroah-Hartman commit ab2f71a42164a8119503f3e6da46353af5eba752 Author: Lv Yunlong Date: Mon Apr 26 05:43:40 2021 -0700 drm/i915/gt: Fix a double free in gen8_preallocate_top_level_pdp commit ea995218dddba171fecd05496c69617c5ef3c5b8 upstream. Our code analyzer reported a double free bug. In gen8_preallocate_top_level_pdp, pde and pde->pt.base are allocated via alloc_pd(vm) with one reference. If pin_pt_dma() failed, pde->pt.base is freed by i915_gem_object_put() with a reference dropped. Then free_pd calls free_px() defined in intel_ppgtt.c, which calls i915_gem_object_put() to put pde->pt.base again. As pde->pt.base is protected by refcount, so the second put will not free pde->pt.base actually. But, maybe it is better to remove the first put? Fixes: 82adf901138cc ("drm/i915/gt: Shrink i915_page_directory's slab bucket") Signed-off-by: Lv Yunlong Reviewed-by: Matthew Auld Signed-off-by: Matthew Auld Link: https://patchwork.freedesktop.org/patch/msgid/20210426124340.4238-1-lyl2019@mail.ustc.edu.cn (cherry picked from commit ac69496fe65cca0611d5917b7d232730ff605bc7) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 6f7ffe3366968c85dc46fd32e7c2245eda5b34a1 Author: Greg Kroah-Hartman Date: Mon Apr 5 11:48:52 2021 +0200 kobject_uevent: remove warning in init_uevent_argv() commit b4104180a2efb85f55e1ba1407885c9421970338 upstream. syzbot can trigger the WARN() in init_uevent_argv() which isn't the nicest as the code does properly recover and handle the error. So change the WARN() call to pr_warn() and provide some more information on what the buffer size that was needed. Link: https://lore.kernel.org/r/20201107082206.GA19079@kroah.com Cc: "Rafael J. Wysocki" Cc: linux-kernel@vger.kernel.org Reported-by: syzbot+92340f7b2b4789907fdb@syzkaller.appspotmail.com Signed-off-by: Greg Kroah-Hartman Link: https://lore.kernel.org/r/20210405094852.1348499-1-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit 26c704bb6eed8d8b566228d10e05f102c24cf6d1 Author: Badhri Jagan Sridharan Date: Wed Apr 14 22:01:21 2021 -0700 usb: typec: tcpm: Fix error while calculating PPS out values commit 374157ff88ae1a7f7927331cbc72c1ec11994e8a upstream. "usb: typec: tcpm: Address incorrect values of tcpm psy for pps supply" introduced a regression for req_out_volt and req_op_curr calculation. req_out_volt should consider the newly calculated max voltage instead of previously accepted max voltage by the port partner. Likewise, req_op_curr should consider the newly calculated max current instead of previously accepted max current by the port partner. Fixes: e3a072022487 ("usb: typec: tcpm: Address incorrect values of tcpm psy for pps supply") Reviewed-by: Guenter Roeck Signed-off-by: Badhri Jagan Sridharan Link: https://lore.kernel.org/r/20210415050121.1928298-1-badhri@google.com Signed-off-by: Greg Kroah-Hartman commit a8aeb722aeac7110a2f9023bba46a0c2e6e88b66 Author: Tony Lindgren Date: Tue Mar 23 09:43:26 2021 +0200 clocksource/drivers/timer-ti-dm: Handle dra7 timer wrap errata i940 commit 25de4ce5ed02994aea8bc111d133308f6fd62566 upstream. There is a timer wrap issue on dra7 for the ARM architected timer. In a typical clock configuration the timer fails to wrap after 388 days. To work around the issue, we need to use timer-ti-dm percpu timers instead. Let's configure dmtimer3 and 4 as percpu timers by default, and warn about the issue if the dtb is not configured properly. Let's do this as a single patch so it can be backported to v5.8 and later kernels easily. Note that this patch depends on earlier timer-ti-dm systimer posted mode fixes, and a preparatory clockevent patch "clocksource/drivers/timer-ti-dm: Prepare to handle dra7 timer wrap issue". For more information, please see the errata for "AM572x Sitara Processors Silicon Revisions 1.1, 2.0": https://www.ti.com/lit/er/sprz429m/sprz429m.pdf The concept is based on earlier reference patches done by Tero Kristo and Keerthy. Cc: Keerthy Cc: Tero Kristo Signed-off-by: Tony Lindgren Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20210323074326.28302-3-tony@atomide.com Signed-off-by: Greg Kroah-Hartman commit be50eafb7ddf7c89514e3122fd102b4c425715be Author: Tony Lindgren Date: Tue Mar 23 09:43:25 2021 +0200 clocksource/drivers/timer-ti-dm: Prepare to handle dra7 timer wrap issue commit 3efe7a878a11c13b5297057bfc1e5639ce1241ce upstream. There is a timer wrap issue on dra7 for the ARM architected timer. In a typical clock configuration the timer fails to wrap after 388 days. To work around the issue, we need to use timer-ti-dm timers instead. Let's prepare for adding support for percpu timers by adding a common dmtimer_clkevt_init_common() and call it from dmtimer_clockevent_init(). This patch makes no intentional functional changes. Signed-off-by: Tony Lindgren Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20210323074326.28302-2-tony@atomide.com Signed-off-by: Greg Kroah-Hartman commit be5839c7e607f016d7e31c5d2a6a602675d28fc6 Author: Maciej W. Rozycki Date: Thu Apr 22 22:36:12 2021 +0200 MIPS: Avoid handcoded DIVU in `__div64_32' altogether commit 25ab14cbe9d1b66fda44c71a2db7582a31b6f5cd upstream. Remove the inline asm with a DIVU instruction from `__div64_32' and use plain C code for the intended DIVMOD calculation instead. GCC is smart enough to know that both the quotient and the remainder are calculated with single DIVU, so with ISAs up to R5 the same instruction is actually produced with overall similar code. For R6 compiled code will work, but separate DIVU and MODU instructions will be produced, which are also interlocked, so scalar implementations will likely not perform as well as older ISAs with their asynchronous MD unit. Likely still faster then the generic algorithm though. This removes a compilation error for R6 however where the original DIVU instruction is not supported anymore and the MDU accumulator registers have been removed and consequently GCC complains as to a constraint it cannot find a register for: In file included from ./include/linux/math.h:5, from ./include/linux/kernel.h:13, from mm/page-writeback.c:15: ./include/linux/math64.h: In function 'div_u64_rem': ./arch/mips/include/asm/div64.h:76:17: error: inconsistent operand constraints in an 'asm' 76 | __asm__("divu $0, %z1, %z2" \ | ^~~~~~~ ./include/asm-generic/div64.h:245:25: note: in expansion of macro '__div64_32' 245 | __rem = __div64_32(&(n), __base); \ | ^~~~~~~~~~ ./include/linux/math64.h:91:22: note: in expansion of macro 'do_div' 91 | *remainder = do_div(dividend, divisor); | ^~~~~~ This has passed correctness verification with test_div64 and reduced the module's average execution time down to 1.0404s from 1.0445s with R3400 @40MHz. The module's MIPS I machine code has also shrunk by 12 bytes or 3 instructions. Signed-off-by: Maciej W. Rozycki Signed-off-by: Thomas Bogendoerfer Signed-off-by: Greg Kroah-Hartman commit 26fc611259fe9b851a4fc5bdc3e1233d9f732a37 Author: Maciej W. Rozycki Date: Tue Apr 20 04:50:48 2021 +0200 MIPS: Avoid DIVU in `__div64_32' is result would be zero commit c1d337d45ec0a802299688e17d568c4e3a585895 upstream. We already check the high part of the divident against zero to avoid the costly DIVU instruction in that case, needed to reduce the high part of the divident, so we may well check against the divisor instead and set the high part of the quotient to zero right away. We need to treat the high part the divident in that case though as the remainder that would be calculated by the DIVU instruction we avoided. This has passed correctness verification with test_div64 and reduced the module's average execution time down to 1.0445s and 0.2619s from 1.0668s and 0.2629s respectively for an R3400 CPU @40MHz and a 5Kc CPU @160MHz. Signed-off-by: Maciej W. Rozycki Signed-off-by: Thomas Bogendoerfer Signed-off-by: Greg Kroah-Hartman commit 7bb9f47110058adb7c9050c310b26750039f3a7a Author: Maciej W. Rozycki Date: Tue Apr 20 04:50:40 2021 +0200 MIPS: Reinstate platform `__div64_32' handler commit c49f71f60754acbff37505e1d16ca796bf8a8140 upstream. Our current MIPS platform `__div64_32' handler is inactive, because it is incorrectly only enabled for 64-bit configurations, for which generic `do_div' code does not call it anyway. The handler is not suitable for being called from there though as it only calculates 32 bits of the quotient under the assumption the 64-bit divident has been suitably reduced. Code for such reduction used to be there, however it has been incorrectly removed with commit c21004cd5b4c ("MIPS: Rewrite to work with gcc 4.4.0."), which should have only updated an obsoleted constraint for an inline asm involving $hi and $lo register outputs, while possibly wiring the original MIPS variant of the `do_div' macro as `__div64_32' handler for the generic `do_div' implementation Correct the handler as follows then: - Revert most of the commit referred, however retaining the current formatting, except for the final two instructions of the inline asm sequence, which the original commit missed. Omit the original 64-bit parts though. - Rename the original `do_div' macro to `__div64_32'. Use the combined `x' constraint referring to the MD accumulator as a whole, replacing the original individual `h' and `l' constraints used for $hi and $lo registers respectively, of which `h' has been obsoleted with GCC 4.4. Update surrounding code accordingly. We have since removed support for GCC versions before 4.9, so no need for a special arrangement here; GCC has supported the `x' constraint since forever anyway, or at least going back to 1991. - Rename the `__base' local variable in `__div64_32' to `__radix' to avoid a conflict with a local variable in `do_div'. - Actually enable this code for 32-bit rather than 64-bit configurations by qualifying it with BITS_PER_LONG being 32 instead of 64. Include for this macro rather than as we don't need anything else. - Finally include last rather than first. This has passed correctness verification with test_div64 and reduced the module's average execution time down to 1.0668s and 0.2629s from 2.1529s and 0.5647s respectively for an R3400 CPU @40MHz and a 5Kc CPU @160MHz. For a reference 64-bit `do_div' code where we have the DDIVU instruction available to do the whole calculation right away averages at 0.0660s for the latter CPU. Fixes: c21004cd5b4c ("MIPS: Rewrite to work with gcc 4.4.0.") Reported-by: Huacai Chen Signed-off-by: Maciej W. Rozycki Cc: stable@vger.kernel.org # v2.6.30+ Signed-off-by: Thomas Bogendoerfer Signed-off-by: Greg Kroah-Hartman commit 856dc266fcf796f9e2a67a42ec5c41783ffaf8e0 Author: Matthew Wilcox (Oracle) Date: Fri May 14 17:27:24 2021 -0700 mm: fix struct page layout on 32-bit systems commit 9ddb3c14afba8bc5950ed297f02d4ae05ff35cd1 upstream. 32-bit architectures which expect 8-byte alignment for 8-byte integers and need 64-bit DMA addresses (arm, mips, ppc) had their struct page inadvertently expanded in 2019. When the dma_addr_t was added, it forced the alignment of the union to 8 bytes, which inserted a 4 byte gap between 'flags' and the union. Fix this by storing the dma_addr_t in one or two adjacent unsigned longs. This restores the alignment to that of an unsigned long. We always store the low bits in the first word to prevent the PageTail bit from being inadvertently set on a big endian platform. If that happened, get_user_pages_fast() racing against a page which was freed and reallocated to the page_pool could dereference a bogus compound_head(), which would be hard to trace back to this cause. Link: https://lkml.kernel.org/r/20210510153211.1504886-1-willy@infradead.org Fixes: c25fff7171be ("mm: add dma_addr_t to struct page") Signed-off-by: Matthew Wilcox (Oracle) Acked-by: Ilias Apalodimas Acked-by: Jesper Dangaard Brouer Acked-by: Vlastimil Babka Tested-by: Matteo Croce Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit e3ea1895df719c4ef87862501bb10d95f4177bed Author: Sean Christopherson Date: Tue May 4 10:17:24 2021 -0700 KVM: VMX: Disable preemption when probing user return MSRs commit 5104d7ffcf24749939bea7fdb5378d186473f890 upstream. Disable preemption when probing a user return MSR via RDSMR/WRMSR. If the MSR holds a different value per logical CPU, the WRMSR could corrupt the host's value if KVM is preempted between the RDMSR and WRMSR, and then rescheduled on a different CPU. Opportunistically land the helper in common x86, SVM will use the helper in a future commit. Fixes: 4be534102624 ("KVM: VMX: Initialize vmx->guest_msrs[] right after allocation") Cc: stable@vger.kernel.org Cc: Xiaoyao Li Signed-off-by: Sean Christopherson Message-Id: <20210504171734.1434054-6-seanjc@google.com> Reviewed-by: Jim Mattson Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 7c9ebc3e4c942f4bd0b301ca703b3632f0d67d9f Author: Sean Christopherson Date: Tue May 4 10:17:20 2021 -0700 KVM: VMX: Do not advertise RDPID if ENABLE_RDTSCP control is unsupported commit 8aec21c04caa2000f91cf8822ae0811e4b0c3971 upstream. Clear KVM's RDPID capability if the ENABLE_RDTSCP secondary exec control is unsupported. Despite being enumerated in a separate CPUID flag, RDPID is bundled under the same VMCS control as RDTSCP and will #UD in VMX non-root if ENABLE_RDTSCP is not enabled. Fixes: 41cd02c6f7f6 ("kvm: x86: Expose RDPID in KVM_GET_SUPPORTED_CPUID") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-Id: <20210504171734.1434054-2-seanjc@google.com> Reviewed-by: Jim Mattson Reviewed-by: Reiji Watanabe Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit bd0e8455b85b651a4c77de9616e307129b15aaa7 Author: Vitaly Kuznetsov Date: Mon May 3 17:08:51 2021 +0200 KVM: nVMX: Always make an attempt to map eVMCS after migration commit f5c7e8425f18fdb9bdb7d13340651d7876890329 upstream. When enlightened VMCS is in use and nested state is migrated with vmx_get_nested_state()/vmx_set_nested_state() KVM can't map evmcs page right away: evmcs gpa is not 'struct kvm_vmx_nested_state_hdr' and we can't read it from VP assist page because userspace may decide to restore HV_X64_MSR_VP_ASSIST_PAGE after restoring nested state (and QEMU, for example, does exactly that). To make sure eVMCS is mapped /vmx_set_nested_state() raises KVM_REQ_GET_NESTED_STATE_PAGES request. Commit f2c7ef3ba955 ("KVM: nSVM: cancel KVM_REQ_GET_NESTED_STATE_PAGES on nested vmexit") added KVM_REQ_GET_NESTED_STATE_PAGES clearing to nested_vmx_vmexit() to make sure MSR permission bitmap is not switched when an immediate exit from L2 to L1 happens right after migration (caused by a pending event, for example). Unfortunately, in the exact same situation we still need to have eVMCS mapped so nested_sync_vmcs12_to_shadow() reflects changes in VMCS12 to eVMCS. As a band-aid, restore nested_get_evmcs_page() when clearing KVM_REQ_GET_NESTED_STATE_PAGES in nested_vmx_vmexit(). The 'fix' is far from being ideal as we can't easily propagate possible failures and even if we could, this is most likely already too late to do so. The whole 'KVM_REQ_GET_NESTED_STATE_PAGES' idea for mapping eVMCS after migration seems to be fragile as we diverge too much from the 'native' path when vmptr loading happens on vmx_set_nested_state(). Fixes: f2c7ef3ba955 ("KVM: nSVM: cancel KVM_REQ_GET_NESTED_STATE_PAGES on nested vmexit") Signed-off-by: Vitaly Kuznetsov Message-Id: <20210503150854.1144255-2-vkuznets@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit ac51e3ac76575efd6ae0a25b63c46f6c8db924d6 Author: Sean Christopherson Date: Tue May 4 10:17:26 2021 -0700 KVM: x86: Add support for RDPID without RDTSCP commit 36fa06f9ff39f23e03cd8206dc6bbb7711c23be6 upstream. Allow userspace to enable RDPID for a guest without also enabling RDTSCP. Aside from checking for RDPID support in the obvious flows, VMX also needs to set ENABLE_RDTSCP=1 when RDPID is exposed. For the record, there is no known scenario where enabling RDPID without RDTSCP is desirable. But, both AMD and Intel architectures allow for the condition, i.e. this is purely to make KVM more architecturally accurate. Fixes: 41cd02c6f7f6 ("kvm: x86: Expose RDPID in KVM_GET_SUPPORTED_CPUID") Cc: stable@vger.kernel.org Reported-by: Reiji Watanabe Signed-off-by: Sean Christopherson Message-Id: <20210504171734.1434054-8-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit c3d8d9e9760753db2d27252b4d5f986fecd94ec9 Author: Sean Christopherson Date: Tue May 4 10:17:23 2021 -0700 KVM: x86: Move RDPID emulation intercept to its own enum commit 2183de4161b90bd3851ccd3910c87b2c9adfc6ed upstream. Add a dedicated intercept enum for RDPID instead of piggybacking RDTSCP. Unlike VMX's ENABLE_RDTSCP, RDPID is not bound to SVM's RDTSCP intercept. Fixes: fb6d4d340e05 ("KVM: x86: emulate RDPID") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-Id: <20210504171734.1434054-5-seanjc@google.com> Reviewed-by: Jim Mattson Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit a6af4f9ebe20a52dd6a3b7475a6aa5e3cf4dd3b5 Author: Sean Christopherson Date: Tue May 4 10:17:21 2021 -0700 KVM: x86: Emulate RDPID only if RDTSCP is supported commit 85d0011264da24be08ae907d7f29983a597ca9b1 upstream. Do not advertise emulation support for RDPID if RDTSCP is unsupported. RDPID emulation subtly relies on MSR_TSC_AUX to exist in hardware, as both vmx_get_msr() and svm_get_msr() will return an error if the MSR is unsupported, i.e. ctxt->ops->get_msr() will fail and the emulator will inject a #UD. Note, RDPID emulation also relies on RDTSCP being enabled in the guest, but this is a KVM bug and will eventually be fixed. Fixes: fb6d4d340e05 ("KVM: x86: emulate RDPID") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-Id: <20210504171734.1434054-3-seanjc@google.com> Reviewed-by: Jim Mattson Reviewed-by: Reiji Watanabe Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 3e6b3632cd4e087b70b70ce77ccedca4926e9245 Author: Juergen Gross Date: Fri Apr 23 07:40:38 2021 +0200 xen/gntdev: fix gntdev_mmap() error exit path commit 970655aa9b42461f8394e4457307005bdeee14d9 upstream. Commit d3eeb1d77c5d0af ("xen/gntdev: use mmu_interval_notifier_insert") introduced an error in gntdev_mmap(): in case the call of mmu_interval_notifier_insert_locked() fails the exit path should not call mmu_interval_notifier_remove(), as this might result in NULL dereferences. One reason for failure is e.g. a signal pending for the running process. Fixes: d3eeb1d77c5d0af ("xen/gntdev: use mmu_interval_notifier_insert") Cc: stable@vger.kernel.org Reported-by: Marek Marczykowski-Górecki Tested-by: Marek Marczykowski-Górecki Signed-off-by: Juergen Gross Reviewed-by: Luca Fancellu Link: https://lore.kernel.org/r/20210423054038.26696-1-jgross@suse.com Signed-off-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman commit 6f1b9e8767ae5e24bc35f2a4d59b29ba3851b16a Author: Alexandre Belloni Date: Tue May 11 03:45:16 2021 +0200 alarmtimer: Check RTC features instead of ops commit e09784a8a751e539dffc94d43bc917b0ac1e934a upstream. RTC drivers used to leave .set_alarm() NULL in order to signal the RTC device doesn't support alarms. The drivers are now clearing the RTC_FEATURE_ALARM bit for that purpose in order to keep the rtc_class_ops structure const. So now, .set_alarm() is set unconditionally and this possibly causes the alarmtimer code to select an RTC device that doesn't support alarms. Test RTC_FEATURE_ALARM instead of relying on ops->set_alarm to determine whether alarms are available. Fixes: 7ae41220ef58 ("rtc: introduce features bitfield") Signed-off-by: Alexandre Belloni Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210511014516.563031-1-alexandre.belloni@bootlin.com Signed-off-by: Greg Kroah-Hartman commit 79c9011443ad46c4c1071f5e3009fb16ffc457f6 Author: Oliver Neukum Date: Mon Apr 26 11:26:22 2021 +0200 cdc-wdm: untangle a circular dependency between callback and softint commit 18abf874367456540846319574864e6ff32752e2 upstream. We have a cycle of callbacks scheduling works which submit URBs with those callbacks. This needs to be blocked, stopped and unblocked to untangle the circle. Signed-off-by: Oliver Neukum Link: https://lore.kernel.org/r/20210426092622.20433-1-oneukum@suse.com Cc: stable Signed-off-by: Greg Kroah-Hartman commit d310d89c79218f6da0ec4e6ba599f138f3bc3c06 Author: Colin Ian King Date: Fri May 7 19:30:41 2021 +0100 iio: tsl2583: Fix division by a zero lux_val commit af0e1871d79cfbb91f732d2c6fa7558e45c31038 upstream. The lux_val returned from tsl2583_get_lux can potentially be zero, so check for this to avoid a division by zero and an overflowed gain_trim_val. Fixes clang scan-build warning: drivers/iio/light/tsl2583.c:345:40: warning: Either the condition 'lux_val<0' is redundant or there is division by zero at line 345. [zerodivcond] Fixes: ac4f6eee8fe8 ("staging: iio: TAOS tsl258x: Device driver") Signed-off-by: Colin Ian King Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 2a40e13d6a71730eb1e22cf102ff44e7ce233292 Author: Dmitry Osipenko Date: Fri Apr 23 05:09:59 2021 +0300 iio: gyro: mpu3050: Fix reported temperature value commit f73c730774d88a14d7b60feee6d0e13570f99499 upstream. The raw temperature value is a 16-bit signed integer. The sign casting is missing in the code, which results in a wrong temperature reported by userspace tools, fix it. Cc: stable@vger.kernel.org Fixes: 3904b28efb2c ("iio: gyro: Add driver for the MPU-3050 gyroscope") Datasheet: https://www.cdiweb.com/datasheets/invensense/mpu-3000a.pdf Tested-by: Maxim Schwalm # Asus TF700T Tested-by: Svyatoslav Ryhel # Asus TF201 Reported-by: Svyatoslav Ryhel Reviewed-by: Andy Shevchenko Reviewed-by: Linus Walleij Signed-off-by: Dmitry Osipenko Acked-by: Jean-Baptiste Maneyrol Link: https://lore.kernel.org/r/20210423020959.5023-1-digetx@gmail.com Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit ab6c935ba3a04317632f3b8b68675bdbaf395303 Author: Tomasz Duszynski Date: Fri Apr 23 10:02:44 2021 +0200 iio: core: fix ioctl handlers removal commit 901f84de0e16bde10a72d7eb2f2eb73fcde8fa1a upstream. Currently ioctl handlers are removed twice. For the first time during iio_device_unregister() then later on inside iio_device_unregister_eventset() and iio_buffers_free_sysfs_and_mask(). Double free leads to kernel panic. Fix this by not touching ioctl handlers list directly but rather letting code responsible for registration call the matching cleanup routine itself. Fixes: 8dedcc3eee3ac ("iio: core: centralize ioctl() calls to the main chardev") Signed-off-by: Tomasz Duszynski Acked-by: Alexandru Ardelean Cc: Link: https://lore.kernel.org/r/20210423080244.2790-1-tomasz.duszynski@octakon.com Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 6c0197c59f97639586988f186bc3c4b18e73dcff Author: Sandeep Singh Date: Wed May 12 11:08:16 2021 +0300 xhci: Add reset resume quirk for AMD xhci controller. commit 3c128781d8da463761495aaf8898c9ecb4e71528 upstream. One of AMD xhci controller require reset on resume. Occasionally AMD xhci controller does not respond to Stop endpoint command. Once the issue happens controller goes into bad state and in that case controller needs to be reset. Cc: Signed-off-by: Sandeep Singh Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20210512080816.866037-6-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit f137f0379893f0e7d899dc73a40af25732476d8e Author: Christophe JAILLET Date: Wed May 12 11:08:14 2021 +0300 xhci: Do not use GFP_KERNEL in (potentially) atomic context commit dda32c00c9a0fa103b5d54ef72c477b7aa993679 upstream. 'xhci_urb_enqueue()' is passed a 'mem_flags' argument, because "URBs may be submitted in interrupt context" (see comment related to 'usb_submit_urb()' in 'drivers/usb/core/urb.c') So this flag should be used in all the calling chain. Up to now, 'xhci_check_maxpacket()' which is only called from 'xhci_urb_enqueue()', uses GFP_KERNEL. Be safe and pass the mem_flags to this function as well. Fixes: ddba5cd0aeff ("xhci: Use command structures when queuing commands on the command ring") Cc: Signed-off-by: Christophe JAILLET Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20210512080816.866037-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 45157f15b2f7c3f4d43ce9d49aae452140858a8e Author: Mathias Nyman Date: Wed May 12 11:08:13 2021 +0300 xhci: Fix giving back cancelled URBs even if halted endpoint can't reset commit 9b6a126ae58d9edfdde2d5f2e87f7615ea5e0155 upstream. Commit 9ebf30007858 ("xhci: Fix halted endpoint at stop endpoint command completion") in 5.12 changes how cancelled URBs are given back. To cancel a URB xhci driver needs to stop the endpoint first. To clear a halted endpoint xhci driver needs to reset the endpoint. In rare cases when an endpoint halt (error) races with a endpoint stop we need to clear the reset before removing, and giving back the cancelled URB. The above change in 5.12 takes care of this, but it also relies on the reset endpoint completion handler to give back the cancelled URBs. There are cases when driver refuses to queue reset endpoint commands, for example when a link suddenly goes to an inactive error state. In this case the cancelled URB is never given back. Fix this by giving back the URB in the stop endpoint if queuing a reset endpoint command fails. Fixes: 9ebf30007858 ("xhci: Fix halted endpoint at stop endpoint command completion") CC: # 5.12 Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20210512080816.866037-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 39291053c49e86bedae23ca282acd5bf9b919ea6 Author: Abhijeet Rao Date: Wed May 12 11:08:12 2021 +0300 xhci-pci: Allow host runtime PM as default for Intel Alder Lake xHCI commit b813511135e8b84fa741afdfbab4937919100bef upstream. In the same way as Intel Tiger Lake TCSS (Type-C Subsystem) the Alder Lake TCSS xHCI needs to be runtime suspended whenever possible to allow the TCSS hardware block to enter D3cold and thus save energy. Cc: stable@vger.kernel.org Signed-off-by: Abhijeet Rao Signed-off-by: Nikunj A. Dadhania Signed-off-by: Azhar Shaikh Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20210512080816.866037-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit a46de12cc7548ea3afb6737127a6aa3d244ab0bb Author: Andy Shevchenko Date: Wed May 5 01:23:37 2021 +0300 usb: typec: ucsi: Put fwnode in any case during ->probe() commit b9a0866a5bdf6a4643a52872ada6be6184c6f4f2 upstream. device_for_each_child_node() bumps a reference counting of a returned variable. We have to balance it whenever we return to the caller. Fixes: c1b0bc2dabfa ("usb: typec: Add support for UCSI interface") Cc: Heikki Krogerus Reviewed-by: Heikki Krogerus Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210504222337.3151726-1-andy.shevchenko@gmail.com Cc: stable Signed-off-by: Greg Kroah-Hartman commit 5e9c6f58b01e6fdfbc740390c01f542a35c97e57 Author: Jack Pham Date: Mon May 3 00:46:11 2021 -0700 usb: typec: ucsi: Retrieve all the PDOs instead of just the first 4 commit 1f4642b72be79757f050924a9b9673b6a02034bc upstream. commit 4dbc6a4ef06d ("usb: typec: ucsi: save power data objects in PD mode") introduced retrieval of the PDOs when connected to a PD-capable source. But only the first 4 PDOs are received since that is the maximum number that can be fetched at a time given the MESSAGE_IN length limitation (16 bytes). However, as per the PD spec a connected source may advertise up to a maximum of 7 PDOs. If such a source is connected it's possible the PPM could have negotiated a power contract with one of the PDOs at index greater than 4, and would be reflected in the request data object's (RDO) object position field. This would result in an out-of-bounds access when the rdo_index() is used to index into the src_pdos array in ucsi_psy_get_voltage_now(). With the help of the UBSAN -fsanitize=array-bounds checker enabled this exact issue is revealed when connecting to a PD source adapter that advertise 5 PDOs and the PPM enters a contract having selected the 5th one. [ 151.545106][ T70] Unexpected kernel BRK exception at EL1 [ 151.545112][ T70] Internal error: BRK handler: f2005512 [#1] PREEMPT SMP ... [ 151.545499][ T70] pc : ucsi_psy_get_prop+0x208/0x20c [ 151.545507][ T70] lr : power_supply_show_property+0xc0/0x328 ... [ 151.545542][ T70] Call trace: [ 151.545544][ T70] ucsi_psy_get_prop+0x208/0x20c [ 151.545546][ T70] power_supply_uevent+0x1a4/0x2f0 [ 151.545550][ T70] dev_uevent+0x200/0x384 [ 151.545555][ T70] kobject_uevent_env+0x1d4/0x7e8 [ 151.545557][ T70] power_supply_changed_work+0x174/0x31c [ 151.545562][ T70] process_one_work+0x244/0x6f0 [ 151.545564][ T70] worker_thread+0x3e0/0xa64 We can resolve this by instead retrieving and storing up to the maximum of 7 PDOs in the con->src_pdos array. This would involve two calls to the GET_PDOS command. Fixes: 992a60ed0d5e ("usb: typec: ucsi: register with power_supply class") Fixes: 4dbc6a4ef06d ("usb: typec: ucsi: save power data objects in PD mode") Cc: stable@vger.kernel.org Reported-and-tested-by: Subbaraman Narayanamurthy Reviewed-by: Heikki Krogerus Signed-off-by: Jack Pham Link: https://lore.kernel.org/r/20210503074611.30973-1-jackp@codeaurora.org Signed-off-by: Greg Kroah-Hartman commit 99b4df1251d29dba657404de1d7e029abcac428a Author: Kyle Tso Date: Tue May 4 01:18:49 2021 +0800 usb: typec: tcpm: Fix wrong handling in GET_SINK_CAP commit 2e2b8d15adc2f6ab2d4aa0550e241b9742a436a0 upstream. After receiving Sink Capabilities Message in GET_SINK_CAP AMS, it is incorrect to call tcpm_pd_handle_state because the Message is expected and the current state is not Ready states. The result of this incorrect operation ends in Soft Reset which is definitely wrong. Simply forwarding to Ready States is enough to finish the AMS. Fixes: 8dea75e11380 ("usb: typec: tcpm: Protocol Error handling") Reviewed-by: Guenter Roeck Acked-by: Heikki Krogerus Signed-off-by: Kyle Tso Cc: stable Link: https://lore.kernel.org/r/20210503171849.2605302-1-kyletso@google.com Signed-off-by: Greg Kroah-Hartman commit 3a37f7581b7dcc52b7e36a3387255ff7861cd9ae Author: Wesley Cheng Date: Fri May 7 10:55:19 2021 -0700 usb: dwc3: gadget: Return success always for kick transfer in ep queue commit 18ffa988dbae69cc6e9949cddd9606f6fe533894 upstream. If an error is received when issuing a start or update transfer command, the error handler will stop all active requests (including the current USB request), and call dwc3_gadget_giveback() to notify function drivers of the requests which have been stopped. Avoid returning an error for kick transfer during EP queue, to remove duplicate cleanup operations on the request being queued. Fixes: 8d99087c2db8 ("usb: dwc3: gadget: Properly handle failed kick_transfer") cc: stable@vger.kernel.org Signed-off-by: Wesley Cheng Link: https://lore.kernel.org/r/1620410119-24971-1-git-send-email-wcheng@codeaurora.org Signed-off-by: Greg Kroah-Hartman commit c30863ab08e12ab8922957bec146f25cbdf94532 Author: Jack Pham Date: Wed Apr 28 02:01:10 2021 -0700 usb: dwc3: gadget: Enable suspend events commit d1d90dd27254c44d087ad3f8b5b3e4fff0571f45 upstream. commit 72704f876f50 ("dwc3: gadget: Implement the suspend entry event handler") introduced (nearly 5 years ago!) an interrupt handler for U3/L1-L2 suspend events. The problem is that these events aren't currently enabled in the DEVTEN register so the handler is never even invoked. Fix this simply by enabling the corresponding bit in dwc3_gadget_enable_irq() using the same revision check as found in the handler. Fixes: 72704f876f50 ("dwc3: gadget: Implement the suspend entry event handler") Acked-by: Felipe Balbi Signed-off-by: Jack Pham Cc: stable Link: https://lore.kernel.org/r/20210428090111.3370-1-jackp@codeaurora.org Signed-off-by: Greg Kroah-Hartman commit bd03dadb1a1fe675dac04e8e4a76527bee40bc46 Author: Zhen Lei Date: Sat May 8 09:53:10 2021 +0800 usb: dwc3: imx8mp: fix error return code in dwc3_imx8mp_probe() commit 0b2b149e918f6dddb4ea53615551bf7bc131f875 upstream. Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: 6dd2565989b4 ("usb: dwc3: add imx8mp dwc3 glue layer driver") Reported-by: Hulk Robot Acked-by: Felipe Balbi Signed-off-by: Zhen Lei Cc: stable Link: https://lore.kernel.org/r/20210508015310.1627-1-thunder.leizhen@huawei.com Signed-off-by: Greg Kroah-Hartman commit e41a3402d106a42a8da0457f404499632b81ee2d Author: Chunfeng Yun Date: Wed May 12 10:07:38 2021 +0800 usb: core: hub: fix race condition about TRSMRCY of resume commit 975f94c7d6c306b833628baa9aec3f79db1eb3a1 upstream. This may happen if the port becomes resume status exactly when usb_port_resume() gets port status, it still need provide a TRSMCRY time before access the device. CC: Reported-by: Tianping Fang Acked-by: Alan Stern Signed-off-by: Chunfeng Yun Link: https://lore.kernel.org/r/20210512020738.52961-1-chunfeng.yun@mediatek.com Signed-off-by: Greg Kroah-Hartman commit b2714ec7e6fd6ee67244c0985c5337aa2ae68149 Author: Phil Elwell Date: Thu May 6 12:22:00 2021 +0100 usb: dwc2: Fix gadget DMA unmap direction commit 75a41ce46bae6cbe7d3bb2584eb844291d642874 upstream. The dwc2 gadget support maps and unmaps DMA buffers as necessary. When mapping and unmapping it uses the direction of the endpoint to select the direction of the DMA transfer, but this fails for Control OUT transfers because the unmap occurs after the endpoint direction has been reversed for the status phase. A possible solution would be to unmap the buffer before the direction is changed, but a safer, less invasive fix is to remember the buffer direction independently of the endpoint direction. Fixes: fe0b94abcdf6 ("usb: dwc2: gadget: manage ep0 state in software") Acked-by: Minas Harutyunyan Cc: stable Signed-off-by: Phil Elwell Link: https://lore.kernel.org/r/20210506112200.2893922-1-phil@raspberrypi.com Signed-off-by: Greg Kroah-Hartman commit 1f418274cfc06937ff668f89193251926f73e843 Author: Maximilian Luz Date: Wed May 12 11:08:15 2021 +0300 usb: xhci: Increase timeout for HC halt commit ca09b1bea63ab83f4cca3a2ae8bc4f597ec28851 upstream. On some devices (specifically the SC8180x based Surface Pro X with QCOM04A6) HC halt / xhci_halt() times out during boot. Manually binding the xhci-hcd driver at some point later does not exhibit this behavior. To work around this, double XHCI_MAX_HALT_USEC, which also resolves this issue. Cc: Signed-off-by: Maximilian Luz Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20210512080816.866037-5-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 9e64fc974c169c224719e1a305e0cdee74ef904b Author: Ferry Toth Date: Sun Apr 25 17:09:47 2021 +0200 usb: dwc3: pci: Enable usb2-gadget-lpm-disable for Intel Merrifield commit 04357fafea9c7ed34525eb9680c760245c3bb958 upstream. On Intel Merrifield LPM is causing host to reset port after a timeout. By disabling LPM entirely this is prevented. Fixes: 066c09593454 ("usb: dwc3: pci: Enable extcon driver for Intel Merrifield") Reviewed-by: Andy Shevchenko Signed-off-by: Ferry Toth Cc: stable Link: https://lore.kernel.org/r/20210425150947.5862-1-ftoth@exalondelft.nl Signed-off-by: Greg Kroah-Hartman commit 9a053a48decc308ba588a838bd570b8601bba103 Author: Marcel Hamer Date: Tue Apr 27 14:21:18 2021 +0200 usb: dwc3: omap: improve extcon initialization commit e17b02d4970913233d543c79c9c66e72cac05bdd upstream. When extcon is used in combination with dwc3, it is assumed that the dwc3 registers are untouched and as such are only configured if VBUS is valid or ID is tied to ground. In case VBUS is not valid or ID is floating, the registers are not configured as such during driver initialization, causing a wrong default state during boot. If the registers are not in a default state, because they are for instance touched by a boot loader, this can cause for a kernel error. Signed-off-by: Marcel Hamer Link: https://lore.kernel.org/r/20210427122118.1948340-1-marcel@solidxs.se Cc: stable Signed-off-by: Greg Kroah-Hartman commit 5e9e6d114b536c654a7209c98a38f982a2de7009 Author: Bart Van Assche Date: Thu May 13 10:15:29 2021 -0700 blk-mq: Swap two calls in blk_mq_exit_queue() [ Upstream commit 630ef623ed26c18a457cdc070cf24014e50129c2 ] If a tag set is shared across request queues (e.g. SCSI LUNs) then the block layer core keeps track of the number of active request queues in tags->active_queues. blk_mq_tag_busy() and blk_mq_tag_idle() update that atomic counter if the hctx flag BLK_MQ_F_TAG_QUEUE_SHARED is set. Make sure that blk_mq_exit_queue() calls blk_mq_tag_idle() before that flag is cleared by blk_mq_del_queue_tag_set(). Cc: Christoph Hellwig Cc: Ming Lei Cc: Hannes Reinecke Fixes: 0d2602ca30e4 ("blk-mq: improve support for shared tags maps") Signed-off-by: Bart Van Assche Reviewed-by: Ming Lei Link: https://lore.kernel.org/r/20210513171529.7977-1-bvanassche@acm.org Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 0b3c8641cc4984403666d1803d8e06d18b638ced Author: Ming Lei Date: Fri May 14 10:20:52 2021 +0800 blk-mq: plug request for shared sbitmap [ Upstream commit 03f26d8f11403295de445b6e4e0e57ac57755791 ] In case of shared sbitmap, request won't be held in plug list any more sine commit 32bc15afed04 ("blk-mq: Facilitate a shared sbitmap per tagset"), this way makes request merge from flush plug list & batching submission not possible, so cause performance regression. Yanhui reports performance regression when running sequential IO test(libaio, 16 jobs, 8 depth for each job) in VM, and the VM disk is emulated with image stored on xfs/megaraid_sas. Fix the issue by recovering original behavior to allow to hold request in plug list. Cc: Yanhui Ma Cc: John Garry Cc: Bart Van Assche Cc: kashyap.desai@broadcom.com Fixes: 32bc15afed04 ("blk-mq: Facilitate a shared sbitmap per tagset") Signed-off-by: Ming Lei Link: https://lore.kernel.org/r/20210514022052.1047665-1-ming.lei@redhat.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit ba5dce1ef996562958f8d78dfea3296397f2bf29 Author: Nicholas Piggin Date: Mon May 3 21:17:08 2021 +1000 powerpc/64s: Make NMI record implicitly soft-masked code as irqs disabled [ Upstream commit 4ec5feec1ad029bdf7d49bc50ccc0c195eeabe93 ] scv support introduced the notion of code that implicitly soft-masks irqs due to the instruction addresses. This is required because scv enters the kernel with MSR[EE]=1. If a NMI (including soft-NMI) interrupt hits when we are implicitly soft-masked then its regs->softe does not reflect this because it is derived from the explicit soft mask state (paca->irq_soft_mask). This makes arch_irq_disabled_regs(regs) return false. This can trigger a warning in the soft-NMI watchdog code (shown below). Fix it by having NMI interrupts set regs->softe to disabled in case of interrupting an implicit soft-masked region. ------------[ cut here ]------------ WARNING: CPU: 41 PID: 1103 at arch/powerpc/kernel/watchdog.c:259 soft_nmi_interrupt+0x3e4/0x5f0 CPU: 41 PID: 1103 Comm: (spawn) Not tainted NIP: c000000000039534 LR: c000000000039234 CTR: c000000000009a00 REGS: c000007fffbcf940 TRAP: 0700 Not tainted MSR: 9000000000021033 CR: 22042482 XER: 200400ad CFAR: c000000000039260 IRQMASK: 3 GPR00: c000000000039204 c000007fffbcfbe0 c000000001d6c300 0000000000000003 GPR04: 00007ffffa45d078 0000000000000000 0000000000000008 0000000000000020 GPR08: 0000007ffd4e0000 0000000000000000 c000007ffffceb00 7265677368657265 GPR12: 9000000000009033 c000007ffffceb00 00000f7075bf4480 000000000000002a GPR16: 00000f705745a528 00007ffffa45ddd8 00000f70574d0008 0000000000000000 GPR20: 00000f7075c58d70 00000f7057459c38 0000000000000001 0000000000000040 GPR24: 0000000000000000 0000000000000029 c000000001dae058 0000000000000029 GPR28: 0000000000000000 0000000000000800 0000000000000009 c000007fffbcfd60 NIP [c000000000039534] soft_nmi_interrupt+0x3e4/0x5f0 LR [c000000000039234] soft_nmi_interrupt+0xe4/0x5f0 Call Trace: [c000007fffbcfbe0] [c000000000039204] soft_nmi_interrupt+0xb4/0x5f0 (unreliable) [c000007fffbcfcf0] [c00000000000c0e8] soft_nmi_common+0x138/0x1c4 --- interrupt: 900 at end_real_trampolines+0x0/0x1000 NIP: c000000000003000 LR: 00007ca426adb03c CTR: 900000000280f033 REGS: c000007fffbcfd60 TRAP: 0900 MSR: 9000000000009033 CR: 44042482 XER: 200400ad CFAR: 00007ca426946020 IRQMASK: 0 GPR00: 00000000000000ad 00007ffffa45d050 00007ca426b07f00 0000000000000035 GPR04: 00007ffffa45d078 0000000000000000 0000000000000008 0000000000000020 GPR08: 0000000000000000 0000000000100000 0000000010000000 00007ffffa45d110 GPR12: 0000000000000001 00007ca426d4e680 00000f7075bf4480 000000000000002a GPR16: 00000f705745a528 00007ffffa45ddd8 00000f70574d0008 0000000000000000 GPR20: 00000f7075c58d70 00000f7057459c38 0000000000000001 0000000000000040 GPR24: 0000000000000000 00000f7057473f68 0000000000000003 000000000000041b GPR28: 00007ffffa45d4c4 0000000000000035 0000000000000000 00000f7057473f68 NIP [c000000000003000] end_real_trampolines+0x0/0x1000 LR [00007ca426adb03c] 0x7ca426adb03c --- interrupt: 900 Instruction dump: 60000000 60000000 60420000 38600001 482b3ae5 60000000 e93f0138 a36d0008 7daa6b78 71290001 7f7907b4 4082fd34 <0fe00000> 4bfffd2c 60420000 ea6100a8 ---[ end trace dc75f67d819779da ]--- Fixes: 118178e62e2e ("powerpc: move NMI entry/exit code into wrapper") Reported-by: Cédric Le Goater Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210503111708.758261-1-npiggin@gmail.com Signed-off-by: Sasha Levin commit 54b78ba7e96e5fe1edb8054e375d31a6c0dc60dc Author: Sun Ke Date: Wed May 12 19:43:30 2021 +0800 nbd: Fix NULL pointer in flush_workqueue [ Upstream commit 79ebe9110fa458d58f1fceb078e2068d7ad37390 ] Open /dev/nbdX first, the config_refs will be 1 and the pointers in nbd_device are still null. Disconnect /dev/nbdX, then reference a null recv_workq. The protection by config_refs in nbd_genl_disconnect is useless. [ 656.366194] BUG: kernel NULL pointer dereference, address: 0000000000000020 [ 656.368943] #PF: supervisor write access in kernel mode [ 656.369844] #PF: error_code(0x0002) - not-present page [ 656.370717] PGD 10cc87067 P4D 10cc87067 PUD 1074b4067 PMD 0 [ 656.371693] Oops: 0002 [#1] SMP [ 656.372242] CPU: 5 PID: 7977 Comm: nbd-client Not tainted 5.11.0-rc5-00040-g76c057c84d28 #1 [ 656.373661] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ 656.375904] RIP: 0010:mutex_lock+0x29/0x60 [ 656.376627] Code: 00 0f 1f 44 00 00 55 48 89 fd 48 83 05 6f d7 fe 08 01 e8 7a c3 ff ff 48 83 05 6a d7 fe 08 01 31 c0 65 48 8b 14 25 00 6d 01 00 48 0f b1 55 d [ 656.378934] RSP: 0018:ffffc900005eb9b0 EFLAGS: 00010246 [ 656.379350] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 656.379915] RDX: ffff888104cf2600 RSI: ffffffffaae8f452 RDI: 0000000000000020 [ 656.380473] RBP: 0000000000000020 R08: 0000000000000000 R09: ffff88813bd6b318 [ 656.381039] R10: 00000000000000c7 R11: fefefefefefefeff R12: ffff888102710b40 [ 656.381599] R13: ffffc900005eb9e0 R14: ffffffffb2930680 R15: ffff88810770ef00 [ 656.382166] FS: 00007fdf117ebb40(0000) GS:ffff88813bd40000(0000) knlGS:0000000000000000 [ 656.382806] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 656.383261] CR2: 0000000000000020 CR3: 0000000100c84000 CR4: 00000000000006e0 [ 656.383819] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 656.384370] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 656.384927] Call Trace: [ 656.385111] flush_workqueue+0x92/0x6c0 [ 656.385395] nbd_disconnect_and_put+0x81/0xd0 [ 656.385716] nbd_genl_disconnect+0x125/0x2a0 [ 656.386034] genl_family_rcv_msg_doit.isra.0+0x102/0x1b0 [ 656.386422] genl_rcv_msg+0xfc/0x2b0 [ 656.386685] ? nbd_ioctl+0x490/0x490 [ 656.386954] ? genl_family_rcv_msg_doit.isra.0+0x1b0/0x1b0 [ 656.387354] netlink_rcv_skb+0x62/0x180 [ 656.387638] genl_rcv+0x34/0x60 [ 656.387874] netlink_unicast+0x26d/0x590 [ 656.388162] netlink_sendmsg+0x398/0x6c0 [ 656.388451] ? netlink_rcv_skb+0x180/0x180 [ 656.388750] ____sys_sendmsg+0x1da/0x320 [ 656.389038] ? ____sys_recvmsg+0x130/0x220 [ 656.389334] ___sys_sendmsg+0x8e/0xf0 [ 656.389605] ? ___sys_recvmsg+0xa2/0xf0 [ 656.389889] ? handle_mm_fault+0x1671/0x21d0 [ 656.390201] __sys_sendmsg+0x6d/0xe0 [ 656.390464] __x64_sys_sendmsg+0x23/0x30 [ 656.390751] do_syscall_64+0x45/0x70 [ 656.391017] entry_SYSCALL_64_after_hwframe+0x44/0xa9 To fix it, just add if (nbd->recv_workq) to nbd_disconnect_and_put(). Fixes: e9e006f5fcf2 ("nbd: fix max number of supported devs") Signed-off-by: Sun Ke Reviewed-by: Josef Bacik Link: https://lore.kernel.org/r/20210512114331.1233964-2-sunke32@huawei.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit ead8ea54ecc465da19c4605b2d33874216155351 Author: Gautham R. Shenoy Date: Tue May 11 20:46:09 2021 +0530 sched/fair: Fix clearing of has_idle_cores flag in select_idle_cpu() [ Upstream commit 02dbb7246c5bbbbe1607ebdc546ba5c454a664b1 ] In commit: 9fe1f127b913 ("sched/fair: Merge select_idle_core/cpu()") in select_idle_cpu(), we check if an idle core is present in the LLC of the target CPU via the flag "has_idle_cores". We look for the idle core in select_idle_cores(). If select_idle_cores() isn't able to find an idle core/CPU, we need to unset the has_idle_cores flag in the LLC of the target to prevent other CPUs from going down this route. However, the current code is unsetting it in the LLC of the current CPU instead of the target CPU. This patch fixes this issue. Fixes: 9fe1f127b913 ("sched/fair: Merge select_idle_core/cpu()") Signed-off-by: Gautham R. Shenoy Signed-off-by: Ingo Molnar Reviewed-by: Vincent Guittot Reviewed-by: Srikar Dronamraju Acked-by: Mel Gorman Link: https://lore.kernel.org/r/1620746169-13996-1-git-send-email-ego@linux.vnet.ibm.com Signed-off-by: Sasha Levin commit 376e35eca187e59d0a32c56edb1b7b51e077bce8 Author: Chao Yu Date: Mon May 10 17:30:32 2021 +0800 f2fs: compress: fix to assign cc.cluster_idx correctly [ Upstream commit 8bfbfb0ddd706b1ce2e89259ecc45f192c0ec2bf ] In f2fs_destroy_compress_ctx(), after f2fs_destroy_compress_ctx(), cc.cluster_idx will be cleared w/ NULL_CLUSTER, f2fs_cluster_blocks() may check wrong cluster metadata, fix it. Fixes: 4c8ff7095bef ("f2fs: support data compression") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 936158b15e2648253afb824d252c910c496d34b5 Author: Chao Yu Date: Mon May 10 17:30:31 2021 +0800 f2fs: compress: fix race condition of overwrite vs truncate [ Upstream commit a949dc5f2c5cfe0c910b664650f45371254c0744 ] pos_fsstress testcase complains a panic as belew: ------------[ cut here ]------------ kernel BUG at fs/f2fs/compress.c:1082! invalid opcode: 0000 [#1] SMP PTI CPU: 4 PID: 2753477 Comm: kworker/u16:2 Tainted: G OE 5.12.0-rc1-custom #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 Workqueue: writeback wb_workfn (flush-252:16) RIP: 0010:prepare_compress_overwrite+0x4c0/0x760 [f2fs] Call Trace: f2fs_prepare_compress_overwrite+0x5f/0x80 [f2fs] f2fs_write_cache_pages+0x468/0x8a0 [f2fs] f2fs_write_data_pages+0x2a4/0x2f0 [f2fs] do_writepages+0x38/0xc0 __writeback_single_inode+0x44/0x2a0 writeback_sb_inodes+0x223/0x4d0 __writeback_inodes_wb+0x56/0xf0 wb_writeback+0x1dd/0x290 wb_workfn+0x309/0x500 process_one_work+0x220/0x3c0 worker_thread+0x53/0x420 kthread+0x12f/0x150 ret_from_fork+0x22/0x30 The root cause is truncate() may race with overwrite as below, so that one reference count left in page can not guarantee the page attaching in mapping tree all the time, after truncation, later find_lock_page() may return NULL pointer. - prepare_compress_overwrite - f2fs_pagecache_get_page - unlock_page - f2fs_setattr - truncate_setsize - truncate_inode_page - delete_from_page_cache - find_lock_page Fix this by avoiding referencing updated page. Fixes: 4c8ff7095bef ("f2fs: support data compression") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 9739055a5d021d7cc7cc13877fe2da1d5dd7e0a3 Author: Chao Yu Date: Thu May 6 17:00:43 2021 +0800 f2fs: compress: fix to free compress page correctly [ Upstream commit a12cc5b423d4f36dc1a1ea3911e49cf9dff43898 ] In error path of f2fs_write_compressed_pages(), it needs to call f2fs_compress_free_page() to release temporary page. Fixes: 5e6bbde95982 ("f2fs: introduce mempool for {,de}compress intermediate page allocation") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 5bdb34466ad8370546dfa0497594fb1d6f2fed90 Author: Michal Kalderon Date: Thu May 6 10:08:19 2021 +0300 nvmet-rdma: Fix NULL deref when SEND is completed with error [ Upstream commit 8cc365f9559b86802afc0208389f5c8d46b4ad61 ] When running some traffic and taking down the link on peer, a retry counter exceeded error is received. This leads to nvmet_rdma_error_comp which tried accessing the cq_context to obtain the queue. The cq_context is no longer valid after the fix to use shared CQ mechanism and should be obtained similar to how it is obtained in other functions from the wc->qp. [ 905.786331] nvmet_rdma: SEND for CQE 0x00000000e3337f90 failed with status transport retry counter exceeded (12). [ 905.832048] BUG: unable to handle kernel NULL pointer dereference at 0000000000000048 [ 905.839919] PGD 0 P4D 0 [ 905.842464] Oops: 0000 1 SMP NOPTI [ 905.846144] CPU: 13 PID: 1557 Comm: kworker/13:1H Kdump: loaded Tainted: G OE --------- - - 4.18.0-304.el8.x86_64 #1 [ 905.872135] RIP: 0010:nvmet_rdma_error_comp+0x5/0x1b [nvmet_rdma] [ 905.878259] Code: 19 4f c0 e8 89 b3 a5 f6 e9 5b e0 ff ff 0f b7 75 14 4c 89 ea 48 c7 c7 08 1a 4f c0 e8 71 b3 a5 f6 e9 4b e0 ff ff 0f 1f 44 00 00 <48> 8b 47 48 48 85 c0 74 08 48 89 c7 e9 98 bf 49 00 e9 c3 e3 ff ff [ 905.897135] RSP: 0018:ffffab601c45fe28 EFLAGS: 00010246 [ 905.902387] RAX: 0000000000000065 RBX: ffff9e729ea2f800 RCX: 0000000000000000 [ 905.909558] RDX: 0000000000000000 RSI: ffff9e72df9567c8 RDI: 0000000000000000 [ 905.916731] RBP: ffff9e729ea2b400 R08: 000000000000074d R09: 0000000000000074 [ 905.923903] R10: 0000000000000000 R11: ffffab601c45fcc0 R12: 0000000000000010 [ 905.931074] R13: 0000000000000000 R14: 0000000000000010 R15: ffff9e729ea2f400 [ 905.938247] FS: 0000000000000000(0000) GS:ffff9e72df940000(0000) knlGS:0000000000000000 [ 905.938249] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 905.950067] nvmet_rdma: SEND for CQE 0x00000000c7356cca failed with status transport retry counter exceeded (12). [ 905.961855] CR2: 0000000000000048 CR3: 000000678d010004 CR4: 00000000007706e0 [ 905.961855] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 905.961856] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 905.961857] PKRU: 55555554 [ 906.010315] Call Trace: [ 906.012778] __ib_process_cq+0x89/0x170 [ib_core] [ 906.017509] ib_cq_poll_work+0x26/0x80 [ib_core] [ 906.022152] process_one_work+0x1a7/0x360 [ 906.026182] ? create_worker+0x1a0/0x1a0 [ 906.030123] worker_thread+0x30/0x390 [ 906.033802] ? create_worker+0x1a0/0x1a0 [ 906.037744] kthread+0x116/0x130 [ 906.040988] ? kthread_flush_work_fn+0x10/0x10 [ 906.045456] ret_from_fork+0x1f/0x40 Fixes: ca0f1a8055be2 ("nvmet-rdma: use new shared CQ mechanism") Signed-off-by: Shai Malin Signed-off-by: Michal Kalderon Reviewed-by: Sagi Grimberg Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 03fce793a991fa2f3a32b836d8b975249d6bfa37 Author: Chaitanya Kulkarni Date: Thu May 6 18:51:36 2021 -0700 nvmet: fix inline bio check for passthru [ Upstream commit ab96de5def854d8fc51280b6a20597e64b14ac31 ] When handling passthru commands, for inline bio allocation we only consider the transfer size. This works well when req->sg_cnt fits into the req->inline_bvec, but it will result in the early return from bio_add_hw_page() when req->sg_cnt > NVMET_MAX_INLINE_BVEC. Consider an I/O of size 32768 and first buffer is not aligned to the page boundary, then I/O is split in following manner :- [ 2206.256140] nvmet: sg->length 3440 sg->offset 656 [ 2206.256144] nvmet: sg->length 4096 sg->offset 0 [ 2206.256148] nvmet: sg->length 4096 sg->offset 0 [ 2206.256152] nvmet: sg->length 4096 sg->offset 0 [ 2206.256155] nvmet: sg->length 4096 sg->offset 0 [ 2206.256159] nvmet: sg->length 4096 sg->offset 0 [ 2206.256163] nvmet: sg->length 4096 sg->offset 0 [ 2206.256166] nvmet: sg->length 4096 sg->offset 0 [ 2206.256170] nvmet: sg->length 656 sg->offset 0 Now the req->transfer_size == NVMET_MAX_INLINE_DATA_LEN i.e. 32768, but the req->sg_cnt is (9) > NVMET_MAX_INLINE_BIOVEC which is (8). This will result in early return in the following code path :- nvmet_bdev_execute_rw() bio_add_pc_page() bio_add_hw_page() if (bio_full(bio, len)) return 0; Use previously introduced helper nvmet_use_inline_bvec() to consider req->sg_cnt when using inline bio. This only affects nvme-loop transport. Fixes: dab3902b19a0 ("nvmet: use inline bio for passthru fast path") Signed-off-by: Chaitanya Kulkarni Reviewed-by: Sagi Grimberg Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 3df867719031392c259999dc6f21e28a935200cb Author: Chaitanya Kulkarni Date: Thu May 6 18:51:35 2021 -0700 nvmet: fix inline bio check for bdev-ns [ Upstream commit 608a969046e6e0567d05a166be66c77d2dd8220b ] When handling rw commands, for inline bio case we only consider transfer size. This works well when req->sg_cnt fits into the req->inline_bvec, but it will result in the warning in __bio_add_page() when req->sg_cnt > NVMET_MAX_INLINE_BVEC. Consider an I/O size 32768 and first page is not aligned to the page boundary, then I/O is split in following manner :- [ 2206.256140] nvmet: sg->length 3440 sg->offset 656 [ 2206.256144] nvmet: sg->length 4096 sg->offset 0 [ 2206.256148] nvmet: sg->length 4096 sg->offset 0 [ 2206.256152] nvmet: sg->length 4096 sg->offset 0 [ 2206.256155] nvmet: sg->length 4096 sg->offset 0 [ 2206.256159] nvmet: sg->length 4096 sg->offset 0 [ 2206.256163] nvmet: sg->length 4096 sg->offset 0 [ 2206.256166] nvmet: sg->length 4096 sg->offset 0 [ 2206.256170] nvmet: sg->length 656 sg->offset 0 Now the req->transfer_size == NVMET_MAX_INLINE_DATA_LEN i.e. 32768, but the req->sg_cnt is (9) > NVMET_MAX_INLINE_BIOVEC which is (8). This will result in the following warning message :- nvmet_bdev_execute_rw() bio_add_page() __bio_add_page() WARN_ON_ONCE(bio_full(bio, len)); This scenario is very hard to reproduce on the nvme-loop transport only with rw commands issued with the passthru IOCTL interface from the host application and the data buffer is allocated with the malloc() and not the posix_memalign(). Fixes: 73383adfad24 ("nvmet: don't split large I/Os unconditionally") Signed-off-by: Chaitanya Kulkarni Reviewed-by: Sagi Grimberg Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 2ef3c76540c49167a0bc3d5f80d00fd1fc4586df Author: Omar Sandoval Date: Mon May 10 17:05:35 2021 -0700 kyber: fix out of bounds access when preempted [ Upstream commit efed9a3337e341bd0989161b97453b52567bc59d ] __blk_mq_sched_bio_merge() gets the ctx and hctx for the current CPU and passes the hctx to ->bio_merge(). kyber_bio_merge() then gets the ctx for the current CPU again and uses that to get the corresponding Kyber context in the passed hctx. However, the thread may be preempted between the two calls to blk_mq_get_ctx(), and the ctx returned the second time may no longer correspond to the passed hctx. This "works" accidentally most of the time, but it can cause us to read garbage if the second ctx came from an hctx with more ctx's than the first one (i.e., if ctx->index_hw[hctx->type] > hctx->nr_ctx). This manifested as this UBSAN array index out of bounds error reported by Jakub: UBSAN: array-index-out-of-bounds in ../kernel/locking/qspinlock.c:130:9 index 13106 is out of range for type 'long unsigned int [128]' Call Trace: dump_stack+0xa4/0xe5 ubsan_epilogue+0x5/0x40 __ubsan_handle_out_of_bounds.cold.13+0x2a/0x34 queued_spin_lock_slowpath+0x476/0x480 do_raw_spin_lock+0x1c2/0x1d0 kyber_bio_merge+0x112/0x180 blk_mq_submit_bio+0x1f5/0x1100 submit_bio_noacct+0x7b0/0x870 submit_bio+0xc2/0x3a0 btrfs_map_bio+0x4f0/0x9d0 btrfs_submit_data_bio+0x24e/0x310 submit_one_bio+0x7f/0xb0 submit_extent_page+0xc4/0x440 __extent_writepage_io+0x2b8/0x5e0 __extent_writepage+0x28d/0x6e0 extent_write_cache_pages+0x4d7/0x7a0 extent_writepages+0xa2/0x110 do_writepages+0x8f/0x180 __writeback_single_inode+0x99/0x7f0 writeback_sb_inodes+0x34e/0x790 __writeback_inodes_wb+0x9e/0x120 wb_writeback+0x4d2/0x660 wb_workfn+0x64d/0xa10 process_one_work+0x53a/0xa80 worker_thread+0x69/0x5b0 kthread+0x20b/0x240 ret_from_fork+0x1f/0x30 Only Kyber uses the hctx, so fix it by passing the request_queue to ->bio_merge() instead. BFQ and mq-deadline just use that, and Kyber can map the queues itself to avoid the mismatch. Fixes: a6088845c2bf ("block: kyber: make kyber more friendly with merging") Reported-by: Jakub Kicinski Signed-off-by: Omar Sandoval Link: https://lore.kernel.org/r/c7598605401a48d5cfeadebb678abd10af22b83f.1620691329.git.osandov@fb.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit a7e17a8d421ae23c920240625b4413c7b94d94a4 Author: Christophe JAILLET Date: Sat May 8 09:23:09 2021 +0200 ACPI: scan: Fix a memory leak in an error handling path [ Upstream commit 0c8bd174f0fc131bc9dfab35cd8784f59045da87 ] If 'acpi_device_set_name()' fails, we must free 'acpi_device_bus_id->bus_id' or there is a (potential) memory leak. Fixes: eb50aaf960e3 ("ACPI: scan: Use unique number for instance_no") Signed-off-by: Christophe JAILLET Reviewed-by: Andy Shevchenko Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 7225188aa169a17c9d9f1e773a2c9abb4eabd179 Author: Andy Shevchenko Date: Mon May 10 13:01:36 2021 +0300 hwmon: (ltc2992) Put fwnode in error case during ->probe() [ Upstream commit 8370e5b093080c03cf89f7ebf0bef6984545429e ] In each iteration fwnode_for_each_available_child_node() bumps a reference counting of a loop variable followed by dropping in on a next iteration, Since in error case the loop is broken, we have to drop a reference count by ourselves. Do it for port_fwnode in error case during ->probe(). Fixes: b0bd407e94b0 ("hwmon: (ltc2992) Add support") Cc: Alexandru Tachici Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210510100136.3303142-1-andy.shevchenko@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 8758cf98e944fe0005f170d4e4a0af84e45b6c0e Author: Christophe JAILLET Date: Tue May 4 22:26:29 2021 +0200 usb: musb: Fix an error message [ Upstream commit d9ff1096a840dddea3d5cfa2149ff7da9f499fb2 ] 'ret' is known to be 0 here. Initialize 'ret' with the expected error code before using it. Fixes: 0990366bab3c ("usb: musb: Add support for MediaTek musb controller") Signed-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/69f514dc7134e3c917cad208e73cc650cb9e2bd6.1620159879.git.christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 4d82702a923556c2f9675ec70a06991836bb1143 Author: Kyle Tso Date: Fri May 7 14:23:00 2021 +0800 usb: typec: tcpm: Fix wrong handling for Not_Supported in VDM AMS [ Upstream commit f1fbd950b59b67bc5c202216c8e1c6ca8c99a3b4 ] Not_Supported Message is acceptable in VDM AMS. Redirect the VDM state machine to VDM_STATE_DONE when receiving Not_Supported and finish the VDM AMS. Also, after the loop in vdm_state_machine_work, add more conditions of VDM states to clear the vdm_sm_running flag because those are all stopping states when leaving the loop. In addition, finish the VDM AMS if the port partner responds BUSY. Fixes: 8dea75e11380 ("usb: typec: tcpm: Protocol Error handling") Fixes: 8d3a0578ad1a ("usb: typec: tcpm: Respond Wait if VDM state machine is running") Reviewed-by: Guenter Roeck Signed-off-by: Kyle Tso Link: https://lore.kernel.org/r/20210507062300.1945009-3-kyletso@google.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit b2a817c6698046526f68cdd2a4f91e92cc093830 Author: Eddie James Date: Thu Apr 29 10:13:36 2021 -0500 hwmon: (occ) Fix poll rate limiting [ Upstream commit 5216dff22dc2bbbbe6f00335f9fd2879670e753b ] The poll rate limiter time was initialized at zero. This breaks the comparison in time_after if jiffies is large. Switch to storing the next update time rather than the previous time, and initialize the time when the device is probed. Fixes: c10e753d43eb ("hwmon (occ): Add sensor types and versions") Signed-off-by: Eddie James Link: https://lore.kernel.org/r/20210429151336.18980-1-eajames@linux.ibm.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit c4f5af40c9ceb3c14cac8043f42310ad37fa5ae9 Author: Christophe JAILLET Date: Thu May 6 22:39:10 2021 +0200 usb: fotg210-hcd: Fix an error message [ Upstream commit a60a34366e0d09ca002c966dd7c43a68c28b1f82 ] 'retval' is known to be -ENODEV here. This is a hard-coded default error code which is not useful in the error message. Moreover, another error message is printed at the end of the error handling path. The corresponding error code (-ENOMEM) is more informative. So remove simplify the first error message. While at it, also remove the useless initialization of 'retval'. Fixes: 7d50195f6c50 ("usb: host: Faraday fotg210-hcd driver") Signed-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/94531bcff98e46d4f9c20183a90b7f47f699126c.1620333419.git.christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit f66cf2c9e4c732bc390528cf81bf18e458c7d795 Author: Alexandru Ardelean Date: Mon May 3 17:43:50 2021 +0300 iio: core: return ENODEV if ioctl is unknown [ Upstream commit af0670b0bf1b116fd729b1b1011cf814bc34e12e ] When the ioctl() mechanism was introduced in IIO core to centralize the registration of all ioctls in one place via commit 8dedcc3eee3ac ("iio: core: centralize ioctl() calls to the main chardev"), the return code was changed from ENODEV to EINVAL, when the ioctl code isn't known. This was done by accident. This change reverts back to the old behavior, where if the ioctl() code isn't known, ENODEV is returned (vs EINVAL). This was brought into perspective by this patch: https://lore.kernel.org/linux-iio/20210428150815.136150-1-paul@crapouillou.net/ Fixes: 8dedcc3eee3ac ("iio: core: centralize ioctl() calls to the main chardev") Signed-off-by: Alexandru Ardelean Reviewed-by: Nuno Sá Tested-by: Paul Cercueil Reviewed-by: Linus Walleij Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit faf84061548a5f3448588b27ec026908c35c2905 Author: Alexandru Ardelean Date: Wed Apr 14 11:49:55 2021 +0300 iio: hid-sensors: select IIO_TRIGGERED_BUFFER under HID_SENSOR_IIO_TRIGGER [ Upstream commit 7061803522ee7876df1ca18cdd1e1551f761352d ] During commit 067fda1c065ff ("iio: hid-sensors: move triggered buffer setup into hid_sensor_setup_trigger"), the iio_triggered_buffer_{setup,cleanup}() functions got moved under the hid-sensor-trigger module. The above change works fine, if any of the sensors get built. However, when only the common hid-sensor-trigger module gets built (and none of the drivers), then the IIO_TRIGGERED_BUFFER symbol isn't selected/enforced. Previously, each driver would enforce/select the IIO_TRIGGERED_BUFFER symbol. With this change the HID_SENSOR_IIO_TRIGGER (for the hid-sensor-trigger module) will enforce that IIO_TRIGGERED_BUFFER gets selected. All HID sensor drivers select the HID_SENSOR_IIO_TRIGGER symbol. So, this change removes the IIO_TRIGGERED_BUFFER enforcement from each driver. Fixes: 067fda1c065ff ("iio: hid-sensors: move triggered buffer setup into hid_sensor_setup_trigger") Reported-by: Thomas Deutschmann Cc: Srinivas Pandruvada Signed-off-by: Alexandru Ardelean Acked-by: Srinivas Pandruvada Link: https://lore.kernel.org/r/20210414084955.260117-1-aardelean@deviqon.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 37b2153a79be949c1dddc8f326d61d3b5069c586 Author: Dinghao Liu Date: Mon Apr 12 13:32:02 2021 +0800 iio: proximity: pulsedlight: Fix rumtime PM imbalance on error [ Upstream commit a2fa9242e89f27696515699fe0f0296bf1ac1815 ] When lidar_write_control() fails, a pairing PM usage counter decrement is needed to keep the counter balanced. Fixes: 4ac4e086fd8c5 ("iio: pulsedlight-lidar-lite: add runtime PM") Signed-off-by: Dinghao Liu Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210412053204.4889-1-dinghao.liu@zju.edu.cn Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit e317435d3efa81306e4b7fc3f741595d36cbf67d Author: Dinghao Liu Date: Wed Apr 7 11:49:27 2021 +0800 iio: light: gp2ap002: Fix rumtime PM imbalance on error [ Upstream commit 8edb79af88efc6e49e735f9baf61d9f0748b881f ] When devm_request_threaded_irq() fails, we should decrease the runtime PM counter to keep the counter balanced. But when iio_device_register() fails, we need not to decrease it because we have already decreased it before. Signed-off-by: Dinghao Liu Reviewed-by: Linus Walleij Fixes: 97d642e23037 ("iio: light: Add a driver for Sharp GP2AP002x00F") Link: https://lore.kernel.org/r/20210407034927.16882-1-dinghao.liu@zju.edu.cn Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit b4b8e9601d7ee8806d2687f081a42485d27674a1 Author: Jack Pham Date: Sat May 1 02:35:58 2021 -0700 usb: dwc3: gadget: Free gadget structure only after freeing endpoints [ Upstream commit bb9c74a5bd1462499fe5ccb1e3c5ac40dcfa9139 ] As part of commit e81a7018d93a ("usb: dwc3: allocate gadget structure dynamically") the dwc3_gadget_release() was added which will free the dwc->gadget structure upon the device's removal when usb_del_gadget_udc() is called in dwc3_gadget_exit(). However, simply freeing the gadget results a dangling pointer situation: the endpoints created in dwc3_gadget_init_endpoints() have their dep->endpoint.ep_list members chained off the list_head anchored at dwc->gadget->ep_list. Thus when dwc->gadget is freed, the first dwc3_ep in the list now has a dangling prev pointer and likewise for the next pointer of the dwc3_ep at the tail of the list. The dwc3_gadget_free_endpoints() that follows will result in a use-after-free when it calls list_del(). This was caught by enabling KASAN and performing a driver unbind. The recent commit 568262bf5492 ("usb: dwc3: core: Add shutdown callback for dwc3") also exposes this as a panic during shutdown. There are a few possibilities to fix this. One could be to perform a list_del() of the gadget->ep_list itself which removes it from the rest of the dwc3_ep chain. Another approach is what this patch does, by splitting up the usb_del_gadget_udc() call into its separate "del" and "put" components. This allows dwc3_gadget_free_endpoints() to be called before the gadget is finally freed with usb_put_gadget(). Fixes: e81a7018d93a ("usb: dwc3: allocate gadget structure dynamically") Reviewed-by: Peter Chen Signed-off-by: Jack Pham Link: https://lore.kernel.org/r/20210501093558.7375-1-jackp@codeaurora.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 7bc747f429176d90644f55699fbc27df482fdafe Author: Jiri Olsa Date: Sat May 8 22:50:20 2021 +0200 perf tools: Fix dynamic libbpf link [ Upstream commit ad1237c30d975535a669746496cbed136aa5a045 ] Justin reported broken build with LIBBPF_DYNAMIC=1. When linking libbpf dynamically we need to use perf's hashmap object, because it's not exported in libbpf.so (only in libbpf.a). Following build is now passing: $ make LIBBPF_DYNAMIC=1 BUILD: Doing 'make -j8' parallel build ... $ ldd perf | grep libbpf libbpf.so.0 => /lib64/libbpf.so.0 (0x00007fa7630db000) Fixes: eee19501926d ("perf tools: Grab a copy of libbpf's hashmap") Reported-by: Justin M. Forbes Signed-off-by: Jiri Olsa Cc: Alexander Shishkin Cc: Ian Rogers Cc: Mark Rutland Cc: Michael Petlan Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lore.kernel.org/lkml/20210508205020.617984-1-jolsa@kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 0accab4d2e7a3be968e45281a45ba166c2492440 Author: Zhen Lei Date: Sat May 8 10:19:13 2021 +0800 xen/unpopulated-alloc: fix error return code in fill_list() [ Upstream commit dbc03e81586fc33e4945263fd6e09e22eb4b980f ] Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: a4574f63edc6 ("mm/memremap_pages: convert to 'struct range'") Reported-by: Hulk Robot Signed-off-by: Zhen Lei Reviewed-by: Juergen Gross Link: https://lore.kernel.org/r/20210508021913.1727-1-thunder.leizhen@huawei.com Signed-off-by: Juergen Gross Signed-off-by: Sasha Levin commit db822599b21e01bd0dba4f893a6291921058a9cf Author: Vivek Goyal Date: Wed Apr 28 15:03:14 2021 -0400 dax: Wake up all waiters after invalidating dax entry [ Upstream commit 237388320deffde7c2d65ed8fc9eef670dc979b3 ] I am seeing missed wakeups which ultimately lead to a deadlock when I am using virtiofs with DAX enabled and running "make -j". I had to mount virtiofs as rootfs and also reduce to dax window size to 256M to reproduce the problem consistently. So here is the problem. put_unlocked_entry() wakes up waiters only if entry is not null as well as !dax_is_conflict(entry). But if I call multiple instances of invalidate_inode_pages2() in parallel, then I can run into a situation where there are waiters on this index but nobody will wake these waiters. invalidate_inode_pages2() invalidate_inode_pages2_range() invalidate_exceptional_entry2() dax_invalidate_mapping_entry_sync() __dax_invalidate_entry() { xas_lock_irq(&xas); entry = get_unlocked_entry(&xas, 0); ... ... dax_disassociate_entry(entry, mapping, trunc); xas_store(&xas, NULL); ... ... put_unlocked_entry(&xas, entry); xas_unlock_irq(&xas); } Say a fault in in progress and it has locked entry at offset say "0x1c". Now say three instances of invalidate_inode_pages2() are in progress (A, B, C) and they all try to invalidate entry at offset "0x1c". Given dax entry is locked, all tree instances A, B, C will wait in wait queue. When dax fault finishes, say A is woken up. It will store NULL entry at index "0x1c" and wake up B. When B comes along it will find "entry=0" at page offset 0x1c and it will call put_unlocked_entry(&xas, 0). And this means put_unlocked_entry() will not wake up next waiter, given the current code. And that means C continues to wait and is not woken up. This patch fixes the issue by waking up all waiters when a dax entry has been invalidated. This seems to fix the deadlock I am facing and I can make forward progress. Reported-by: Sergio Lopez Fixes: ac401cc78242 ("dax: New fault locking") Reviewed-by: Jan Kara Suggested-by: Dan Williams Signed-off-by: Vivek Goyal Link: https://lore.kernel.org/r/20210428190314.1865312-4-vgoyal@redhat.com Signed-off-by: Dan Williams Signed-off-by: Sasha Levin commit fa38341f78132d974acc7db6a0fed4d111c1cf53 Author: Vivek Goyal Date: Wed Apr 28 15:03:13 2021 -0400 dax: Add a wakeup mode parameter to put_unlocked_entry() [ Upstream commit 4c3d043d271d4d629aa2328796cdfc96b37d3b3c ] As of now put_unlocked_entry() always wakes up next waiter. In next patches we want to wake up all waiters at one callsite. Hence, add a parameter to the function. This patch does not introduce any change of behavior. Reviewed-by: Greg Kurz Reviewed-by: Jan Kara Suggested-by: Dan Williams Signed-off-by: Vivek Goyal Link: https://lore.kernel.org/r/20210428190314.1865312-3-vgoyal@redhat.com Signed-off-by: Dan Williams Signed-off-by: Sasha Levin commit 27514d7b526ad3857e2b2ba17726ef8693ddcf4a Author: Vivek Goyal Date: Wed Apr 28 15:03:12 2021 -0400 dax: Add an enum for specifying dax wakup mode [ Upstream commit 698ab77aebffe08b312fbcdddeb0e8bd08b78717 ] Dan mentioned that he is not very fond of passing around a boolean true/false to specify if only next waiter should be woken up or all waiters should be woken up. He instead prefers that we introduce an enum and make it very explicity at the callsite itself. Easier to read code. This patch should not introduce any change of behavior. Reviewed-by: Greg Kurz Reviewed-by: Jan Kara Suggested-by: Dan Williams Signed-off-by: Vivek Goyal Link: https://lore.kernel.org/r/20210428190314.1865312-2-vgoyal@redhat.com Signed-off-by: Dan Williams Signed-off-by: Sasha Levin commit bfe31390c04861ef0adfd86c04e05c61c6a0a047 Author: Tom Lendacky Date: Thu May 6 15:14:41 2021 -0500 KVM: SVM: Move GHCB unmapping to fix RCU warning [ Upstream commit ce7ea0cfdc2e9ff31d12da31c3226deddb9644f5 ] When an SEV-ES guest is running, the GHCB is unmapped as part of the vCPU run support. However, kvm_vcpu_unmap() triggers an RCU dereference warning with CONFIG_PROVE_LOCKING=y because the SRCU lock is released before invoking the vCPU run support. Move the GHCB unmapping into the prepare_guest_switch callback, which is invoked while still holding the SRCU lock, eliminating the RCU dereference warning. Fixes: 291bd20d5d88 ("KVM: SVM: Add initial support for a VMGEXIT VMEXIT") Reported-by: Borislav Petkov Signed-off-by: Tom Lendacky Message-Id: Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 80fae432eb8d3a3455d74190cf054c516809cac1 Author: Thomas Gleixner Date: Thu May 6 15:21:37 2021 +0200 KVM: x86: Prevent deadlock against tk_core.seq [ Upstream commit 3f804f6d201ca93adf4c3df04d1bfd152c1129d6 ] syzbot reported a possible deadlock in pvclock_gtod_notify(): CPU 0 CPU 1 write_seqcount_begin(&tk_core.seq); pvclock_gtod_notify() spin_lock(&pool->lock); queue_work(..., &pvclock_gtod_work) ktime_get() spin_lock(&pool->lock); do { seq = read_seqcount_begin(tk_core.seq) ... } while (read_seqcount_retry(&tk_core.seq, seq); While this is unlikely to happen, it's possible. Delegate queue_work() to irq_work() which postpones it until the tk_core.seq write held region is left and interrupts are reenabled. Fixes: 16e8d74d2da9 ("KVM: x86: notifier for clocksource changes") Reported-by: syzbot+6beae4000559d41d80f8@syzkaller.appspotmail.com Signed-off-by: Thomas Gleixner Message-Id: <87h7jgm1zy.ffs@nanos.tec.linutronix.de> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 171895f5b596780f125601469e12d8f61cd7af49 Author: Thomas Gleixner Date: Wed May 5 23:48:17 2021 +0200 KVM: x86: Cancel pvclock_gtod_work on module removal [ Upstream commit 594b27e677b35f9734b1969d175ebc6146741109 ] Nothing prevents the following: pvclock_gtod_notify() queue_work(system_long_wq, &pvclock_gtod_work); ... remove_module(kvm); ... work_queue_run() pvclock_gtod_work() <- UAF Ditto for any other operation on that workqueue list head which touches pvclock_gtod_work after module removal. Cancel the work in kvm_arch_exit() to prevent that. Fixes: 16e8d74d2da9 ("KVM: x86: notifier for clocksource changes") Signed-off-by: Thomas Gleixner Message-Id: <87czu4onry.ffs@nanos.tec.linutronix.de> Cc: stable@vger.kernel.org Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 41d92e63158a78a59ed6b63b675551a0576e4b06 Author: Kuogee Hsieh Date: Wed Apr 21 16:37:36 2021 -0700 drm/msm/dp: initialize audio_comp when audio starts [ Upstream commit f2f46b878777e0d3f885c7ddad48f477b4dea247 ] Initialize audio_comp when audio starts and wait for audio_comp at dp_display_disable(). This will take care of both dongle unplugged and display off (suspend) cases. Changes in v2: -- add dp_display_signal_audio_start() Changes in v3: -- restore dp_display_handle_plugged_change() at dp_hpd_unplug_handle(). Changes in v4: -- none Signed-off-by: Kuogee Hsieh Reviewed-by: Stephen Boyd Tested-by: Stephen Boyd Fixes: c703d5789590 ("drm/msm/dp: trigger unplug event in msm_dp_display_disable") Link: https://lore.kernel.org/r/1619048258-8717-3-git-send-email-khsieh@codeaurora.org Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 081f7f9349704f7a16da94a5944cff9026c98223 Author: Wanpeng Li Date: Wed Apr 28 19:08:02 2021 +0800 KVM: LAPIC: Accurately guarantee busy wait for timer to expire when using hv_timer [ Upstream commit d981dd15498b188636ec5a7d8ad485e650f63d8d ] Commit ee66e453db13d (KVM: lapic: Busy wait for timer to expire when using hv_timer) tries to set ktime->expired_tscdeadline by checking ktime->hv_timer_in_use since lapic timer oneshot/periodic modes which are emulated by vmx preemption timer also get advanced, they leverage the same vmx preemption timer logic with tsc-deadline mode. However, ktime->hv_timer_in_use is cleared before apic_timer_expired() handling, let's delay this clearing in preemption-disabled region. Fixes: ee66e453db13d ("KVM: lapic: Busy wait for timer to expire when using hv_timer") Reviewed-by: Sean Christopherson Signed-off-by: Wanpeng Li Message-Id: <1619608082-4187-1-git-send-email-wanpengli@tencent.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit ac7055e5636750da0d896b9aecbe0df110431849 Author: Jonathan Marek Date: Fri Apr 23 21:49:26 2021 -0400 drm/msm: fix LLC not being enabled for mmu500 targets [ Upstream commit 4b95d371fb001185af84d177e69a23d55bd0167a ] mmu500 targets don't have a "cx_mem" region, set llc_mmio to NULL in that case to avoid the IS_ERR() condition in a6xx_llc_activate(). Fixes: 3d247123b5a1 ("drm/msm/a6xx: Add support for using system cache on MMU500 based targets") Signed-off-by: Jonathan Marek Link: https://lore.kernel.org/r/20210424014927.1661-1-jonathan@marek.ca Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 0b4d0ae9ffd841593020290697d5c9acfda4600d Author: Benjamin Segall Date: Thu Apr 29 16:22:34 2021 +0000 kvm: exit halt polling on need_resched() as well commit 262de4102c7bb8e59f26a967a8ffe8cce85cc537 upstream. single_task_running() is usually more general than need_resched() but CFS_BANDWIDTH throttling will use resched_task() when there is just one task to get the task to block. This was causing long-need_resched warnings and was likely allowing VMs to overrun their quota when halt polling. Signed-off-by: Ben Segall Signed-off-by: Venkatesh Srinivas Message-Id: <20210429162233.116849-1-venkateshs@chromium.org> Signed-off-by: Paolo Bonzini Cc: stable@vger.kernel.org Reviewed-by: Jim Mattson Signed-off-by: Greg Kroah-Hartman commit 266a9da628ae5ec6db17cd179d9b1859c83a87ba Author: Kai-Heng Feng Date: Wed Apr 21 13:20:31 2021 +0800 drm/i915/dp: Use slow and wide link training for everything commit a5c936add6a23c15c6ae538ab7a12f80751fdf0f upstream. Screen flickers on Innolux eDP 1.3 panel when clock rate 540000 is in use. According to the panel vendor, though clock rate 540000 is advertised, but the max clock rate it really supports is 270000. Ville Syrjälä mentioned that fast and narrow also breaks some eDP 1.4 panel, so use slow and wide training for all panels to resolve the issue. User also confirmed that the new strategy doesn't introduce any regression on XPS 9380. v2: - Use slow and wide for everything. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3384 References: https://gitlab.freedesktop.org/drm/intel/-/issues/272 Signed-off-by: Kai-Heng Feng Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20210421052054.1434718-1-kai.heng.feng@canonical.com (cherry picked from commit acca7762eb71bc05a8f28d29320d193150051f79) Fixes: 2bbd6dba84d4 ("drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure") Cc: # v5.12+ Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit afef1a33dd5ace853c085a01703c4a46f32eb270 Author: Ville Syrjälä Date: Wed Apr 21 18:33:58 2021 +0300 drm/i915: Avoid div-by-zero on gen2 commit 4819d16d91145966ce03818a95169df1fd56b299 upstream. Gen2 tiles are 2KiB in size so i915_gem_object_get_tile_row_size() can in fact return <4KiB, which leads to div-by-zero here. Avoid that. Not sure i915_gem_object_get_tile_row_size() is entirely sane anyway since it doesn't account for the different tile layouts on i8xx/i915... I'm not able to hit this before commit 6846895fde05 ("drm/i915: Replace PIN_NONFAULT with calls to PIN_NOEVICT") and it looks like I also need to run recent version of Mesa. With those in place xonotic trips on this quite easily on my 85x. Cc: stable@vger.kernel.org Reviewed-by: Chris Wilson Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20210421153401.13847-2-ville.syrjala@linux.intel.com (cherry picked from commit ed52c62d386f764194e0184fdb905d5f24194cae) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 013950b55e53da84277934aa55167f8f1ac7d49f Author: David Ward Date: Mon May 10 05:30:39 2021 -0400 drm/amd/display: Initialize attribute for hdcp_srm sysfs file commit fe1c97d008f86f672f0e9265f180c22451ca3b9f upstream. It is stored in dynamically allocated memory, so sysfs_bin_attr_init() must be called to initialize it. (Note: "initialization" only sets the .attr.key member in this struct; it does not change the value of any other members.) Otherwise, when CONFIG_DEBUG_LOCK_ALLOC=y this message appears during boot: BUG: key ffff9248900cd148 has not been registered! Fixes: 9037246bb2da ("drm/amd/display: Add sysfs interface for set/get srm") Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1586 Reported-by: Mikhail Gavrilov Signed-off-by: David Ward Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 15372dd6de6d1d5e399809e87e4c31aef8110c7d Author: Kai-Heng Feng Date: Fri Apr 30 12:56:56 2021 +0800 drm/radeon/dpm: Disable sclk switching on Oland when two 4K 60Hz monitors are connected commit 227545b9a08c68778ddd89428f99c351fc9315ac upstream. Screen flickers rapidly when two 4K 60Hz monitors are in use. This issue doesn't happen when one monitor is 4K 60Hz (pixelclock 594MHz) and another one is 4K 30Hz (pixelclock 297MHz). The issue is gone after setting "power_dpm_force_performance_level" to "high". Following the indication, we found that the issue occurs when sclk is too low. So resolve the issue by disabling sclk switching when there are two monitors requires high pixelclock (> 297MHz). v2: - Only apply the fix to Oland. Signed-off-by: Kai-Heng Feng Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 78536c791ff8b197b43540bb17d34eef1018ae16 Author: Naohiro Aota Date: Fri Apr 30 15:34:17 2021 +0200 btrfs: zoned: sanity check zone type commit 784daf2b9628f2d0117f1f0b578cfe5ab6634919 upstream. The fstests test case generic/475 creates a dm-linear device that gets changed to a dm-error device. This leads to errors in loading the block group's zone information when running on a zoned file system, ultimately resulting in a list corruption. When running on a kernel with list debugging enabled this leads to the following crash. BTRFS: error (device dm-2) in cleanup_transaction:1953: errno=-5 IO failure kernel BUG at lib/list_debug.c:54! invalid opcode: 0000 [#1] SMP PTI CPU: 1 PID: 2433 Comm: umount Tainted: G W 5.12.0+ #1018 RIP: 0010:__list_del_entry_valid.cold+0x1d/0x47 RSP: 0018:ffffc90001473df0 EFLAGS: 00010296 RAX: 0000000000000054 RBX: ffff8881038fd000 RCX: ffffc90001473c90 RDX: 0000000100001a31 RSI: 0000000000000003 RDI: 0000000000000003 RBP: ffff888308871108 R08: 0000000000000003 R09: 0000000000000001 R10: 3961373532383838 R11: 6666666620736177 R12: ffff888308871000 R13: ffff8881038fd088 R14: ffff8881038fdc78 R15: dead000000000100 FS: 00007f353c9b1540(0000) GS:ffff888627d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f353cc2c710 CR3: 000000018e13c000 CR4: 00000000000006a0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: btrfs_free_block_groups+0xc9/0x310 [btrfs] close_ctree+0x2ee/0x31a [btrfs] ? call_rcu+0x8f/0x270 ? mutex_lock+0x1c/0x40 generic_shutdown_super+0x67/0x100 kill_anon_super+0x14/0x30 btrfs_kill_super+0x12/0x20 [btrfs] deactivate_locked_super+0x31/0x90 cleanup_mnt+0x13e/0x1b0 task_work_run+0x63/0xb0 exit_to_user_mode_loop+0xd9/0xe0 exit_to_user_mode_prepare+0x3e/0x60 syscall_exit_to_user_mode+0x1d/0x50 entry_SYSCALL_64_after_hwframe+0x44/0xae As dm-error has no support for zones, btrfs will run it's zone emulation mode on this device. The zone emulation mode emulates conventional zones, so bail out if the zone bitmap that gets populated on mount sees the zone as sequential while we're thinking it's a conventional zone when creating a block group. Note: this scenario is unlikely in a real wold application and can only happen by this (ab)use of device-mapper targets. CC: stable@vger.kernel.org # 5.12+ Signed-off-by: Naohiro Aota Signed-off-by: Johannes Thumshirn Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit c6b9a5a8204429a9416b5fb79ce9b632817b93f3 Author: Tom Rix Date: Fri Apr 30 11:06:55 2021 -0700 btrfs: initialize return variable in cleanup_free_space_cache_v1 commit 77364faf21b4105ee5adbb4844fdfb461334d249 upstream. Static analysis reports this problem free-space-cache.c:3965:2: warning: Undefined or garbage value returned return ret; ^~~~~~~~~~ ret is set in the node handling loop. Treat doing nothing as a success and initialize ret to 0, although it's unlikely the loop would be skipped. We always have block groups, but as it could lead to transaction abort in the caller it's better to be safe. CC: stable@vger.kernel.org # 5.12+ Signed-off-by: Tom Rix Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 70264829d969ed355bcab07283e6996f9236cebc Author: Filipe Manana Date: Tue Apr 27 11:27:20 2021 +0100 btrfs: fix race leading to unpersisted data and metadata on fsync commit 626e9f41f7c281ba3e02843702f68471706aa6d9 upstream. When doing a fast fsync on a file, there is a race which can result in the fsync returning success to user space without logging the inode and without durably persisting new data. The following example shows one possible scenario for this: $ mkfs.btrfs -f /dev/sdc $ mount /dev/sdc /mnt $ touch /mnt/bar $ xfs_io -f -c "pwrite -S 0xab 0 1M" -c "fsync" /mnt/baz # Now we have: # file bar == inode 257 # file baz == inode 258 $ mv /mnt/baz /mnt/foo # Now we have: # file bar == inode 257 # file foo == inode 258 $ xfs_io -c "pwrite -S 0xcd 0 1M" /mnt/foo # fsync bar before foo, it is important to trigger the race. $ xfs_io -c "fsync" /mnt/bar $ xfs_io -c "fsync" /mnt/foo # After this: # inode 257, file bar, is empty # inode 258, file foo, has 1M filled with 0xcd # Replay the log: $ mount /dev/sdc /mnt # After this point file foo should have 1M filled with 0xcd and not 0xab The following steps explain how the race happens: 1) Before the first fsync of inode 258, when it has the "baz" name, its ->logged_trans is 0, ->last_sub_trans is 0 and ->last_log_commit is -1. The inode also has the full sync flag set; 2) After the first fsync, we set inode 258 ->logged_trans to 6, which is the generation of the current transaction, and set ->last_log_commit to 0, which is the current value of ->last_sub_trans (done at btrfs_log_inode()). The full sync flag is cleared from the inode during the fsync. The log sub transaction that was committed had an ID of 0 and when we synced the log, at btrfs_sync_log(), we incremented root->log_transid from 0 to 1; 3) During the rename: We update inode 258, through btrfs_update_inode(), and that causes its ->last_sub_trans to be set to 1 (the current log transaction ID), and ->last_log_commit remains with a value of 0. After updating inode 258, because we have previously logged the inode in the previous fsync, we log again the inode through the call to btrfs_log_new_name(). This results in updating the inode's ->last_log_commit from 0 to 1 (the current value of its ->last_sub_trans). The ->last_sub_trans of inode 257 is updated to 1, which is the ID of the next log transaction; 4) Then a buffered write against inode 258 is made. This leaves the value of ->last_sub_trans as 1 (the ID of the current log transaction, stored at root->log_transid); 5) Then an fsync against inode 257 (or any other inode other than 258), happens. This results in committing the log transaction with ID 1, which results in updating root->last_log_commit to 1 and bumping root->log_transid from 1 to 2; 6) Then an fsync against inode 258 starts. We flush delalloc and wait only for writeback to complete, since the full sync flag is not set in the inode's runtime flags - we do not wait for ordered extents to complete. Then, at btrfs_sync_file(), we call btrfs_inode_in_log() before the ordered extent completes. The call returns true: static inline bool btrfs_inode_in_log(...) { bool ret = false; spin_lock(&inode->lock); if (inode->logged_trans == generation && inode->last_sub_trans <= inode->last_log_commit && inode->last_sub_trans <= inode->root->last_log_commit) ret = true; spin_unlock(&inode->lock); return ret; } generation has a value of 6 (fs_info->generation), ->logged_trans also has a value of 6 (set when we logged the inode during the first fsync and when logging it during the rename), ->last_sub_trans has a value of 1, set during the rename (step 3), ->last_log_commit also has a value of 1 (set in step 3) and root->last_log_commit has a value of 1, which was set in step 5 when fsyncing inode 257. As a consequence we don't log the inode, any new extents and do not sync the log, resulting in a data loss if a power failure happens after the fsync and before the current transaction commits. Also, because we do not log the inode, after a power failure the mtime and ctime of the inode do not match those we had before. When the ordered extent completes before we call btrfs_inode_in_log(), then the call returns false and we log the inode and sync the log, since at the end of ordered extent completion we update the inode and set ->last_sub_trans to 2 (the value of root->log_transid) and ->last_log_commit to 1. This problem is found after removing the check for the emptiness of the inode's list of modified extents in the recent commit 209ecbb8585bf6 ("btrfs: remove stale comment and logic from btrfs_inode_in_log()"), added in the 5.13 merge window. However checking the emptiness of the list is not really the way to solve this problem, and was never intended to, because while that solves the problem for COW writes, the problem persists for NOCOW writes because in that case the list is always empty. In the case of NOCOW writes, even though we wait for the writeback to complete before returning from btrfs_sync_file(), we end up not logging the inode, which has a new mtime/ctime, and because we don't sync the log, we never issue disk barriers (send REQ_PREFLUSH to the device) since that only happens when we sync the log (when we write super blocks at btrfs_sync_log()). So effectively, for a NOCOW case, when we return from btrfs_sync_file() to user space, we are not guaranteeing that the data is durably persisted on disk. Also, while the example above uses a rename exchange to show how the problem happens, it is not the only way to trigger it. An alternative could be adding a new hard link to inode 258, since that also results in calling btrfs_log_new_name() and updating the inode in the log. An example reproducer using the addition of a hard link instead of a rename operation: $ mkfs.btrfs -f /dev/sdc $ mount /dev/sdc /mnt $ touch /mnt/bar $ xfs_io -f -c "pwrite -S 0xab 0 1M" -c "fsync" /mnt/foo $ ln /mnt/foo /mnt/foo_link $ xfs_io -c "pwrite -S 0xcd 0 1M" /mnt/foo $ xfs_io -c "fsync" /mnt/bar $ xfs_io -c "fsync" /mnt/foo # Replay the log: $ mount /dev/sdc /mnt # After this point file foo often has 1M filled with 0xab and not 0xcd The reasons leading to the final fsync of file foo, inode 258, not persisting the new data are the same as for the previous example with a rename operation. So fix by never skipping logging and log syncing when there are still any ordered extents in flight. To avoid making the conditional if statement that checks if logging an inode is needed harder to read, place all the logic into an helper function with separate if statements to make it more manageable and easier to read. A test case for fstests will follow soon. For NOCOW writes, the problem existed before commit b5e6c3e170b770 ("btrfs: always wait on ordered extents at fsync time"), introduced in kernel 4.19, then it went away with that commit since we started to always wait for ordered extent completion before logging. The problem came back again once the fast fsync path was changed again to avoid waiting for ordered extent completion, in commit 487781796d3022 ("btrfs: make fast fsyncs wait only for writeback"), added in kernel 5.10. However, for COW writes, the race only happens after the recent commit 209ecbb8585bf6 ("btrfs: remove stale comment and logic from btrfs_inode_in_log()"), introduced in the 5.13 merge window. For NOCOW writes, the bug existed before that commit. So tag 5.10+ as the release for stable backports. CC: stable@vger.kernel.org # 5.10+ Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 757e859667402f633066a5a439d2c8aaf59133aa Author: Filipe Manana Date: Wed Apr 21 14:31:50 2021 +0100 btrfs: zoned: fix silent data loss after failure splitting ordered extent commit adbd914dcde0b03bfc08ffe40b81f31b0457833f upstream. On a zoned filesystem, sometimes we need to split an ordered extent into 3 different ordered extents. The original ordered extent is shortened, at the front and at the rear, and we create two other new ordered extents to represent the trimmed parts of the original ordered extent. After adjusting the original ordered extent, we create an ordered extent to represent the pre-range, and that may fail with ENOMEM for example. After that we always try to create the ordered extent for the post-range, and if that happens to succeed we end up returning success to the caller as we overwrite the 'ret' variable which contained the previous error. This means we end up with a file range for which there is no ordered extent, which results in the range never getting a new file extent item pointing to the new data location. And since the split operation did not return an error, writeback does not fail and the inode's mapping is not flagged with an error, resulting in a subsequent fsync not reporting an error either. It's possibly very unlikely to have the creation of the post-range ordered extent succeed after the creation of the pre-range ordered extent failed, but it's not impossible. So fix this by making sure we only create the post-range ordered extent if there was no error creating the ordered extent for the pre-range. Fixes: d22002fd37bd97 ("btrfs: zoned: split ordered extent when bio is sent") CC: stable@vger.kernel.org # 5.12+ Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 96157707c0420e3d3edfe046f1cc797fee117ade Author: Filipe Manana Date: Thu Apr 22 12:08:05 2021 +0100 btrfs: fix deadlock when cloning inline extents and using qgroups commit f9baa501b4fd6962257853d46ddffbc21f27e344 upstream. There are a few exceptional cases where cloning an inline extent needs to copy the inline extent data into a page of the destination inode. When this happens, we end up starting a transaction while having a dirty page for the destination inode and while having the range locked in the destination's inode iotree too. Because when reserving metadata space for a transaction we may need to flush existing delalloc in case there is not enough free space, we have a mechanism in place to prevent a deadlock, which was introduced in commit 3d45f221ce627d ("btrfs: fix deadlock when cloning inline extent and low on free metadata space"). However when using qgroups, a transaction also reserves metadata qgroup space, which can also result in flushing delalloc in case there is not enough available space at the moment. When this happens we deadlock, since flushing delalloc requires locking the file range in the inode's iotree and the range was already locked at the very beginning of the clone operation, before attempting to start the transaction. When this issue happens, stack traces like the following are reported: [72747.556262] task:kworker/u81:9 state:D stack: 0 pid: 225 ppid: 2 flags:0x00004000 [72747.556268] Workqueue: writeback wb_workfn (flush-btrfs-1142) [72747.556271] Call Trace: [72747.556273] __schedule+0x296/0x760 [72747.556277] schedule+0x3c/0xa0 [72747.556279] io_schedule+0x12/0x40 [72747.556284] __lock_page+0x13c/0x280 [72747.556287] ? generic_file_readonly_mmap+0x70/0x70 [72747.556325] extent_write_cache_pages+0x22a/0x440 [btrfs] [72747.556331] ? __set_page_dirty_nobuffers+0xe7/0x160 [72747.556358] ? set_extent_buffer_dirty+0x5e/0x80 [btrfs] [72747.556362] ? update_group_capacity+0x25/0x210 [72747.556366] ? cpumask_next_and+0x1a/0x20 [72747.556391] extent_writepages+0x44/0xa0 [btrfs] [72747.556394] do_writepages+0x41/0xd0 [72747.556398] __writeback_single_inode+0x39/0x2a0 [72747.556403] writeback_sb_inodes+0x1ea/0x440 [72747.556407] __writeback_inodes_wb+0x5f/0xc0 [72747.556410] wb_writeback+0x235/0x2b0 [72747.556414] ? get_nr_inodes+0x35/0x50 [72747.556417] wb_workfn+0x354/0x490 [72747.556420] ? newidle_balance+0x2c5/0x3e0 [72747.556424] process_one_work+0x1aa/0x340 [72747.556426] worker_thread+0x30/0x390 [72747.556429] ? create_worker+0x1a0/0x1a0 [72747.556432] kthread+0x116/0x130 [72747.556435] ? kthread_park+0x80/0x80 [72747.556438] ret_from_fork+0x1f/0x30 [72747.566958] Workqueue: btrfs-flush_delalloc btrfs_work_helper [btrfs] [72747.566961] Call Trace: [72747.566964] __schedule+0x296/0x760 [72747.566968] ? finish_wait+0x80/0x80 [72747.566970] schedule+0x3c/0xa0 [72747.566995] wait_extent_bit.constprop.68+0x13b/0x1c0 [btrfs] [72747.566999] ? finish_wait+0x80/0x80 [72747.567024] lock_extent_bits+0x37/0x90 [btrfs] [72747.567047] btrfs_invalidatepage+0x299/0x2c0 [btrfs] [72747.567051] ? find_get_pages_range_tag+0x2cd/0x380 [72747.567076] __extent_writepage+0x203/0x320 [btrfs] [72747.567102] extent_write_cache_pages+0x2bb/0x440 [btrfs] [72747.567106] ? update_load_avg+0x7e/0x5f0 [72747.567109] ? enqueue_entity+0xf4/0x6f0 [72747.567134] extent_writepages+0x44/0xa0 [btrfs] [72747.567137] ? enqueue_task_fair+0x93/0x6f0 [72747.567140] do_writepages+0x41/0xd0 [72747.567144] __filemap_fdatawrite_range+0xc7/0x100 [72747.567167] btrfs_run_delalloc_work+0x17/0x40 [btrfs] [72747.567195] btrfs_work_helper+0xc2/0x300 [btrfs] [72747.567200] process_one_work+0x1aa/0x340 [72747.567202] worker_thread+0x30/0x390 [72747.567205] ? create_worker+0x1a0/0x1a0 [72747.567208] kthread+0x116/0x130 [72747.567211] ? kthread_park+0x80/0x80 [72747.567214] ret_from_fork+0x1f/0x30 [72747.569686] task:fsstress state:D stack: 0 pid:841421 ppid:841417 flags:0x00000000 [72747.569689] Call Trace: [72747.569691] __schedule+0x296/0x760 [72747.569694] schedule+0x3c/0xa0 [72747.569721] try_flush_qgroup+0x95/0x140 [btrfs] [72747.569725] ? finish_wait+0x80/0x80 [72747.569753] btrfs_qgroup_reserve_data+0x34/0x50 [btrfs] [72747.569781] btrfs_check_data_free_space+0x5f/0xa0 [btrfs] [72747.569804] btrfs_buffered_write+0x1f7/0x7f0 [btrfs] [72747.569810] ? path_lookupat.isra.48+0x97/0x140 [72747.569833] btrfs_file_write_iter+0x81/0x410 [btrfs] [72747.569836] ? __kmalloc+0x16a/0x2c0 [72747.569839] do_iter_readv_writev+0x160/0x1c0 [72747.569843] do_iter_write+0x80/0x1b0 [72747.569847] vfs_writev+0x84/0x140 [72747.569869] ? btrfs_file_llseek+0x38/0x270 [btrfs] [72747.569873] do_writev+0x65/0x100 [72747.569876] do_syscall_64+0x33/0x40 [72747.569879] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [72747.569899] task:fsstress state:D stack: 0 pid:841424 ppid:841417 flags:0x00004000 [72747.569903] Call Trace: [72747.569906] __schedule+0x296/0x760 [72747.569909] schedule+0x3c/0xa0 [72747.569936] try_flush_qgroup+0x95/0x140 [btrfs] [72747.569940] ? finish_wait+0x80/0x80 [72747.569967] __btrfs_qgroup_reserve_meta+0x36/0x50 [btrfs] [72747.569989] start_transaction+0x279/0x580 [btrfs] [72747.570014] clone_copy_inline_extent+0x332/0x490 [btrfs] [72747.570041] btrfs_clone+0x5b7/0x7a0 [btrfs] [72747.570068] ? lock_extent_bits+0x64/0x90 [btrfs] [72747.570095] btrfs_clone_files+0xfc/0x150 [btrfs] [72747.570122] btrfs_remap_file_range+0x3d8/0x4a0 [btrfs] [72747.570126] do_clone_file_range+0xed/0x200 [72747.570131] vfs_clone_file_range+0x37/0x110 [72747.570134] ioctl_file_clone+0x7d/0xb0 [72747.570137] do_vfs_ioctl+0x138/0x630 [72747.570140] __x64_sys_ioctl+0x62/0xc0 [72747.570143] do_syscall_64+0x33/0x40 [72747.570146] entry_SYSCALL_64_after_hwframe+0x44/0xa9 So fix this by skipping the flush of delalloc for an inode that is flagged with BTRFS_INODE_NO_DELALLOC_FLUSH, meaning it is currently under such a special case of cloning an inline extent, when flushing delalloc during qgroup metadata reservation. The special cases for cloning inline extents were added in kernel 5.7 by by commit 05a5a7621ce66c ("Btrfs: implement full reflink support for inline extents"), while having qgroup metadata space reservation flushing delalloc when low on space was added in kernel 5.9 by commit c53e9653605dbf ("btrfs: qgroup: try to flush qgroup space when we get -EDQUOT"). So use a "Fixes:" tag for the later commit to ease stable kernel backports. Reported-by: Wang Yugui Link: https://lore.kernel.org/linux-btrfs/20210421083137.31E3.409509F4@e16-tech.com/ Fixes: c53e9653605dbf ("btrfs: qgroup: try to flush qgroup space when we get -EDQUOT") CC: stable@vger.kernel.org # 5.9+ Reviewed-by: Qu Wenruo Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 0449f835a6866098d4cfd0fb89e360b35f2ec94d Author: Catalin Marinas Date: Fri May 14 10:50:01 2021 +0100 arm64: Fix race condition on PG_dcache_clean in __sync_icache_dcache() commit 588a513d34257fdde95a9f0df0202e31998e85c6 upstream. To ensure that instructions are observable in a new mapping, the arm64 set_pte_at() implementation cleans the D-cache and invalidates the I-cache to the PoU. As an optimisation, this is only done on executable mappings and the PG_dcache_clean page flag is set to avoid future cache maintenance on the same page. When two different processes map the same page (e.g. private executable file or shared mapping) there's a potential race on checking and setting PG_dcache_clean via set_pte_at() -> __sync_icache_dcache(). While on the fault paths the page is locked (PG_locked), mprotect() does not take the page lock. The result is that one process may see the PG_dcache_clean flag set but the I/D cache maintenance not yet performed. Avoid test_and_set_bit(PG_dcache_clean) in favour of separate test_bit() and set_bit(). In the rare event of a race, the cache maintenance is done twice. Signed-off-by: Catalin Marinas Cc: Cc: Will Deacon Cc: Steven Price Reviewed-by: Steven Price Acked-by: Will Deacon Link: https://lore.kernel.org/r/20210514095001.13236-1-catalin.marinas@arm.com Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 74314ea121979a92dd0ba80e6b3ac184d63bc52a Author: Peter Collingbourne Date: Fri May 7 11:59:05 2021 -0700 arm64: mte: initialize RGSR_EL1.SEED in __cpu_setup commit 37a8024d265564eba680575df6421f19db21dfce upstream. A valid implementation choice for the ChooseRandomNonExcludedTag() pseudocode function used by IRG is to behave in the same way as with GCR_EL1.RRND=0. This would mean that RGSR_EL1.SEED is used as an LFSR which must have a non-zero value in order for IRG to properly produce pseudorandom numbers. However, RGSR_EL1 is reset to an UNKNOWN value on soft reset and thus may reset to 0. Therefore we must initialize RGSR_EL1.SEED to a non-zero value in order to ensure that IRG behaves as expected. Signed-off-by: Peter Collingbourne Fixes: 3b714d24ef17 ("arm64: mte: CPU feature detection and initial sysreg configuration") Cc: # 5.10 Link: https://linux-review.googlesource.com/id/I2b089b6c7d6f17ee37e2f0db7df5ad5bcc04526c Acked-by: Mark Rutland Link: https://lore.kernel.org/r/20210507185905.1745402-1-pcc@google.com Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 8942128ca6a3c9e2438d5560cd65a783c86978e3 Author: Huang Rui Date: Sun Apr 25 15:34:51 2021 +0800 x86, sched: Fix the AMD CPPC maximum performance value on certain AMD Ryzen generations commit 3743d55b289c203d8f77b7cd47c24926b9d186ae upstream. Some AMD Ryzen generations has different calculation method on maximum performance. 255 is not for all ASICs, some specific generations should use 166 as the maximum performance. Otherwise, it will report incorrect frequency value like below: ~ → lscpu | grep MHz CPU MHz: 3400.000 CPU max MHz: 7228.3198 CPU min MHz: 2200.0000 [ mingo: Tidied up whitespace use. ] [ Alexander Monakov : fix 225 -> 255 typo. ] Fixes: 41ea667227ba ("x86, sched: Calculate frequency invariance for AMD systems") Fixes: 3c55e94c0ade ("cpufreq: ACPI: Extend frequency tables to cover boost frequencies") Reported-by: Jason Bagavatsingham Fixed-by: Alexander Monakov Reviewed-by: Rafael J. Wysocki Signed-off-by: Huang Rui Signed-off-by: Ingo Molnar Tested-by: Jason Bagavatsingham Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210425073451.2557394-1-ray.huang@amd.com Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=211791 Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 86d9a6b8c799c3f2630e6a9a4f9fbebc1738d184 Author: Tejun Heo Date: Tue May 11 21:38:36 2021 -0400 blk-iocost: fix weight updates of inner active iocgs commit e9f4eee9a0023ba22db9560d4cc6ee63f933dae8 upstream. When the weight of an active iocg is updated, weight_updated() is called which in turn calls __propagate_weights() to update the active and inuse weights so that the effective hierarchical weights are update accordingly. The current implementation is incorrect for inner active nodes. For an active leaf iocg, inuse can be any value between 1 and active and the difference represents how much the iocg is donating. When weight is updated, as long as inuse is clamped between 1 and the new weight, we're alright and this is what __propagate_weights() currently implements. However, that's not how an active inner node's inuse is set. An inner node's inuse is solely determined by the ratio between the sums of inuse's and active's of its children - ie. they're results of propagating the leaves' active and inuse weights upwards. __propagate_weights() incorrectly applies the same clamping as for a leaf when an active inner node's weight is updated. Consider a hierarchy which looks like the following with saturating workloads in AA and BB. R / \ A B | | AA BB 1. For both A and B, active=100, inuse=100, hwa=0.5, hwi=0.5. 2. echo 200 > A/io.weight 3. __propagate_weights() update A's active to 200 and leave inuse at 100 as it's already between 1 and the new active, making A:active=200, A:inuse=100. As R's active_sum is updated along with A's active, A:hwa=2/3, B:hwa=1/3. However, because the inuses didn't change, the hwi's remain unchanged at 0.5. 4. The weight of A is now twice that of B but AA and BB still have the same hwi of 0.5 and thus are doing the same amount of IOs. Fix it by making __propgate_weights() always calculate the inuse of an active inner iocg based on the ratio of child_inuse_sum to child_active_sum. Signed-off-by: Tejun Heo Reported-by: Dan Schatzberg Fixes: 7caa47151ab2 ("blkcg: implement blk-iocost") Cc: stable@vger.kernel.org # v5.4+ Link: https://lore.kernel.org/r/YJsxnLZV1MnBcqjj@slm.duckdns.org Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit b582847eae108185fad15c73573270aa4b402b97 Author: Peter Xu Date: Fri May 14 17:27:07 2021 -0700 mm/hugetlb: fix cow where page writtable in child commit 84894e1c42e9f25c17f2888e0c0e1505cb727538 upstream. When rework early cow of pinned hugetlb pages, we moved huge_ptep_get() upper but overlooked a side effect that the huge_ptep_get() will fetch the pte after wr-protection. After moving it upwards, we need explicit wr-protect of child pte or we will keep the write bit set in the child process, which could cause data corrution where the child can write to the original page directly. This issue can also be exposed by "memfd_test hugetlbfs" kselftest. Link: https://lkml.kernel.org/r/20210503234356.9097-3-peterx@redhat.com Fixes: 4eae4efa2c299 ("hugetlb: do early cow when page pinned on src mm") Signed-off-by: Peter Xu Reviewed-by: Mike Kravetz Cc: Hugh Dickins Cc: Joel Fernandes (Google) Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 62917eecde04e8a4cf0668f8559e633cc015df83 Author: Peter Xu Date: Fri May 14 17:27:04 2021 -0700 mm/hugetlb: fix F_SEAL_FUTURE_WRITE commit 22247efd822e6d263f3c8bd327f3f769aea9b1d9 upstream. Patch series "mm/hugetlb: Fix issues on file sealing and fork", v2. Hugh reported issue with F_SEAL_FUTURE_WRITE not applied correctly to hugetlbfs, which I can easily verify using the memfd_test program, which seems that the program is hardly run with hugetlbfs pages (as by default shmem). Meanwhile I found another probably even more severe issue on that hugetlb fork won't wr-protect child cow pages, so child can potentially write to parent private pages. Patch 2 addresses that. After this series applied, "memfd_test hugetlbfs" should start to pass. This patch (of 2): F_SEAL_FUTURE_WRITE is missing for hugetlb starting from the first day. There is a test program for that and it fails constantly. $ ./memfd_test hugetlbfs memfd-hugetlb: CREATE memfd-hugetlb: BASIC memfd-hugetlb: SEAL-WRITE memfd-hugetlb: SEAL-FUTURE-WRITE mmap() didn't fail as expected Aborted (core dumped) I think it's probably because no one is really running the hugetlbfs test. Fix it by checking FUTURE_WRITE also in hugetlbfs_file_mmap() as what we do in shmem_mmap(). Generalize a helper for that. Link: https://lkml.kernel.org/r/20210503234356.9097-1-peterx@redhat.com Link: https://lkml.kernel.org/r/20210503234356.9097-2-peterx@redhat.com Fixes: ab3948f58ff84 ("mm/memfd: add an F_SEAL_FUTURE_WRITE seal to memfd") Signed-off-by: Peter Xu Reported-by: Hugh Dickins Reviewed-by: Mike Kravetz Cc: Joel Fernandes (Google) Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 89951f677300da9e35ab735ba15d6ac1cc01258b Author: Peter Collingbourne Date: Fri May 14 17:27:27 2021 -0700 kasan: fix unit tests with CONFIG_UBSAN_LOCAL_BOUNDS enabled commit f649dc0e0d7b509c75570ee403723660f5b72ec7 upstream. These tests deliberately access these arrays out of bounds, which will cause the dynamic local bounds checks inserted by CONFIG_UBSAN_LOCAL_BOUNDS to fail and panic the kernel. To avoid this problem, access the arrays via volatile pointers, which will prevent the compiler from being able to determine the array bounds. These accesses use volatile pointers to char (char *volatile) rather than the more conventional pointers to volatile char (volatile char *) because we want to prevent the compiler from making inferences about the pointer itself (i.e. its array bounds), not the data that it refers to. Link: https://lkml.kernel.org/r/20210507025915.1464056-1-pcc@google.com Link: https://linux-review.googlesource.com/id/I90b1713fbfa1bf68ff895aef099ea77b98a7c3b9 Signed-off-by: Peter Collingbourne Tested-by: Alexander Potapenko Reviewed-by: Andrey Konovalov Cc: Peter Collingbourne Cc: George Popescu Cc: Elena Petrova Cc: Evgenii Stepanov Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 2d59a0ed8b26b8f3638d8afc31f839e27759f1f6 Author: Axel Rasmussen Date: Fri May 14 17:27:19 2021 -0700 userfaultfd: release page in error path to avoid BUG_ON commit 7ed9d238c7dbb1fdb63ad96a6184985151b0171c upstream. Consider the following sequence of events: 1. Userspace issues a UFFD ioctl, which ends up calling into shmem_mfill_atomic_pte(). We successfully account the blocks, we shmem_alloc_page(), but then the copy_from_user() fails. We return -ENOENT. We don't release the page we allocated. 2. Our caller detects this error code, tries the copy_from_user() after dropping the mmap_lock, and retries, calling back into shmem_mfill_atomic_pte(). 3. Meanwhile, let's say another process filled up the tmpfs being used. 4. So shmem_mfill_atomic_pte() fails to account blocks this time, and immediately returns - without releasing the page. This triggers a BUG_ON in our caller, which asserts that the page should always be consumed, unless -ENOENT is returned. To fix this, detect if we have such a "dangling" page when accounting fails, and if so, release it before returning. Link: https://lkml.kernel.org/r/20210428230858.348400-1-axelrasmussen@google.com Fixes: cb658a453b93 ("userfaultfd: shmem: avoid leaking blocks and used blocks in UFFDIO_COPY") Signed-off-by: Axel Rasmussen Reported-by: Hugh Dickins Acked-by: Hugh Dickins Reviewed-by: Peter Xu Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 9ce43b4f3c13479cb106117767e3b8e387da78f2 Author: Phillip Lougher Date: Fri May 14 17:27:16 2021 -0700 squashfs: fix divide error in calculate_skip() commit d6e621de1fceb3b098ebf435ef7ea91ec4838a1a upstream. Sysbot has reported a "divide error" which has been identified as being caused by a corrupted file_size value within the file inode. This value has been corrupted to a much larger value than expected. Calculate_skip() is passed i_size_read(inode) >> msblk->block_log. Due to the file_size value corruption this overflows the int argument/variable in that function, leading to the divide error. This patch changes the function to use u64. This will accommodate any unexpectedly large values due to corruption. The value returned from calculate_skip() is clamped to be never more than SQUASHFS_CACHED_BLKS - 1, or 7. So file_size corruption does not lead to an unexpectedly large return result here. Link: https://lkml.kernel.org/r/20210507152618.9447-1-phillip@squashfs.org.uk Signed-off-by: Phillip Lougher Reported-by: Reported-by: Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 97314e45aa1223a42d60256a62c5d9af54baf446 Author: Jouni Roivas Date: Fri May 14 17:27:33 2021 -0700 hfsplus: prevent corruption in shrinking truncate commit c3187cf32216313fb316084efac4dab3a8459b1d upstream. I believe there are some issues introduced by commit 31651c607151 ("hfsplus: avoid deadlock on file truncation") HFS+ has extent records which always contains 8 extents. In case the first extent record in catalog file gets full, new ones are allocated from extents overflow file. In case shrinking truncate happens to middle of an extent record which locates in extents overflow file, the logic in hfsplus_file_truncate() was changed so that call to hfs_brec_remove() is not guarded any more. Right action would be just freeing the extents that exceed the new size inside extent record by calling hfsplus_free_extents(), and then check if the whole extent record should be removed. However since the guard (blk_cnt > start) is now after the call to hfs_brec_remove(), this has unfortunate effect that the last matching extent record is removed unconditionally. To reproduce this issue, create a file which has at least 10 extents, and then perform shrinking truncate into middle of the last extent record, so that the number of remaining extents is not under or divisible by 8. This causes the last extent record (8 extents) to be removed totally instead of truncating into middle of it. Thus this causes corruption, and lost data. Fix for this is simply checking if the new truncated end is below the start of this extent record, making it safe to remove the full extent record. However call to hfs_brec_remove() can't be moved to it's previous place since we're dropping ->tree_lock and it can cause a race condition and the cached info being invalidated possibly corrupting the node data. Another issue is related to this one. When entering into the block (blk_cnt > start) we are not holding the ->tree_lock. We break out from the loop not holding the lock, but hfs_find_exit() does unlock it. Not sure if it's possible for someone else to take the lock under our feet, but it can cause hard to debug errors and premature unlocking. Even if there's no real risk of it, the locking should still always be kept in balance. Thus taking the lock now just before the check. Link: https://lkml.kernel.org/r/20210429165139.3082828-1-jouni.roivas@tuxera.com Fixes: 31651c607151f ("hfsplus: avoid deadlock on file truncation") Signed-off-by: Jouni Roivas Reviewed-by: Anton Altaparmakov Cc: Anatoly Trosinenko Cc: Viacheslav Dubeyko Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 5bc00fdda1e934c557351a9c751a205293e68cbf Author: Michael Ellerman Date: Thu May 6 14:49:59 2021 +1000 powerpc/64s: Fix crashes when toggling entry flush barrier commit aec86b052df6541cc97c5fca44e5934cbea4963b upstream. The entry flush mitigation can be enabled/disabled at runtime via a debugfs file (entry_flush), which causes the kernel to patch itself to enable/disable the relevant mitigations. However depending on which mitigation we're using, it may not be safe to do that patching while other CPUs are active. For example the following crash: sleeper[15639]: segfault (11) at c000000000004c20 nip c000000000004c20 lr c000000000004c20 Shows that we returned to userspace with a corrupted LR that points into the kernel, due to executing the partially patched call to the fallback entry flush (ie. we missed the LR restore). Fix it by doing the patching under stop machine. The CPUs that aren't doing the patching will be spinning in the core of the stop machine logic. That is currently sufficient for our purposes, because none of the patching we do is to that code or anywhere in the vicinity. Fixes: f79643787e0a ("powerpc/64s: flush L1D on kernel entry") Cc: stable@vger.kernel.org # v5.10+ Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210506044959.1298123-2-mpe@ellerman.id.au Signed-off-by: Greg Kroah-Hartman commit ba16e1f89dc2d6c34211ed69e08f3e987b1a2e36 Author: Michael Ellerman Date: Thu May 6 14:49:58 2021 +1000 powerpc/64s: Fix crashes when toggling stf barrier commit 8ec7791bae1327b1c279c5cd6e929c3b12daaf0a upstream. The STF (store-to-load forwarding) barrier mitigation can be enabled/disabled at runtime via a debugfs file (stf_barrier), which causes the kernel to patch itself to enable/disable the relevant mitigations. However depending on which mitigation we're using, it may not be safe to do that patching while other CPUs are active. For example the following crash: User access of kernel address (c00000003fff5af0) - exploit attempt? (uid: 0) segfault (11) at c00000003fff5af0 nip 7fff8ad12198 lr 7fff8ad121f8 code 1 code: 40820128 e93c00d0 e9290058 7c292840 40810058 38600000 4bfd9a81 e8410018 code: 2c030006 41810154 3860ffb6 e9210098 7d295279 39400000 40820a3c Shows that we returned to userspace without restoring the user r13 value, due to executing the partially patched STF exit code. Fix it by doing the patching under stop machine. The CPUs that aren't doing the patching will be spinning in the core of the stop machine logic. That is currently sufficient for our purposes, because none of the patching we do is to that code or anywhere in the vicinity. Fixes: a048a07d7f45 ("powerpc/64s: Add support for a store forwarding barrier at kernel entry/exit") Cc: stable@vger.kernel.org # v4.17+ Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210506044959.1298123-1-mpe@ellerman.id.au Signed-off-by: Greg Kroah-Hartman commit ecd6bdc103e345390431baf64af2a67f470aa9eb Author: Eric Dumazet Date: Wed Apr 14 10:05:17 2021 -0700 sh: Remove unused variable commit 0d3ae948741ac6d80e39ab27b45297367ee477de upstream. Removes this annoying warning: arch/sh/kernel/traps.c: In function ‘nmi_trap_handler’: arch/sh/kernel/traps.c:183:15: warning: unused variable ‘cpu’ [-Wunused-variable] 183 | unsigned int cpu = smp_processor_id(); Fixes: fe3f1d5d7cd3 ("sh: Get rid of nmi_count()") Signed-off-by: Eric Dumazet Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210414170517.1205430-1-eric.dumazet@gmail.com Signed-off-by: Greg Kroah-Hartman commit e3a8166fa6e2e33316d829fbf81cfcff18dba472 Author: Vladimir Isaev Date: Tue Apr 27 15:13:54 2021 +0300 ARC: mm: Use max_high_pfn as a HIGHMEM zone border commit 1d5e4640e5df15252398c1b621f6bd432f2d7f17 upstream. Commit 4af22ded0ecf ("arc: fix memory initialization for systems with two memory banks") fixed highmem, but for the PAE case it causes bug messages: | BUG: Bad page state in process swapper pfn:80000 | page:(ptrval) refcount:0 mapcount:1 mapping:00000000 index:0x0 pfn:0x80000 flags: 0x0() | raw: 00000000 00000100 00000122 00000000 00000000 00000000 00000000 00000000 | raw: 00000000 | page dumped because: nonzero mapcount | Modules linked in: | CPU: 0 PID: 0 Comm: swapper Not tainted 5.12.0-rc5-00003-g1e43c377a79f #1 This is because the fix expects highmem to be always less than lowmem and uses min_low_pfn as an upper zone border for highmem. max_high_pfn should be ok for both highmem and highmem+PAE cases. Fixes: 4af22ded0ecf ("arc: fix memory initialization for systems with two memory banks") Signed-off-by: Vladimir Isaev Cc: Mike Rapoport Cc: stable@vger.kernel.org #5.8 onwards Signed-off-by: Vineet Gupta Signed-off-by: Greg Kroah-Hartman commit 059e7eeb1f3975cd7ca1bd01976b7a541e6c9fb3 Author: Vladimir Isaev Date: Tue Apr 27 15:12:37 2021 +0300 ARC: mm: PAE: use 40-bit physical page mask commit c5f756d8c6265ebb1736a7787231f010a3b782e5 upstream. 32-bit PAGE_MASK can not be used as a mask for physical addresses when PAE is enabled. PAGE_MASK_PHYS must be used for physical addresses instead of PAGE_MASK. Without this, init gets SIGSEGV if pte_modify was called: | potentially unexpected fatal signal 11. | Path: /bin/busybox | CPU: 0 PID: 1 Comm: init Not tainted 5.12.0-rc5-00003-g1e43c377a79f-dirty | Insn could not be fetched | @No matching VMA found | ECR: 0x00040000 EFA: 0x00000000 ERET: 0x00000000 | STAT: 0x80080082 [IE U ] BTA: 0x00000000 | SP: 0x5f9ffe44 FP: 0x00000000 BLK: 0xaf3d4 | LPS: 0x000d093e LPE: 0x000d0950 LPC: 0x00000000 | r00: 0x00000002 r01: 0x5f9fff14 r02: 0x5f9fff20 | ... | Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b Signed-off-by: Vladimir Isaev Reported-by: kernel test robot Cc: Vineet Gupta Cc: stable@vger.kernel.org Signed-off-by: Vineet Gupta Signed-off-by: Greg Kroah-Hartman commit 47fcfe49330df1b847ae038be4f8c6bbd095e012 Author: Vineet Gupta Date: Fri Apr 23 12:16:25 2021 -0700 ARC: entry: fix off-by-one error in syscall number validation commit 3433adc8bd09fc9f29b8baddf33b4ecd1ecd2cdc upstream. We have NR_syscall syscalls from [0 .. NR_syscall-1]. However the check for invalid syscall number is "> NR_syscall" as opposed to >=. This off-by-one error erronesously allows "NR_syscall" to be treated as valid syscall causeing out-of-bounds access into syscall-call table ensuing a crash (holes within syscall table have a invalid-entry handler but this is beyond the array implementing the table). This problem showed up on v5.6 kernel when testing glibc 2.33 (v5.10 kernel capable, includng faccessat2 syscall 439). The v5.6 kernel has NR_syscalls=439 (0 to 438). Due to the bug, 439 passed by glibc was not handled as -ENOSYS but processed leading to a crash. Link: https://github.com/foss-for-synopsys-dwc-arc-processors/linux/issues/48 Reported-by: Shahab Vahedi Cc: Signed-off-by: Vineet Gupta Signed-off-by: Greg Kroah-Hartman commit d7a9d125c3c57a87b6e7ec3039cdf5822c5e91b4 Author: Paolo Abeni Date: Thu May 6 17:16:38 2021 -0700 mptcp: fix splat when closing unaccepted socket [ Upstream commit 578c18eff1627d6a911f08f4cf351eca41fdcc7d ] If userspace exits before calling accept() on a listener that had at least one new connection ready, we get: Attempt to release TCP socket in state 8 This happens because the mptcp socket gets cloned when the TCP connection is ready, but the socket is never exposed to userspace. The client additionally sends a DATA_FIN, which brings connection into CLOSE_WAIT state. This in turn prevents the orphan+state reset fixup in mptcp_sock_destruct() from doing its job. Fixes: 3721b9b64676b ("mptcp: Track received DATA_FIN sequence number and add related helpers") Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/185 Tested-by: Florian Westphal Signed-off-by: Paolo Abeni Signed-off-by: Mat Martineau Link: https://lore.kernel.org/r/20210507001638.225468-1-mathew.j.martineau@linux.intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ca1fff55783178239c58281db47e1df05971bbbe Author: Arkadiusz Kubalewski Date: Fri Apr 16 23:43:57 2021 +0200 i40e: Remove LLDP frame filters [ Upstream commit 8085a36db71f54d2592426eb76bdf71b82479140 ] Remove filters from being setup in case of software DCB and allow the LLDP frames to be properly transmitted to the wire. It is not possible to transmit the LLDP frame out of the port, if they are filtered by control VSI. This prohibits software LLDP agent properly communicate its DCB capabilities to the neighbors. Fixes: 4b208eaa8078 ("i40e: Add init and default config of software based DCB") Signed-off-by: Arkadiusz Kubalewski Tested-by: Imam Hassan Reza Biswas Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit bd4febf1386c4b672d1224238174dfb35013902d Author: Mateusz Palczewski Date: Tue Apr 13 14:43:07 2021 +0000 i40e: Fix PHY type identifiers for 2.5G and 5G adapters [ Upstream commit 15395ec4685bd45a43d1b54b8fd9846b87e2c621 ] Unlike other supported adapters, 2.5G and 5G use different PHY type identifiers for reading/writing PHY settings and for reading link status. This commit introduces separate PHY identifiers for these two operation types. Fixes: 2e45d3f4677a ("i40e: Add support for X710 B/P & SFP+ cards") Signed-off-by: Dawid Lukwinski Signed-off-by: Mateusz Palczewski Reviewed-by: Aleksandr Loktionov Tested-by: Dave Switzer Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 4591ae84b2831fb0ac5dbd0eb01b712e0f0b162e Author: Jaroslaw Gawin Date: Tue Apr 13 14:19:40 2021 +0000 i40e: fix the restart auto-negotiation after FEC modified [ Upstream commit 61343e6da7810de81d6b826698946ae4f9070819 ] When FEC mode was changed the link didn't know it because the link was not reset and new parameters were not negotiated. Set a flag 'I40E_AQ_PHY_ENABLE_ATOMIC_LINK' in 'abilities' to restart the link and make it run with the new settings. Fixes: 1d96340196f1 ("i40e: Add support FEC configuration for Fortville 25G") Signed-off-by: Jaroslaw Gawin Signed-off-by: Mateusz Palczewski Tested-by: Dave Switzer Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 1fd5d262e7442192ac7611ff1597a36c5b044323 Author: Yunjian Wang Date: Mon Apr 12 22:41:18 2021 +0800 i40e: Fix use-after-free in i40e_client_subtask() [ Upstream commit 38318f23a7ef86a8b1862e5e8078c4de121960c3 ] Currently the call to i40e_client_del_instance frees the object pf->cinst, however pf->cinst->lan_info is being accessed after the free. Fix this by adding the missing return. Addresses-Coverity: ("Read from pointer after free") Fixes: 7b0b1a6d0ac9 ("i40e: Disable iWARP VSI PETCP_ENA flag on netdev down events") Signed-off-by: Yunjian Wang Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit ad453d44cf23c3de73065e0c21672982831c5548 Author: Magnus Karlsson Date: Mon Apr 26 13:14:01 2021 +0200 i40e: fix broken XDP support [ Upstream commit ae4393dfd472b194c90d75d2123105fb5ed59b04 ] Commit 12738ac4754e ("i40e: Fix sparse errors in i40e_txrx.c") broke XDP support in the i40e driver. That commit was fixing a sparse error in the code by introducing a new variable xdp_res instead of overloading this into the skb pointer. The problem is that the code later uses the skb pointer in if statements and these where not extended to also test for the new xdp_res variable. Fix this by adding the correct tests for xdp_res in these places. The skb pointer was used to store the result of the XDP program by overloading the results in the error pointer ERR_PTR(-result). Therefore, the allocation failure test that used to only test for !skb now need to be extended to also consider !xdp_res. i40e_cleanup_headers() had a check that based on the skb value being an error pointer, i.e. a result from the XDP program != XDP_PASS, and if so start to process a new packet immediately, instead of populating skb fields and sending the skb to the stack. This check is not needed anymore, since we have added an explicit test for xdp_res being set and if so just do continue to pick the next packet from the NIC. Fixes: 12738ac4754e ("i40e: Fix sparse errors in i40e_txrx.c") Acked-by: Jesper Dangaard Brouer Tested-by: Jesper Dangaard Brouer Reported-by: Jesper Dangaard Brouer Reviewed-by: Maciej Fijalkowski Signed-off-by: Magnus Karlsson Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit a388d10961ff8578b1a6691945d406c0f33aa71b Author: Eric Dumazet Date: Thu May 6 05:53:23 2021 -0700 netfilter: nftables: avoid overflows in nft_hash_buckets() [ Upstream commit a54754ec9891830ba548e2010c889e3c8146e449 ] Number of buckets being stored in 32bit variables, we have to ensure that no overflows occur in nft_hash_buckets() syzbot injected a size == 0x40000000 and reported: UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13 shift exponent 64 is too large for 64-bit type 'long unsigned int' CPU: 1 PID: 29539 Comm: syz-executor.4 Not tainted 5.12.0-rc7-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x141/0x1d7 lib/dump_stack.c:120 ubsan_epilogue+0xb/0x5a lib/ubsan.c:148 __ubsan_handle_shift_out_of_bounds.cold+0xb1/0x181 lib/ubsan.c:327 __roundup_pow_of_two include/linux/log2.h:57 [inline] nft_hash_buckets net/netfilter/nft_set_hash.c:411 [inline] nft_hash_estimate.cold+0x19/0x1e net/netfilter/nft_set_hash.c:652 nft_select_set_ops net/netfilter/nf_tables_api.c:3586 [inline] nf_tables_newset+0xe62/0x3110 net/netfilter/nf_tables_api.c:4322 nfnetlink_rcv_batch+0xa09/0x24b0 net/netfilter/nfnetlink.c:488 nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:612 [inline] nfnetlink_rcv+0x3af/0x420 net/netfilter/nfnetlink.c:630 netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927 sock_sendmsg_nosec net/socket.c:654 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:674 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2350 ___sys_sendmsg+0xf3/0x170 net/socket.c:2404 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 Fixes: 0ed6389c483d ("netfilter: nf_tables: rename set implementations") Signed-off-by: Eric Dumazet Reported-by: syzbot Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 56587c4df27a2c46de85d4123c883d5d9322eb10 Author: David Hildenbrand Date: Thu May 6 18:05:16 2021 -0700 kernel/resource: make walk_mem_res() find all busy IORESOURCE_MEM resources [ Upstream commit 3c9c797534364593b73ba6ab060a014af8934721 ] It used to be true that we can have system RAM (IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY) only on the first level in the resource tree. However, this is no longer holds for driver-managed system RAM (i.e., added via dax/kmem and virtio-mem), which gets added on lower levels, for example, inside device containers. IORESOURCE_SYSTEM_RAM is defined as IORESOURCE_MEM | IORESOURCE_SYSRAM and just a special type of IORESOURCE_MEM. The function walk_mem_res() only considers the first level and is used in arch/x86/mm/ioremap.c:__ioremap_check_mem() only. We currently fail to identify System RAM added by dax/kmem and virtio-mem as "IORES_MAP_SYSTEM_RAM", for example, allowing for remapping of such "normal RAM" in __ioremap_caller(). Let's find all IORESOURCE_MEM | IORESOURCE_BUSY resources, making the function behave similar to walk_system_ram_res(). Link: https://lkml.kernel.org/r/20210325115326.7826-3-david@redhat.com Fixes: ebf71552bb0e ("virtio-mem: Add parent resource for all added "System RAM"") Fixes: c221c0b0308f ("device-dax: "Hotplug" persistent memory for use like normal RAM") Signed-off-by: David Hildenbrand Reviewed-by: Dan Williams Cc: Greg Kroah-Hartman Cc: Dan Williams Cc: Daniel Vetter Cc: Andy Shevchenko Cc: Mauro Carvalho Chehab Cc: Dave Young Cc: Baoquan He Cc: Vivek Goyal Cc: Dave Hansen Cc: Keith Busch Cc: Michal Hocko Cc: Qian Cai Cc: Oscar Salvador Cc: Eric Biederman Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: "H. Peter Anvin" Cc: Tom Lendacky Cc: Brijesh Singh Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit dc3b515a96bf201571c3d58873aa473f1cd5a175 Author: David Hildenbrand Date: Thu May 6 18:05:12 2021 -0700 kernel/resource: make walk_system_ram_res() find all busy IORESOURCE_SYSTEM_RAM resources [ Upstream commit 97f61c8f44ec9020708b97a51188170add4f3084 ] Patch series "kernel/resource: make walk_system_ram_res() and walk_mem_res() search the whole tree", v2. Playing with kdump+virtio-mem I noticed that kexec_file_load() does not consider System RAM added via dax/kmem and virtio-mem when preparing the elf header for kdump. Looking into the details, the logic used in walk_system_ram_res() and walk_mem_res() seems to be outdated. walk_system_ram_range() already does the right thing, let's change walk_system_ram_res() and walk_mem_res(), and clean up. Loading a kdump kernel via "kexec -p -s" ... will result in the kdump kernel to also dump dax/kmem and virtio-mem added System RAM now. Note: kexec-tools on x86-64 also have to be updated to consider this memory in the kexec_load() case when processing /proc/iomem. This patch (of 3): It used to be true that we can have system RAM (IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY) only on the first level in the resource tree. However, this is no longer holds for driver-managed system RAM (i.e., added via dax/kmem and virtio-mem), which gets added on lower levels, for example, inside device containers. We have two users of walk_system_ram_res(), which currently only consideres the first level: a) kernel/kexec_file.c:kexec_walk_resources() -- We properly skip IORESOURCE_SYSRAM_DRIVER_MANAGED resources via locate_mem_hole_callback(), so even after this change, we won't be placing kexec images onto dax/kmem and virtio-mem added memory. No change. b) arch/x86/kernel/crash.c:fill_up_crash_elf_data() -- we're currently not adding relevant ranges to the crash elf header, resulting in them not getting dumped via kdump. This change fixes loading a crashkernel via kexec_file_load() and including dax/kmem and virtio-mem added System RAM in the crashdump on x86-64. Note that e.g,, arm64 relies on memblock data and, therefore, always considers all added System RAM already. Let's find all IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY resources, making the function behave like walk_system_ram_range(). Link: https://lkml.kernel.org/r/20210325115326.7826-1-david@redhat.com Link: https://lkml.kernel.org/r/20210325115326.7826-2-david@redhat.com Fixes: ebf71552bb0e ("virtio-mem: Add parent resource for all added "System RAM"") Fixes: c221c0b0308f ("device-dax: "Hotplug" persistent memory for use like normal RAM") Signed-off-by: David Hildenbrand Reviewed-by: Dan Williams Acked-by: Baoquan He Cc: Greg Kroah-Hartman Cc: Dan Williams Cc: Daniel Vetter Cc: Andy Shevchenko Cc: Mauro Carvalho Chehab Cc: Dave Young Cc: Baoquan He Cc: Vivek Goyal Cc: Dave Hansen Cc: Keith Busch Cc: Michal Hocko Cc: Qian Cai Cc: Oscar Salvador Cc: Eric Biederman Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: "H. Peter Anvin" Cc: Tom Lendacky Cc: Brijesh Singh Cc: "Eric W. Biederman" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 8bb4152dfd5f8830aaef18db110883f4a4fdd0ba Author: Jia-Ju Bai Date: Thu May 6 18:04:38 2021 -0700 kernel: kexec_file: fix error return code of kexec_calculate_store_digests() [ Upstream commit 31d82c2c787d5cf65fedd35ebbc0c1bd95c1a679 ] When vzalloc() returns NULL to sha_regions, no error return code of kexec_calculate_store_digests() is assigned. To fix this bug, ret is assigned with -ENOMEM in this case. Link: https://lkml.kernel.org/r/20210309083904.24321-1-baijiaju1990@gmail.com Fixes: a43cac0d9dc2 ("kexec: split kexec_file syscall code to kexec_file.c") Signed-off-by: Jia-Ju Bai Reported-by: TOTE Robot Acked-by: Baoquan He Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 68428bbdc5f0e2b6fb8ae8274ec3e7281a129500 Author: Colin Ian King Date: Thu May 6 18:02:10 2021 -0700 fs/proc/generic.c: fix incorrect pde_is_permanent check [ Upstream commit f4bf74d82915708208bc9d0c9bd3f769f56bfbec ] Currently the pde_is_permanent() check is being run on root multiple times rather than on the next proc directory entry. This looks like a copy-paste error. Fix this by replacing root with next. Addresses-Coverity: ("Copy-paste error") Link: https://lkml.kernel.org/r/20210318122633.14222-1-colin.king@canonical.com Fixes: d919b33dafb3 ("proc: faster open/read/close with "permanent" files") Signed-off-by: Colin Ian King Acked-by: Christian Brauner Reviewed-by: Alexey Dobriyan Cc: Greg Kroah-Hartman Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit e72b2405436c6cbaff7dcd535584086a5e4f0f82 Author: Alex Elder Date: Wed May 5 17:36:36 2021 -0500 net: ipa: fix inter-EE IRQ register definitions [ Upstream commit 6a780f51f87b430cc69ebf4e859e7e9be720b283 ] In gsi_irq_setup(), two registers are written with the intention of disabling inter-EE channel and event IRQs. But the wrong registers are used (and defined); the ones used are read-only registers that indicate whether the interrupt condition is present. Define the mask registers instead of the status registers, and use them to disable the inter-EE interrupt types. Fixes: 46f748ccaf01 ("net: ipa: explicitly disallow inter-EE interrupts") Signed-off-by: Alex Elder Link: https://lore.kernel.org/r/20210505223636.232527-1-elder@linaro.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c6b7a63233089bd5147defc33df2c91da9bf4609 Author: Odin Ugedal Date: Sat May 1 16:19:50 2021 +0200 sched/fair: Fix unfairness caused by missing load decay [ Upstream commit 0258bdfaff5bd13c4d2383150b7097aecd6b6d82 ] This fixes an issue where old load on a cfs_rq is not properly decayed, resulting in strange behavior where fairness can decrease drastically. Real workloads with equally weighted control groups have ended up getting a respective 99% and 1%(!!) of cpu time. When an idle task is attached to a cfs_rq by attaching a pid to a cgroup, the old load of the task is attached to the new cfs_rq and sched_entity by attach_entity_cfs_rq. If the task is then moved to another cpu (and therefore cfs_rq) before being enqueued/woken up, the load will be moved to cfs_rq->removed from the sched_entity. Such a move will happen when enforcing a cpuset on the task (eg. via a cgroup) that force it to move. The load will however not be removed from the task_group itself, making it look like there is a constant load on that cfs_rq. This causes the vruntime of tasks on other sibling cfs_rq's to increase faster than they are supposed to; causing severe fairness issues. If no other task is started on the given cfs_rq, and due to the cpuset it would not happen, this load would never be properly unloaded. With this patch the load will be properly removed inside update_blocked_averages. This also applies to tasks moved to the fair scheduling class and moved to another cpu, and this path will also fix that. For fork, the entity is queued right away, so this problem does not affect that. This applies to cases where the new process is the first in the cfs_rq, issue introduced 3d30544f0212 ("sched/fair: Apply more PELT fixes"), and when there has previously been load on the cgroup but the cgroup was removed from the leaflist due to having null PELT load, indroduced in 039ae8bcf7a5 ("sched/fair: Fix O(nr_cgroups) in the load balancing path"). For a simple cgroup hierarchy (as seen below) with two equally weighted groups, that in theory should get 50/50 of cpu time each, it often leads to a load of 60/40 or 70/30. parent/ cg-1/ cpu.weight: 100 cpuset.cpus: 1 cg-2/ cpu.weight: 100 cpuset.cpus: 1 If the hierarchy is deeper (as seen below), while keeping cg-1 and cg-2 equally weighted, they should still get a 50/50 balance of cpu time. This however sometimes results in a balance of 10/90 or 1/99(!!) between the task groups. $ ps u -C stress USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 18568 1.1 0.0 3684 100 pts/12 R+ 13:36 0:00 stress --cpu 1 root 18580 99.3 0.0 3684 100 pts/12 R+ 13:36 0:09 stress --cpu 1 parent/ cg-1/ cpu.weight: 100 sub-group/ cpu.weight: 1 cpuset.cpus: 1 cg-2/ cpu.weight: 100 sub-group/ cpu.weight: 10000 cpuset.cpus: 1 This can be reproduced by attaching an idle process to a cgroup and moving it to a given cpuset before it wakes up. The issue is evident in many (if not most) container runtimes, and has been reproduced with both crun and runc (and therefore docker and all its "derivatives"), and with both cgroup v1 and v2. Fixes: 3d30544f0212 ("sched/fair: Apply more PELT fixes") Fixes: 039ae8bcf7a5 ("sched/fair: Fix O(nr_cgroups) in the load balancing path") Signed-off-by: Odin Ugedal Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Vincent Guittot Link: https://lkml.kernel.org/r/20210501141950.23622-2-odin@uged.al Signed-off-by: Sasha Levin commit 42ee47c7e3569d9a0e2cb5053c496d97d380472f Author: Quentin Perret Date: Fri Apr 30 15:14:12 2021 +0000 sched: Fix out-of-bound access in uclamp [ Upstream commit 6d2f8909a5fabb73fe2a63918117943986c39b6c ] Util-clamp places tasks in different buckets based on their clamp values for performance reasons. However, the size of buckets is currently computed using a rounding division, which can lead to an off-by-one error in some configurations. For instance, with 20 buckets, the bucket size will be 1024/20=51. A task with a clamp of 1024 will be mapped to bucket id 1024/51=20. Sadly, correct indexes are in range [0,19], hence leading to an out of bound memory access. Clamp the bucket id to fix the issue. Fixes: 69842cba9ace ("sched/uclamp: Add CPU's clamp buckets refcounting") Suggested-by: Qais Yousef Signed-off-by: Quentin Perret Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Vincent Guittot Reviewed-by: Dietmar Eggemann Link: https://lkml.kernel.org/r/20210430151412.160913-1-qperret@google.com Signed-off-by: Sasha Levin commit a6bf154e0ae85ee0cbc998f533559c81169f3fb0 Author: Marc Kleine-Budde Date: Wed May 5 13:32:27 2021 +0200 can: m_can: m_can_tx_work_queue(): fix tx_skb race condition [ Upstream commit e04b2cfe61072c7966e1a5fb73dd1feb30c206ed ] The m_can_start_xmit() function checks if the cdev->tx_skb is NULL and returns with NETDEV_TX_BUSY in case tx_sbk is not NULL. There is a race condition in the m_can_tx_work_queue(), where first the skb is send to the driver and then the case tx_sbk is set to NULL. A TX complete IRQ might come in between and wake the queue, which results in tx_skb not being cleared yet. Fixes: f524f829b75a ("can: m_can: Create a m_can platform framework") Tested-by: Torin Cooper-Bennun Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit e1e10a390fd9479209c4d834d916ca5e6d5d396b Author: Frieder Schrempf Date: Wed May 5 09:14:15 2021 +0200 can: mcp251x: fix resume from sleep before interface was brought up [ Upstream commit 03c427147b2d3e503af258711af4fc792b89b0af ] Since 8ce8c0abcba3 the driver queues work via priv->restart_work when resuming after suspend, even when the interface was not previously enabled. This causes a null dereference error as the workqueue is only allocated and initialized in mcp251x_open(). To fix this we move the workqueue init to mcp251x_can_probe() as there is no reason to do it later and repeat it whenever mcp251x_open() is called. Fixes: 8ce8c0abcba3 ("can: mcp251x: only reset hardware as required") Link: https://lore.kernel.org/r/17d5d714-b468-482f-f37a-482e3d6df84e@kontron.de Signed-off-by: Frieder Schrempf Reviewed-by: Andy Shevchenko [mkl: fix error handling in mcp251x_stop()] Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit eb40b2f5144742669a32ccf9a7498256d0420a65 Author: Marc Kleine-Budde Date: Sun May 2 11:34:34 2021 +0200 can: mcp251xfd: mcp251xfd_probe(): add missing can_rx_offload_del() in error path [ Upstream commit 4376ea42db8bfcac2bc3a30bba93917244a8c2d4 ] This patch adds the missing can_rx_offload_del(), that must be called if mcp251xfd_register() fails. Fixes: 55e5b97f003e ("can: mcp25xxfd: add driver for Microchip MCP25xxFD SPI CAN") Link: https://lore.kernel.org/r/20210504091838.1109047-1-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 15f8f96ec7fc35024d4e03296e4d838fcea33d83 Author: Dan Carpenter Date: Mon May 3 17:49:09 2021 +0300 can: mcp251xfd: mcp251xfd_probe(): fix an error pointer dereference in probe [ Upstream commit 4cc7faa406975b460aa674606291dea197c1210c ] When we converted this code to use dev_err_probe() we accidentally removed a return. It means that if devm_clk_get() it will lead to an Oops when we call clk_get_rate() on the next line. Fixes: cf8ee6de2543 ("can: mcp251xfd: mcp251xfd_probe(): use dev_err_probe() to simplify error handling") Link: https://lore.kernel.org/r/YJANZf13Qxd5Mhr1@mwanda Signed-off-by: Dan Carpenter Reviewed-by: Manivannan Sadhasivam Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit dd3bebf515f336214a91994348a2b86b9a1d3d7f Author: Pablo Neira Ayuso Date: Wed May 5 23:06:43 2021 +0200 netfilter: nftables: Fix a memleak from userdata error path in new objects [ Upstream commit 85dfd816fabfc16e71786eda0a33a7046688b5b0 ] Release object name if userdata allocation fails. Fixes: b131c96496b3 ("netfilter: nf_tables: add userdata support for nft_object") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 2bf8be1ebc940831e6ed6b101cdb4f9e40e0f654 Author: Pablo Neira Ayuso Date: Wed May 5 22:25:24 2021 +0200 netfilter: nfnetlink_osf: Fix a missing skb_header_pointer() NULL check [ Upstream commit 5e024c325406470d1165a09c6feaf8ec897936be ] Do not assume that the tcph->doff field is correct when parsing for TCP options, skb_header_pointer() might fail to fetch these bits. Fixes: 11eeef41d5f6 ("netfilter: passive OS fingerprint xtables match") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 0687acc371ebabceff821faf1408011c50f12661 Author: Cong Wang Date: Wed May 5 12:40:48 2021 -0700 smc: disallow TCP_ULP in smc_setsockopt() [ Upstream commit 8621436671f3a4bba5db57482e1ee604708bf1eb ] syzbot is able to setup kTLS on an SMC socket which coincidentally uses sk_user_data too. Later, kTLS treats it as psock so triggers a refcnt warning. The root cause is that smc_setsockopt() simply calls TCP setsockopt() which includes TCP_ULP. I do not think it makes sense to setup kTLS on top of SMC sockets, so we should just disallow this setup. It is hard to find a commit to blame, but we can apply this patch since the beginning of TCP_ULP. Reported-and-tested-by: syzbot+b54a1ce86ba4a623b7f0@syzkaller.appspotmail.com Fixes: 734942cc4ea6 ("tcp: ULP infrastructure") Cc: John Fastabend Signed-off-by: Karsten Graul Signed-off-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 45a1a92d0a00401aae1635b0250a745b47679e6e Author: Maciej Żenczykowski Date: Wed May 5 09:58:31 2021 -0700 net: fix nla_strcmp to handle more then one trailing null character [ Upstream commit 2c16db6c92b0ee4aa61e88366df82169e83c3f7e ] Android userspace has been using TCA_KIND with a char[IFNAMESIZ] many-null-terminated buffer containing the string 'bpf'. This works on 4.19 and ceases to work on 5.10. I'm not entirely sure what fixes tag to use, but I think the issue was likely introduced in the below mentioned 5.4 commit. Reported-by: Nucca Chen Cc: Cong Wang Cc: David Ahern Cc: David S. Miller Cc: Jakub Kicinski Cc: Jamal Hadi Salim Cc: Jiri Pirko Cc: Jiri Pirko Fixes: 62794fc4fbf5 ("net_sched: add max len check for TCA_KIND") Change-Id: I66dc281f165a2858fc29a44869a270a2d698a82b Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 2af12426dff84e865dfd321d86b1f0dc06a83242 Author: Fernando Fernandez Mancera Date: Wed May 5 00:47:14 2021 +0200 ethtool: fix missing NLM_F_MULTI flag when dumping [ Upstream commit cf754ae331be7cc192b951756a1dd031e9ed978a ] When dumping the ethtool information from all the interfaces, the netlink reply should contain the NLM_F_MULTI flag. This flag allows userspace tools to identify that multiple messages are expected. Link: https://bugzilla.redhat.com/1953847 Fixes: 365f9ae4ee36 ("ethtool: fix genlmsg_put() failure handling in ethnl_default_dumpit()") Signed-off-by: Fernando Fernandez Mancera Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7ad70fa661355ef60e1fe46297843db7c679b1e5 Author: Marco Elver Date: Tue May 4 18:40:21 2021 -0700 kfence: await for allocation using wait_event [ Upstream commit 407f1d8c1b5f3ec66a6a3eb835d3b81c76440f4e ] Patch series "kfence: optimize timer scheduling", v2. We have observed that mostly-idle systems with KFENCE enabled wake up otherwise idle CPUs, preventing such to enter a lower power state. Debugging revealed that KFENCE spends too much active time in toggle_allocation_gate(). While the first version of KFENCE was using all the right bits to be scheduling optimal, and thus power efficient, by simply using wait_event() + wake_up(), that code was unfortunately removed. As KFENCE was exposed to various different configs and tests, the scheduling optimal code slowly disappeared. First because of hung task warnings, and finally because of deadlocks when an allocation is made by timer code with debug objects enabled. Clearly, the "fixes" were not too friendly for devices that want to be power efficient. Therefore, let's try a little harder to fix the hung task and deadlock problems that we have with wait_event() + wake_up(), while remaining as scheduling friendly and power efficient as possible. Crucially, we need to defer the wake_up() to an irq_work, avoiding any potential for deadlock. The result with this series is that on the devices where we observed a power regression, power usage returns back to baseline levels. This patch (of 3): On mostly-idle systems, we have observed that toggle_allocation_gate() is a cause of frequent wake-ups, preventing an otherwise idle CPU to go into a lower power state. A late change in KFENCE's development, due to a potential deadlock [1], required changing the scheduling-friendly wait_event_timeout() and wake_up() to an open-coded wait-loop using schedule_timeout(). [1] https://lkml.kernel.org/r/000000000000c0645805b7f982e4@google.com To avoid unnecessary wake-ups, switch to using wait_event_timeout(). Unfortunately, we still cannot use a version with direct wake_up() in __kfence_alloc() due to the same potential for deadlock as in [1]. Instead, add a level of indirection via an irq_work that is scheduled if we determine that the kfence_timer requires a wake_up(). Link: https://lkml.kernel.org/r/20210421105132.3965998-1-elver@google.com Link: https://lkml.kernel.org/r/20210421105132.3965998-2-elver@google.com Fixes: 0ce20dd84089 ("mm: add Kernel Electric-Fence infrastructure") Signed-off-by: Marco Elver Cc: Alexander Potapenko Cc: Dmitry Vyukov Cc: Jann Horn Cc: Mark Rutland Cc: Hillf Danton Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 36c6110fd85b73f2a886bdbe4d5e5767a7b8bba7 Author: Pavel Tatashin Date: Tue May 4 18:38:49 2021 -0700 mm/gup: check for isolation errors [ Upstream commit 6e7f34ebb8d25d71ce7f4580ba3cbfc10b895580 ] It is still possible that we pin movable CMA pages if there are isolation errors and cma_page_list stays empty when we check again. Check for isolation errors, and return success only when there are no isolation errors, and cma_page_list is empty after checking. Because isolation errors are transient, we retry indefinitely. Link: https://lkml.kernel.org/r/20210215161349.246722-5-pasha.tatashin@soleen.com Fixes: 9a4e9f3b2d73 ("mm: update get_user_pages_longterm to migrate pages allocated from CMA region") Signed-off-by: Pavel Tatashin Reviewed-by: Jason Gunthorpe Cc: Dan Williams Cc: David Hildenbrand Cc: David Rientjes Cc: Ingo Molnar Cc: Ira Weiny Cc: James Morris Cc: Jason Gunthorpe Cc: John Hubbard Cc: Joonsoo Kim Cc: Matthew Wilcox Cc: Mel Gorman Cc: Michal Hocko Cc: Michal Hocko Cc: Mike Kravetz Cc: Oscar Salvador Cc: Peter Zijlstra Cc: Sasha Levin Cc: Steven Rostedt (VMware) Cc: Tyler Hicks Cc: Vlastimil Babka Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 8ee15052ce9e4e48094d30d8a1dd5cf9d690e77b Author: Pavel Tatashin Date: Tue May 4 18:38:46 2021 -0700 mm/gup: return an error on migration failure [ Upstream commit f0f4463837da17a89d965dcbe4e411629dbcf308 ] When migration failure occurs, we still pin pages, which means that we may pin CMA movable pages which should never be the case. Instead return an error without pinning pages when migration failure happens. No need to retry migrating, because migrate_pages() already retries 10 times. Link: https://lkml.kernel.org/r/20210215161349.246722-4-pasha.tatashin@soleen.com Signed-off-by: Pavel Tatashin Reviewed-by: Jason Gunthorpe Cc: Dan Williams Cc: David Hildenbrand Cc: David Rientjes Cc: Ingo Molnar Cc: Ira Weiny Cc: James Morris Cc: Jason Gunthorpe Cc: John Hubbard Cc: Joonsoo Kim Cc: Matthew Wilcox Cc: Mel Gorman Cc: Michal Hocko Cc: Michal Hocko Cc: Mike Kravetz Cc: Oscar Salvador Cc: Peter Zijlstra Cc: Sasha Levin Cc: Steven Rostedt (VMware) Cc: Tyler Hicks Cc: Vlastimil Babka Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 97e5135ddcaa751daa2a17cf0c086bfbb7610d6f Author: Pavel Tatashin Date: Tue May 4 18:38:42 2021 -0700 mm/gup: check every subpage of a compound page during isolation [ Upstream commit 83c02c23d0747a7bdcd71f99a538aacec94b146c ] When pages are isolated in check_and_migrate_movable_pages() we skip compound number of pages at a time. However, as Jason noted, it is not necessary correct that pages[i] corresponds to the pages that we skipped. This is because it is possible that the addresses in this range had split_huge_pmd()/split_huge_pud(), and these functions do not update the compound page metadata. The problem can be reproduced if something like this occurs: 1. User faulted huge pages. 2. split_huge_pmd() was called for some reason 3. User has unmapped some sub-pages in the range 4. User tries to longterm pin the addresses. The resulting pages[i] might end-up having pages which are not compound size page aligned. Link: https://lkml.kernel.org/r/20210215161349.246722-3-pasha.tatashin@soleen.com Fixes: aa712399c1e8 ("mm/gup: speed up check_and_migrate_cma_pages() on huge page") Signed-off-by: Pavel Tatashin Reported-by: Jason Gunthorpe Reviewed-by: Jason Gunthorpe Cc: Dan Williams Cc: David Hildenbrand Cc: David Rientjes Cc: Ingo Molnar Cc: Ira Weiny Cc: James Morris Cc: Jason Gunthorpe Cc: John Hubbard Cc: Joonsoo Kim Cc: Matthew Wilcox Cc: Mel Gorman Cc: Michal Hocko Cc: Michal Hocko Cc: Mike Kravetz Cc: Oscar Salvador Cc: Peter Zijlstra Cc: Sasha Levin Cc: Steven Rostedt (VMware) Cc: Tyler Hicks Cc: Vlastimil Babka Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit d2348b6e465a4567b195cb78f54f5bab312e6bb7 Author: Miaohe Lin Date: Tue May 4 18:37:45 2021 -0700 ksm: fix potential missing rmap_item for stable_node [ Upstream commit c89a384e2551c692a9fe60d093fd7080f50afc51 ] When removing rmap_item from stable tree, STABLE_FLAG of rmap_item is cleared with head reserved. So the following scenario might happen: For ksm page with rmap_item1: cmp_and_merge_page stable_node->head = &migrate_nodes; remove_rmap_item_from_tree, but head still equal to stable_node; try_to_merge_with_ksm_page failed; return; For the same ksm page with rmap_item2, stable node migration succeed this time. The stable_node->head does not equal to migrate_nodes now. For ksm page with rmap_item1 again: cmp_and_merge_page stable_node->head != &migrate_nodes && rmap_item->head == stable_node return; We would miss the rmap_item for stable_node and might result in failed rmap_walk_ksm(). Fix this by set rmap_item->head to NULL when rmap_item is removed from stable tree. Link: https://lkml.kernel.org/r/20210330140228.45635-5-linmiaohe@huawei.com Fixes: 4146d2d673e8 ("ksm: make !merge_across_nodes migration safe") Signed-off-by: Miaohe Lin Cc: Hugh Dickins Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit f1183744e8d0dab17d73913804af8158fa0d4d56 Author: Miaohe Lin Date: Tue May 4 18:37:10 2021 -0700 mm/migrate.c: fix potential indeterminate pte entry in migrate_vma_insert_page() [ Upstream commit 34f5e9b9d1990d286199084efa752530ee3d8297 ] If the zone device page does not belong to un-addressable device memory, the variable entry will be uninitialized and lead to indeterminate pte entry ultimately. Fix this unexpected case and warn about it. Link: https://lkml.kernel.org/r/20210325131524.48181-4-linmiaohe@huawei.com Fixes: df6ad69838fc ("mm/device-public-memory: device memory cache coherent with CPU") Signed-off-by: Miaohe Lin Reviewed-by: David Hildenbrand Cc: Alistair Popple Cc: Jerome Glisse Cc: Rafael Aquini Cc: Yang Shi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit ed98b887d31c2f83db133bcb7b88b46fbb9af845 Author: Miaohe Lin Date: Tue May 4 18:34:38 2021 -0700 mm/hugeltb: handle the error case in hugetlb_fix_reserve_counts() [ Upstream commit da56388c4397878a65b74f7fe97760f5aa7d316b ] A rare out of memory error would prevent removal of the reserve map region for a page. hugetlb_fix_reserve_counts() handles this rare case to avoid dangling with incorrect counts. Unfortunately, hugepage_subpool_get_pages and hugetlb_acct_memory could possibly fail too. We should correctly handle these cases. Link: https://lkml.kernel.org/r/20210410072348.20437-5-linmiaohe@huawei.com Fixes: b5cec28d36f5 ("hugetlbfs: truncate_hugepages() takes a range of pages") Signed-off-by: Miaohe Lin Cc: Feilong Lin Cc: Mike Kravetz Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 22349c15b5a85abe9e9c507f0c3db016f4364525 Author: Miaohe Lin Date: Tue May 4 18:33:46 2021 -0700 khugepaged: fix wrong result value for trace_mm_collapse_huge_page_isolate() [ Upstream commit 74e579bf231a337ab3786d59e64bc94f45ca7b3f ] In writable and !referenced case, the result value should be SCAN_LACK_REFERENCED_PAGE for trace_mm_collapse_huge_page_isolate() instead of default 0 (SCAN_FAIL) here. Link: https://lkml.kernel.org/r/20210306032947.35921-5-linmiaohe@huawei.com Fixes: 7d2eba0557c1 ("mm: add tracepoint for scanning pages") Signed-off-by: Miaohe Lin Acked-by: Kirill A. Shutemov Cc: Dan Carpenter Cc: Ebru Akagunduz Cc: Mike Kravetz Cc: Rik van Riel Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit d8d52005f57bbb4a4ec02f647e2555d327135c68 Author: Sasha Levin Date: Mon May 10 12:14:31 2021 -0400 arm64: entry: always set GIC_PRIO_PSR_I_SET during entry [ Upstream commit 4d6a38da8e79e94cbd1344aa90876f0f805db705 ] Zenghui reports that booting a kernel with "irqchip.gicv3_pseudo_nmi=1" on the command line hits a warning during kernel entry, due to the way we manipulate the PMR. Early in the entry sequence, we call lockdep_hardirqs_off() to inform lockdep that interrupts have been masked (as the HW sets DAIF wqhen entering an exception). Architecturally PMR_EL1 is not affected by exception entry, and we don't set GIC_PRIO_PSR_I_SET in the PMR early in the exception entry sequence, so early in exception entry the PMR can indicate that interrupts are unmasked even though they are masked by DAIF. If DEBUG_LOCKDEP is selected, lockdep_hardirqs_off() will check that interrupts are masked, before we set GIC_PRIO_PSR_I_SET in any of the exception entry paths, and hence lockdep_hardirqs_off() will WARN() that something is amiss. We can avoid this by consistently setting GIC_PRIO_PSR_I_SET during exception entry so that kernel code sees a consistent environment. We must also update local_daif_inherit() to undo this, as currently only touches DAIF. For other paths, local_daif_restore() will update both DAIF and the PMR. With this done, we can remove the existing special cases which set this later in the entry code. We always use (GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET) for consistency with local_daif_save(), as this will warn if it ever encounters (GIC_PRIO_IRQOFF | GIC_PRIO_PSR_I_SET), and never sets this itself. This matches the gic_prio_kentry_setup that we have to retain for ret_to_user. The original splat from Zenghui's report was: | DEBUG_LOCKS_WARN_ON(!irqs_disabled()) | WARNING: CPU: 3 PID: 125 at kernel/locking/lockdep.c:4258 lockdep_hardirqs_off+0xd4/0xe8 | Modules linked in: | CPU: 3 PID: 125 Comm: modprobe Tainted: G W 5.12.0-rc8+ #463 | Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 | pstate: 604003c5 (nZCv DAIF +PAN -UAO -TCO BTYPE=--) | pc : lockdep_hardirqs_off+0xd4/0xe8 | lr : lockdep_hardirqs_off+0xd4/0xe8 | sp : ffff80002a39bad0 | pmr_save: 000000e0 | x29: ffff80002a39bad0 x28: ffff0000de214bc0 | x27: ffff0000de1c0400 x26: 000000000049b328 | x25: 0000000000406f30 x24: ffff0000de1c00a0 | x23: 0000000020400005 x22: ffff8000105f747c | x21: 0000000096000044 x20: 0000000000498ef9 | x19: ffff80002a39bc88 x18: ffffffffffffffff | x17: 0000000000000000 x16: ffff800011c61eb0 | x15: ffff800011700a88 x14: 0720072007200720 | x13: 0720072007200720 x12: 0720072007200720 | x11: 0720072007200720 x10: 0720072007200720 | x9 : ffff80002a39bad0 x8 : ffff80002a39bad0 | x7 : ffff8000119f0800 x6 : c0000000ffff7fff | x5 : ffff8000119f07a8 x4 : 0000000000000001 | x3 : 9bcdab23f2432800 x2 : ffff800011730538 | x1 : 9bcdab23f2432800 x0 : 0000000000000000 | Call trace: | lockdep_hardirqs_off+0xd4/0xe8 | enter_from_kernel_mode.isra.5+0x7c/0xa8 | el1_abort+0x24/0x100 | el1_sync_handler+0x80/0xd0 | el1_sync+0x6c/0x100 | __arch_clear_user+0xc/0x90 | load_elf_binary+0x9fc/0x1450 | bprm_execve+0x404/0x880 | kernel_execve+0x180/0x188 | call_usermodehelper_exec_async+0xdc/0x158 | ret_from_fork+0x10/0x18 Fixes: 23529049c684 ("arm64: entry: fix non-NMI user<->kernel transitions") Fixes: 7cd1ea1010ac ("arm64: entry: fix non-NMI kernel<->kernel transitions") Fixes: f0cd5ac1e4c5 ("arm64: entry: fix NMI {user, kernel}->kernel transitions") Fixes: 2a9b3e6ac69a ("arm64: entry: fix EL1 debug transitions") Link: https://lore.kernel.org/r/f4012761-026f-4e51-3a0c-7524e434e8b3@huawei.com Signed-off-by: Mark Rutland Reported-by: Zenghui Yu Cc: Marc Zyngier Cc: Will Deacon Acked-by: Marc Zyngier Link: https://lore.kernel.org/r/20210428111555.50880-1-mark.rutland@arm.com Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit b520ea4ea613b5fb85f9eba586ebf51304c9a47a Author: Marc Zyngier Date: Mon Mar 15 11:56:27 2021 +0000 arm64: entry: factor irq triage logic into macros [ Upstream commit 9eb563cdabe1d583c262042d5d44cc256f644543 ] In subsequent patches we'll allow an FIQ handler to be registered, and FIQ exceptions will need to be triaged very similarly to IRQ exceptions. So that we can reuse the existing logic, this patch factors the IRQ triage logic out into macros that can be reused for FIQ. The macros are named to follow the elX_foo_handler scheme used by the C exception handlers. For consistency with other top-level exception handlers, the kernel_entry/kernel_exit logic is not moved into the macros. As FIQ will use a different C handler, this handler name is provided as an argument to the macros. There should be no functional change as a result of this patch. Signed-off-by: Marc Zyngier [Mark: rework macros, commit message, rebase before DAIF rework] Signed-off-by: Mark Rutland Tested-by: Hector Martin Cc: James Morse Cc: Thomas Gleixner Cc: Will Deacon Acked-by: Will Deacon Link: https://lore.kernel.org/r/20210315115629.57191-5-mark.rutland@arm.com Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit b1652314ac62730b67fd6416c49b2d1d0b20e1d8 Author: Kees Cook Date: Sun May 2 22:06:08 2021 -0700 drm/radeon: Avoid power table parsing memory leaks [ Upstream commit c69f27137a38d24301a6b659454a91ad85dff4aa ] Avoid leaving a hanging pre-allocated clock_info if last mode is invalid, and avoid heap corruption if no valid modes are found. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=211537 Fixes: 6991b8f2a319 ("drm/radeon/kms: fix segfault in pm rework") Signed-off-by: Kees Cook Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 33b3d1dc73cec9ac6ddffe56b359e8504e5aaaf9 Author: Kees Cook Date: Sun May 2 22:06:07 2021 -0700 drm/radeon: Fix off-by-one power_state index heap overwrite [ Upstream commit 5bbf219328849e83878bddb7c226d8d42e84affc ] An out of bounds write happens when setting the default power state. KASAN sees this as: [drm] radeon: 512M of GTT memory ready. [drm] GART: num cpu pages 131072, num gpu pages 131072 ================================================================== BUG: KASAN: slab-out-of-bounds in radeon_atombios_parse_power_table_1_3+0x1837/0x1998 [radeon] Write of size 4 at addr ffff88810178d858 by task systemd-udevd/157 CPU: 0 PID: 157 Comm: systemd-udevd Not tainted 5.12.0-E620 #50 Hardware name: eMachines eMachines E620 /Nile , BIOS V1.03 09/30/2008 Call Trace: dump_stack+0xa5/0xe6 print_address_description.constprop.0+0x18/0x239 kasan_report+0x170/0x1a8 radeon_atombios_parse_power_table_1_3+0x1837/0x1998 [radeon] radeon_atombios_get_power_modes+0x144/0x1888 [radeon] radeon_pm_init+0x1019/0x1904 [radeon] rs690_init+0x76e/0x84a [radeon] radeon_device_init+0x1c1a/0x21e5 [radeon] radeon_driver_load_kms+0xf5/0x30b [radeon] drm_dev_register+0x255/0x4a0 [drm] radeon_pci_probe+0x246/0x2f6 [radeon] pci_device_probe+0x1aa/0x294 really_probe+0x30e/0x850 driver_probe_device+0xe6/0x135 device_driver_attach+0xc1/0xf8 __driver_attach+0x13f/0x146 bus_for_each_dev+0xfa/0x146 bus_add_driver+0x2b3/0x447 driver_register+0x242/0x2c1 do_one_initcall+0x149/0x2fd do_init_module+0x1ae/0x573 load_module+0x4dee/0x5cca __do_sys_finit_module+0xf1/0x140 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae Without KASAN, this will manifest later when the kernel attempts to allocate memory that was stomped, since it collides with the inline slab freelist pointer: invalid opcode: 0000 [#1] SMP NOPTI CPU: 0 PID: 781 Comm: openrc-run.sh Tainted: G W 5.10.12-gentoo-E620 #2 Hardware name: eMachines eMachines E620 /Nile , BIOS V1.03 09/30/2008 RIP: 0010:kfree+0x115/0x230 Code: 89 c5 e8 75 ea ff ff 48 8b 00 0f ba e0 09 72 63 e8 1f f4 ff ff 41 89 c4 48 8b 45 00 0f ba e0 10 72 0a 48 8b 45 08 a8 01 75 02 <0f> 0b 44 89 e1 48 c7 c2 00 f0 ff ff be 06 00 00 00 48 d3 e2 48 c7 RSP: 0018:ffffb42f40267e10 EFLAGS: 00010246 RAX: ffffd61280ee8d88 RBX: 0000000000000004 RCX: 000000008010000d RDX: 4000000000000000 RSI: ffffffffba1360b0 RDI: ffffd61280ee8d80 RBP: ffffd61280ee8d80 R08: ffffffffb91bebdf R09: 0000000000000000 R10: ffff8fe2c1047ac8 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000100 FS: 00007fe80eff6b68(0000) GS:ffff8fe339c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe80eec7bc0 CR3: 0000000038012000 CR4: 00000000000006f0 Call Trace: __free_fdtable+0x16/0x1f put_files_struct+0x81/0x9b do_exit+0x433/0x94d do_group_exit+0xa6/0xa6 __x64_sys_exit_group+0xf/0xf do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7fe80ef64bea Code: Unable to access opcode bytes at RIP 0x7fe80ef64bc0. RSP: 002b:00007ffdb1c47528 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fe80ef64bea RDX: 00007fe80ef64f60 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 00007fe80ee2c620 R11: 0000000000000246 R12: 00007fe80eff41e0 R13: 00000000ffffffff R14: 0000000000000024 R15: 00007fe80edf9cd0 Modules linked in: radeon(+) ath5k(+) snd_hda_codec_realtek ... Use a valid power_state index when initializing the "flags" and "misc" and "misc2" fields. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=211537 Reported-by: Erhard F. Fixes: a48b9b4edb8b ("drm/radeon/kms/pm: add asic specific callbacks for getting power state (v2)") Fixes: 79daedc94281 ("drm/radeon/kms: minor pm cleanups") Signed-off-by: Kees Cook Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit beea32fb00c3abc6c8bda89d863e7e757f76d510 Author: Ramesh Babu B Date: Tue May 4 21:12:41 2021 +0530 net: stmmac: Clear receive all(RA) bit when promiscuous mode is off [ Upstream commit 4c7a94286ef7ac7301d633f17519fb1bb89d7550 ] In promiscuous mode Receive All bit is set in GMAC packet filter register, but outside promiscuous mode Receive All bit is not cleared, which resulted in all network packets are received when toggle (ON/OFF) the promiscuous mode. Fixes: e0f9956a3862 ("net: stmmac: Add option for VLAN filter fail queue enable") Signed-off-by: Ramesh Babu B Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 3a8a866e9372182e5101b6b0513382b2d8aecb84 Author: Sandipan Das Date: Sat May 1 21:32:54 2021 +0530 powerpc/powernv/memtrace: Fix dcache flushing [ Upstream commit b910fcbada9721c21f1d59ab59e07e8e354c23cc ] Trace memory is cleared and the corresponding dcache lines are flushed after allocation. However, this should not be done using the PFN. This adds the missing conversion to virtual address. Fixes: 2ac02e5ecec0 ("powerpc/mm: Remove dcache flush from memory remove.") Signed-off-by: Sandipan Das Reviewed-by: Aneesh Kumar K.V Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210501160254.1179831-1-sandipan@linux.ibm.com Signed-off-by: Sasha Levin commit 271976d0ebf89ed50f41b288385d4f985535e6d3 Author: Xuan Zhuo Date: Wed Apr 28 17:44:24 2021 +0800 xsk: Fix for xp_aligned_validate_desc() when len == chunk_size [ Upstream commit ac31565c21937eee9117e43c9cd34f557f6f1cb8 ] When desc->len is equal to chunk_size, it is legal. But when the xp_aligned_validate_desc() got chunk_end from desc->addr + desc->len pointing to the next chunk during the check, it caused the check to fail. This problem was first introduced in bbff2f321a86 ("xsk: new descriptor addressing scheme"). Later in 2b43470add8c ("xsk: Introduce AF_XDP buffer allocation API") this piece of code was moved into the new function called xp_aligned_validate_desc(). This function was then moved into xsk_queue.h via 26062b185eee ("xsk: Explicitly inline functions and move definitions"). Fixes: bbff2f321a86 ("xsk: new descriptor addressing scheme") Signed-off-by: Xuan Zhuo Signed-off-by: Daniel Borkmann Acked-by: Magnus Karlsson Link: https://lore.kernel.org/bpf/20210428094424.54435-1-xuanzhuo@linux.alibaba.com Signed-off-by: Sasha Levin commit 21e926b7c9de36cd2e545f220fbb38e1dac8ce81 Author: Pablo Neira Ayuso Date: Fri Apr 30 14:00:13 2021 +0200 netfilter: xt_SECMARK: add new revision to fix structure layout [ Upstream commit c7d13358b6a2f49f81a34aa323a2d0878a0532a2 ] This extension breaks when trying to delete rules, add a new revision to fix this. Fixes: 5e6874cdb8de ("[SECMARK]: Add xtables SECMARK target") Signed-off-by: Phil Sutter Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 0492084fa4c68114ad3dd0e599f85966fc020c21 Author: Xin Long Date: Mon May 3 04:41:20 2021 +0800 sctp: fix a SCTP_MIB_CURRESTAB leak in sctp_sf_do_dupcook_b [ Upstream commit f282df0391267fb2b263da1cc3233aa6fb81defc ] Normally SCTP_MIB_CURRESTAB is always incremented once asoc enter into ESTABLISHED from the state < ESTABLISHED and decremented when the asoc is being deleted. However, in sctp_sf_do_dupcook_b(), the asoc's state can be changed to ESTABLISHED from the state >= ESTABLISHED where it shouldn't increment SCTP_MIB_CURRESTAB. Otherwise, one asoc may increment MIB_CURRESTAB multiple times but only decrement once at the end. I was able to reproduce it by using scapy to do the 4-way shakehands, after that I replayed the COOKIE-ECHO chunk with 'peer_vtag' field changed to different values, and SCTP_MIB_CURRESTAB was incremented multiple times and never went back to 0 even when the asoc was freed. This patch is to fix it by only incrementing SCTP_MIB_CURRESTAB when the state < ESTABLISHED in sctp_sf_do_dupcook_b(). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Marcelo Ricardo Leitner Signed-off-by: Xin Long Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d90529392aaf498dafa95d212295d64b2cea4e24 Author: Lv Yunlong Date: Sun May 2 04:58:18 2021 -0700 ethernet:enic: Fix a use after free bug in enic_hard_start_xmit [ Upstream commit 643001b47adc844ae33510c4bb93c236667008a3 ] In enic_hard_start_xmit, it calls enic_queue_wq_skb(). Inside enic_queue_wq_skb, if some error happens, the skb will be freed by dev_kfree_skb(skb). But the freed skb is still used in skb_tx_timestamp(skb). My patch makes enic_queue_wq_skb() return error and goto spin_unlock() incase of error. The solution is provided by Govind. See https://lkml.org/lkml/2021/4/30/961. Fixes: fb7516d42478e ("enic: add sw timestamp support") Signed-off-by: Lv Yunlong Acked-by: Govindarajulu Varadarajan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7c968f9ca1348f049e5f8a836198f1a6b4f578f7 Author: Jim Quinlan Date: Fri Apr 30 11:21:56 2021 -0400 PCI: brcmstb: Use reset/rearm instead of deassert/assert [ Upstream commit bb610757fcd74558ad94fe19993fd4470208dd02 ] The Broadcom STB PCIe RC uses a reset control "rescal" for certain chips. The "rescal" implements a "pulse reset" so using assert/deassert is wrong for this device. Instead, we use reset/rearm. We need to use rearm so that we can reset it after a suspend/resume cycle; w/o using "rearm", the "rescal" device will only ever fire once. Of course for suspend/resume to work we also need to put the reset/rearm calls in the suspend and resume routines. Fixes: 740d6c3708a9 ("PCI: brcmstb: Add control of rescal reset") Link: https://lore.kernel.org/r/20210430152156.21162-4-jim2101024@gmail.com Signed-off-by: Jim Quinlan Signed-off-by: Bjorn Helgaas Acked-by: Florian Fainelli Signed-off-by: Sasha Levin commit fe55c9d259c4ba852c511179f3e9f261f399c676 Author: Jim Quinlan Date: Fri Apr 30 11:21:55 2021 -0400 ata: ahci_brcm: Fix use of BCM7216 reset controller [ Upstream commit e8d6f9e56187c101b325e8d18f1d4032420d08ff ] This driver may use one of two resets controllers. Keep them in separate variables to keep things simple. The reset controller "rescal" is shared between the AHCI driver and the PCIe driver for the BrcmSTB 7216 chip. Use devm_reset_control_get_optional_shared() to handle this sharing. [bhelgaas: add Jens' ack from v5 posting] Fixes: 272ecd60a636 ("ata: ahci_brcm: BCM7216 reset is self de-asserting") Fixes: c345ec6a50e9 ("ata: ahci_brcm: Support BCM7216 reset controller name") Link: https://lore.kernel.org/r/20210430152156.21162-3-jim2101024@gmail.com Signed-off-by: Jim Quinlan Signed-off-by: Bjorn Helgaas Acked-by: Jens Axboe Acked-by: Florian Fainelli Signed-off-by: Sasha Levin commit b345ba612d4d33d11d1a3dfa901263a56d51ee1e Author: Md Haris Iqbal Date: Wed Apr 28 08:13:58 2021 +0200 block/rnbd-clt: Check the return value of the function rtrs_clt_query [ Upstream commit 1056ad829ec43f9b705b507c2093b05e2088b0b7 ] In case none of the paths are in connected state, the function rtrs_clt_query returns an error. In such a case, error out since the values in the rtrs_attrs structure would be garbage. Fixes: f7a7a5c228d45 ("block/rnbd: client: main functionality") Signed-off-by: Md Haris Iqbal Reviewed-by: Guoqing Jiang Signed-off-by: Jack Wang Signed-off-by: Gioh Kim Link: https://lore.kernel.org/r/20210428061359.206794-4-gi-oh.kim@ionos.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 05a023f98e0d8913da07e37a6501ad754a2251b7 Author: Md Haris Iqbal Date: Wed Apr 28 08:13:56 2021 +0200 block/rnbd-clt: Change queue_depth type in rnbd_clt_session to size_t [ Upstream commit 80d43cbd46155744ee450d2476ee4fcf2917ae9b ] The member queue_depth in the structure rnbd_clt_session is read from the rtrs client side using the function rtrs_clt_query, which in turn is read from the rtrs_clt structure. It should really be of type size_t. Fixes: 90426e89f54db ("block/rnbd: client: private header with client structs and functions") Signed-off-by: Md Haris Iqbal Reviewed-by: Guoqing Jiang Signed-off-by: Gioh Kim Link: https://lore.kernel.org/r/20210428061359.206794-2-gi-oh.kim@ionos.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 117151b0d560c286be000a212d30a9e813e55ed7 Author: Brendan Jackman Date: Thu Apr 29 13:05:10 2021 +0000 libbpf: Fix signed overflow in ringbuf_process_ring [ Upstream commit 2a30f9440640c418bcfbea9b2b344d268b58e0a2 ] One of our benchmarks running in (Google-internal) CI pushes data through the ringbuf faster htan than userspace is able to consume it. In this case it seems we're actually able to get >INT_MAX entries in a single ring_buffer__consume() call. ASAN detected that cnt overflows in this case. Fix by using 64-bit counter internally and then capping the result to INT_MAX before converting to the int return type. Do the same for the ring_buffer__poll(). Fixes: bf99c936f947 (libbpf: Add BPF ring buffer support) Signed-off-by: Brendan Jackman Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20210429130510.1621665-1-jackmanb@google.com Signed-off-by: Sasha Levin commit 36e63f39d7962ce24ceb923936482ed0a2b866fb Author: Baptiste Lepers Date: Sat May 1 14:10:51 2021 +1000 sunrpc: Fix misplaced barrier in call_decode [ Upstream commit f8f7e0fb22b2e75be55f2f0c13e229e75b0eac07 ] Fix a misplaced barrier in call_decode. The struct rpc_rqst is modified as follows by xprt_complete_rqst: req->rq_private_buf.len = copied; /* Ensure all writes are done before we update */ /* req->rq_reply_bytes_recvd */ smp_wmb(); req->rq_reply_bytes_recvd = copied; And currently read as follows by call_decode: smp_rmb(); // misplaced if (!req->rq_reply_bytes_recvd) goto out; req->rq_rcv_buf.len = req->rq_private_buf.len; This patch places the smp_rmb after the if to ensure that rq_reply_bytes_recvd and rq_private_buf.len are read in order. Fixes: 9ba828861c56a ("SUNRPC: Don't try to parse incomplete RPC messages") Signed-off-by: Baptiste Lepers Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 8eda58d1e939ff76c22578569315e4243e170cd3 Author: Anup Patel Date: Thu Apr 15 14:25:22 2021 +0530 RISC-V: Fix error code returned by riscv_hartid_to_cpuid() [ Upstream commit 533b4f3a789d49574e7ae0f6ececed153f651f97 ] We should return a negative error code upon failure in riscv_hartid_to_cpuid() instead of NR_CPUS. This is also aligned with all uses of riscv_hartid_to_cpuid() which expect negative error code upon failure. Fixes: 6825c7a80f18 ("RISC-V: Add logical CPU indexing for RISC-V") Fixes: f99fb607fb2b ("RISC-V: Use Linux logical CPU number instead of hartid") Signed-off-by: Anup Patel Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit 0bfd913c2121b3d553bfd52810fe6061d542d625 Author: Xin Long Date: Sat May 1 04:02:58 2021 +0800 sctp: do asoc update earlier in sctp_sf_do_dupcook_a [ Upstream commit 35b4f24415c854cd718ccdf38dbea6297f010aae ] There's a panic that occurs in a few of envs, the call trace is as below: [] general protection fault, ... 0x29acd70f1000a: 0000 [#1] SMP PTI [] RIP: 0010:sctp_ulpevent_notify_peer_addr_change+0x4b/0x1fa [sctp] [] sctp_assoc_control_transport+0x1b9/0x210 [sctp] [] sctp_do_8_2_transport_strike.isra.16+0x15c/0x220 [sctp] [] sctp_cmd_interpreter.isra.21+0x1231/0x1a10 [sctp] [] sctp_do_sm+0xc3/0x2a0 [sctp] [] sctp_generate_timeout_event+0x81/0xf0 [sctp] This is caused by a transport use-after-free issue. When processing a duplicate COOKIE-ECHO chunk in sctp_sf_do_dupcook_a(), both COOKIE-ACK and SHUTDOWN chunks are allocated with the transort from the new asoc. However, later in the sideeffect machine, the old asoc is used to send them out and old asoc's shutdown_last_sent_to is set to the transport that SHUTDOWN chunk attached to in sctp_cmd_setup_t2(), which actually belongs to the new asoc. After the new_asoc is freed and the old asoc T2 timeout, the old asoc's shutdown_last_sent_to that is already freed would be accessed in sctp_sf_t2_timer_expire(). Thanks Alexander and Jere for helping dig into this issue. To fix it, this patch is to do the asoc update first, then allocate the COOKIE-ACK and SHUTDOWN chunks with the 'updated' old asoc. This would make more sense, as a chunk from an asoc shouldn't be sent out with another asoc. We had fixed quite a few issues caused by this. Fixes: 145cb2f7177d ("sctp: Fix bundling of SHUTDOWN with COOKIE-ACK") Reported-by: Alexander Sverdlin Reported-by: syzbot+bbe538efd1046586f587@syzkaller.appspotmail.com Reported-by: Michal Tesar Signed-off-by: Xin Long Acked-by: Marcelo Ricardo Leitner Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e4e9d03b9841784836c919e97e9d3c2622156a1a Author: Yufeng Mo Date: Fri Apr 30 17:06:22 2021 +0800 net: hns3: disable phy loopback setting in hclge_mac_start_phy [ Upstream commit 472497d0bdae890a896013332a0b673f9acdf2bf ] If selftest and reset are performed at the same time, the phy loopback setting may be still in enable state after the reset, and device cannot link up. So fix this issue by disabling phy loopback before phy_start(). Fixes: 256727da7395 ("net: hns3: Add MDIO support to HNS3 Ethernet driver for hip08 SoC") Signed-off-by: Yufeng Mo Signed-off-by: Huazhong Tan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8dd424cd4a561108ea50132325eef835428ec1b3 Author: Peng Li Date: Fri Apr 30 17:06:20 2021 +0800 net: hns3: use netif_tx_disable to stop the transmit queue [ Upstream commit b416e872be06fdace3c36cf5210130509d0f0e72 ] Currently, netif_tx_stop_all_queues() is used to ensure that the xmit is not running, but for the concurrent case it will not take effect, since netif_tx_stop_all_queues() just sets a flag without locking to indicate that the xmit queue(s) should not be run. So use netif_tx_disable() to replace netif_tx_stop_all_queues(), it takes the xmit queue lock while marking the queue stopped. Fixes: 76ad4f0ee747 ("net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC") Signed-off-by: Peng Li Signed-off-by: Huazhong Tan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 449a9789f7352af8b11b6ada0a15093ec1fb368d Author: Hao Chen Date: Fri Apr 30 17:06:19 2021 +0800 net: hns3: fix for vxlan gpe tx checksum bug [ Upstream commit 905416f18fe74bdd4de91bf94ef5a790a36e4b99 ] When skb->ip_summed is CHECKSUM_PARTIAL, for non-tunnel udp packet, which has a dest port as the IANA assigned, the hardware is expected to do the checksum offload, but the hardware whose version is below V3 will not do the checksum offload when udp dest port is 4790. So fixes it by doing the checksum in software for this case. Fixes: 76ad4f0ee747 ("net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC") Signed-off-by: Hao Chen Signed-off-by: Huazhong Tan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 57464cecdf77b481bdec0096917db00347a4ba0c Author: Mark Rutland Date: Thu Apr 29 11:20:04 2021 +0100 arm64: stacktrace: restore terminal records [ Upstream commit 8533d5bfad41e74b7dd80d292fd484913cdfb374 ] We removed the terminal frame records in commit: 6106e1112cc69a36 ("arm64: remove EL0 exception frame record") ... on the assumption that as we no longer used them to find the pt_regs at exception boundaries, they were no longer necessary. However, Leo reports that as an unintended side-effect, this causes traces which cross secondary_start_kernel to terminate one entry too late, with a spurious "0" entry. There are a few ways we could sovle this, but as we're planning to use terminal records for RELIABLE_STACKTRACE, let's revert the logic change for now, keeping the update comments and accounting for the changes in commit: 3c02600144bdb0a1 ("arm64: stacktrace: Report when we reach the end of the stack") This is effectively a partial revert of commit: 6106e1112cc69a36 ("arm64: remove EL0 exception frame record") Signed-off-by: Mark Rutland Fixes: 6106e1112cc6 ("arm64: remove EL0 exception frame record") Reported-by: Leo Yan Tested-by: Leo Yan Cc: Will Deacon Cc: Mark Brown Cc: "Madhavan T. Venkataraman" Link: https://lore.kernel.org/r/20210429104813.GA33550@C02TD0UTHF1T.local Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit f3309b93c066c73797a4f3de57f5d176d822936a Author: Jian Shen Date: Thu Apr 29 16:34:52 2021 +0800 net: hns3: add check for HNS3_NIC_STATE_INITED in hns3_reset_notify_up_enet() [ Upstream commit b4047aac4ec1066bab6c71950623746d7bcf7154 ] In some cases, the device is not initialized because reset failed. If another task calls hns3_reset_notify_up_enet() before reset retry, it will cause an error since uninitialized pointer access. So add check for HNS3_NIC_STATE_INITED before calling hns3_nic_net_open() in hns3_reset_notify_up_enet(). Fixes: bb6b94a896d4 ("net: hns3: Add reset interface implementation in client") Signed-off-by: Jian Shen Signed-off-by: Huazhong Tan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a81a61e3843a6984f03727c8c4a8c13f6049fcc7 Author: Yufeng Mo Date: Thu Apr 29 16:34:51 2021 +0800 net: hns3: initialize the message content in hclge_get_link_mode() [ Upstream commit 568a54bdf70b143f3e0befa298e22ad469ffc732 ] The message sent to VF should be initialized, otherwise random value of some contents may cause improper processing by the target. So add a initialization to message in hclge_get_link_mode(). Fixes: 9194d18b0577 ("net: hns3: fix the problem that the supported port is empty") Signed-off-by: Yufeng Mo Signed-off-by: Huazhong Tan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4c2b7a0e6dab0434b8f9e6f5a0123220fd7cc786 Author: Yufeng Mo Date: Thu Apr 29 16:34:50 2021 +0800 net: hns3: fix incorrect configuration for igu_egu_hw_err [ Upstream commit 2867298dd49ee84214b8721521dc7a5a6382520c ] According to the UM, the type and enable status of igu_egu_hw_err should be configured separately. Currently, the type field is incorrect when disable this error. So fix it by configuring these two fields separately. Fixes: bf1faf9415dd ("net: hns3: Add enable and process hw errors from IGU, EGU and NCSI") Signed-off-by: Yufeng Mo Signed-off-by: Huazhong Tan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b5fdbaf6d3278388b4dd9f3545c109105ad283db Author: Nobuhiro Iwamatsu Date: Tue Apr 20 11:39:17 2021 +0900 rtc: ds1307: Fix wday settings for rx8130 [ Upstream commit 204756f016726a380bafe619438ed979088bd04a ] rx8130 wday specifies the bit position, not BCD. Fixes: ee0981be7704 ("rtc: ds1307: Add support for Epson RX8130CE") Signed-off-by: Nobuhiro Iwamatsu Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20210420023917.1949066-1-nobuhiro1.iwamatsu@toshiba.co.jp Signed-off-by: Sasha Levin commit 5b86538ebcce09b55fcf1a3b5764dc7795df38a0 Author: Can Guo Date: Sun Apr 25 20:48:40 2021 -0700 scsi: ufs: core: Narrow down fast path in system suspend path [ Upstream commit ce4f62f9dd8cf43ac044045ed598a0b80ef33890 ] If spm_lvl is set to 0 or 1, when system suspend kicks start and HBA is runtime active, system suspend may just bail without doing anything (the fast path), leaving other contexts still running, e.g., clock gating and clock scaling. When system resume kicks start, concurrency can happen between ufshcd_resume() and these contexts, leading to various stability issues. Add a check against HBA's runtime state and allowing fast path only if HBA is runtime suspended, otherwise let system suspend go ahead call ufshcd_suspend(). This will guarantee that these contexts are stopped by either runtime suspend or system suspend. Link: https://lore.kernel.org/r/1619408921-30426-4-git-send-email-cang@codeaurora.org Fixes: 0b257734344a ("scsi: ufs: optimize system suspend handling") Reviewed-by: Daejun Park Signed-off-by: Can Guo Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 7d129abdd95f01454a64df9ae08e44272ea8e5ee Author: Can Guo Date: Sun Apr 25 20:48:39 2021 -0700 scsi: ufs: core: Cancel rpm_dev_flush_recheck_work during system suspend [ Upstream commit 637822e63b79ee8a729f7ba2645a26cf5a524ee4 ] During ufs system suspend, leaving rpm_dev_flush_recheck_work running or pending is risky because concurrency may happen between system suspend/resume and runtime resume routine. Fix this by cancelling rpm_dev_flush_recheck_work synchronously during system suspend. Link: https://lore.kernel.org/r/1619408921-30426-3-git-send-email-cang@codeaurora.org Fixes: 51dd905bd2f6 ("scsi: ufs: Fix WriteBooster flush during runtime suspend") Reviewed-by: Daejun Park Signed-off-by: Can Guo Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 31a585964e33ac9ed0610ed3dd99733c81118851 Author: Can Guo Date: Sun Apr 25 20:48:38 2021 -0700 scsi: ufs: core: Do not put UFS power into LPM if link is broken [ Upstream commit 23043dd87b153d02eaf676e752d32429be5e5126 ] During resume, if link is broken due to AH8 failure, make sure ufshcd_resume() does not put UFS power back into LPM. Link: https://lore.kernel.org/r/1619408921-30426-2-git-send-email-cang@codeaurora.org Fixes: 4db7a2360597 ("scsi: ufs: Fix concurrency of error handler and other error recovery paths") Reviewed-by: Daejun Park Signed-off-by: Can Guo Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 50c6b018a0fa418fa558a8abd41c6c4b16997f45 Author: Anastasia Kovaleva Date: Thu Apr 22 18:34:14 2021 +0300 scsi: qla2xxx: Prevent PRLI in target mode [ Upstream commit fcb16d9a8ecf1e9bfced0fc654ea4e2caa7517f4 ] In a case when the initiator in P2P mode by some circumstances does not send PRLI, the target, in a case when the target port's WWPN is less than initiator's, changes the discovery state in DSC_GNL. When gnl completes it sends PRLI to the initiator. Usually the initiator in P2P mode always sends PRLI. We caught this issue on Linux stable v5.4.6 https://www.spinics.net/lists/stable/msg458515.html. Fix this particular corner case in the behaviour of the P2P mod target login state machine. Link: https://lore.kernel.org/r/20210422153414.4022-1-a.kovaleva@yadro.com Fixes: a9ed06d4e640 ("scsi: qla2xxx: Allow PLOGI in target mode") Reviewed-by: Roman Bolshakov Reviewed-by: Himanshu Madhani Signed-off-by: Anastasia Kovaleva Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 0a219432127d396120fc88cabd82785e0ff72a2f Author: Jeff Layton Date: Fri Mar 26 09:21:53 2021 -0400 ceph: fix inode leak on getattr error in __fh_to_dentry [ Upstream commit 1775c7ddacfcea29051c67409087578f8f4d751b ] Fixes: 878dabb64117 ("ceph: don't return -ESTALE if there's still an open file") Signed-off-by: Jeff Layton Reviewed-by: Xiubo Li Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 569bb35eb594cb129728889838d197e93375b6ff Author: Claire Chang Date: Thu Apr 22 16:14:53 2021 +0800 swiotlb: Fix the type of index [ Upstream commit 95b079d8215b83b37fa59341fda92fcb9392f14a ] Fix the type of index from unsigned int to int since find_slots() might return -1. Fixes: 26a7e094783d ("swiotlb: refactor swiotlb_tbl_map_single") Reviewed-by: Christoph Hellwig Signed-off-by: Claire Chang Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Sasha Levin commit 38ccbba8677005e54f3b92e62688121e91099732 Author: Nathan Chancellor Date: Thu Mar 25 15:38:07 2021 -0700 riscv: Select HAVE_DYNAMIC_FTRACE when -fpatchable-function-entry is available [ Upstream commit adebc8817b5c975d598ac379bbdf67a7a5186ade ] clang prior to 13.0.0 does not support -fpatchable-function-entry for RISC-V. clang: error: unsupported option '-fpatchable-function-entry=8' for target 'riscv64-unknown-linux-gnu' To avoid this error, only select HAVE_DYNAMIC_FTRACE when this option is not available. Fixes: afc76b8b8011 ("riscv: Using PATCHABLE_FUNCTION_ENTRY instead of MCOUNT") Link: https://github.com/ClangBuiltLinux/linux/issues/1268 Reported-by: kernel test robot Signed-off-by: Nathan Chancellor Reviewed-by: Fangrui Song Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit e9cfa24c28f438221a24f43970dfdac112f48b72 Author: Chuck Lever Date: Mon Apr 19 14:02:54 2021 -0400 xprtrdma: rpcrdma_mr_pop() already does list_del_init() [ Upstream commit 1363e6388c363d0433f9aa4e2f33efe047572687 ] The rpcrdma_mr_pop() earlier in the function has already cleared out mr_list, so it must not be done again in the error path. Fixes: 847568942f93 ("xprtrdma: Remove fr_state") Signed-off-by: Chuck Lever Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 19b5fa9489b5706bc878c3a522a7f771079e2fa0 Author: Chuck Lever Date: Mon Apr 19 14:02:41 2021 -0400 xprtrdma: Fix cwnd update ordering [ Upstream commit 35d8b10a25884050bb3b0149b62c3818ec59f77c ] After a reconnect, the reply handler is opening the cwnd (and thus enabling more RPC Calls to be sent) /before/ rpcrdma_post_recvs() can post enough Receive WRs to receive their replies. This causes an RNR and the new connection is lost immediately. The race is most clearly exposed when KASAN and disconnect injection are enabled. This slows down rpcrdma_rep_create() enough to allow the send side to post a bunch of RPC Calls before the Receive completion handler can invoke ib_post_recv(). Fixes: 2ae50ad68cd7 ("xprtrdma: Close window between waking RPC senders and posting Receives") Signed-off-by: Chuck Lever Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 9ec43636c735623ab18f346c2e04954711d76e65 Author: Chuck Lever Date: Mon Apr 19 14:02:03 2021 -0400 xprtrdma: Avoid Receive Queue wrapping [ Upstream commit 32e6b68167f1d446111c973d57e6f52aee11897a ] Commit e340c2d6ef2a ("xprtrdma: Reduce the doorbell rate (Receive)") increased the number of Receive WRs that are posted by the client, but did not increase the size of the Receive Queue allocated during transport set-up. This is usually not an issue because RPCRDMA_BACKWARD_WRS is defined as (32) when SUNRPC_BACKCHANNEL is defined. In cases where it isn't, there is a real risk of Receive Queue wrapping. Fixes: e340c2d6ef2a ("xprtrdma: Reduce the doorbell rate (Receive)") Signed-off-by: Chuck Lever Reviewed-by: Tom Talpey Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 726d2d5e08444710557d0d602abc978c523f5337 Author: Uwe Kleine-König Date: Tue Apr 20 11:51:17 2021 +0200 pwm: atmel: Fix duty cycle calculation in .get_state() [ Upstream commit 453e8b3d8e36ddcb283b3d1698864a03ea45599a ] The CDTY register contains the number of inactive cycles. .apply() does this correctly, however .get_state() got this wrong. Fixes: 651b510a74d4 ("pwm: atmel: Implement .get_state()") Signed-off-by: Uwe Kleine-König Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit c664aaec9aee544538a78ba4893a44bc73a6d742 Author: Yunjian Wang Date: Fri Apr 23 17:42:58 2021 +0800 SUNRPC: Fix null pointer dereference in svc_rqst_free() [ Upstream commit b9f83ffaa0c096b4c832a43964fe6bff3acffe10 ] When alloc_pages_node() returns null in svc_rqst_alloc(), the null rq_scratch_page pointer will be dereferenced when calling put_page() in svc_rqst_free(). Fix it by adding a null check. Addresses-Coverity: ("Dereference after null check") Fixes: 5191955d6fc6 ("SUNRPC: Prepare for xdr_stream-style decoding on the server-side") Signed-off-by: Yunjian Wang Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 3bfd15afcbbb2a615d89584c3a1437345fdf9af6 Author: Dan Carpenter Date: Thu Apr 22 12:14:37 2021 +0300 SUNRPC: fix ternary sign expansion bug in tracing [ Upstream commit cb579086536f6564f5846f89808ec394ef8b8621 ] This code is supposed to pass negative "err" values for tracing but it passes positive values instead. The problem is that the trace_svcsock_tcp_send() function takes a long but "err" is an int and "sent" is a u32. The negative is first type promoted to u32 so it becomes a high positive then it is promoted to long and it stays positive. Fix this by casting "err" directly to long. Fixes: 998024dee197 ("SUNRPC: Add more svcsock tracepoints") Signed-off-by: Dan Carpenter Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit e7a75d332d396d1e82f1869878b5d7e065347113 Author: Dave Jiang Date: Thu Apr 15 16:37:57 2021 -0700 dmaengine: idxd: fix cdev setup and free device lifetime issues [ Upstream commit 04922b7445a1950b86f130a1fe8c52cc27b3e30b ] The char device setup and cleanup has device lifetime issues regarding when parts are initialized and cleaned up. The initialization of struct device is done incorrectly. device_initialize() needs to be called on the 'struct device' and then additional changes can be added. The ->release() function needs to be setup via device_type before dev_set_name() to allow proper cleanup. The change re-parents the cdev under the wq->conf_dev to get natural reference inheritance. No known dependency on the old device path exists. Reported-by: Jason Gunthorpe Fixes: 42d279f9137a ("dmaengine: idxd: add char driver to expose submission portal to userland") Signed-off-by: Dave Jiang Reviewed-by: Dan Williams Link: https://lore.kernel.org/r/161852987721.2203940.1478218825576630810.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 1c28fd5f94d8996f7dd3805bd6a16ed46a5d0886 Author: Dave Jiang Date: Thu Apr 15 16:37:51 2021 -0700 dmaengine: idxd: fix group conf_dev lifetime [ Upstream commit defe49f96012ca91e8e673cb95b5c30b4a3735e8 ] Remove devm_* allocation and fix group->conf_dev 'struct device' lifetime. Address issues flagged by CONFIG_DEBUG_KOBJECT_RELEASE. Add release functions in order to free the allocated memory at the group->conf_dev destruction time. Reported-by: Jason Gunthorpe Fixes: bfe1d56091c1 ("dmaengine: idxd: Init and probe for Intel data accelerators") Signed-off-by: Dave Jiang Link: https://lore.kernel.org/r/161852987144.2203940.8830315575880047.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 35ea8721d9e6e74c6847cf4d6c27e883b00b0331 Author: Dave Jiang Date: Thu Apr 15 16:37:44 2021 -0700 dmaengine: idxd: fix engine conf_dev lifetime [ Upstream commit 75b911309060f42ba94bbbf46f5f497d35d5cd02 ] Remove devm_* allocation and fix engine->conf_dev 'struct device' lifetime. Address issues flagged by CONFIG_DEBUG_KOBJECT_RELEASE. Add release functions in order to free the allocated memory at the engine conf_dev destruction time. Reported-by: Jason Gunthorpe Fixes: bfe1d56091c1 ("dmaengine: idxd: Init and probe for Intel data accelerators") Signed-off-by: Dave Jiang Link: https://lore.kernel.org/r/161852986460.2203940.16603218225412118431.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit b09ad63775f58a8de3e228f59fb9543bfd964c9c Author: Dave Jiang Date: Thu Apr 15 16:37:39 2021 -0700 dmaengine: idxd: fix wq conf_dev 'struct device' lifetime [ Upstream commit 7c5dd23e57c14cf7177b8a5e0fd08916e0c60005 ] Remove devm_* allocation and fix wq->conf_dev 'struct device' lifetime. Address issues flagged by CONFIG_DEBUG_KOBJECT_RELEASE. Add release functions in order to free the allocated memory for the wq context at device destruction time. Reported-by: Jason Gunthorpe Fixes: bfe1d56091c1 ("dmaengine: idxd: Init and probe for Intel data accelerators") Signed-off-by: Dave Jiang Link: https://lore.kernel.org/r/161852985907.2203940.6840120734115043753.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit a13e4cf29da68630a116c1309072a265ade9566d Author: Dave Jiang Date: Thu Apr 15 16:37:33 2021 -0700 dmaengine: idxd: fix idxd conf_dev 'struct device' lifetime [ Upstream commit 47c16ac27d4cb664cee53ee0b9b7e2f907923fb3 ] The devm managed lifetime is incompatible with 'struct device' objects that resides in idxd context. This is one of the series that clean up the idxd driver 'struct device' lifetime. Fix idxd->conf_dev 'struct device' lifetime. Address issues flagged by CONFIG_DEBUG_KOBJECT_RELEASE. Add release functions in order to free the allocated memory at the appropriate time. Reported-by: Jason Gunthorpe Fixes: bfe1d56091c1 ("dmaengine: idxd: Init and probe for Intel data accelerators") Signed-off-by: Dave Jiang Link: https://lore.kernel.org/r/161852985319.2203940.4650791514462735368.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit b89ae48e3b883b251dd7d666fa36045935b99e24 Author: Dave Jiang Date: Thu Apr 15 16:37:27 2021 -0700 dmaengine: idxd: use ida for device instance enumeration [ Upstream commit f7f7739847bd68b3c3103fd1b50d943038bd14c7 ] The idr is only used for an device id, never to lookup context from that id. Switch to plain ida. Fixes: bfe1d56091c1 ("dmaengine: idxd: Init and probe for Intel data accelerators") Reported-by: Jason Gunthorpe Signed-off-by: Dave Jiang Link: https://lore.kernel.org/r/161852984730.2203940.15032482460902003819.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit eb5fb986f904f0353ff4f626091d3470e9376e74 Author: Dave Jiang Date: Thu Apr 15 16:37:21 2021 -0700 dmaengine: idxd: removal of pcim managed mmio mapping [ Upstream commit a39c7cd0438ee2f0b859ee1eb86cdc52217d2223 ] The devm managed lifetime is incompatible with 'struct device' objects that resides in idxd context. This is one of the series that clean up the idxd driver 'struct device' lifetime. Remove pcim_* management of the PCI device and the ioremap of MMIO BAR and replace with unmanaged versions. This is for consistency of removing all the pcim/devm based calls. Reported-by: Jason Gunthorpe Fixes: bfe1d56091c1 ("dmaengine: idxd: Init and probe for Intel data accelerators") Signed-off-by: Dave Jiang Reviewed-by: Dan Williams Link: https://lore.kernel.org/r/161852984150.2203940.8043988289748519056.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit ee87b468ce057e4c34f8ff6b658dc733c78906b6 Author: Dave Jiang Date: Thu Apr 15 16:37:15 2021 -0700 dmaengine: idxd: cleanup pci interrupt vector allocation management [ Upstream commit 5fc8e85ff12ce0530ac658686902a0ee64600f56 ] The devm managed lifetime is incompatible with 'struct device' objects that resides in idxd context. This is one of the series that clean up the idxd driver 'struct device' lifetime. Remove devm managed pci interrupt vectors and replace with unmanged allocators. Reported-by: Jason Gunthorpe Fixes: bfe1d56091c1 ("dmaengine: idxd: Init and probe for Intel data accelerators") Signed-off-by: Dave Jiang Reviewed-by: Dan Williams Link: https://lore.kernel.org/r/161852983563.2203940.8116028229124776669.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 7982ff0d7449dbdc5b46225064b10a0f0ccce38c Author: Dave Jiang Date: Thu Apr 15 16:37:10 2021 -0700 dmaengine: idxd: fix dma device lifetime [ Upstream commit 397862855619271296e46d10f7dfa7bafe71eb81 ] The devm managed lifetime is incompatible with 'struct device' objects that resides in idxd context. This is one of the series that clean up the idxd driver 'struct device' lifetime. Remove embedding of dma_device and dma_chan in idxd since it's not the only interface that idxd will use. The freeing of the dma_device will be managed by the ->release() function. Reported-by: Jason Gunthorpe Fixes: bfe1d56091c1 ("dmaengine: idxd: Init and probe for Intel data accelerators") Signed-off-by: Dave Jiang Reviewed-by: Dan Williams Link: https://lore.kernel.org/r/161852983001.2203940.14817017492384561719.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 7bc402f843e7817a4a808e7b9ab0bcd7ffd55bfa Author: Colin Ian King Date: Thu Apr 15 12:06:54 2021 +0100 dmaengine: idxd: Fix potential null dereference on pointer status [ Upstream commit 28ac8e03c43dfc6a703aa420d18222540b801120 ] There are calls to idxd_cmd_exec that pass a null status pointer however a recent commit has added an assignment to *status that can end up with a null pointer dereference. The function expects a null status pointer sometimes as there is a later assignment to *status where status is first null checked. Fix the issue by null checking status before making the assignment. Addresses-Coverity: ("Explicit null dereferenced") Fixes: 89e3becd8f82 ("dmaengine: idxd: check device state before issue command") Signed-off-by: Colin Ian King Acked-by: Dave Jiang Link: https://lore.kernel.org/r/20210415110654.1941580-1-colin.king@canonical.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 5a373286e281acdda77f1fc5b40cfefc74224489 Author: Michael Walle Date: Wed Apr 14 10:40:06 2021 +0200 rtc: fsl-ftm-alarm: add MODULE_TABLE() [ Upstream commit 7fcb86185978661c9188397d474f90364745b8d9 ] The module doesn't load automatically. Fix it by adding the missing MODULE_TABLE(). Fixes: 7b0b551dbc1e ("rtc: fsl-ftm-alarm: add FTM alarm driver") Signed-off-by: Michael Walle Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20210414084006.17933-1-michael@walle.cc Signed-off-by: Sasha Levin commit 15f103a1ca301a059d1e9ea7f54134bcdfa9a425 Author: J. Bruce Fields Date: Fri Apr 16 14:00:14 2021 -0400 nfsd: ensure new clients break delegations [ Upstream commit 217fd6f625af591e2866bebb8cda778cf85bea2e ] If nfsd already has an open file that it plans to use for IO from another, it may not need to do another vfs open, but it still may need to break any delegations in case the existing opens are for another client. Symptoms are that we may incorrectly fail to break a delegation on a write open from a different client, when the delegation-holding client already has a write open. Fixes: 28df3d1539de ("nfsd: clients don't need to break their own delegations") Signed-off-by: J. Bruce Fields Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit b8ba461b81a5f02a50d86e940e74446879cc8556 Author: Trond Myklebust Date: Thu Apr 15 15:09:41 2021 -0400 NFSv4.x: Don't return NFS4ERR_NOMATCHING_LAYOUT if we're unmounting [ Upstream commit 8926cc8302819be9e67f70409ed001ecb2c924a9 ] If the NFS super block is being unmounted, then we currently may end up telling the server that we've forgotten the layout while it is actually still in use by the client. In that case, just assume that the client will soon return the layout anyway, and so return NFS4ERR_DELAY in response to the layout recall. Fixes: 58ac3e59235f ("NFSv4/pnfs: Clean up nfs_layout_find_inode()") Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 0e97ce3379945961961f1996086d9ae3b3edd07c Author: Guangqing Zhu Date: Sun Apr 4 20:54:31 2021 +0800 thermal/drivers/tsens: Fix missing put_device error [ Upstream commit f4136863e8899fa0554343201b78b9e197c78a78 ] Fixes coccicheck error: drivers/thermal/qcom/tsens.c:759:4-10: ERROR: missing put_device; call of_find_device_by_node on line 715, but without a corresponding object release within this function. Fixes: a7ff82976122 ("drivers: thermal: tsens: Merge tsens-common.c into tsens.c") Signed-off-by: Guangqing Zhu Reviewed-by: Bjorn Andersson Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20210404125431.12208-1-zhuguangqing83@gmail.com Signed-off-by: Sasha Levin commit 9765abb2f89db13b47354bbbc277cf0c9ee2f77c Author: Trond Myklebust Date: Wed Apr 14 10:10:09 2021 -0400 NFSv42: Copy offload should update the file size when appropriate [ Upstream commit 94d202d5ca39d0eb757d16ef2624b013fb64f64d ] If the result of a copy offload or clone operation is to grow the destination file size, then we should update it. The reason is that when a client holds a delegation, it is authoritative for the file size. Fixes: 16abd2a0c124 ("NFSv4.2: fix client's attribute cache management for copy_file_range") Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit abc164b84f0ee33a9ecf4cb90e867486e2fc934a Author: Chris Dion Date: Sun Apr 4 21:29:26 2021 -0400 SUNRPC: Handle major timeout in xprt_adjust_timeout() [ Upstream commit 09252177d5f924f404551b4b4eded5daa7f04a3a ] Currently if a major timeout value is reached, but the minor value has not been reached, an ETIMEOUT will not be sent back to the caller. This can occur if the v4 server is not responding to requests and retrans is configured larger than the default of two. For example, A TCP mount with a configured timeout value of 50 and a retransmission count of 3 to a v4 server which is not responding: 1. Initial value and increment set to 5s, maxval set to 20s, retries at 3 2. Major timeout is set to 20s, minor timeout set to 5s initially 3. xport_adjust_timeout() is called after 5s, retry with 10s timeout, minor timeout is bumped to 10s 4. And again after another 10s, 15s total time with minor timeout set to 15s 5. After 20s total time xport_adjust_timeout is called as major timeout is reached, but skipped because the minor timeout is not reached - After this time the cpu spins continually calling xport_adjust_timeout() and returning 0 for 10 seconds. As seen on perf sched: 39243.913182 [0005] mount.nfs[3794] 4607.938 0.017 9746.863 6. This continues until the 15s minor timeout condition is reached (in this case for 10 seconds). After which the ETIMEOUT is processed back to the caller, the cpu spinning stops, and normal operations continue Fixes: 7de62bc09fe6 ("SUNRPC dont update timeout value on connection reset") Signed-off-by: Chris Dion Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 947355dd9a69e0856a7295b556c029a890c916fe Author: Chuck Lever Date: Wed Mar 31 16:03:08 2021 -0400 SUNRPC: Remove trace_xprt_transmit_queued [ Upstream commit 6cf23783f750634e10daeede48b0f5f5d64ebf3a ] This tracepoint can crash when dereferencing snd_task because when some transports connect, they put a cookie in that field instead of a pointer to an rpc_task. BUG: KASAN: use-after-free in trace_event_raw_event_xprt_writelock_event+0x141/0x18e [sunrpc] Read of size 2 at addr ffff8881a83bd3a0 by task git/331872 CPU: 11 PID: 331872 Comm: git Tainted: G S 5.12.0-rc2-00007-g3ab6e585a7f9 #1453 Hardware name: Supermicro SYS-6028R-T/X10DRi, BIOS 1.1a 10/16/2015 Call Trace: dump_stack+0x9c/0xcf print_address_description.constprop.0+0x18/0x239 kasan_report+0x174/0x1b0 trace_event_raw_event_xprt_writelock_event+0x141/0x18e [sunrpc] xprt_prepare_transmit+0x8e/0xc1 [sunrpc] call_transmit+0x4d/0xc6 [sunrpc] Fixes: 9ce07ae5eb1d ("SUNRPC: Replace dprintk() call site in xprt_prepare_transmit") Signed-off-by: Chuck Lever Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 835b2f8c4e68d57284bd81f46077525e56f28128 Author: Chuck Lever Date: Wed Mar 31 13:22:14 2021 -0400 SUNRPC: Move fault injection call sites [ Upstream commit 7638e0bfaed1b653d3ca663e560e9ffb44bb1030 ] I've hit some crashes that occur in the xprt_rdma_inject_disconnect path. It appears that, for some provides, rdma_disconnect() can take so long that the transport can disconnect and release its hardware resources while rdma_disconnect() is still running, resulting in a UAF in the provider. The transport's fault injection method may depend on the stability of transport data structures. That means it needs to be invoked only from contexts that hold the transport write lock. Fixes: 4a0682583988 ("SUNRPC: Transport fault injection") Signed-off-by: Chuck Lever Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit c63e7c5d94e9cc6452d05b0e217d18f35ce11be0 Author: Olga Kornievskaia Date: Wed Mar 31 15:30:25 2021 -0400 NFSv4.2 fix handling of sr_eof in SEEK's reply [ Upstream commit 73f5c88f521a630ea1628beb9c2d48a2e777a419 ] Currently the client ignores the value of the sr_eof of the SEEK operation. According to the spec, if the server didn't find the requested extent and reached the end of the file, the server would return sr_eof=true. In case the request for DATA and no data was found (ie in the middle of the hole), then the lseek expects that ENXIO would be returned. Fixes: 1c6dcbe5ceff8 ("NFS: Implement SEEK") Signed-off-by: Olga Kornievskaia Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 754efbbdaf4e99f9e8d9bd0ef1470ff639cdb5f4 Author: Nikola Livic Date: Mon Mar 29 11:56:49 2021 +0300 pNFS/flexfiles: fix incorrect size check in decode_nfs_fh() [ Upstream commit ed34695e15aba74f45247f1ee2cf7e09d449f925 ] We (adam zabrocki, alexander matrosov, alexander tereshkin, maksym bazalii) observed the check: if (fh->size > sizeof(struct nfs_fh)) should not use the size of the nfs_fh struct which includes an extra two bytes from the size field. struct nfs_fh { unsigned short size; unsigned char data[NFS_MAXFHSIZE]; } but should determine the size from data[NFS_MAXFHSIZE] so the memcpy will not write 2 bytes beyond destination. The proposed fix is to compare against the NFS_MAXFHSIZE directly, as is done elsewhere in fs code base. Fixes: d67ae825a59d ("pnfs/flexfiles: Add the FlexFile Layout Driver") Signed-off-by: Nikola Livic Signed-off-by: Dan Carpenter Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 9b29c75db48df9c869ec6cd6bc30f55b33fa8678 Author: Suman Anna Date: Wed Apr 7 10:56:41 2021 -0500 remoteproc: pru: Fix and cleanup firmware interrupt mapping logic [ Upstream commit 880a66e026fbe6a17cd59fe0ee942bbad62a6c26 ] The PRU firmware interrupt mappings are configured and unconfigured in .start() and .stop() callbacks respectively using the variables 'evt_count' and a 'mapped_irq' pointer. These variables are modified only during these callbacks but are not re-initialized/reset properly during unwind or failure paths. These stale values caused a kernel crash while stopping a PRU remoteproc running a different firmware with no events on a subsequent run after a previous run that was running a firmware with events. Fix this crash by ensuring that the evt_count is 0 and the mapped_irq pointer is set to NULL in pru_dispose_irq_mapping(). Also, reset these variables properly during any failures in the .start() callback. While at this, the pru_dispose_irq_mapping() callsites are all made to look the same, moving any conditional logic to inside the function. Reviewed-by: Mathieu Poirier Fixes: c75c9fdac66e ("remoteproc: pru: Add support for PRU specific interrupt configuration") Reported-by: Vignesh Raghavendra Signed-off-by: Suman Anna Link: https://lore.kernel.org/r/20210407155641.5501-4-s-anna@ti.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 2ecce3d08fb2ceb495e7eee1f711f2cba9a0598f Author: Suman Anna Date: Wed Apr 7 10:56:40 2021 -0500 remoteproc: pru: Fix wrong success return value for fw events [ Upstream commit 1fe72bcfac087dba5ab52778e0646ed9e145cd32 ] The irq_create_fwspec_mapping() returns a proper virq value on success and 0 upon any failure. The pru_handle_intrmap() treats this as an error and disposes all firmware event mappings correctly, but is returning this incorrect value as is, letting the pru_rproc_start() interpret it as a success and boot the PRU. Fix this by returning an error value back upon any such failure. While at this, revise the error trace to print some meaningful info about the failed event. Fixes: c75c9fdac66e ("remoteproc: pru: Add support for PRU specific interrupt configuration") Signed-off-by: Suman Anna Reviewed-by: Mathieu Poirier Link: https://lore.kernel.org/r/20210407155641.5501-3-s-anna@ti.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 7da84d16394ddc4d2385469e08d11c5053c272d9 Author: Suman Anna Date: Wed Apr 7 10:56:39 2021 -0500 remoteproc: pru: Fixup interrupt-parent logic for fw events [ Upstream commit 6d1f2803cb6b414c2e45fa64d1fdad6b581e1e88 ] The PRU firmware interrupt mapping logic in pru_handle_intrmap() uses of_irq_find_parent() with PRU device node to get a handle to the PRUSS Interrupt Controller at present. This logic however requires that the PRU nodes always define a interrupt-parent property. This property is neither a required/defined property as per the PRU remoteproc binding, nor is relevant from a DT node point of view without any associated interrupts. The current logic finds a wrong interrupt controller and fails to perform proper mapping without any interrupt-parent property in the PRU nodes. Fix this logic to always find and use the sibling interrupt controller. Also, while at this, fix the acquired interrupt controller device node reference properly. Fixes: c75c9fdac66e ("remoteproc: pru: Add support for PRU specific interrupt configuration") Signed-off-by: Suman Anna Reviewed-by: Mathieu Poirier Link: https://lore.kernel.org/r/20210407155641.5501-2-s-anna@ti.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 8aaf14b0b05b077a3fdd633ecab62331c5c8fbb8 Author: Yang Yingliang Date: Wed Mar 31 16:40:12 2021 +0800 PCI: endpoint: Fix missing destroy_workqueue() [ Upstream commit acaef7981a218813e3617edb9c01837808de063c ] Add the missing destroy_workqueue() before return from pci_epf_test_init() in the error handling case and add destroy_workqueue() in pci_epf_test_exit(). Link: https://lore.kernel.org/r/20210331084012.2091010-1-yangyingliang@huawei.com Fixes: 349e7a85b25fa ("PCI: endpoint: functions: Add an EP function to test PCI") Reported-by: Hulk Robot Signed-off-by: Yang Yingliang Signed-off-by: Lorenzo Pieralisi Signed-off-by: Sasha Levin commit 14a952ccf17381fbac431c62c387d076e61dff24 Author: Trond Myklebust Date: Mon Mar 29 16:46:05 2021 -0400 NFS: Deal correctly with attribute generation counter overflow [ Upstream commit 9fdbfad1777cb4638f489eeb62d85432010c0031 ] We need to use unsigned long subtraction and then convert to signed in order to deal correcly with C overflow rules. Fixes: f5062003465c ("NFS: Set an attribute barrier on all updates") Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 81fc0f863a64f1b1c2b9fde7d2cb58c568e34afb Author: Trond Myklebust Date: Sun Mar 28 18:17:14 2021 -0400 NFSv4.2: Always flush out writes in nfs42_proc_fallocate() [ Upstream commit 99f23783224355e7022ceea9b8d9f62c0fd01bd8 ] Whether we're allocating or delallocating space, we should flush out the pending writes in order to avoid races with attribute updates. Fixes: 1e564d3dbd68 ("NFSv4.2: Fix a race in nfs42_proc_deallocate()") Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit ff29c67b809c096c22ef60b02cc52822f589faf1 Author: Trond Myklebust Date: Sun Mar 28 18:12:03 2021 -0400 NFS: Fix attribute bitmask in _nfs42_proc_fallocate() [ Upstream commit e99812e1382f0bfb6149393262bc70645c9f537a ] We can't use nfs4_fattr_bitmap as a bitmask, because it hasn't been filtered to represent the attributes supported by the server. Instead, let's revert to using server->cache_consistency_bitmask after adding in the missing SPACE_USED attribute. Fixes: 913eca1aea87 ("NFS: Fallocate should use the nfs4_fattr_bitmap") Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 425d311e5115af6a37995ee5dcb812bdb2208632 Author: Trond Myklebust Date: Thu Mar 25 18:15:36 2021 -0400 NFS: nfs4_bitmask_adjust() must not change the server global bitmasks [ Upstream commit 332d1a0373be32a3a3c152756bca45ff4f4e11b5 ] As currently set, the calls to nfs4_bitmask_adjust() will end up overwriting the contents of the nfs_server cache_consistency_bitmask field. The intention here should be to modify a private copy of that mask in the close/delegreturn/write arguments. Fixes: 76bd5c016ef4 ("NFSv4: make cache consistency bitmask dynamic") Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit de68b23bedae7b056e2b6a080cc8fe4e3cdf1b64 Author: Jia-Ju Bai Date: Sat Mar 6 05:36:24 2021 -0800 rpmsg: qcom_glink_native: fix error return code of qcom_glink_rx_data() [ Upstream commit 26594c6bbb60c6bc87e3762a86ceece57d164c66 ] When idr_find() returns NULL to intent, no error return code of qcom_glink_rx_data() is assigned. To fix this bug, ret is assigned with -ENOENT in this case. Fixes: 64f95f87920d ("rpmsg: glink: Use the local intents when receiving data") Reported-by: TOTE Robot Signed-off-by: Jia-Ju Bai Link: https://lore.kernel.org/r/20210306133624.17237-1-baijiaju1990@gmail.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 058b7d4f013edaf0298994fd0e58cf2d0a1e0e1b Author: Chao Yu Date: Fri Apr 2 17:22:23 2021 +0800 f2fs: fix to avoid accessing invalid fio in f2fs_allocate_data_block() [ Upstream commit 25ae837e61dee712b4b1df36602ebfe724b2a0b6 ] Callers may pass fio parameter with NULL value to f2fs_allocate_data_block(), so we should make sure accessing fio's field after fio's validation check. Fixes: f608c38c59c6 ("f2fs: clean up parameter of f2fs_allocate_data_block()") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 2f8dda840046b55bfe8383fb524f76a49226db95 Author: Trond Myklebust Date: Wed Mar 17 08:46:19 2021 -0400 NFS: Only change the cookie verifier if the directory page cache is empty [ Upstream commit f892c41c14e0fa3d78ce37de1d5c8161ed13bf08 ] The cached NFSv3/v4 readdir cookies are associated with a verifier, which is checked by the server on subsequent calls to readdir, and is only expected to change when the cookies (and hence also the page cache contents) are considered invalid. We therefore do have to store the verifier, but only when the page cache is empty. Fixes: b593c09f83a2 ("NFS: Improve handling of directory verifiers") Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 7d2597210e79e436f77bff0d1de7833f81ad3f34 Author: Trond Myklebust Date: Tue Mar 16 07:57:40 2021 -0400 NFS: Fix handling of cookie verifier in uncached_readdir() [ Upstream commit 13884ff2bef01df37c450c6dd09122f92333dccc ] If we're doing uncached readdir(), then the readdir cookie could be different from the one cached in the nfs_inode. We should therefore ensure that we save that one in the struct nfs_open_dir_context. Fixes: 35df59d3ef69 ("NFS: Reduce number of RPC calls when doing uncached readdir") Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 213a094da6c9ea4ae8b8d2cf7b1f9f328f194a4f Author: Nagendra S Tomar Date: Tue Mar 16 10:25:14 2021 +0000 nfs: Subsequent READDIR calls should carry non-zero cookieverifier [ Upstream commit ee3707ae2c1f1327ad5188836b7ab62ed2c93b28 ] If the loop in nfs_readdir_xdr_to_array() runs more than once, subsequent READDIR RPCs may wrongly carry a zero cookie verifier and non-zero cookie. Make sure subsequent calls to READDIR carry the cookie verifier returned by the first call. Signed-off-by: Nagendra S Tomar Fixes: b593c09f83a2 ("NFS: Improve handling of directory verifiers") Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 37d20a735e608ca865de737dc345081ef80a1025 Author: Yi Zhuang Date: Wed Mar 31 17:34:14 2021 +0800 f2fs: Fix a hungtask problem in atomic write [ Upstream commit be1ee45d51384161681ecf21085a42d316ae25f7 ] In the cache writing process, if it is an atomic file, increase the page count of F2FS_WB_CP_DATA, otherwise increase the page count of F2FS_WB_DATA. When you step into the hook branch due to insufficient memory in f2fs_write_begin, f2fs_drop_inmem_pages_all will be called to traverse all atomic inodes and clear the FI_ATOMIC_FILE mark of all atomic files. In f2fs_drop_inmem_pages，first acquire the inmem_lock , revoke all the inmem_pages, and then clear the FI_ATOMIC_FILE mark. Before this mark is cleared, other threads may hold inmem_lock to add inmem_pages to the inode that has just been emptied inmem_pages, and increase the page count of F2FS_WB_CP_DATA. When the IO returns, it is found that the FI_ATOMIC_FILE flag is cleared by f2fs_drop_inmem_pages_all, and f2fs_is_atomic_file returns false,which causes the page count of F2FS_WB_DATA to be decremented. The page count of F2FS_WB_CP_DATA cannot be cleared. Finally, hungtask is triggered in f2fs_wait_on_all_pages because get_pages will never return zero. process A: process B: f2fs_drop_inmem_pages_all ->f2fs_drop_inmem_pages of inode#1 ->mutex_lock(&fi->inmem_lock) ->__revoke_inmem_pages of inode#1 f2fs_ioc_commit_atomic_write ->mutex_unlock(&fi->inmem_lock) ->f2fs_commit_inmem_pages of inode#1 ->mutex_lock(&fi->inmem_lock) ->__f2fs_commit_inmem_pages ->f2fs_do_write_data_page ->f2fs_outplace_write_data ->do_write_page ->f2fs_submit_page_write ->inc_page_count(sbi, F2FS_WB_CP_DATA ) ->mutex_unlock(&fi->inmem_lock) ->spin_lock(&sbi->inode_lock[ATOMIC_FILE]); ->clear_inode_flag(inode, FI_ATOMIC_FILE) ->spin_unlock(&sbi->inode_lock[ATOMIC_FILE]) f2fs_write_end_io ->dec_page_count(sbi, F2FS_WB_DATA ); We can fix the problem by putting the action of clearing the FI_ATOMIC_FILE mark into the inmem_lock lock. This operation can ensure that no one will submit the inmem pages before the FI_ATOMIC_FILE mark is cleared, so that there will be no atomic writes waiting for writeback. Fixes: 57864ae5ce3a ("f2fs: limit # of inmemory pages") Signed-off-by: Yi Zhuang Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 83e20645435880fbad7bea292f584703c99f8f55 Author: Chao Yu Date: Wed Mar 31 11:16:32 2021 +0800 f2fs: fix to restrict mount condition on readonly block device [ Upstream commit 23738e74472f9c5f3a05a68724a2ccfba97d283d ] When we mount an unclean f2fs image in a readonly block device, let's make mount() succeed only when there is no recoverable data in that image, otherwise after mount(), file fsyned won't be recovered as user expected. Fixes: 938a184265d7 ("f2fs: give a warning only for readonly partition") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 70dbc3283c3a6031b10c57dd839a44e06fa4111f Author: Yang Yingliang Date: Tue Mar 30 21:06:32 2021 +0800 fs: 9p: fix v9fs_file_open writeback fid error check [ Upstream commit f8b139e2f24112f4e21f1eb02c7fc7600fea4b8d ] IS_ERR() and PTR_ERR() use wrong pointer, it should be writeback_fid, fix it. Link: http://lkml.kernel.org/r/20210330130632.1054357-1-yangyingliang@huawei.com Fixes: 5bfe97d7382b ("9p: Fix writeback fid incorrectly being attached to dentry") Reported-by: Hulk Robot Signed-off-by: Yang Yingliang [Dominique: adjusted commit summary] Signed-off-by: Dominique Martinet Signed-off-by: Sasha Levin commit 88a46398bf05beb91161914a6aff62084f5c1544 Author: Chao Yu Date: Fri Mar 26 09:46:22 2021 +0800 f2fs: fix to cover __allocate_new_section() with curseg_lock [ Upstream commit 823d13e12b6cbaef2f6e5d63c648643e7bc094dd ] In order to avoid race with f2fs_do_replace_block(). Fixes: f5a53edcf01e ("f2fs: support aligned pinned file") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 211372b2571520e394b56b431a0705586013b3ff Author: Chao Yu Date: Wed Mar 24 11:18:28 2021 +0800 f2fs: fix to avoid touching checkpointed data in get_victim() [ Upstream commit 61461fc921b756ae16e64243f72af2bfc2e620db ] In CP disabling mode, there are two issues when using LFS or SSR | AT_SSR mode to select victim: 1. LFS is set to find source section during GC, the victim should have no checkpointed data, since after GC, section could not be set free for reuse. Previously, we only check valid chpt blocks in current segment rather than section, fix it. 2. SSR | AT_SSR are set to find target segment for writes which can be fully filled by checkpointed and newly written blocks, we should never select such segment, otherwise it can cause panic or data corruption during allocation, potential case is described as below: a) target segment has 'n' (n < 512) ckpt valid blocks b) GC migrates 'n' valid blocks to other segment (segment is still in dirty list) c) GC migrates '512 - n' blocks to target segment (segment has 'n' cp_vblocks and '512 - n' vblocks) d) If GC selects target segment via {AT,}SSR allocator, however there is no free space in targe segment. Fixes: 4354994f097d ("f2fs: checkpoint disabling") Fixes: 093749e296e2 ("f2fs: support age threshold based garbage collection") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 0169d4f0bee44fdfef908c13ed21fcb326c38695 Author: Shradha Todi Date: Wed Mar 24 15:46:09 2021 +0530 PCI: endpoint: Fix NULL pointer dereference for ->get_features() [ Upstream commit 6613bc2301ba291a1c5a90e1dc24cf3edf223c03 ] get_features ops of pci_epc_ops may return NULL, causing NULL pointer dereference in pci_epf_test_alloc_space function. Let us add a check for pci_epc_feature pointer in pci_epf_test_bind before we access it to avoid any such NULL pointer dereference and return -ENOTSUPP in case pci_epc_feature is not found. When the patch is not applied and EPC features is not implemented in the platform driver, we see the following dump due to kernel NULL pointer dereference. Call trace: pci_epf_test_bind+0xf4/0x388 pci_epf_bind+0x3c/0x80 pci_epc_epf_link+0xa8/0xcc configfs_symlink+0x1a4/0x48c vfs_symlink+0x104/0x184 do_symlinkat+0x80/0xd4 __arm64_sys_symlinkat+0x1c/0x24 el0_svc_common.constprop.3+0xb8/0x170 el0_svc_handler+0x70/0x88 el0_svc+0x8/0x640 Code: d2800581 b9403ab9 f9404ebb 8b394f60 (f9400400) ---[ end trace a438e3c5a24f9df0 ]--- Link: https://lore.kernel.org/r/20210324101609.79278-1-shradha.t@samsung.com Fixes: 2c04c5b8eef79 ("PCI: pci-epf-test: Use pci_epc_get_features() to get EPC features") Signed-off-by: Sriram Dash Signed-off-by: Shradha Todi Signed-off-by: Lorenzo Pieralisi Reviewed-by: Pankaj Dubey Reviewed-by: Kishon Vijay Abraham I Signed-off-by: Sasha Levin commit 5ede51f41b3a143f256f3cccf4c06ba5bf941746 Author: Chao Yu Date: Wed Mar 24 11:24:33 2021 +0800 f2fs: fix to update last i_size if fallocate partially succeeds [ Upstream commit 88f2cfc5fa90326edb569b4a81bb38ed4dcd3108 ] In the case of expanding pinned file, map.m_lblk and map.m_len will update in each round of section allocation, so in error path, last i_size will be calculated with wrong m_lblk and m_len, fix it. Fixes: f5a53edcf01e ("f2fs: support aligned pinned file") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 16e712005049e8fd795408f055efcd58ec719db0 Author: Chao Yu Date: Fri Mar 5 17:56:01 2021 +0800 f2fs: fix to align to section for fallocate() on pinned file [ Upstream commit e1175f02291141bbd924fc578299305fcde35855 ] Now, fallocate() on a pinned file only allocates blocks which aligns to segment rather than section, so GC may try to migrate pinned file's block, and after several times of failure, pinned file's block could be migrated to other place, however user won't be aware of such condition, and then old obsolete block address may be readed/written incorrectly. To avoid such condition, let's try to allocate pinned file's blocks with section alignment. Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit dabe299425b1a53a69461fed7ac8922ea6733a25 Author: Zhen Lei Date: Thu Feb 18 03:00:05 2021 +0100 ARM: 9064/1: hw_breakpoint: Do not directly check the event's overflow_handler hook [ Upstream commit a506bd5756290821a4314f502b4bafc2afcf5260 ] The commit 1879445dfa7b ("perf/core: Set event's default ::overflow_handler()") set a default event->overflow_handler in perf_event_alloc(), and replace the check event->overflow_handler with is_default_overflow_handler(), but one is missing. Currently, the bp->overflow_handler can not be NULL. As a result, enable_single_step() is always not invoked. Comments from Zhen Lei: https://patchwork.kernel.org/project/linux-arm-kernel/patch/20210207105934.2001-1-thunder.leizhen@huawei.com/ Fixes: 1879445dfa7b ("perf/core: Set event's default ::overflow_handler()") Signed-off-by: Zhen Lei Cc: Wang Nan Acked-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Sasha Levin commit e91ab236316842bede39046edb57ca54821f1ec5 Author: Dmitry Baryshkov Date: Mon Jan 25 02:28:26 2021 +0300 PCI: Release OF node in pci_scan_device()'s error path [ Upstream commit c99e755a4a4c165cad6effb39faffd0f3377c02d ] In pci_scan_device(), if pci_setup_device() fails for any reason, the code will not release device's of_node by calling pci_release_of_node(). Fix that by calling the release function. Fixes: 98d9f30c820d ("pci/of: Match PCI devices to OF nodes dynamically") Link: https://lore.kernel.org/r/20210124232826.1879-1-dmitry.baryshkov@linaro.org Signed-off-by: Dmitry Baryshkov Signed-off-by: Bjorn Helgaas Reviewed-by: Leon Romanovsky Signed-off-by: Sasha Levin commit a81e0a2343204d7d57da4ab96118aecfce3b68c1 Author: Wei Yongjun Date: Mon Mar 8 13:56:19 2021 +0000 PCI: brcmstb: Fix error return code in brcm_pcie_probe() [ Upstream commit b5d9209d50838474fc1b2901d0e11bba59906428 ] Fix to return negative error code -ENODEV from the unsupported revision error handling case instead of 0, as done elsewhere in this function. Link: https://lore.kernel.org/r/20210308135619.19133-1-weiyongjun1@huawei.com Fixes: 0cdfaceb9889 ("PCI: brcmstb: support BCM4908 with external PERST# signal controller") Reported-by: Hulk Robot Signed-off-by: Wei Yongjun Signed-off-by: Lorenzo Pieralisi Reviewed-by: Krzysztof Wilczyński Acked-by: Florian Fainelli Signed-off-by: Sasha Levin commit ad6461f164642660f357ba334c17b4e47c34cb24 Author: Pali Rohár Date: Wed Mar 3 15:22:02 2021 +0100 PCI: iproc: Fix return value of iproc_msi_irq_domain_alloc() [ Upstream commit 1e83130f01b04c16579ed5a5e03d729bcffc4c5d ] IRQ domain alloc function should return zero on success. Non-zero value indicates failure. Link: https://lore.kernel.org/r/20210303142202.25780-1-pali@kernel.org Fixes: fc54bae28818 ("PCI: iproc: Allow allocation of multiple MSIs") Signed-off-by: Pali Rohár Signed-off-by: Lorenzo Pieralisi Reviewed-by: Krzysztof Wilczyński Acked-by: Ray Jui Acked-by: Marc Zyngier Signed-off-by: Sasha Levin commit ef27ec3805c05e67abfd6fae7baabb5e1d15c829 Author: Bjorn Andersson Date: Fri Mar 12 15:20:02 2021 -0800 remoteproc: qcom_q6v5_mss: Validate p_filesz in ELF loader [ Upstream commit 3d2ee78906af5f08d499d6aa3aa504406fa38106 ] Analog to the issue in the common mdt_loader code the MSS ELF loader does not validate that p_filesz bytes will fit in the memory region and that the loaded segments are not truncated. Fix this in the same way as proposed for the mdt_loader. Reviewed-by: Mathieu Poirier Fixes: 135b9e8d1cd8 ("remoteproc: qcom_q6v5_mss: Validate modem blob firmware size before load") Link: https://lore.kernel.org/r/20210312232002.3466791-1-bjorn.andersson@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit d06ad5425e98304f2582b45817d6c88f7e18185c Author: Arnd Bergmann Date: Thu Feb 25 14:42:04 2021 +0100 rtc: tps65910: include linux/property.h [ Upstream commit 936d3685e62436a378f02b8b74759b054d4aeca1 ] The added device_property_present() call causes a build failure in some configurations because of the missing header: drivers/rtc/rtc-tps65910.c:422:7: error: implicit declaration of function 'device_property_present' [-Werror,-Wimplicit-function-declaration] Fixes: 454ba154a62c ("rtc: tps65910: Support wakeup-source property") Signed-off-by: Arnd Bergmann Reviewed-by: Dmitry Osipenko Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20210225134215.2263694-1-arnd@kernel.org Signed-off-by: Sasha Levin commit 155c1706ed0d0962d73fddc5949d868193ae9707 Author: Colin Ian King Date: Thu Mar 4 09:21:18 2021 +0000 f2fs: fix a redundant call to f2fs_balance_fs if an error occurs [ Upstream commit 28e18ee636ba28532dbe425540af06245a0bbecb ] The uninitialized variable dn.node_changed does not get set when a call to f2fs_get_node_page fails. This uninitialized value gets used in the call to f2fs_balance_fs() that may or not may not balances dirty node and dentry pages depending on the uninitialized state of the variable. Fix this by only calling f2fs_balance_fs if err is not set. Thanks to Jaegeuk Kim for suggesting an appropriate fix. Addresses-Coverity: ("Uninitialized scalar variable") Fixes: 2a3407607028 ("f2fs: call f2fs_balance_fs only when node was changed") Signed-off-by: Colin Ian King Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 822054e5026c43b1dd60cf387dd999e95ee2ecc2 Author: Chao Yu Date: Sat Feb 20 17:35:41 2021 +0800 f2fs: fix panic during f2fs_resize_fs() [ Upstream commit 3ab0598e6d860ef49d029943ba80f627c15c15d6 ] f2fs_resize_fs() hangs in below callstack with testcase: - mkfs 16GB image & mount image - dd 8GB fileA - dd 8GB fileB - sync - rm fileA - sync - resize filesystem to 8GB kernel BUG at segment.c:2484! Call Trace: allocate_segment_by_default+0x92/0xf0 [f2fs] f2fs_allocate_data_block+0x44b/0x7e0 [f2fs] do_write_page+0x5a/0x110 [f2fs] f2fs_outplace_write_data+0x55/0x100 [f2fs] f2fs_do_write_data_page+0x392/0x850 [f2fs] move_data_page+0x233/0x320 [f2fs] do_garbage_collect+0x14d9/0x1660 [f2fs] free_segment_range+0x1f7/0x310 [f2fs] f2fs_resize_fs+0x118/0x330 [f2fs] __f2fs_ioctl+0x487/0x3680 [f2fs] __x64_sys_ioctl+0x8e/0xd0 do_syscall_64+0x33/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xa9 The root cause is we forgot to check that whether we have enough space in resized filesystem to store all valid blocks in before-resizing filesystem, then allocator will run out-of-space during block migration in free_segment_range(). Fixes: b4b10061ef98 ("f2fs: refactor resize_fs to avoid meta updates in progress") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 339bf4baa5eb376735c3936fde7d44f8a6293ac8 Author: Chao Yu Date: Sat Feb 20 17:35:40 2021 +0800 f2fs: fix to allow migrating fully valid segment [ Upstream commit 7dede88659df38f96128ab3922c50dde2d29c574 ] F2FS_IOC_FLUSH_DEVICE/F2FS_IOC_RESIZE_FS needs to migrate all blocks of target segment to other place, no matter the segment has partially or fully valid blocks. However, after commit 803e74be04b3 ("f2fs: stop GC when the victim becomes fully valid"), we may skip migration due to target segment is fully valid, result in failing the ioctl interface, fix this. Fixes: 803e74be04b3 ("f2fs: stop GC when the victim becomes fully valid") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit a04d3f9877cb69101344a9ec3cedb1be3df52772 Author: Qiuxu Zhuo Date: Mon Feb 22 09:17:17 2021 +0800 PCI/RCEC: Fix RCiEP device to RCEC association [ Upstream commit d9b7eae8e3424c3480fe9f40ebafbb0c96426e4c ] rcec_assoc_rciep() used "rciep->devfn" (a single byte encoding both the device and function number) as the device number to check whether the corresponding bit was set in the RCEC's Association Bitmap for RCiEPs. But per PCIe r5.0, sec 7.9.10.2, "Association Bitmap for RCiEPs", the 32-bit bitmap contains one bit per device. That bit applies to all functions of the device. Fix rcec_assoc_rciep() to convert the value of "rciep->devfn" to a device number to ensure that RCiEP devices are correctly associated with the RCEC. Reported-and-tested-by: Wen Jin Fixes: 507b460f8144 ("PCI/ERR: Add pcie_link_rcec() to associate RCiEPs") Link: https://lore.kernel.org/r/20210222011717.43266-1-qiuxu.zhuo@intel.com Signed-off-by: Qiuxu Zhuo Signed-off-by: Bjorn Helgaas Reviewed-by: Sean V Kelley Signed-off-by: Sasha Levin commit 16276fb241c089d65a82e0550aa1ce3ace70b100 Author: Jia-Ju Bai Date: Wed Mar 10 04:24:23 2021 -0800 thermal: thermal_of: Fix error return code of thermal_of_populate_bind_params() [ Upstream commit 45c7eaeb29d67224db4ba935deb575586a1fda09 ] When kcalloc() returns NULL to __tcbp or of_count_phandle_with_args() returns zero or -ENOENT to count, no error return code of thermal_of_populate_bind_params() is assigned. To fix these bugs, ret is assigned with -ENOMEM and -ENOENT in these cases, respectively. Fixes: a92bab8919e3 ("of: thermal: Allow multiple devices to share cooling map") Reported-by: TOTE Robot Signed-off-by: Jia-Ju Bai Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20210310122423.3266-1-baijiaju1990@gmail.com Signed-off-by: Sasha Levin commit 746fa58120aaac11f39166b157661df11571f693 Author: Arnd Bergmann Date: Mon Mar 8 16:30:46 2021 +0100 leds: lgm: fix gpiolib dependency [ Upstream commit 34731ed13e8a8ca95fa0dca466537396b5f2d1af ] Without gpiolib, the driver fails to build: drivers/leds/blink/leds-lgm-sso.c:123:19: error: field has incomplete type 'struct gpio_chip' struct gpio_chip chip; ^ include/linux/gpio.h:107:8: note: forward declaration of 'struct gpio_chip' struct gpio_chip; ^ drivers/leds/blink/leds-lgm-sso.c:263:3: error: implicit declaration of function 'gpiod_set_value' [-Werror,-Wimplicit-function-declaration] gpiod_set_value(led->gpiod, val); ^ drivers/leds/blink/leds-lgm-sso.c:263:3: note: did you mean 'gpio_set_value'? include/linux/gpio.h:168:20: note: 'gpio_set_value' declared here static inline void gpio_set_value(unsigned gpio, int value) ^ drivers/leds/blink/leds-lgm-sso.c:345:3: error: implicit declaration of function 'gpiod_set_value' [-Werror,-Wimplicit-function-declaration] gpiod_set_value(led->gpiod, 1); ^ Add the dependency in Kconfig. Fixes: c3987cd2bca3 ("leds: lgm: Add LED controller driver for LGM SoC") Signed-off-by: Arnd Bergmann Signed-off-by: Pavel Machek Signed-off-by: Sasha Levin commit 22052b84eea7952fbecba361a6cad9a18f3733af Author: David Ward Date: Sun Apr 18 09:46:57 2021 -0400 ASoC: rt286: Make RT286_SET_GPIO_* readable and writable [ Upstream commit cd8499d5c03ba260e3191e90236d0e5f6b147563 ] The GPIO configuration cannot be applied if the registers are inaccessible. This prevented the headset mic from working on the Dell XPS 13 9343. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=114171 Signed-off-by: David Ward Link: https://lore.kernel.org/r/20210418134658.4333-5-david.ward@gatech.edu Reviewed-by: Pierre-Louis Bossart Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 9ac5c943c399e8805aff30f0e3b5690bb2172072 Author: Petr Mladek Date: Thu Apr 29 22:54:33 2021 -0700 watchdog: fix barriers when printing backtraces from all CPUs [ Upstream commit 9f113bf760ca90d709f8f89a733d10abb1f04a83 ] Any parallel softlockup reports are skipped when one CPU is already printing backtraces from all CPUs. The exclusive rights are synchronized using one bit in soft_lockup_nmi_warn. There is also one memory barrier that does not make much sense. Use two barriers on the right location to prevent mixing two reports. [pmladek@suse.com: use bit lock operations to prevent multiple soft-lockup reports] Link: https://lkml.kernel.org/r/YFSVsLGVWMXTvlbk@alley Link: https://lkml.kernel.org/r/20210311122130.6788-6-pmladek@suse.com Signed-off-by: Petr Mladek Acked-by: Peter Zijlstra (Intel) Cc: Ingo Molnar Cc: Laurence Oberman Cc: Michal Hocko Cc: Thomas Gleixner Cc: Vincent Whitchurch Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit c083d669dcc772cae6dfe1e7a8ac6acec574213d Author: Petr Mladek Date: Thu Apr 29 22:54:30 2021 -0700 watchdog/softlockup: remove logic that tried to prevent repeated reports [ Upstream commit 1bc503cb4a2638fb1c57801a7796aca57845ce63 ] The softlockup detector does some gymnastic with the variable soft_watchdog_warn. It was added by the commit 58687acba59266735ad ("lockup_detector: Combine nmi_watchdog and softlockup detector"). The purpose is not completely clear. There are the following clues. They describe the situation how it looked after the above mentioned commit: 1. The variable was checked with a comment "only warn once". 2. The variable was set when softlockup was reported. It was cleared only when the CPU was not longer in the softlockup state. 3. watchdog_touch_ts was not explicitly updated when the softlockup was reported. Without this variable, the report would normally be printed again during every following watchdog_timer_fn() invocation. The logic has got even more tangled up by the commit ed235875e2ca98 ("kernel/watchdog.c: print traces for all cpus on lockup detection"). After this commit, soft_watchdog_warn is set only when softlockup_all_cpu_backtrace is enabled. But multiple reports from all CPUs are prevented by a new variable soft_lockup_nmi_warn. Conclusion: The variable probably never worked as intended. In each case, it has not worked last many years because the softlockup was reported repeatedly after the full period defined by watchdog_thresh. The reason is that watchdog gets touched in many known slow paths, for example, in printk_stack_address(). This code is called also when printing the softlockup report. It means that the watchdog timestamp gets updated after each report. Solution: Simply remove the logic. People want the periodic report anyway. Link: https://lkml.kernel.org/r/20210311122130.6788-5-pmladek@suse.com Signed-off-by: Petr Mladek Cc: Ingo Molnar Cc: Laurence Oberman Cc: Michal Hocko Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Vincent Whitchurch Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 071802a3a9d90c0abbdb8777d52769d025a169af Author: Petr Mladek Date: Thu Apr 29 22:54:26 2021 -0700 watchdog/softlockup: report the overall time of softlockups [ Upstream commit fef06efc2ebaa94c8aee299b863e870467dbab8d ] The softlockup detector currently shows the time spent since the last report. As a result it is not clear whether a CPU is infinitely hogged by a single task or if it is a repeated event. The situation can be simulated with a simply busy loop: while (true) cpu_relax(); The softlockup detector produces: [ 168.277520] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! [cat:4865] [ 196.277604] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! [cat:4865] [ 236.277522] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! [cat:4865] But it should be, something like: [ 480.372418] watchdog: BUG: soft lockup - CPU#2 stuck for 26s! [cat:4943] [ 508.372359] watchdog: BUG: soft lockup - CPU#2 stuck for 52s! [cat:4943] [ 548.372359] watchdog: BUG: soft lockup - CPU#2 stuck for 89s! [cat:4943] [ 576.372351] watchdog: BUG: soft lockup - CPU#2 stuck for 115s! [cat:4943] For the better output, add an additional timestamp of the last report. Only this timestamp is reset when the watchdog is intentionally touched from slow code paths or when printing the report. Link: https://lkml.kernel.org/r/20210311122130.6788-4-pmladek@suse.com Signed-off-by: Petr Mladek Cc: Ingo Molnar Cc: Laurence Oberman Cc: Michal Hocko Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Vincent Whitchurch Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 04573e92b1d05b22ade4762e1caa467d635edb37 Author: Petr Mladek Date: Thu Apr 29 22:54:23 2021 -0700 watchdog: explicitly update timestamp when reporting softlockup [ Upstream commit c9ad17c991492f4390f42598f6ab0531f87eed07 ] The softlockup situation might stay for a long time or even forever. When it happens, the softlockup debug messages are printed in regular intervals defined by get_softlockup_thresh(). There is a mystery. The repeated message is printed after the full interval that is defined by get_softlockup_thresh(). But the timer callback is called more often as defined by sample_period. The code looks like the soflockup should get reported in every sample_period when it was once behind the thresh. It works only by chance. The watchdog is touched when printing the stall report, for example, in printk_stack_address(). Make the behavior clear and predictable by explicitly updating the timestamp in watchdog_timer_fn() when the report gets printed. Link: https://lkml.kernel.org/r/20210311122130.6788-3-pmladek@suse.com Signed-off-by: Petr Mladek Cc: Ingo Molnar Cc: Laurence Oberman Cc: Michal Hocko Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Vincent Whitchurch Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 15cfe627b05a3433babe2e8839cfd81a9cc60189 Author: Petr Mladek Date: Thu Apr 29 22:54:20 2021 -0700 watchdog: rename __touch_watchdog() to a better descriptive name [ Upstream commit 7c0012f522c802d25be102bafe54f333168e6119 ] Patch series "watchdog/softlockup: Report overall time and some cleanup", v2. I dug deep into the softlockup watchdog history when time permitted this year. And reworked the patchset that fixed timestamps and cleaned up the code[2]. I split it into very small steps and did even more code clean up. The result looks quite strightforward and I am pretty confident with the changes. [1] v2: https://lore.kernel.org/r/20201210160038.31441-1-pmladek@suse.com [2] v1: https://lore.kernel.org/r/20191024114928.15377-1-pmladek@suse.com This patch (of 6): There are many touch_*watchdog() functions. They are called in situations where the watchdog could report false positives or create unnecessary noise. For example, when CPU is entering idle mode, a virtual machine is stopped, or a lot of messages are printed in the atomic context. These functions set SOFTLOCKUP_RESET instead of a real timestamp. It allows to call them even in a context where jiffies might be outdated. For example, in an atomic context. The real timestamp is set by __touch_watchdog() that is called from the watchdog timer callback. Rename this callback to update_touch_ts(). It better describes the effect and clearly distinguish is from the other touch_*watchdog() functions. Another motivation is that two timestamps are going to be used. One will be used for the total softlockup time. The other will be used to measure time since the last report. The new function name will help to distinguish which timestamp is being updated. Link: https://lkml.kernel.org/r/20210311122130.6788-1-pmladek@suse.com Link: https://lkml.kernel.org/r/20210311122130.6788-2-pmladek@suse.com Signed-off-by: Petr Mladek Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Laurence Oberman Cc: Vincent Whitchurch Cc: Michal Hocko Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit fc8f347e12177af6442d93ea11ea1d78e63be7a0 Author: Sergei Trofimovich Date: Thu Apr 29 22:53:48 2021 -0700 ia64: module: fix symbolizer crash on fdescr [ Upstream commit 99e729bd40fb3272fa4b0140839d5e957b58588a ] Noticed failure as a crash on ia64 when tried to symbolize all backtraces collected by page_owner=on: $ cat /sys/kernel/debug/page_owner CPU: 1 PID: 2074 Comm: cat Not tainted 5.12.0-rc4 #226 Hardware name: hp server rx3600, BIOS 04.03 04/08/2008 ip is at dereference_module_function_descriptor+0x41/0x100 Crash happens at dereference_module_function_descriptor() due to use-after-free when dereferencing ".opd" section header. All section headers are already freed after module is laoded successfully. To keep symbolizer working the change stores ".opd" address and size after module is relocated to a new place and before section headers are discarded. To make similar errors less obscure module_finalize() now zeroes out all variables relevant to module loading only. Link: https://lkml.kernel.org/r/20210403074803.3309096-1-slyfox@gentoo.org Signed-off-by: Sergei Trofimovich Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 60e7dd22ba866cb238a1c5a7e0512c3eba22d72b Author: Michael Chan Date: Sun Apr 25 13:45:25 2021 -0400 bnxt_en: Add PCI IDs for Hyper-V VF devices. [ Upstream commit 7fbf359bb2c19c824cbb1954020680824f6ee5a5 ] Support VF device IDs used by the Hyper-V hypervisor. Reviewed-by: Vasundhara Volam Reviewed-by: Andy Gospodarek Signed-off-by: Edwin Peer Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 2c1cfecc94d09e61265a2118d6980c1d0b4bfc8a Author: Masahiro Yamada Date: Fri Mar 26 03:54:09 2021 +0900 kbuild: generate Module.symvers only when vmlinux exists [ Upstream commit 69bc8d386aebbd91a6bb44b6d33f77c8dfa9ed8c ] The external module build shows the following warning if Module.symvers is missing in the kernel tree. WARNING: Symbol version dump "Module.symvers" is missing. Modules may not have dependencies or modversions. I think this is an important heads-up because the resulting modules may not work as expected. This happens when you did not build the entire kernel tree, for example, you might have prepared the minimal setups for external modules by 'make defconfig && make modules_preapre'. A problem is that 'make modules' creates Module.symvers even without vmlinux. In this case, that warning is suppressed since Module.symvers already exists in spite of its incomplete content. The incomplete (i.e. invalid) Module.symvers should not be created. This commit changes the second pass of modpost to dump symbols into modules-only.symvers. The final Module.symvers is created by concatenating vmlinux.symvers and modules-only.symvers if both exist. Module.symvers is supposed to collect symbols from both vmlinux and modules. It might be a bit confusing, and I am not quite sure if it is an official interface, but presumably it is difficult to rename it because some tools (e.g. kmod) parse it. Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit d3f0131b86a9a016eb1577d556f540097675f1a5 Author: Petr Machata Date: Fri Apr 23 14:19:48 2021 +0200 selftests: mlxsw: Fix mausezahn invocation in ERSPAN scale test [ Upstream commit 1233898ab758cbcf5f6fea10b8dd16a0b2c24fab ] The mirror_gre_scale test creates as many ERSPAN sessions as the underlying chip supports, and tests that they all work. In order to determine that it issues a stream of ICMP packets and checks if they are mirrored as expected. However, the mausezahn invocation missed the -6 flag to identify the use of IPv6 protocol, and was sending ICMP messages over IPv6, as opposed to ICMP6. It also didn't pass an explicit source IP address, which apparently worked at some point in the past, but does not anymore. To fix these issues, extend the function mirror_test() in mirror_lib by detecting the IPv6 protocol addresses, and using a different ICMP scheme. Fix __mirror_gre_test() in the selftest itself to pass a source IP address. Signed-off-by: Petr Machata Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit cbcf354333eaac86aed0df2fe011f15b47023395 Author: Petr Machata Date: Fri Apr 23 14:19:47 2021 +0200 selftests: mlxsw: Increase the tolerance of backlog buildup [ Upstream commit dda7f4fa55839baeb72ae040aeaf9ccf89d3e416 ] The intention behind this test is to make sure that qdisc limit is correctly projected to the HW. However, first, due to rounding in the qdisc, and then in the driver, the number cannot actually be accurate. And second, the approach to testing this is to oversubscribe the port with traffic generated on the same switch. The actual backlog size therefore fluctuates. In practice, this test proved to be noisier than the rest, and spuriously fails every now and then. Increase the tolerance to 10 % to avoid these issues. Signed-off-by: Petr Machata Acked-by: Jiri Pirko Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d363d36093115c4597af6c17c0d305dec82f8d99 Author: Felix Fietkau Date: Thu Apr 22 22:20:54 2021 -0700 net: ethernet: mtk_eth_soc: fix RX VLAN offload [ Upstream commit 3f57d8c40fea9b20543cab4da12f4680d2ef182c ] The VLAN ID in the rx descriptor is only valid if the RX_DMA_VTAG bit is set. Fixes frames wrongly marked with VLAN tags. Signed-off-by: Felix Fietkau [Ilya: fix commit message] Signed-off-by: Ilya Lipnitskiy Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 6e541e8d52abafcbeab4be50b328f35bdf378481 Author: Stefan Assmann Date: Tue Mar 9 15:41:42 2021 +0100 iavf: remove duplicate free resources calls [ Upstream commit 1a0e880b028f97478dc689e2900b312741d0d772 ] Both iavf_free_all_tx_resources() and iavf_free_all_rx_resources() have already been called in the very same function. Remove the duplicate calls. Signed-off-by: Stefan Assmann Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 3b04966e08584d666b951b736d18efdf7b541d08 Author: Alexey Kardashevskiy Date: Mon Mar 1 17:36:53 2021 +1100 powerpc/iommu: Annotate nested lock for lockdep [ Upstream commit cc7130bf119add37f36238343a593b71ef6ecc1e ] The IOMMU table is divided into pools for concurrent mappings and each pool has a separate spinlock. When taking the ownership of an IOMMU group to pass through a device to a VM, we lock these spinlocks which triggers a false negative warning in lockdep (below). This fixes it by annotating the large pool's spinlock as a nest lock which makes lockdep not complaining when locking nested locks if the nest lock is locked already. === WARNING: possible recursive locking detected 5.11.0-le_syzkaller_a+fstn1 #100 Not tainted -------------------------------------------- qemu-system-ppc/4129 is trying to acquire lock: c0000000119bddb0 (&(p->lock)/1){....}-{2:2}, at: iommu_take_ownership+0xac/0x1e0 but task is already holding lock: c0000000119bdd30 (&(p->lock)/1){....}-{2:2}, at: iommu_take_ownership+0xac/0x1e0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&(p->lock)/1); lock(&(p->lock)/1); === Signed-off-by: Alexey Kardashevskiy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210301063653.51003-1-aik@ozlabs.ru Signed-off-by: Sasha Levin commit 51bf956d3c50f5219a4f298206da85dd32b554c8 Author: Lee Gibson Date: Mon Apr 19 15:58:42 2021 +0100 qtnfmac: Fix possible buffer overflow in qtnf_event_handle_external_auth [ Upstream commit 130f634da1af649205f4a3dd86cbe5c126b57914 ] Function qtnf_event_handle_external_auth calls memcpy without checking the length. A user could control that length and trigger a buffer overflow. Fix by checking the length is within the maximum allowed size. Signed-off-by: Lee Gibson Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210419145842.345787-1-leegib@gmail.com Signed-off-by: Sasha Levin commit 08f92310c387d838bdcdaddb7f767155c10fec99 Author: Gustavo A. R. Silva Date: Wed Apr 14 18:45:15 2021 -0500 wl3501_cs: Fix out-of-bounds warnings in wl3501_mgmt_join [ Upstream commit bb43e5718d8f1b46e7a77e7b39be3c691f293050 ] Fix the following out-of-bounds warnings by adding a new structure wl3501_req instead of duplicating the same members in structure wl3501_join_req and wl3501_scan_confirm: arch/x86/include/asm/string_32.h:182:25: warning: '__builtin_memcpy' offset [39, 108] from the object at 'sig' is out of the bounds of referenced subobject 'beacon_period' with type 'short unsigned int' at offset 36 [-Warray-bounds] arch/x86/include/asm/string_32.h:182:25: warning: '__builtin_memcpy' offset [25, 95] from the object at 'sig' is out of the bounds of referenced subobject 'beacon_period' with type 'short unsigned int' at offset 22 [-Warray-bounds] Refactor the code, accordingly: $ pahole -C wl3501_req drivers/net/wireless/wl3501_cs.o struct wl3501_req { u16 beacon_period; /* 0 2 */ u16 dtim_period; /* 2 2 */ u16 cap_info; /* 4 2 */ u8 bss_type; /* 6 1 */ u8 bssid[6]; /* 7 6 */ struct iw_mgmt_essid_pset ssid; /* 13 34 */ struct iw_mgmt_ds_pset ds_pset; /* 47 3 */ struct iw_mgmt_cf_pset cf_pset; /* 50 8 */ struct iw_mgmt_ibss_pset ibss_pset; /* 58 4 */ struct iw_mgmt_data_rset bss_basic_rset; /* 62 10 */ /* size: 72, cachelines: 2, members: 10 */ /* last cacheline: 8 bytes */ }; $ pahole -C wl3501_join_req drivers/net/wireless/wl3501_cs.o struct wl3501_join_req { u16 next_blk; /* 0 2 */ u8 sig_id; /* 2 1 */ u8 reserved; /* 3 1 */ struct iw_mgmt_data_rset operational_rset; /* 4 10 */ u16 reserved2; /* 14 2 */ u16 timeout; /* 16 2 */ u16 probe_delay; /* 18 2 */ u8 timestamp[8]; /* 20 8 */ u8 local_time[8]; /* 28 8 */ struct wl3501_req req; /* 36 72 */ /* size: 108, cachelines: 2, members: 10 */ /* last cacheline: 44 bytes */ }; $ pahole -C wl3501_scan_confirm drivers/net/wireless/wl3501_cs.o struct wl3501_scan_confirm { u16 next_blk; /* 0 2 */ u8 sig_id; /* 2 1 */ u8 reserved; /* 3 1 */ u16 status; /* 4 2 */ char timestamp[8]; /* 6 8 */ char localtime[8]; /* 14 8 */ struct wl3501_req req; /* 22 72 */ /* --- cacheline 1 boundary (64 bytes) was 30 bytes ago --- */ u8 rssi; /* 94 1 */ /* size: 96, cachelines: 2, members: 8 */ /* padding: 1 */ /* last cacheline: 32 bytes */ }; The problem is that the original code is trying to copy data into a bunch of struct members adjacent to each other in a single call to memcpy(). Now that a new struct wl3501_req enclosing all those adjacent members is introduced, memcpy() doesn't overrun the length of &sig.beacon_period and &this->bss_set[i].beacon_period, because the address of the new struct object _req_ is used as the destination, instead. This helps with the ongoing efforts to globally enable -Warray-bounds and get us closer to being able to tighten the FORTIFY_SOURCE routines on memcpy(). Link: https://github.com/KSPP/linux/issues/109 Reported-by: kernel test robot Signed-off-by: Gustavo A. R. Silva Reviewed-by: Kees Cook Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/1fbaf516da763b50edac47d792a9145aa4482e29.1618442265.git.gustavoars@kernel.org Signed-off-by: Sasha Levin commit 2b05548a844092c1d4780b2edd69971c1c2a24d6 Author: Gustavo A. R. Silva Date: Wed Apr 14 18:43:19 2021 -0500 wl3501_cs: Fix out-of-bounds warnings in wl3501_send_pkt [ Upstream commit 820aa37638a252b57967bdf4038a514b1ab85d45 ] Fix the following out-of-bounds warnings by enclosing structure members daddr and saddr into new struct addr, in structures wl3501_md_req and wl3501_md_ind: arch/x86/include/asm/string_32.h:182:25: warning: '__builtin_memcpy' offset [18, 23] from the object at 'sig' is out of the bounds of referenced subobject 'daddr' with type 'u8[6]' {aka 'unsigned char[6]'} at offset 11 [-Warray-bounds] arch/x86/include/asm/string_32.h:182:25: warning: '__builtin_memcpy' offset [18, 23] from the object at 'sig' is out of the bounds of referenced subobject 'daddr' with type 'u8[6]' {aka 'unsigned char[6]'} at offset 11 [-Warray-bounds] Refactor the code, accordingly: $ pahole -C wl3501_md_req drivers/net/wireless/wl3501_cs.o struct wl3501_md_req { u16 next_blk; /* 0 2 */ u8 sig_id; /* 2 1 */ u8 routing; /* 3 1 */ u16 data; /* 4 2 */ u16 size; /* 6 2 */ u8 pri; /* 8 1 */ u8 service_class; /* 9 1 */ struct { u8 daddr[6]; /* 10 6 */ u8 saddr[6]; /* 16 6 */ } addr; /* 10 12 */ /* size: 22, cachelines: 1, members: 8 */ /* last cacheline: 22 bytes */ }; $ pahole -C wl3501_md_ind drivers/net/wireless/wl3501_cs.o struct wl3501_md_ind { u16 next_blk; /* 0 2 */ u8 sig_id; /* 2 1 */ u8 routing; /* 3 1 */ u16 data; /* 4 2 */ u16 size; /* 6 2 */ u8 reception; /* 8 1 */ u8 pri; /* 9 1 */ u8 service_class; /* 10 1 */ struct { u8 daddr[6]; /* 11 6 */ u8 saddr[6]; /* 17 6 */ } addr; /* 11 12 */ /* size: 24, cachelines: 1, members: 9 */ /* padding: 1 */ /* last cacheline: 24 bytes */ }; The problem is that the original code is trying to copy data into a couple of arrays adjacent to each other in a single call to memcpy(). Now that a new struct _addr_ enclosing those two adjacent arrays is introduced, memcpy() doesn't overrun the length of &sig.daddr[0] and &sig.daddr, because the address of the new struct object _addr_ is used, instead. This helps with the ongoing efforts to globally enable -Warray-bounds and get us closer to being able to tighten the FORTIFY_SOURCE routines on memcpy(). Link: https://github.com/KSPP/linux/issues/109 Reported-by: kernel test robot Reviewed-by: Kees Cook Signed-off-by: Gustavo A. R. Silva Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/d260fe56aed7112bff2be5b4d152d03ad7b78e78.1618442265.git.gustavoars@kernel.org Signed-off-by: Sasha Levin commit 259cdcc2822c3ee385f08cf042274c42294f8af6 Author: Sean Christopherson Date: Tue Apr 6 15:49:45 2021 -0700 crypto: ccp: Free SEV device if SEV init fails [ Upstream commit b61a9071dc72a3c709192c0c00ab87c2b3de1d94 ] Free the SEV device if later initialization fails. The memory isn't technically leaked as it's tracked in the top-level device's devres list, but unless the top-level device is removed, the memory won't be freed and is effectively leaked. Signed-off-by: Sean Christopherson Message-Id: <20210406224952.4177376-2-seanjc@google.com> Reviewed-by: Brijesh Singh Acked-by: Tom Lendacky Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 0a80721349724feba71c55635c666c2ced484c25 Author: Felix Fietkau Date: Thu Apr 15 21:07:53 2021 +0200 mt76: mt7615: fix entering driver-own state on mt7663 [ Upstream commit 5c7d374444afdeb9dd534a37c4f6c13af032da0c ] Fixes hardware wakeup issues Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit b824c8101886397e869880bfb4d8ebdd64b518cc Author: Jinzhou Su Date: Tue Apr 20 16:17:14 2021 +0800 drm/amdgpu: Add mem sync flag for IB allocated by SA [ Upstream commit 5c88e3b86a88f14efa0a3ddd28641c6ff49fb9c4 ] The buffer of SA bo will be used by many cases. So it's better to invalidate the cache of indirect buffer allocated by SA before commit the IB. Signed-off-by: Jinzhou Su Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit d80cd200804544381f6ccf026ef6e6ecf7a02c4a Author: Dingchen (David) Zhang Date: Mon Jan 25 18:05:50 2021 -0500 drm/amd/display: add handling for hdcp2 rx id list validation [ Upstream commit 4ccf9446b2a3615615045346c97f8a1e2a16568a ] [why] the current implementation of hdcp2 rx id list validation does not have handler/checker for invalid message status, e.g. HMAC, the V parameter calculated from PSP not matching the V prime from Rx. [how] return a generic FAILURE for any message status not SUCCESS or REVOKED. Signed-off-by: Dingchen (David) Zhang Reviewed-by: Bhawanpreet Lakha Acked-by: Aurabindo Pillai Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit be3fd94c21df940cf47067ddb12b1a4682d6ba12 Author: Robin Singh Date: Mon Dec 14 19:14:48 2020 -0500 drm/amd/display: fixed divide by zero kernel crash during dsc enablement [ Upstream commit 19cc1f3829567e7dca21c1389ea6407b8f5efab4 ] [why] During dsc enable, a divide by zero condition triggered the kernel crash. [how] An IGT test, which enable the DSC, was crashing at the time of restore the default dsc status, becaue of h_totals value becoming 0. So add a check before divide condition. If h_total is zero, gracefully ignore and set the default value. kernel panic log: [ 128.758827] divide error: 0000 [#1] PREEMPT SMP NOPTI [ 128.762714] CPU: 5 PID: 4562 Comm: amd_dp_dsc Tainted: G W 5.4.19-android-x86_64 #1 [ 128.769728] Hardware name: ADVANCED MICRO DEVICES, INC. Mauna/Mauna, BIOS WMN0B13N Nov 11 2020 [ 128.777695] RIP: 0010:hubp2_vready_at_or_After_vsync+0x37/0x7a [amdgpu] [ 128.785707] Code: 80 02 00 00 48 89 f3 48 8b 7f 08 b ...... [ 128.805696] RSP: 0018:ffffad8f82d43628 EFLAGS: 00010246 ...... [ 128.857707] CR2: 00007106d8465000 CR3: 0000000426530000 CR4: 0000000000140ee0 [ 128.865695] Call Trace: [ 128.869712] hubp3_setup+0x1f/0x7f [amdgpu] [ 128.873705] dcn20_update_dchubp_dpp+0xc8/0x54a [amdgpu] [ 128.877706] dcn20_program_front_end_for_ctx+0x31d/0x463 [amdgpu] [ 128.885706] dc_commit_state+0x3d2/0x658 [amdgpu] [ 128.889707] amdgpu_dm_atomic_commit_tail+0x4b3/0x1e7c [amdgpu] [ 128.897699] ? dm_read_reg_func+0x41/0xb5 [amdgpu] [ 128.901707] ? dm_read_reg_func+0x41/0xb5 [amdgpu] [ 128.905706] ? __is_insn_slot_addr+0x43/0x48 [ 128.909706] ? fill_plane_buffer_attributes+0x29e/0x3dc [amdgpu] [ 128.917705] ? dm_plane_helper_prepare_fb+0x255/0x284 [amdgpu] [ 128.921700] ? usleep_range+0x7c/0x7c [ 128.925705] ? preempt_count_sub+0xf/0x18 [ 128.929706] ? _raw_spin_unlock_irq+0x13/0x24 [ 128.933732] ? __wait_for_common+0x11e/0x18f [ 128.937705] ? _raw_spin_unlock_irq+0x13/0x24 [ 128.941706] ? __wait_for_common+0x11e/0x18f [ 128.945705] commit_tail+0x8b/0xd2 [drm_kms_helper] [ 128.949707] drm_atomic_helper_commit+0xd8/0xf5 [drm_kms_helper] [ 128.957706] amdgpu_dm_atomic_commit+0x337/0x360 [amdgpu] [ 128.961705] ? drm_atomic_check_only+0x543/0x68d [drm] [ 128.969705] ? drm_atomic_set_property+0x760/0x7af [drm] [ 128.973704] ? drm_mode_atomic_ioctl+0x6f3/0x85a [drm] [ 128.977705] drm_mode_atomic_ioctl+0x6f3/0x85a [drm] [ 128.985705] ? drm_atomic_set_property+0x7af/0x7af [drm] [ 128.989706] drm_ioctl_kernel+0x82/0xda [drm] [ 128.993706] drm_ioctl+0x225/0x319 [drm] [ 128.997707] ? drm_atomic_set_property+0x7af/0x7af [drm] [ 129.001706] ? preempt_count_sub+0xf/0x18 [ 129.005713] amdgpu_drm_ioctl+0x4b/0x76 [amdgpu] [ 129.009705] vfs_ioctl+0x1d/0x2a [ 129.013705] do_vfs_ioctl+0x419/0x43d [ 129.017707] ksys_ioctl+0x52/0x71 [ 129.021707] __x64_sys_ioctl+0x16/0x19 [ 129.025706] do_syscall_64+0x78/0x85 [ 129.029705] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Signed-off-by: Robin Singh Reviewed-by: Harry Wentland Reviewed-by: Robin Singh Acked-by: Aurabindo Pillai Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit e39ff623cdec5dcaa91482666682bbdd08e0c084 Author: Michael Ellerman Date: Sun Apr 18 23:54:13 2021 +1000 powerpc/pseries: Stop calling printk in rtas_stop_self() [ Upstream commit ed8029d7b472369a010a1901358567ca3b6dbb0d ] RCU complains about us calling printk() from an offline CPU: ============================= WARNING: suspicious RCU usage 5.12.0-rc7-02874-g7cf90e481cb8 #1 Not tainted ----------------------------- kernel/locking/lockdep.c:3568 RCU-list traversed in non-reader section!! other info that might help us debug this: RCU used illegally from offline CPU! rcu_scheduler_active = 2, debug_locks = 1 no locks held by swapper/0/0. stack backtrace: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.12.0-rc7-02874-g7cf90e481cb8 #1 Call Trace: dump_stack+0xec/0x144 (unreliable) lockdep_rcu_suspicious+0x124/0x144 __lock_acquire+0x1098/0x28b0 lock_acquire+0x128/0x600 _raw_spin_lock_irqsave+0x6c/0xc0 down_trylock+0x2c/0x70 __down_trylock_console_sem+0x60/0x140 vprintk_emit+0x1a8/0x4b0 vprintk_func+0xcc/0x200 printk+0x40/0x54 pseries_cpu_offline_self+0xc0/0x120 arch_cpu_idle_dead+0x54/0x70 do_idle+0x174/0x4a0 cpu_startup_entry+0x38/0x40 rest_init+0x268/0x388 start_kernel+0x748/0x790 start_here_common+0x1c/0x614 Which happens because by the time we get to rtas_stop_self() we are already offline. In addition the message can be spammy, and is not that helpful for users, so remove it. Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210418135413.1204031-1-mpe@ellerman.id.au Signed-off-by: Sasha Levin commit 0737b426244cd1487d98852f9860b0e0d6b26519 Author: Yaqi Chen Date: Fri Apr 16 23:48:03 2021 +0800 samples/bpf: Fix broken tracex1 due to kprobe argument change [ Upstream commit 137733d08f4ab14a354dacaa9a8fc35217747605 ] >From commit c0bbbdc32feb ("__netif_receive_skb_core: pass skb by reference"), the first argument passed into __netif_receive_skb_core has changed to reference of a skb pointer. This commit fixes by using bpf_probe_read_kernel. Signed-off-by: Yaqi Chen Signed-off-by: Alexei Starovoitov Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20210416154803.37157-1-chendotjs@gmail.com Signed-off-by: Sasha Levin commit 274e30f3f85bbc99db42ddbeafa29dfcd1a6fa82 Author: Du Cheng Date: Sat Apr 17 07:30:46 2021 +0800 net: sched: tapr: prevent cycle_time == 0 in parse_taprio_schedule [ Upstream commit ed8157f1ebf1ae81a8fa2653e3f20d2076fad1c9 ] There is a reproducible sequence from the userland that will trigger a WARN_ON() condition in taprio_get_start_time, which causes kernel to panic if configured as "panic_on_warn". Catch this condition in parse_taprio_schedule to prevent this condition. Reported as bug on syzkaller: https://syzkaller.appspot.com/bug?extid=d50710fd0873a9c6b40c Reported-by: syzbot+d50710fd0873a9c6b40c@syzkaller.appspotmail.com Signed-off-by: Du Cheng Acked-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 47a0bb49f2eedb18e2c40c3a896917fb677b5e15 Author: Gustavo A. R. Silva Date: Fri Apr 16 15:15:40 2021 -0500 ethtool: ioctl: Fix out-of-bounds warning in store_link_ksettings_for_user() [ Upstream commit c1d9e34e11281a8ba1a1c54e4db554232a461488 ] Fix the following out-of-bounds warning: net/ethtool/ioctl.c:492:2: warning: 'memcpy' offset [49, 84] from the object at 'link_usettings' is out of the bounds of referenced subobject 'base' with type 'struct ethtool_link_settings' at offset 0 [-Warray-bounds] The problem is that the original code is trying to copy data into a some struct members adjacent to each other in a single call to memcpy(). This causes a legitimate compiler warning because memcpy() overruns the length of &link_usettings.base. Fix this by directly using &link_usettings and _from_ as destination and source addresses, instead. This helps with the ongoing efforts to globally enable -Warray-bounds and get us closer to being able to tighten the FORTIFY_SOURCE routines on memcpy(). Link: https://github.com/KSPP/linux/issues/109 Reported-by: kernel test robot Signed-off-by: Gustavo A. R. Silva Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 33fe1e54657d621376b951ee37adbb0534237205 Author: David Ward Date: Sun Apr 18 09:46:58 2021 -0400 ASoC: rt286: Generalize support for ALC3263 codec [ Upstream commit aa2f9c12821e6a4ba1df4fb34a3dbc6a2a1ee7fe ] The ALC3263 codec on the XPS 13 9343 is also found on the Latitude 13 7350 and Venue 11 Pro 7140. They require the same handling for the combo jack to work with a headset: GPIO pin 6 must be set. The HDA driver always sets this pin on the ALC3263, which it distinguishes by the codec vendor/device ID 0x10ec0288 and PCI subsystem vendor ID 0x1028 (Dell). The ASoC driver does not use PCI, so adapt this check to use DMI to determine if Dell is the system vendor. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=150601 BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=205961 Signed-off-by: David Ward Reviewed-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20210418134658.4333-6-david.ward@gatech.edu Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f7fcd7b556054110ece8128d5ed2801cc2c51c40 Author: Emmanuel Grumbach Date: Fri Apr 9 12:40:16 2021 +0300 mac80211: properly drop the connection in case of invalid CSA IE [ Upstream commit 253907ab8bc0818639af382f6398810fa1f022b3 ] In case the frequency is invalid, ieee80211_parse_ch_switch_ie will fail and we may not even reach the check in ieee80211_sta_process_chanswitch. Drop the connection in case ieee80211_parse_ch_switch_ie failed, but still take into account the CSA mode to remember not to send a deauth frame in case if it is forbidden to. Signed-off-by: Emmanuel Grumbach Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20210409123755.34712ef96a0a.I75d7ad7f1d654e8b0aa01cd7189ff00a510512b3@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 21f1d27b06b993bab0e7e386b9a6804a21a43e1b Author: David Mosberger-Tang Date: Wed Mar 3 19:50:07 2021 +0000 wilc1000: Bring MAC address setting in line with typical Linux behavior [ Upstream commit a381b78a1598dde34a6e40dae2842024308a6ef2 ] Linux network drivers normally disallow changing the MAC address when the interface is up. This driver has been different in that it allows to change the MAC address *only* when it's up. This patch brings wilc1000 behavior more in line with other network drivers. We could have replaced wilc_set_mac_addr() with eth_mac_addr() but that would break existing documentation on how to change the MAC address. Likewise, return -EADDRNOTAVAIL (not -EINVAL) when the specified MAC address is invalid or unavailable. Signed-off-by: David Mosberger-Tang Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210303194846.1823596-1-davidm@egauge.net Signed-off-by: Sasha Levin commit 629d855c0f2f8767a42a565cc2440a7b1cfd1aec Author: Srikar Dronamraju Date: Thu Apr 1 21:12:00 2021 +0530 powerpc/smp: Set numa node before updating mask [ Upstream commit 6980d13f0dd189846887bbbfa43793d9a41768d3 ] Geethika reported a trace when doing a dlpar CPU add. ------------[ cut here ]------------ WARNING: CPU: 152 PID: 1134 at kernel/sched/topology.c:2057 CPU: 152 PID: 1134 Comm: kworker/152:1 Not tainted 5.12.0-rc5-master #5 Workqueue: events cpuset_hotplug_workfn NIP: c0000000001cfc14 LR: c0000000001cfc10 CTR: c0000000007e3420 REGS: c0000034a08eb260 TRAP: 0700 Not tainted (5.12.0-rc5-master+) MSR: 8000000000029033 CR: 28828422 XER: 00000020 CFAR: c0000000001fd888 IRQMASK: 0 #012GPR00: c0000000001cfc10 c0000034a08eb500 c000000001f35400 0000000000000027 #012GPR04: c0000035abaa8010 c0000035abb30a00 0000000000000027 c0000035abaa8018 #012GPR08: 0000000000000023 c0000035abaaef48 00000035aa540000 c0000035a49dffe8 #012GPR12: 0000000028828424 c0000035bf1a1c80 0000000000000497 0000000000000004 #012GPR16: c00000000347a258 0000000000000140 c00000000203d468 c000000001a1a490 #012GPR20: c000000001f9c160 c0000034adf70920 c0000034aec9fd20 0000000100087bd3 #012GPR24: 0000000100087bd3 c0000035b3de09f8 0000000000000030 c0000035b3de09f8 #012GPR28: 0000000000000028 c00000000347a280 c0000034aefe0b00 c0000000010a2a68 NIP [c0000000001cfc14] build_sched_domains+0x6a4/0x1500 LR [c0000000001cfc10] build_sched_domains+0x6a0/0x1500 Call Trace: [c0000034a08eb500] [c0000000001cfc10] build_sched_domains+0x6a0/0x1500 (unreliable) [c0000034a08eb640] [c0000000001d1e6c] partition_sched_domains_locked+0x3ec/0x530 [c0000034a08eb6e0] [c0000000002936d4] rebuild_sched_domains_locked+0x524/0xbf0 [c0000034a08eb7e0] [c000000000296bb0] rebuild_sched_domains+0x40/0x70 [c0000034a08eb810] [c000000000296e74] cpuset_hotplug_workfn+0x294/0xe20 [c0000034a08ebc30] [c000000000178dd0] process_one_work+0x300/0x670 [c0000034a08ebd10] [c0000000001791b8] worker_thread+0x78/0x520 [c0000034a08ebda0] [c000000000185090] kthread+0x1a0/0x1b0 [c0000034a08ebe10] [c00000000000ccec] ret_from_kernel_thread+0x5c/0x70 Instruction dump: 7d2903a6 4e800421 e8410018 7f67db78 7fe6fb78 7f45d378 7f84e378 7c681b78 3c62ff1a 3863c6f8 4802dc35 60000000 <0fe00000> 3920fff4 f9210070 e86100a0 ---[ end trace 532d9066d3d4d7ec ]--- Some of the per-CPU masks use cpu_cpu_mask as a filter to limit the search for related CPUs. On a dlpar add of a CPU, update cpu_cpu_mask before updating the per-CPU masks. This will ensure the cpu_cpu_mask is updated correctly before its used in setting the masks. Setting the numa_node will ensure that when cpu_cpu_mask() gets called, the correct node number is used. This code movement helped fix the above call trace. Reported-by: Geetika Moolchandani Signed-off-by: Srikar Dronamraju Reviewed-by: Nathan Lynch Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210401154200.150077-1-srikar@linux.vnet.ibm.com Signed-off-by: Sasha Levin commit 44880149f825604d46f71a96207b7988163f98e5 Author: Cédric Le Goater Date: Tue Apr 13 15:03:52 2021 +0200 powerpc/xive: Use the "ibm, chip-id" property only under PowerNV [ Upstream commit e9e16917bc388846163b8566a298a291d71e44c9 ] The 'chip_id' field of the XIVE CPU structure is used to choose a target for a source located on the same chip. For that, the XIVE driver queries the chip identifier from the "ibm,chip-id" property and compares it to a 'src_chip' field identifying the chip of a source. This information is only available on the PowerNV platform, 'src_chip' being assigned to XIVE_INVALID_CHIP_ID under pSeries. The "ibm,chip-id" property is also not available on all platforms. It was first introduced on PowerNV and later, under QEMU for pSeries/KVM. However, the property is not part of PAPR and does not exist under pSeries/PowerVM. Assign 'chip_id' to XIVE_INVALID_CHIP_ID by default and let the PowerNV platform override the value with the "ibm,chip-id" property. Signed-off-by: Cédric Le Goater Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210413130352.1183267-1-clg@kaod.org Signed-off-by: Sasha Levin commit a4fae79e1c4ed4c6220104acca088d23c27720c6 Author: Gustavo A. R. Silva Date: Fri Apr 16 14:31:51 2021 -0500 flow_dissector: Fix out-of-bounds warning in __skb_flow_bpf_to_target() [ Upstream commit 1e3d976dbb23b3fce544752b434bdc32ce64aabc ] Fix the following out-of-bounds warning: net/core/flow_dissector.c:835:3: warning: 'memcpy' offset [33, 48] from the object at 'flow_keys' is out of the bounds of referenced subobject 'ipv6_src' with type '__u32[4]' {aka 'unsigned int[4]'} at offset 16 [-Warray-bounds] The problem is that the original code is trying to copy data into a couple of struct members adjacent to each other in a single call to memcpy(). So, the compiler legitimately complains about it. As these are just a couple of members, fix this by copying each one of them in separate calls to memcpy(). This helps with the ongoing efforts to globally enable -Warray-bounds and get us closer to being able to tighten the FORTIFY_SOURCE routines on memcpy(). Link: https://github.com/KSPP/linux/issues/109 Reported-by: kernel test robot Signed-off-by: Gustavo A. R. Silva Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e123fdd294a10fd210dcefc32bd8f21ea448e25f Author: Gustavo A. R. Silva Date: Fri Apr 16 14:12:36 2021 -0500 sctp: Fix out-of-bounds warning in sctp_process_asconf_param() [ Upstream commit e5272ad4aab347dde5610c0aedb786219e3ff793 ] Fix the following out-of-bounds warning: net/sctp/sm_make_chunk.c:3150:4: warning: 'memcpy' offset [17, 28] from the object at 'addr' is out of the bounds of referenced subobject 'v4' with type 'struct sockaddr_in' at offset 0 [-Warray-bounds] This helps with the ongoing efforts to globally enable -Warray-bounds and get us closer to being able to tighten the FORTIFY_SOURCE routines on memcpy(). Link: https://github.com/KSPP/linux/issues/109 Reported-by: kernel test robot Signed-off-by: Gustavo A. R. Silva Reviewed-by: Kees Cook Acked-by: Marcelo Ricardo Leitner Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 6d978f701bcf2b1148b2bfa880fca36e0a37e47f Author: Jarkko Nikula Date: Mon Apr 12 16:41:12 2021 +0300 i2c: i801: Add support for Intel Alder Lake PCH-M [ Upstream commit 8f51c1763ae98bb63fc04627ceae383aa0e8ff7b ] Add PCI ID of SMBus controller on Intel Alder Lake PCH-M. Signed-off-by: Jarkko Nikula Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 78fc41e6216fbc5d082760f9d58e84c07ab93546 Author: Kai Vehmanen Date: Fri Apr 16 16:11:57 2021 +0300 ALSA: hda/hdmi: fix race in handling acomp ELD notification at resume [ Upstream commit 0c37e2eb6b83e375e8a654d01598292d5591fc65 ] When snd-hda-codec-hdmi is used with ASoC HDA controller like SOF (acomp used for ELD notifications), display connection change done during suspend, can be lost due to following sequence of events: 1. system in S3 suspend 2. DP/HDMI receiver connected 3. system resumed 4. HDA controller resumed, but card->deferred_resume_work not complete 5. acomp eld_notify callback 6. eld_notify ignored as power state is not CTL_POWER_D0 7. HDA resume deferred work completed, power state set to CTL_POWER_D0 This results in losing the notification, and the jack state reported to user-space is not correct. The check on step 6 was added in commit 8ae743e82f0b ("ALSA: hda - Skip ELD notification during system suspend"). It would seem with the deferred resume logic in ASoC core, this check is not safe. Fix the issue by modifying the check to use "dev.power.power_state.event" instead of ALSA specific card power state variable. BugLink: https://github.com/thesofproject/linux/issues/2825 Suggested-by: Takashi Iwai Signed-off-by: Kai Vehmanen Link: https://lore.kernel.org/r/20210416131157.1881366-1-kai.vehmanen@linux.intel.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit c79b6ef5f94761742700092ec9198652bfad8177 Author: Vamshi Krishna Gopal Date: Thu Apr 15 12:50:09 2021 -0500 ASoC: Intel: sof_sdw: add quirk for new ADL-P Rvp [ Upstream commit d25bbe80485f8bcbbeb91a2a6cd8798c124b27b7 ] Add quirks for jack detection, rt711 DAI and DMIC Reviewed-by: Bard Liao Reviewed-by: Kai Vehmanen Signed-off-by: Vamshi Krishna Gopal Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20210415175013.192862-6-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 59a9814c84401db9f96022226fec9675120b4251 Author: Takashi Iwai Date: Fri Apr 16 10:12:11 2021 +0200 ALSA: hda/realtek: Add quirk for Lenovo Ideapad S740 [ Upstream commit 26928ca1f06aab4361eb5adbe7ef3b5c82f13cf2 ] Lenovo Ideapad S740 requires quite a few COEF setups to make its speakers working. The verb table was provided from Ryan Prescott as the result of investigation via qemu: https://github.com/ryanprescott/realtek-verb-tools/wiki/How-to-sniff-verbs-from-a-Windows-sound-driver BugLink: https://github.com/thesofproject/linux/issues/2748 Tested-by: Ryan Prescott Link: https://lore.kernel.org/r/20210416081211.20059-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 3c96f542bf751c3e6c16c28b57d737aedbcc106e Author: Mihai Moldovan Date: Thu Apr 15 09:28:03 2021 +0200 kconfig: nconf: stop endless search loops [ Upstream commit 8c94b430b9f6213dec84e309bb480a71778c4213 ] If the user selects the very first entry in a page and performs a search-up operation, or selects the very last entry in a page and performs a search-down operation that will not succeed (e.g., via [/]asdfzzz[Up Arrow]), nconf will never terminate searching the page. The reason is that in this case, the starting point will be set to -1 or n, which is then translated into (n - 1) (i.e., the last entry of the page) or 0 (i.e., the first entry of the page) and finally the search begins. This continues to work fine until the index reaches 0 or (n - 1), at which point it will be decremented to -1 or incremented to n, but not checked against the starting point right away. Instead, it's wrapped around to the bottom or top again, after which the starting point check occurs... and naturally fails. My original implementation added another check for -1 before wrapping the running index variable around, but Masahiro Yamada pointed out that the actual issue is that the comparison point (starting point) exceeds bounds (i.e., the [0,n-1] interval) in the first place and that, instead, the starting point should be fixed. This has the welcome side-effect of also fixing the case where the starting point was n while searching down, which also lead to an infinite loop. OTOH, this code is now essentially all his work. Amazingly, nobody seems to have been hit by this for 11 years - or at the very least nobody bothered to debug and fix this. Signed-off-by: Mihai Moldovan Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit b09c2f7325009fcf37dc4e2dc2ffb254a697b426 Author: Yonghong Song Date: Tue Apr 13 08:34:13 2021 -0700 selftests: Set CC to clang in lib.mk if LLVM is set [ Upstream commit 26e6dd1072763cd5696b75994c03982dde952ad9 ] selftests/bpf/Makefile includes lib.mk. With the following command make -j60 LLVM=1 LLVM_IAS=1 <=== compile kernel make -j60 -C tools/testing/selftests/bpf LLVM=1 LLVM_IAS=1 V=1 some files are still compiled with gcc. This patch fixed lib.mk issue which sets CC to gcc in all cases. Signed-off-by: Yonghong Song Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20210413153413.3027426-1-yhs@fb.com Signed-off-by: Sasha Levin commit dd74af4f37be5326466507cf84260f723af28ab8 Author: Anthony Wang Date: Wed Mar 31 11:03:35 2021 -0400 drm/amd/display: Force vsync flip when reconfiguring MPCC [ Upstream commit 56d63782af9bbd1271bff1422a6a013123eade4d ] [Why] Underflow observed when disabling PIP overlay in-game when vsync is disabled, due to OTC master lock not working with game pipe which is immediate flip. [How] When performing a full update, override flip_immediate value to false for all planes, so that flip occurs on vsync. Signed-off-by: Anthony Wang Acked-by: Bindu Ramamurthy Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 0bf066735babc279b041032ce562f10852a8ae52 Author: Suravee Suthikulpanit Date: Fri Apr 9 03:58:48 2021 -0500 iommu/amd: Remove performance counter pre-initialization test [ Upstream commit 994d6608efe4a4c8834bdc5014c86f4bc6aceea6 ] In early AMD desktop/mobile platforms (during 2013), when the IOMMU Performance Counter (PMC) support was first introduced in commit 30861ddc9cca ("perf/x86/amd: Add IOMMU Performance Counter resource management"), there was a HW bug where the counters could not be accessed. The result was reading of the counter always return zero. At the time, the suggested workaround was to add a test logic prior to initializing the PMC feature to check if the counters can be programmed and read back the same value. This has been working fine until the more recent desktop/mobile platforms start enabling power gating for the PMC, which prevents access to the counters. This results in the PMC support being disabled unnecesarily. Unfortunatly, there is no documentation of since which generation of hardware the original PMC HW bug was fixed. Although, it was fixed soon after the first introduction of the PMC. Base on this, we assume that the buggy platforms are less likely to be in used, and it should be relatively safe to remove this legacy logic. Link: https://lore.kernel.org/linux-iommu/alpine.LNX.3.20.13.2006030935570.3181@monopod.intra.ispras.ru/ Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=201753 Cc: Tj (Elloe Linux) Cc: Shuah Khan Cc: Alexander Monakov Cc: David Coe Cc: Paul Menzel Signed-off-by: Suravee Suthikulpanit Tested-by: Shuah Khan Link: https://lore.kernel.org/r/20210409085848.3908-3-suravee.suthikulpanit@amd.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 40b97d88acbe6289a75c2de9fb3cd13b110b68f0 Author: Paul Menzel Date: Fri Apr 9 03:58:47 2021 -0500 Revert "iommu/amd: Fix performance counter initialization" [ Upstream commit 715601e4e36903a653cd4294dfd3ed0019101991 ] This reverts commit 6778ff5b21bd8e78c8bd547fd66437cf2657fd9b. The original commit tries to address an issue, where PMC power-gating causing the IOMMU PMC pre-init test to fail on certain desktop/mobile platforms where the power-gating is normally enabled. There have been several reports that the workaround still does not guarantee to work, and can add up to 100 ms (on the worst case) to the boot process on certain platforms such as the MSI B350M MORTAR with AMD Ryzen 3 2200G. Therefore, revert this commit as a prelude to removing the pre-init test. Link: https://lore.kernel.org/linux-iommu/alpine.LNX.3.20.13.2006030935570.3181@monopod.intra.ispras.ru/ Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=201753 Cc: Tj (Elloe Linux) Cc: Shuah Khan Cc: Alexander Monakov Cc: David Coe Signed-off-by: Paul Menzel Signed-off-by: Suravee Suthikulpanit Link: https://lore.kernel.org/r/20210409085848.3908-2-suravee.suthikulpanit@amd.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit a9863a282f98cd8bdd89e51dd2d72ab5480d0e81 Author: Florian Fainelli Date: Wed Apr 14 22:22:57 2021 +0300 net: bridge: propagate error code and extack from br_mc_disabled_update [ Upstream commit ae1ea84b33dab45c7b6c1754231ebda5959b504c ] Some Ethernet switches might only be able to support disabling multicast snooping globally, which is an issue for example when several bridges span the same physical device and request contradictory settings. Propagate the return value of br_mc_disabled_update() such that this limitation is transmitted correctly to user-space. Signed-off-by: Florian Fainelli Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit dc49a6391b289bd9123b281ce13f48b9899ee4b7 Author: Kuninori Morimoto Date: Thu Apr 8 13:28:38 2021 +0900 ASoC: rsnd: call rsnd_ssi_master_clk_start() from rsnd_ssi_init() [ Upstream commit a122a116fc6d8fcf2f202dcd185173a54268f239 ] Current rsnd needs to call .prepare (P) for clock settings, .trigger for playback start (S) and stop (E). It should be called as below from SSI point of view. P -> S -> E -> P -> S -> E -> ... But, if you used MIXer, below case might happen (2) 1: P -> S ---> E -> ... 2: P ----> S -> ... (1) (3) P(1) setups clock, but E(2) resets it. and starts playback (3). In such case, it will reports "SSI parent/child should use same rate". rsnd_ssi_master_clk_start() which is the main function at (P) was called from rsnd_ssi_init() (= S) before, but was moved by below patch to rsnd_soc_dai_prepare() (= P) to avoid using clk_get_rate() which shouldn't be used under atomic context. commit 4d230d1271064 ("ASoC: rsnd: fixup not to call clk_get/set under non-atomic") Because of above patch, rsnd_ssi_master_clk_start() is now called at (P) which is for non atomic context. But (P) is assuming that spin lock is *not* used. One issue now is rsnd_ssi_master_clk_start() is checking ssi->xxx which should be protected by spin lock. After above patch, adg.c had below patch for other reasons. commit 06e8f5c842f2d ("ASoC: rsnd: don't call clk_get_rate() under atomic context") clk_get_rate() is used at probe() timing by this patch. In other words, rsnd_ssi_master_clk_start() is no longer using clk_get_rate() any more. This means we can call it from rsnd_ssi_init() (= S) again which is protected by spin lock. This patch re-move it to under spin lock, and solves 1. checking ssi->xxx without spin lock issue. 2. clk setting / device start / device stop race condition. Reported-by: Linh Phung T. Y. Signed-off-by: Kuninori Morimoto Link: https://lore.kernel.org/r/875z0x1jt5.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit b9ffa48e3d194e222c20f823ac3b5cae038267a6 Author: Vaibhav Jain Date: Sun Apr 4 22:01:48 2021 +0530 powerpc/mm: Add cond_resched() while removing hpte mappings [ Upstream commit a5d6a3e73acbd619dd5b7b831762b755f9e2db80 ] While removing large number of mappings from hash page tables for large memory systems as soft-lockup is reported because of the time spent inside htap_remove_mapping() like one below: watchdog: BUG: soft lockup - CPU#8 stuck for 23s! NIP plpar_hcall+0x38/0x58 LR pSeries_lpar_hpte_invalidate+0x68/0xb0 Call Trace: 0x1fffffffffff000 (unreliable) pSeries_lpar_hpte_removebolted+0x9c/0x230 hash__remove_section_mapping+0xec/0x1c0 remove_section_mapping+0x28/0x3c arch_remove_memory+0xfc/0x150 devm_memremap_pages_release+0x180/0x2f0 devm_action_release+0x30/0x50 release_nodes+0x28c/0x300 device_release_driver_internal+0x16c/0x280 unbind_store+0x124/0x170 drv_attr_store+0x44/0x60 sysfs_kf_write+0x64/0x90 kernfs_fop_write+0x1b0/0x290 __vfs_write+0x3c/0x70 vfs_write+0xd4/0x270 ksys_write+0xdc/0x130 system_call+0x5c/0x70 Fix this by adding a cond_resched() to the loop in htap_remove_mapping() that issues hcall to remove hpte mapping. The call to cond_resched() is issued every HZ jiffies which should prevent the soft-lockup from being reported. Suggested-by: Aneesh Kumar K.V Signed-off-by: Vaibhav Jain Reviewed-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210404163148.321346-1-vaibhav@linux.ibm.com Signed-off-by: Sasha Levin commit 92dbe230fbef493f6e55047675ba6abcaa1f1082 Author: Johannes Berg Date: Sun Apr 11 13:25:41 2021 +0300 iwlwifi: trans/pcie: defer transport initialisation [ Upstream commit d12455fdbfe9430affd88bfbfee51777356667a0 ] In a few PCIe devices we may have to swap out the configuration after we allocate/initialise some parts of the device because we only know the correct one after reading some registers. This causes some things such as the byte-count table allocations to be incorrect, since the configuration is swapped for one with a bigger queue size. Fix this by initialising most of the transport much later, only after the configuration has finally been determined. Signed-off-by: Johannes Berg Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20210411132130.8f5db97db1e4.Ic622da559b586a04ca536a0ec49ed5ecf03a9354@changeid Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin commit 60b9f967ad03ee0578f6046cc98c2057472c451c Author: Mordechay Goodstein Date: Sun Apr 11 12:46:22 2021 +0300 iwlwifi: queue: avoid memory leak in reset flow [ Upstream commit 4cf2f5904d971a461f67825434ae3c31900ff84b ] In case the device is stopped any usage of hw queues needs to be reallocated in fw due to fw reset after device stop, so all driver internal queue should also be freed, and if we don't free the next usage would leak the old memory and get in recover flows "iwlwifi 0000:00:03.0: dma_pool_destroy iwlwifi:bc" warning. Also warn about trying to reuse an internal allocated queue. Signed-off-by: Mordechay Goodstein Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20210411124417.c72d2f0355c4.Ia3baff633b9b9109f88ab379ef0303aa152c16bf@changeid Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin commit d441b3a309eced434e0e4fc2a2fc7cc04ed97399 Author: Johannes Berg Date: Tue Mar 30 16:24:58 2021 +0300 iwlwifi: pcie: make cfg vs. trans_cfg more robust [ Upstream commit 48a5494d6a4cb5812f0640d9515f1876ffc7a013 ] If we (for example) have a trans_cfg entry in the PCI IDs table, but then don't find a full cfg entry for it in the info table, we fall through to the code that treats the PCI ID table entry as a full cfg entry. This obviously causes crashes later, e.g. when trying to build the firmware name string. Avoid such crashes by using the low bit of the pointer as a tag for trans_cfg entries (automatically using a macro that checks the type when assigning) and then checking that before trying to use the data as a full entry - if it's just a partial entry at that point, fail. Since we're adding some macro magic, also check that the type is in fact either struct iwl_cfg_trans_params or struct iwl_cfg, failing compilation ("initializer element is not constant") if it isn't. Signed-off-by: Johannes Berg Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20210330162204.6f69fe6e4128.I921d4ae20ef5276716baeeeda0b001cf25b9b968@changeid Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin commit e9423d1a37e081c1a03f6d3a0aeb5274f6e5a2af Author: Miklos Szeredi Date: Wed Apr 14 10:40:58 2021 +0200 cuse: prevent clone [ Upstream commit 8217673d07256b22881127bf50dce874d0e51653 ] For cloned connections cuse_channel_release() will be called more than once, resulting in use after free. Prevent device cloning for CUSE, which does not make sense at this point, and highly unlikely to be used in real life. Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit 2b50e2c77e3d6340a0d20acefce6fe1b0988c988 Author: Miklos Szeredi Date: Wed Apr 14 10:40:58 2021 +0200 virtiofs: fix userns [ Upstream commit 0a7419c68a45d2d066b996be5087aa2d07ce80eb ] get_user_ns() is done twice (once in virtio_fs_get_tree() and once in fuse_conn_init()), resulting in a reference leak. Also looks better to use fsc->user_ns (which *should* be the current_user_ns() at this point). Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit 1b965c56029ddfdd2418ddcf0d75e24112bb88da Author: Vivek Goyal Date: Tue Apr 6 10:07:06 2021 -0400 fuse: invalidate attrs when page writeback completes [ Upstream commit 3466958beb31a8e9d3a1441a34228ed088b84f3e ] In fuse when a direct/write-through write happens we invalidate attrs because that might have updated mtime/ctime on server and cached mtime/ctime will be stale. What about page writeback path. Looks like we don't invalidate attrs there. To be consistent, invalidate attrs in writeback path as well. Only exception is when writeback_cache is enabled. In that case we strust local mtime/ctime and there is no need to invalidate attrs. Recently users started experiencing failure of xfstests generic/080, geneirc/215 and generic/614 on virtiofs. This happened only newer "stat" utility and not older one. This patch fixes the issue. So what's the root cause of the issue. Here is detailed explanation. generic/080 test does mmap write to a file, closes the file and then checks if mtime has been updated or not. When file is closed, it leads to flushing of dirty pages (and that should update mtime/ctime on server). But we did not explicitly invalidate attrs after writeback finished. Still generic/080 passed so far and reason being that we invalidated atime in fuse_readpages_end(). This is called in fuse_readahead() path and always seems to trigger before mmaped write. So after mmaped write when lstat() is called, it sees that atleast one of the fields being asked for is invalid (atime) and that results in generating GETATTR to server and mtime/ctime also get updated and test passes. But newer /usr/bin/stat seems to have moved to using statx() syscall now (instead of using lstat()). And statx() allows it to query only ctime or mtime (and not rest of the basic stat fields). That means when querying for mtime, fuse_update_get_attr() sees that mtime is not invalid (only atime is invalid). So it does not generate a new GETATTR and fill stat with cached mtime/ctime. And that means updated mtime is not seen by xfstest and tests start failing. Invalidating attrs after writeback completion should solve this problem in a generic manner. Signed-off-by: Vivek Goyal Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit f3f672f88f1443e0ae25bd0eb57316700f32c715 Author: Ye Weihua Date: Thu Apr 8 19:06:38 2021 +0800 i2c: imx: Fix PM reference leak in i2c_imx_reg_slave() [ Upstream commit c4b1fcc310e655fa8414696c38a84d36c00684c8 ] pm_runtime_get_sync() will increment the PM reference count even on failure. Forgetting to put the reference again will result in a leak. Replace it with pm_runtime_resume_and_get() to keep the usage counter balanced. Reported-by: Hulk Robot Signed-off-by: Ye Weihua Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 297ff6866bc6bac4144a7d1366f21042fbfcdf1e Author: Ryder Lee Date: Tue Apr 6 12:46:09 2021 +0800 mt76: mt7915: add wifi subsystem reset [ Upstream commit e07419a7dca97dd9bddfe5d099380857c19535f3 ] Reset wifi subsystem when MCU is already running. Fixes firmware download failure after soft reboot on systems where the PCIe reset could not be performed properly. Signed-off-by: Ryder Lee Co-developed-by: Felix Fietkau Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit ea81ee2ad2c945787d6fba44f6a35449fdc324f3 Author: Lorenzo Bianconi Date: Sat Mar 27 10:10:14 2021 +0100 mt76: mt7921: fix key set/delete issue [ Upstream commit 60468f7fd7072c804b2613f1cadabace8d77d311 ] Similar to the mt7915 driver, deleting a key with the previous key index deletes the current key. Rework the code to better keep track of multiple keys and check for the key index before deleting the current key Signed-off-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit e79f04f2ccf83339516c16d16448405a9ccb0171 Author: Shayne Chen Date: Thu Apr 1 10:31:29 2021 +0800 mt76: mt7915: fix txpower init for TSSI off chips [ Upstream commit a226ccd04c479ccd23d6927c64bad1b441707f70 ] Fix incorrect txpower init value for TSSI off chips which causes too small txpower. Signed-off-by: Shayne Chen Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit be31395351acc292f86e818073635016d55f7d8d Author: Felix Fietkau Date: Mon Mar 22 21:39:57 2021 +0100 mt76: mt7915: fix key set/delete issue [ Upstream commit 1da4fd48d28436f8b690cdc2879603dede6d8355 ] Deleting a key with the previous key index deletes the current key Rework the code to better keep track of multiple keys and check for the key index before deleting the current key Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 4f6458377e0e5d4b6f86584810d7bb79ca5554ad Author: Lorenzo Bianconi Date: Fri Feb 12 20:30:04 2021 +0100 mt76: mt7915: always check return value from mt7915_mcu_alloc_wtbl_req [ Upstream commit 45f93e368211fbbd247e1ece254ffb121e20fa10 ] As done for mt76_connac_mcu_alloc_wtbl_req, even if this is not a real bug since mt7915_mcu_alloc_wtbl_req routine can fails just if nskb is NULL, always check return value from mt7915_mcu_alloc_wtbl_req in order to avoid possible future mistake. Signed-off-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 7df5286e96122fa862c5fca432c8f8a1c820149c Author: Lorenzo Bianconi Date: Fri Feb 12 12:51:05 2021 +0100 mt76: connac: always check return value from mt76_connac_mcu_alloc_wtbl_req [ Upstream commit baa3afb39e94965f4ca5b5d3d274379504b8fa24 ] Even if this is not a real bug since mt76_connac_mcu_alloc_wtbl_req routine can fails just if nskb is NULL , always check return value from mt76_connac_mcu_alloc_wtbl_req in order to avoid possible future mistake. Reported-by: Dan Carpenter Signed-off-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 8d0834eab64c4aec24aa2e58bc409f3ac1a0ac39 Author: David Bauer Date: Sun Feb 7 16:09:17 2021 +0100 mt76: mt76x0: disable GTK offloading [ Upstream commit 4b36cc6b390f18dbc59a45fb4141f90d7dfe2b23 ] When operating two VAP on a MT7610 with encryption (PSK2, SAE, OWE), only the first one to be created will transmit properly encrypteded frames. All subsequently created VAPs will sent out frames with the payload left unencrypted, breaking multicast traffic (ICMP6 NDP) and potentially disclosing information to a third party. Disable GTK offloading and encrypt these frames in software to circumvent this issue. THis only seems to be necessary on MT7610 chips, as MT7612 is not affected from our testing. Signed-off-by: David Bauer Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit c11122299694e139e7136a6ddd8de82eba7d9225 Author: Sander Vanheule Date: Tue Feb 2 09:59:53 2021 +0100 mt76: mt7615: support loading EEPROM for MT7613BE [ Upstream commit 858ebf446bee7d5077bd99488aae617908c3f4fe ] EEPROM blobs for MT7613BE radios start with (little endian) 0x7663, which is also the PCI device ID for this device. The EEPROM is required for the radio to work at useful power levels, otherwise only the lowest power level is available. Suggested-by: Georgi Vlaev Tested-by: Stijn Segers Signed-off-by: Sander Vanheule Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 72b1993a5424bcf5cc2290d5cedd04d0e6fe3ea9 Author: Felix Fietkau Date: Mon Feb 8 17:07:27 2021 +0100 mt76: mt7615: fix key set/delete issues [ Upstream commit 730d6d0da8d8f5905faafe645a5b3c08ac3f5a8f ] There were multiple issues in the current key set/remove code: - deleting a key with the previous key index deletes the current key - BIP key would only be uploaded correctly initially and corrupted on rekey Rework the code to better keep track of multiple keys and check for the key index before deleting the current key Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 14a5f69f474b159989ade5e142dfb22deb630b4b Author: Po-Hao Huang Date: Fri Mar 19 13:42:16 2021 +0800 rtw88: 8822c: add LC calibration for RTL8822C [ Upstream commit 7ae7784ec2a812c07d2ca91a6538ef2470154fb6 ] Fix power tracking issue by replacing unnecessary IQ calibration with LC calibration. When thermal difference exceeds limitation, let RF circuit adjsut its characteristic to fit in current environment. Signed-off-by: Po-Hao Huang Signed-off-by: Ping-Ke Shih Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210319054218.3319-6-pkshih@realtek.com Signed-off-by: Sasha Levin commit bb55990c07ef13d45095d088b74f630606c88a15 Author: Krzysztof Kozlowski Date: Thu Apr 8 21:50:29 2021 +0200 pinctrl: samsung: use 'int' for register masks in Exynos [ Upstream commit fa0c10a5f3a49130dd11281aa27e7e1c8654abc7 ] The Special Function Registers on all Exynos SoC, including ARM64, are 32-bit wide, so entire driver uses matching functions like readl() or writel(). On 64-bit ARM using unsigned long for register masks: 1. makes little sense as immediately after bitwise operation it will be cast to 32-bit value when calling writel(), 2. is actually error-prone because it might promote other operands to 64-bit. Addresses-Coverity: Unintentional integer overflow Signed-off-by: Krzysztof Kozlowski Reviewed-by: Sylwester Nawrocki Link: https://lore.kernel.org/r/20210408195029.69974-1-krzysztof.kozlowski@canonical.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit d320da6e4bee2b145cef878bfc0420c044674b1a Author: Heiner Kallweit Date: Wed Apr 7 17:52:45 2021 +0200 net: fec: use mac-managed PHY PM [ Upstream commit 557d5dc83f6831b4e54d141e9b121850406f9a60 ] Use the new mac_managed_pm flag to work around an issue with KSZ8081 PHY that becomes unstable when a soft reset is triggered during aneg. Reported-by: Joakim Zhang Tested-by: Joakim Zhang Signed-off-by: Heiner Kallweit Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e782c60aa10c14a38085b032dbfc914973b9819b Author: Heiner Kallweit Date: Wed Apr 7 17:51:56 2021 +0200 net: phy: make PHY PM ops a no-op if MAC driver manages PHY PM [ Upstream commit fba863b816049b03f3fbb07b10ebdcfe5c4141f7 ] Resume callback of the PHY driver is called after the one for the MAC driver. The PHY driver resume callback calls phy_init_hw(), and this is potentially problematic if the MAC driver calls phy_start() in its resume callback. One issue was reported with the fec driver and a KSZ8081 PHY which seems to become unstable if a soft reset is triggered during aneg. The new flag allows MAC drivers to indicate that they take care of suspending/resuming the PHY. Then the MAC PM callbacks can handle any dependency between MAC and PHY PM. Signed-off-by: Heiner Kallweit Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 30e55f55bb713c2c5693e046e4c372b12e9584d5 Author: Gyeongtaek Lee Date: Wed Apr 7 13:14:04 2021 +0900 ASoC: soc-compress: lock pcm_mutex to resolve lockdep error [ Upstream commit 45475bf60cc1d42da229a0aa757180c88bab8d22 ] If panic_on_warn=1 is added in bootargs and compress offload playback with DPCM is started, kernel panic would be occurred because rtd->card->pcm_mutex isn't held in soc_compr_open_fe() and soc_compr_free_fe() and it generates lockdep warning in the following code. void snd_soc_runtime_action(struct snd_soc_pcm_runtime *rtd, int stream, int action) { struct snd_soc_dai *dai; int i; lockdep_assert_held(&rtd->card->pcm_mutex); To prevent lockdep warning but minimize side effect by adding mutex, pcm_mutex is held just before snd_soc_runtime_activate() and snd_soc_runtime_deactivate() and is released right after them. Signed-off-by: Gyeongtaek Lee Link: https://lore.kernel.org/r/1891546521.01617772502282.JavaMail.epsvc@epcpadp3 Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a8933606c15e0c931d869e3463d7b9198d25478a Author: Emmanuel Grumbach Date: Thu Apr 8 14:31:25 2021 +0200 mac80211: clear the beacon's CRC after channel switch [ Upstream commit d6843d1ee283137723b4a8c76244607ce6db1951 ] After channel switch, we should consider any beacon with a CSA IE as a new switch. If the CSA IE is a leftover from before the switch that the AP forgot to remove, we'll get a CSA-to-Self. This caused issues in iwlwifi where the firmware saw a beacon with a CSA-to-Self with mode = 1 on the new channel after a switch. The firmware considered this a new switch and closed its queues. Since the beacon didn't change between before and after the switch, we wouldn't handle it (the CRC is the same) and we wouldn't let the firmware open its queues again or disconnect if the CSA IE stays for too long. Clear the CRC valid state after we switch to make sure that we handle the beacon and handle the CSA IE as required. Signed-off-by: Emmanuel Grumbach Link: https://lore.kernel.org/r/20210408143124.b9e68aa98304.I465afb55ca2c7d59f7bf610c6046a1fd732b4c28@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 9b1b2a59be231e56eec3f4e245880f8d6a53887b Author: Johan Almbladh Date: Thu Apr 1 18:44:55 2021 +0200 mac80211: Set priority and queue mapping for injected frames [ Upstream commit 96a7109a16665255b65d021e24141c2edae0e202 ] Some drivers, for example mt76, use the skb priority field, and expects that to be consistent with the skb queue mapping. On some frame injection code paths that was not true, and it broke frame injection. Now the skb queue mapping is set according to the skb priority value when the frame is injected. The skb priority value is also derived from the frame data for all frame types, as it was done prior to commit dbd50a851c50 (only allocate one queue when using iTXQs). Fixes frame injection with the mt76 driver on MT7610E chipset. Signed-off-by: Johan Almbladh Link: https://lore.kernel.org/r/20210401164455.978245-1-johan.almbladh@anyfinetworks.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 98138aa2e625f222da9151b1f612fbd796e48ba3 Author: Mike Marciniszyn Date: Mon Mar 29 09:54:09 2021 -0400 IB/hfi1: Correct oversized ring allocation [ Upstream commit b536d4b2a279733f440c911dc831764690b90050 ] The completion ring for tx is using the wrong size to size the ring, oversizing the ring by two orders of magniture. Correct the allocation size and use kcalloc_node() to allocate the ring. Fix mistaken GFP defines in similar allocations. Link: https://lore.kernel.org/r/1617026056-50483-4-git-send-email-dennis.dalessandro@cornelisnetworks.com Reviewed-by: Kaike Wan Signed-off-by: Mike Marciniszyn Signed-off-by: Dennis Dalessandro Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit bcbdb48349740b8c65a4ac49c6a9a9510f7aa341 Author: Suzuki K Poulose Date: Mon Apr 5 17:42:57 2021 +0100 coresight: Do not scan for graph if none is present [ Upstream commit 2b921b671a8d29c2adb255a86409aad1e3267309 ] If a graph node is not found for a given node, of_get_next_endpoint() will emit the following error message : OF: graph: no port node found in / If the given component doesn't have any explicit connections (e.g, ETE) we could simply ignore the graph parsing. As for any legacy component where this is mandatory, the device will not be usable as before this patch. Updating the DT bindings to Yaml and enabling the schema checks can detect such issues with the DT. Cc: Mike Leach Cc: Leo Yan Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20210405164307.1720226-11-suzuki.poulose@arm.com Signed-off-by: Mathieu Poirier Signed-off-by: Sasha Levin commit a3241f9019dfa9c53cf505d02fb9c229edb604de Author: Tiezhu Yang Date: Tue Apr 6 17:25:12 2021 +0800 MIPS: Loongson64: Use _CACHE_UNCACHED instead of _CACHE_UNCACHED_ACCELERATED [ Upstream commit 5e65c52ec716af6e8f51dacdaeb4a4d872249af1 ] Loongson64 processors have a writecombine issue that maybe failed to write back framebuffer used with ATI Radeon or AMD GPU at times, after commit 8a08e50cee66 ("drm: Permit video-buffers writecombine mapping for MIPS"), there exists some errors such as blurred screen and lockup, and so on. [ 60.958721] radeon 0000:03:00.0: ring 0 stalled for more than 10079msec [ 60.965315] radeon 0000:03:00.0: GPU lockup (current fence id 0x0000000000000112 last fence id 0x000000000000011d on ring 0) [ 60.976525] radeon 0000:03:00.0: ring 3 stalled for more than 10086msec [ 60.983156] radeon 0000:03:00.0: GPU lockup (current fence id 0x0000000000000374 last fence id 0x00000000000003a8 on ring 3) As discussed earlier [1], it might be better to disable writecombine on the CPU detection side because the root cause is unknown now. Actually, this patch is a temporary solution to just make it work well, it is not a proper and final solution, I hope someone will have a better solution to fix this issue in the future. [1] https://lore.kernel.org/patchwork/patch/1285542/ Signed-off-by: Tiezhu Yang Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 1a3b3a7674b1b0ae2ce8b19e5c0e48bd29c6e1cb Author: Daniel Winkler Date: Mon Apr 5 16:33:05 2021 -0700 Bluetooth: Do not set cur_adv_instance in adv param MGMT request [ Upstream commit b6f1b79deabd32f89adbf24ef7b30f82d029808a ] We set hdev->cur_adv_instance in the adv param MGMT request to allow the callback to the hci param request to set the tx power to the correct instance. Now that the callbacks use the advertising handle from the hci request (as they should), this workaround is no longer necessary. Furthermore, this change resolves a race condition that is more prevalent when using the extended advertising MGMT calls - if hdev->cur_adv_instance is set in the params request, then when the data request is called, we believe our new instance is already active. This treats it as an update and immediately schedules the instance with the controller, which has a potential race with the software rotation adv update. By not setting hdev->cur_adv_instance too early, the new instance is queued as it should be, to be used when the rotation comes around again. This change is tested on harrison peak to confirm that it resolves the race condition on registration, and that there is no regression in single- and multi-advertising automated tests. Reviewed-by: Miao-chen Chou Signed-off-by: Daniel Winkler Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit ee411020903a90fd02829c4521cfbfdad5f3f7ee Author: Bence Csókás Date: Wed Mar 31 19:19:20 2021 +0000 i2c: Add I2C_AQ_NO_REP_START adapter quirk [ Upstream commit aca01415e076aa96cca0f801f4420ee5c10c660d ] This quirk signifies that the adapter cannot do a repeated START, it always issues a STOP condition after transfers. Suggested-by: Wolfram Sang Signed-off-by: Bence Csókás Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 1fe18e625a454dd87f8928015541c63062aaa168 Author: Matthieu Baerts Date: Thu Apr 1 16:19:45 2021 -0700 selftests: mptcp: launch mptcp_connect with timeout [ Upstream commit 5888a61cb4e00695075bbacfd86f3fa73af00413 ] 'mptcp_connect' already has a timeout for poll() but in some cases, it is not enough. With "timeout" tool, we will force the command to fail if it doesn't finish on time. Thanks to that, the script will continue and display details about the current state before marking the test as failed. Displaying this state is very important to be able to understand the issue. Best to have our CI reporting the issue than just "the test hanged". Note that in mptcp_connect.sh, we were using a long timeout to validate the fact we cannot create a socket if a sysctl is set. We don't need this timeout. In diag.sh, we want to send signals to mptcp_connect instances that have been started in the netns. But we cannot send this signal to 'timeout' otherwise that will stop the timeout and messages telling us SIGUSR1 has been received will be printed. Instead of trying to find the right PID and storing them in an array, we can simply use the output of 'ip netns pids' which is all the PIDs we want to send signal to. Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/160 Signed-off-by: Matthieu Baerts Signed-off-by: Mat Martineau Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f1fef5c97a7e341684e7fd483b1849b716da1241 Author: Hans de Goede Date: Fri Apr 2 16:07:45 2021 +0200 ASoC: rt5670: Add a quirk for the Dell Venue 10 Pro 5055 [ Upstream commit 84cb0d5581b6a7bd5d96013f67e9f2eb0c7b4378 ] Add a quirk with the jack-detect and dmic settings necessary to make jack-detect and the builtin mic work on Dell Venue 10 Pro 5055 tablets. Signed-off-by: Hans de Goede Acked-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20210402140747.174716-5-hdegoede@redhat.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f5caa9943d45d7b6398596fdd0c3137d5175226e Author: mark-yw.chen Date: Mon Mar 29 01:18:33 2021 +0800 Bluetooth: btusb: Enable quirk boolean flag for Mediatek Chip. [ Upstream commit 27e554a4fcd84e499bf0a82122b8c4c3f1de38b6 ] Adding support LE scatternet and WBS for Mediatek Chip Signed-off-by: mark-yw.chen Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit ccd9f0417c12120b8363a96cc01ac4b7bdab9d72 Author: Paul M Stillwell Jr Date: Tue Mar 2 10:12:05 2021 -0800 ice: handle increasing Tx or Rx ring sizes [ Upstream commit 2ec5638559c13b923250eccf495d2a033fccb3e7 ] There is an issue when the Tx or Rx ring size increases using 'ethtool -L ...' where the new rings don't get the correct ITR values because when we rebuild the VSI we don't know that some of the rings may be new. Fix this by looking at the original number of rings and determining if the rings in ice_vsi_rebuild_set_coalesce() were not present in the original rings received in ice_vsi_rebuild_get_coalesce(). Also change the code to return an error if we can't allocate memory for the coalesce data in ice_vsi_rebuild(). Signed-off-by: Paul M Stillwell Jr Tested-by: Tony Brelinski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 18094f2b842eacb205ffa44f2abd01dd81cc299d Author: Hans de Goede Date: Thu Mar 25 23:10:54 2021 +0100 ASoC: Intel: bytcr_rt5640: Add quirk for the Chuwi Hi8 tablet [ Upstream commit 875c40eadf6ac6644c0f71842a4f30dd9968d281 ] The Chuwi Hi8 tablet is using an analog mic on IN1 and has its jack-detect connected to JD2_IN4N, instead of using the default IN3 for its internal mic and JD1_IN4P for jack-detect. It also only has 1 speaker. Add a quirk applying the correct settings for this configuration. Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20210325221054.22714-1-hdegoede@redhat.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit e6c10a27ddf9c51087649a9313c88c5c48fa84c2 Author: Xiang Chen Date: Tue Mar 30 20:58:26 2021 +0800 iommu/arm-smmu-v3: Add a check to avoid invalid iotlb sync [ Upstream commit 6cc7e5a9c6b02507b9be5a99b51e970afa91c85f ] It may send a invalid tlb sync for smmuv3 if iotlb_gather is not valid (iotlb_gather->pgsize = 0). So add a check to avoid invalid iotlb sync for it. Signed-off-by: Xiang Chen Link: https://lore.kernel.org/r/1617109106-121844-1-git-send-email-chenxiang66@hisilicon.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit a5ebdf08b44bf897c816cc46e00307cdaea8acab Author: Marc Kleine-Budde Date: Fri Mar 19 15:08:13 2021 +0100 can: dev: can_free_echo_skb(): don't crash the kernel if can_priv::echo_skb is accessed out of bounds [ Upstream commit 4168d079aa41498639b2c64b4583375bcdf360d9 ] A out of bounds access to "struct can_priv::echo_skb" leads to a kernel crash. Better print a sensible warning message instead and try to recover. This patch is similar to: | e7a6994d043a ("can: dev: __can_get_echo_skb(): Don't crash the kernel | if can_priv::echo_skb is accessed out of bounds") Link: https://lore.kernel.org/r/20210319142700.305648-2-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 3e7996f1e6efff098780cc3f2ed570168a797213 Author: Eric Dumazet Date: Mon Mar 29 12:12:54 2021 -0700 ip6_vti: proper dev_{hold|put} in ndo_[un]init methods [ Upstream commit 40cb881b5aaa0b69a7d93dec8440d5c62dae299f ] After adopting CONFIG_PCPU_DEV_REFCNT=n option, syzbot was able to trigger a warning [1] Issue here is that: - all dev_put() should be paired with a corresponding prior dev_hold(). - A driver doing a dev_put() in its ndo_uninit() MUST also do a dev_hold() in its ndo_init(), only when ndo_init() is returning 0. Otherwise, register_netdevice() would call ndo_uninit() in its error path and release a refcount too soon. Therefore, we need to move dev_hold() call from vti6_tnl_create2() to vti6_dev_init_gen() [1] WARNING: CPU: 0 PID: 15951 at lib/refcount.c:31 refcount_warn_saturate+0xbf/0x1e0 lib/refcount.c:31 Modules linked in: CPU: 0 PID: 15951 Comm: syz-executor.3 Not tainted 5.12.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:refcount_warn_saturate+0xbf/0x1e0 lib/refcount.c:31 Code: 1d 6a 5a e8 09 31 ff 89 de e8 8d 1a ab fd 84 db 75 e0 e8 d4 13 ab fd 48 c7 c7 a0 e1 c1 89 c6 05 4a 5a e8 09 01 e8 2e 36 fb 04 <0f> 0b eb c4 e8 b8 13 ab fd 0f b6 1d 39 5a e8 09 31 ff 89 de e8 58 RSP: 0018:ffffc90001eaef28 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000040000 RSI: ffffffff815c51f5 RDI: fffff520003d5dd7 RBP: 0000000000000004 R08: 0000000000000000 R09: 0000000000000000 R10: ffffffff815bdf8e R11: 0000000000000000 R12: ffff88801bb1c568 R13: ffff88801f69e800 R14: 00000000ffffffff R15: ffff888050889d40 FS: 00007fc79314e700(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1c1ff47108 CR3: 0000000020fd5000 CR4: 00000000001506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __refcount_dec include/linux/refcount.h:344 [inline] refcount_dec include/linux/refcount.h:359 [inline] dev_put include/linux/netdevice.h:4135 [inline] vti6_dev_uninit+0x31a/0x360 net/ipv6/ip6_vti.c:297 register_netdevice+0xadf/0x1500 net/core/dev.c:10308 vti6_tnl_create2+0x1b5/0x400 net/ipv6/ip6_vti.c:190 vti6_newlink+0x9d/0xd0 net/ipv6/ip6_vti.c:1020 __rtnl_newlink+0x1062/0x1710 net/core/rtnetlink.c:3443 rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3491 rtnetlink_rcv_msg+0x44e/0xad0 net/core/rtnetlink.c:5553 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2502 netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927 sock_sendmsg_nosec net/socket.c:654 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:674 ____sys_sendmsg+0x331/0x810 net/socket.c:2350 ___sys_sendmsg+0xf3/0x170 net/socket.c:2404 __sys_sendmmsg+0x195/0x470 net/socket.c:2490 __do_sys_sendmmsg net/socket.c:2519 [inline] __se_sys_sendmmsg net/socket.c:2516 [inline] __x64_sys_sendmmsg+0x99/0x100 net/socket.c:2516 Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5ffb52837d25b191876085c58f33c4a209e39fb8 Author: Yunsheng Lin Date: Mon Mar 29 11:57:50 2021 +0800 net: hns3: add handling for xmit skb with recursive fraglist [ Upstream commit d5d5e0193ee8f88efbbc7f1471087255657bc19a ] Currently hns3 driver only handle the xmit skb with one level of fraglist skb, add handling for multi level by calling hns3_tx_bd_num() recursively when calculating bd num and calling hns3_fill_skb_to_desc() recursively when filling tx desc. When the skb has a fraglist level of 24, the skb is simply dropped and stats.max_recursion_level is added to record the error. Move the stat handling from hns3_nic_net_xmit() to hns3_nic_maybe_stop_tx() in order to handle different error stat and add the 'max_recursion_level' and 'hw_limitation' stat. Note that the max recursive level as 24 is chose according to below: commit 48a1df65334b ("skbuff: return -EMSGSIZE in skb_to_sgvec to prevent overflow"). And that we are not able to find a testcase to verify the recursive fraglist case, so Fixes tag is not provided. Reported-by: Barry Song Signed-off-by: Yunsheng Lin Signed-off-by: Huazhong Tan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4cd9a1b396fd77e4341c33dea28634b94cdee043 Author: Guangbin Huang Date: Mon Mar 29 11:57:47 2021 +0800 net: hns3: remediate a potential overflow risk of bd_num_list [ Upstream commit a2ee6fd28a190588e142ad8ea9d40069cd3c9f98 ] The array size of bd_num_list is a fixed value, it may have potential overflow risk when array size of hclge_dfx_bd_offset_list is greater than that fixed value. So modify bd_num_list as a pointer and allocate memory for it according to array size of hclge_dfx_bd_offset_list. Signed-off-by: Guangbin Huang Signed-off-by: Huazhong Tan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f3443d376adee917da2829d2805516a69765ef25 Author: Christophe Leroy Date: Fri Mar 12 12:50:25 2021 +0000 powerpc/32: Statically initialise first emergency context [ Upstream commit a4719f5bb6d7dc220bffdc1b9f5ce5eaa5543581 ] The check of the emergency context initialisation in vmap_stack_overflow is buggy for the SMP case, as it compares r1 with 0 while in the SMP case r1 is offseted by the CPU id. Instead of fixing it, just perform static initialisation of the first emergency context. Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/4a67ba422be75713286dca0c86ee0d3df2eb6dfa.1615552867.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin commit 392a01682cbb15cf760846cce6c974b59f9a31c6 Author: Kai Vehmanen Date: Wed Mar 24 19:23:37 2021 +0200 ALSA: hda/hdmi: fix max DP-MST dev_num for Intel TGL+ platforms [ Upstream commit e839fbed26e8b8713803b8ac73da92fd2b0c7594 ] Increase the device select range to 4 on platforms supporting 4 concurrent displays. This fixes a problem in scenario where total of 4 displays are active, and 3 of these are audio capable DP receivers and connected to a DP-MST hub. Due to incorrect range for device select, audio could not be played to the 3rd monitor in DP-MST hub. BugLink: https://github.com/thesofproject/linux/issues/2798 Signed-off-by: Kai Vehmanen Reviewed-by: Ranjani Sridharan Reviewed-by: Guennadi Liakhovetski Link: https://lore.kernel.org/r/20210324172337.51730-1-kai.vehmanen@linux.intel.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 86e41065119422438912872186b845395ffe444a Author: Russell Currey Date: Tue Feb 23 17:02:27 2021 +1000 selftests/powerpc: Fix L1D flushing tests for Power10 [ Upstream commit 3a72c94ebfb1f171eba0715998010678a09ec796 ] The rfi_flush and entry_flush selftests work by using the PM_LD_MISS_L1 perf event to count L1D misses. The value of this event has changed over time: - Power7 uses 0x400f0 - Power8 and Power9 use both 0x400f0 and 0x3e054 - Power10 uses only 0x3e054 Rather than relying on raw values, configure perf to count L1D read misses in the most explicit way available. This fixes the selftests to work on systems without 0x400f0 as PM_LD_MISS_L1, and should change no behaviour for systems that the tests already worked on. The only potential downside is that referring to a specific perf event requires PMU support implemented in the kernel for that platform. Signed-off-by: Russell Currey Acked-by: Daniel Axtens Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210223070227.2916871-1-ruscur@russell.cc Signed-off-by: Sasha Levin commit f2e8da285341b33755cf7f00eccfa039a0214751 Author: Archie Pusaka Date: Tue Mar 23 16:32:20 2021 +0800 Bluetooth: check for zapped sk before connecting [ Upstream commit 3af70b39fa2d415dc86c370e5b24ddb9fdacbd6f ] There is a possibility of receiving a zapped sock on l2cap_sock_connect(). This could lead to interesting crashes, one such case is tearing down an already tore l2cap_sock as is happened with this call trace: __dump_stack lib/dump_stack.c:15 [inline] dump_stack+0xc4/0x118 lib/dump_stack.c:56 register_lock_class kernel/locking/lockdep.c:792 [inline] register_lock_class+0x239/0x6f6 kernel/locking/lockdep.c:742 __lock_acquire+0x209/0x1e27 kernel/locking/lockdep.c:3105 lock_acquire+0x29c/0x2fb kernel/locking/lockdep.c:3599 __raw_spin_lock_bh include/linux/spinlock_api_smp.h:137 [inline] _raw_spin_lock_bh+0x38/0x47 kernel/locking/spinlock.c:175 spin_lock_bh include/linux/spinlock.h:307 [inline] lock_sock_nested+0x44/0xfa net/core/sock.c:2518 l2cap_sock_teardown_cb+0x88/0x2fb net/bluetooth/l2cap_sock.c:1345 l2cap_chan_del+0xa3/0x383 net/bluetooth/l2cap_core.c:598 l2cap_chan_close+0x537/0x5dd net/bluetooth/l2cap_core.c:756 l2cap_chan_timeout+0x104/0x17e net/bluetooth/l2cap_core.c:429 process_one_work+0x7e3/0xcb0 kernel/workqueue.c:2064 worker_thread+0x5a5/0x773 kernel/workqueue.c:2196 kthread+0x291/0x2a6 kernel/kthread.c:211 ret_from_fork+0x4e/0x80 arch/x86/entry/entry_64.S:604 Signed-off-by: Archie Pusaka Reported-by: syzbot+abfc0f5e668d4099af73@syzkaller.appspotmail.com Reviewed-by: Alain Michaud Reviewed-by: Abhishek Pandit-Subedi Reviewed-by: Guenter Roeck Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit 759b3fb78309f839ac99c6c5057f15e1595197fa Author: Nikolay Aleksandrov Date: Mon Mar 22 17:45:27 2021 +0200 net: bridge: when suppression is enabled exclude RARP packets [ Upstream commit 0353b4a96b7a9f60fe20d1b3ebd4931a4085f91c ] Recently we had an interop issue where RARP packets got suppressed with bridge neigh suppression enabled, but the check in the code was meant to suppress GARP. Exclude RARP packets from it which would allow some VMWare setups to work, to quote the report: "Those RARP packets usually get generated by vMware to notify physical switches when vMotion occurs. vMware may use random sip/tip or just use sip=tip=0. So the RARP packet sometimes get properly flooded by the vtep and other times get dropped by the logic" Reported-by: Amer Abdalamer Signed-off-by: Nikolay Aleksandrov Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 840ba68003015d9ad5240c4810a00d176baa0308 Author: Vladimir Oltean Date: Sun Mar 21 23:05:48 2021 +0200 net/sched: cls_flower: use ntohs for struct flow_dissector_key_ports [ Upstream commit 6215afcb9a7e35cef334dc0ae7f998cc72c8465f ] A make W=1 build complains that: net/sched/cls_flower.c:214:20: warning: cast from restricted __be16 net/sched/cls_flower.c:214:20: warning: incorrect type in argument 1 (different base types) net/sched/cls_flower.c:214:20: expected unsigned short [usertype] val net/sched/cls_flower.c:214:20: got restricted __be16 [usertype] dst This is because we use htons on struct flow_dissector_key_ports members src and dst, which are defined as __be16, so they are already in network byte order, not host. The byte swap function for the other direction should have been used. Because htons and ntohs do the same thing (either both swap, or none does), this change has no functional effect except to silence the warnings. Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 91f14c60aff85b07d3ff2ae16557142ac3099c33 Author: Tetsuo Handa Date: Mon Mar 22 07:52:07 2021 +0900 Bluetooth: initialize skb_queue_head at l2cap_chan_create() [ Upstream commit be8597239379f0f53c9710dd6ab551bbf535bec6 ] syzbot is hitting "INFO: trying to register non-static key." message [1], for "struct l2cap_chan"->tx_q.lock spinlock is not yet initialized when l2cap_chan_del() is called due to e.g. timeout. Since "struct l2cap_chan"->lock mutex is initialized at l2cap_chan_create() immediately after "struct l2cap_chan" is allocated using kzalloc(), let's as well initialize "struct l2cap_chan"->{tx_q,srej_q}.lock spinlocks there. [1] https://syzkaller.appspot.com/bug?extid=fadfba6a911f6bf71842 Reported-and-tested-by: syzbot Signed-off-by: Tetsuo Handa Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit 50ef75bbe73328512ccb03c4ce05cd19858edf3a Author: Archie Pusaka Date: Mon Mar 22 14:02:15 2021 +0800 Bluetooth: Set CONF_NOT_COMPLETE as l2cap_chan default [ Upstream commit 3a9d54b1947ecea8eea9a902c0b7eb58a98add8a ] Currently l2cap_chan_set_defaults() reset chan->conf_state to zero. However, there is a flag CONF_NOT_COMPLETE which is set when creating the l2cap_chan. It is suggested that the flag should be cleared when l2cap_chan is ready, but when l2cap_chan_set_defaults() is called, l2cap_chan is not yet ready. Therefore, we must set this flag as the default. Example crash call trace: __dump_stack lib/dump_stack.c:15 [inline] dump_stack+0xc4/0x118 lib/dump_stack.c:56 panic+0x1c6/0x38b kernel/panic.c:117 __warn+0x170/0x1b9 kernel/panic.c:471 warn_slowpath_fmt+0xc7/0xf8 kernel/panic.c:494 debug_print_object+0x175/0x193 lib/debugobjects.c:260 debug_object_assert_init+0x171/0x1bf lib/debugobjects.c:614 debug_timer_assert_init kernel/time/timer.c:629 [inline] debug_assert_init kernel/time/timer.c:677 [inline] del_timer+0x7c/0x179 kernel/time/timer.c:1034 try_to_grab_pending+0x81/0x2e5 kernel/workqueue.c:1230 cancel_delayed_work+0x7c/0x1c4 kernel/workqueue.c:2929 l2cap_clear_timer+0x1e/0x41 include/net/bluetooth/l2cap.h:834 l2cap_chan_del+0x2d8/0x37e net/bluetooth/l2cap_core.c:640 l2cap_chan_close+0x532/0x5d8 net/bluetooth/l2cap_core.c:756 l2cap_sock_shutdown+0x806/0x969 net/bluetooth/l2cap_sock.c:1174 l2cap_sock_release+0x64/0x14d net/bluetooth/l2cap_sock.c:1217 __sock_release+0xda/0x217 net/socket.c:580 sock_close+0x1b/0x1f net/socket.c:1039 __fput+0x322/0x55c fs/file_table.c:208 ____fput+0x17/0x19 fs/file_table.c:244 task_work_run+0x19b/0x1d3 kernel/task_work.c:115 exit_task_work include/linux/task_work.h:21 [inline] do_exit+0xe4c/0x204a kernel/exit.c:766 do_group_exit+0x291/0x291 kernel/exit.c:891 get_signal+0x749/0x1093 kernel/signal.c:2396 do_signal+0xa5/0xcdb arch/x86/kernel/signal.c:737 exit_to_usermode_loop arch/x86/entry/common.c:243 [inline] prepare_exit_to_usermode+0xed/0x235 arch/x86/entry/common.c:277 syscall_return_slowpath+0x3a7/0x3b3 arch/x86/entry/common.c:348 int_ret_from_sys_call+0x25/0xa3 Signed-off-by: Archie Pusaka Reported-by: syzbot+338f014a98367a08a114@syzkaller.appspotmail.com Reviewed-by: Alain Michaud Reviewed-by: Abhishek Pandit-Subedi Reviewed-by: Guenter Roeck Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit 24cb3ff558953e78d54aaf50bf591dc1da2737ef Author: Takashi Sakamoto Date: Sun Mar 21 12:28:31 2021 +0900 ALSA: bebob: enable to deliver MIDI messages for multiple ports [ Upstream commit d2b6f15bc18ac8fbce25398290774c21f5b2cd44 ] Current implementation of bebob driver doesn't correctly handle the case that the device has multiple MIDI ports. The cause is the number of MIDI conformant data channels is passed to AM824 data block processing layer. This commit fixes the bug. Signed-off-by: Takashi Sakamoto Link: https://lore.kernel.org/r/20210321032831.340278-4-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit bf95eb72efbe2735af3b9502d0e8fe853aa96e32 Author: Tong Zhang Date: Sun Mar 21 11:38:40 2021 -0400 ALSA: rme9652: don't disable if not enabled [ Upstream commit f57a741874bb6995089020e97a1dcdf9b165dcbe ] rme9652 wants to disable a not enabled pci device, which makes kernel throw a warning. Make sure the device is enabled before calling disable. [ 1.751595] snd_rme9652 0000:00:03.0: disabling already-disabled device [ 1.751605] WARNING: CPU: 0 PID: 174 at drivers/pci/pci.c:2146 pci_disable_device+0x91/0xb0 [ 1.759968] Call Trace: [ 1.760145] snd_rme9652_card_free+0x76/0xa0 [snd_rme9652] [ 1.760434] release_card_device+0x4b/0x80 [snd] [ 1.760679] device_release+0x3b/0xa0 [ 1.760874] kobject_put+0x94/0x1b0 [ 1.761059] put_device+0x13/0x20 [ 1.761235] snd_card_free+0x61/0x90 [snd] [ 1.761454] snd_rme9652_probe+0x3be/0x700 [snd_rme9652] Suggested-by: Takashi Iwai Signed-off-by: Tong Zhang Link: https://lore.kernel.org/r/20210321153840.378226-4-ztong0001@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 95e11e73128afa3d2ebcad9938e93d758ac51129 Author: Tong Zhang Date: Sun Mar 21 11:38:39 2021 -0400 ALSA: hdspm: don't disable if not enabled [ Upstream commit 790f5719b85e12e10c41753b864e74249585ed08 ] hdspm wants to disable a not enabled pci device, which makes kernel throw a warning. Make sure the device is enabled before calling disable. [ 1.786391] snd_hdspm 0000:00:03.0: disabling already-disabled device [ 1.786400] WARNING: CPU: 0 PID: 182 at drivers/pci/pci.c:2146 pci_disable_device+0x91/0xb0 [ 1.795181] Call Trace: [ 1.795320] snd_hdspm_card_free+0x58/0xa0 [snd_hdspm] [ 1.795595] release_card_device+0x4b/0x80 [snd] [ 1.795860] device_release+0x3b/0xa0 [ 1.796072] kobject_put+0x94/0x1b0 [ 1.796260] put_device+0x13/0x20 [ 1.796438] snd_card_free+0x61/0x90 [snd] [ 1.796659] snd_hdspm_probe+0x97b/0x1440 [snd_hdspm] Suggested-by: Takashi Iwai Signed-off-by: Tong Zhang Link: https://lore.kernel.org/r/20210321153840.378226-3-ztong0001@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit df94915a89bf949db604fa9fb442ab83df5caf68 Author: Tong Zhang Date: Sun Mar 21 11:38:38 2021 -0400 ALSA: hdsp: don't disable if not enabled [ Upstream commit 507cdb9adba006a7798c358456426e1aea3d9c4f ] hdsp wants to disable a not enabled pci device, which makes kernel throw a warning. Make sure the device is enabled before calling disable. [ 1.758292] snd_hdsp 0000:00:03.0: disabling already-disabled device [ 1.758327] WARNING: CPU: 0 PID: 180 at drivers/pci/pci.c:2146 pci_disable_device+0x91/0xb0 [ 1.766985] Call Trace: [ 1.767121] snd_hdsp_card_free+0x94/0xf0 [snd_hdsp] [ 1.767388] release_card_device+0x4b/0x80 [snd] [ 1.767639] device_release+0x3b/0xa0 [ 1.767838] kobject_put+0x94/0x1b0 [ 1.768027] put_device+0x13/0x20 [ 1.768207] snd_card_free+0x61/0x90 [snd] [ 1.768430] snd_hdsp_probe+0x524/0x5e0 [snd_hdsp] Suggested-by: Takashi Iwai Signed-off-by: Tong Zhang Link: https://lore.kernel.org/r/20210321153840.378226-2-ztong0001@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 5f82c7be706ddb2c20bf9ae8a68404fcb6e26c5e Author: Wolfram Sang Date: Fri Mar 12 12:57:34 2021 +0100 i2c: bail out early when RDWR parameters are wrong [ Upstream commit 71581562ee36032d2d574a9b23ad4af6d6a64cf7 ] The buggy parameters currently get caught later, but emit a noisy WARN. Userspace should not be able to trigger this, so add similar checks much earlier. Also avoids some unneeded code paths, of course. Apply kernel coding stlye to a comment while here. Reported-by: syzbot+ffb0b3ffa6cfbc7d7b3f@syzkaller.appspotmail.com Tested-by: syzbot+ffb0b3ffa6cfbc7d7b3f@syzkaller.appspotmail.com Signed-off-by: Wolfram Sang Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 016c0942c13bd6775578ecbdbbd72edf50837e60 Author: Ayush Garg Date: Wed Mar 17 16:52:14 2021 +0530 Bluetooth: Fix incorrect status handling in LE PHY UPDATE event [ Upstream commit 87df8bcccd2cede62dfb97dc3d4ca1fe66cb4f83 ] Skip updation of tx and rx PHYs values, when PHY Update event's status is not successful. Signed-off-by: Ayush Garg Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit 186007c917933c6b7fcda2df82bf8d0ab24eec44 Author: Mikhail Durnev Date: Tue Mar 16 14:47:35 2021 +1000 ASoC: rsnd: core: Check convert rate in rsnd_hw_params [ Upstream commit 19c6a63ced5e07e40f3a5255cb1f0fe0d3be7b14 ] snd_pcm_hw_params_set_rate_near can return incorrect sample rate in some cases, e.g. when the backend output rate is set to some value higher than 48000 Hz and the input rate is 8000 Hz. So passing the value returned by snd_pcm_hw_params_set_rate_near to snd_pcm_hw_params will result in "FSO/FSI ratio error" and playing no audio at all while the userland is not properly notified about the issue. If SRC is unable to convert the requested sample rate to the sample rate the backend is using, then the requested sample rate should be adjusted in rsnd_hw_params. The userland will be notified about that change in the returned hw_params structure. Signed-off-by: Mikhail Durnev Link: https://lore.kernel.org/r/1615870055-13954-1-git-send-email-mikhail_durnev@mentor.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c2da6ff22b4ee295a285d01dac9d58232be69701 Author: Jonathan McDowell Date: Sat Mar 13 13:18:26 2021 +0000 net: stmmac: Set FIFO sizes for ipq806x [ Upstream commit e127906b68b49ddb3ecba39ffa36a329c48197d3 ] Commit eaf4fac47807 ("net: stmmac: Do not accept invalid MTU values") started using the TX FIFO size to verify what counts as a valid MTU request for the stmmac driver. This is unset for the ipq806x variant. Looking at older patches for this it seems the RX + TXs buffers can be up to 8k, so set appropriately. (I sent this as an RFC patch in June last year, but received no replies. I've been running with this on my hardware (a MikroTik RB3011) since then with larger MTUs to support both the internal qca8k switch and VLANs with no problems. Without the patch it's impossible to set the larger MTU required to support this.) Signed-off-by: Jonathan McDowell Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit bbbb5a2cee25fc8d6de4b0b151768d76039acf82 Author: Maxim Mikityanskiy Date: Fri Jan 29 18:43:31 2021 +0200 net/mlx5e: Use net_prefetchw instead of prefetchw in MPWQE TX datapath [ Upstream commit 991b2654605b455a94dac73e14b23480e7e20991 ] Commit e20f0dbf204f ("net/mlx5e: RX, Add a prefetch command for small L1_CACHE_BYTES") switched to using net_prefetchw at all places in mlx5e. In the same time frame, commit 5af75c747e2a ("net/mlx5e: Enhanced TX MPWQE for SKBs") added one more usage of prefetchw. When these two changes were merged, this new occurrence of prefetchw wasn't replaced with net_prefetchw. This commit fixes this last occurrence of prefetchw in mlx5e_tx_mpwqe_session_start, making the same change that was done in mlx5e_xdp_mpwqe_session_start. Signed-off-by: Maxim Mikityanskiy Reviewed-by: Saeed Mahameed Reviewed-by: Tariq Toukan Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit a7a3cc3245c720979974f053b2bdc89c20cd35bd Author: Hans de Goede Date: Fri Mar 12 12:48:50 2021 +0100 ASoC: Intel: bytcr_rt5640: Enable jack-detect support on Asus T100TAF [ Upstream commit b7c7203a1f751348f35fc4bcb157572d303f7573 ] The Asus T100TAF uses the same jack-detect settings as the T100TA, this has been confirmed on actual hardware. Add these settings to the T100TAF quirks to enable jack-detect support on the T100TAF. Signed-off-by: Hans de Goede Acked-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20210312114850.13832-1-hdegoede@redhat.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit e7610fc2dda78fb3930f3a9bb64585c76cccda52 Author: Hoang Le Date: Thu Mar 11 10:33:22 2021 +0700 tipc: convert dest node's address to network order [ Upstream commit 1980d37565061ab44bdc2f9e4da477d3b9752e81 ] (struct tipc_link_info)->dest is in network order (__be32), so we must convert the value to network order before assigning. The problem detected by sparse: net/tipc/netlink_compat.c:699:24: warning: incorrect type in assignment (different base types) net/tipc/netlink_compat.c:699:24: expected restricted __be32 [usertype] dest net/tipc/netlink_compat.c:699:24: got int Acked-by: Jon Maloy Signed-off-by: Hoang Le Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 3fe241d36b3c23b9954a941ecb1dbc07200ddec4 Author: Alexander Aring Date: Mon Mar 1 17:05:20 2021 -0500 fs: dlm: add shutdown hook [ Upstream commit 9d232469bcd772dbedb9e75a165c681b920524ee ] This patch fixes issues which occurs when dlm lowcomms synchronize their workqueues but dlm application layer already released the lockspace. In such cases messages like: dlm: gfs2: release_lockspace final free dlm: invalid lockspace 3841231384 from 1 cmd 1 type 11 are printed on the kernel log. This patch is solving this issue by introducing a new "shutdown" hook before calling "stop" hook when the lockspace is going to be released finally. This should pretend any dlm messages sitting in the workqueues during or after lockspace removal. It's necessary to call dlm_scand_stop() as I instrumented dlm_lowcomms_get_buffer() code to report a warning after it's called after dlm_midcomms_shutdown() functionality, see below: WARNING: CPU: 1 PID: 3794 at fs/dlm/midcomms.c:1003 dlm_midcomms_get_buffer+0x167/0x180 Modules linked in: joydev iTCO_wdt intel_pmc_bxt iTCO_vendor_support drm_ttm_helper ttm pcspkr serio_raw i2c_i801 i2c_smbus drm_kms_helper virtio_scsi lpc_ich virtio_balloon virtio_console xhci_pci xhci_pci_renesas cec qemu_fw_cfg drm [last unloaded: qxl] CPU: 1 PID: 3794 Comm: dlm_scand Tainted: G W 5.11.0+ #26 Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.13.0-2.module+el8.3.0+7353+9de0a3cc 04/01/2014 RIP: 0010:dlm_midcomms_get_buffer+0x167/0x180 Code: 5d 41 5c 41 5d 41 5e 41 5f c3 0f 0b 45 31 e4 5b 5d 4c 89 e0 41 5c 41 5d 41 5e 41 5f c3 4c 89 e7 45 31 e4 e8 3b f1 ec ff eb 86 <0f> 0b 4c 89 e7 45 31 e4 e8 2c f1 ec ff e9 74 ff ff ff 0f 1f 80 00 RSP: 0018:ffffa81503f8fe60 EFLAGS: 00010202 RAX: 0000000000000008 RBX: ffff8f969827f200 RCX: 0000000000000001 RDX: 0000000000000000 RSI: ffffffffad1e89a0 RDI: ffff8f96a5294160 RBP: 0000000000000001 R08: 0000000000000000 R09: ffff8f96a250bc60 R10: 00000000000045d3 R11: 0000000000000000 R12: ffff8f96a250bc60 R13: ffffa81503f8fec8 R14: 0000000000000070 R15: 0000000000000c40 FS: 0000000000000000(0000) GS:ffff8f96fbc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055aa3351c000 CR3: 000000010bf22000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: dlm_scan_rsbs+0x420/0x670 ? dlm_uevent+0x20/0x20 dlm_scand+0xbf/0xe0 kthread+0x13a/0x150 ? __kthread_bind_mask+0x60/0x60 ret_from_fork+0x22/0x30 To synchronize all dlm scand messages we stop it right before shutdown hook. Signed-off-by: Alexander Aring Signed-off-by: David Teigland Signed-off-by: Sasha Levin commit 926fd4e47bdbe01cfc07ad75512f425f9e8dc588 Author: Alexander Aring Date: Mon Mar 1 17:05:19 2021 -0500 fs: dlm: flush swork on shutdown [ Upstream commit eec054b5a7cfe6d1f1598a323b05771ee99857b5 ] This patch fixes the flushing of send work before shutdown. The function cancel_work_sync() is not the right workqueue functionality to use here as it would cancel the work if the work queues itself. In cases of EAGAIN in send() for dlm message we need to be sure that everything is send out before. The function flush_work() will ensure that every send work is be done inclusive in EAGAIN cases. Signed-off-by: Alexander Aring Signed-off-by: David Teigland Signed-off-by: Sasha Levin commit c1bb3ef861b669fc649904cc6cc60bff367561be Author: Alexander Aring Date: Mon Mar 1 17:05:17 2021 -0500 fs: dlm: check on minimum msglen size [ Upstream commit 710176e8363f269c6ecd73d203973b31ace119d3 ] This patch adds an additional check for minimum dlm header size which is an invalid dlm message and signals a broken stream. A msglen field cannot be less than the dlm header size because the field is inclusive header lengths. Signed-off-by: Alexander Aring Signed-off-by: David Teigland Signed-off-by: Sasha Levin commit ce9e8126adc038e26e9dc8f14bafa9e3868ac3e7 Author: Alexander Aring Date: Mon Mar 1 17:05:14 2021 -0500 fs: dlm: change allocation limits [ Upstream commit c45674fbdda138814ca21138475219c96fa5aa1f ] While running tcpkill I experienced invalid header length values while receiving to check that a node doesn't try to send a invalid dlm message we also check on applications minimum allocation limit. Also use DEFAULT_BUFFER_SIZE as maximum allocation limit. The define LOWCOMMS_MAX_TX_BUFFER_LEN is to calculate maximum buffer limits on application layer, future midcomms layer will subtract their needs from this define. Signed-off-by: Alexander Aring Signed-off-by: David Teigland Signed-off-by: Sasha Levin commit 1b400d1b19d6493b43008d8816c0573f031cde9f Author: Alexander Aring Date: Mon Mar 1 17:05:13 2021 -0500 fs: dlm: add check if dlm is currently running [ Upstream commit 517461630d1c25ee4dfc1dee80973a64189d6ccf ] This patch adds checks for dlm config attributes regarding to protocol parameters as it makes only sense to change them when dlm is not running. It also adds a check for valid protocol specifiers and return invalid argument if they are not supported. Signed-off-by: Alexander Aring Signed-off-by: David Teigland Signed-off-by: Sasha Levin commit 2929c46f0e0eb137609e6a289e8c5fb0d7b9603e Author: Alexander Aring Date: Mon Mar 1 17:05:12 2021 -0500 fs: dlm: add errno handling to check callback [ Upstream commit 8aa9540b49e0833feba75dbf4f45babadd0ed215 ] This allows to return individual errno values for the config attribute check callback instead of returning invalid argument only. Signed-off-by: Alexander Aring Signed-off-by: David Teigland Signed-off-by: Sasha Levin commit 664523603440737b30ad10b37be3e0fec75ffd9f Author: Alexander Aring Date: Mon Mar 1 17:05:09 2021 -0500 fs: dlm: fix mark setting deadlock [ Upstream commit e125fbeb538e5e35a00c6c8150a5361bef34814c ] This patch fixes an deadlock issue when dlm_lowcomms_close() is called. When dlm_lowcomms_close() is called the clusters_root.subsys.su_mutex is held to remove configfs items. At this time we flushing (e.g. cancel_work_sync()) the workers of send and recv workqueue. Due the fact that we accessing configfs items (mark values), these workers will lock clusters_root.subsys.su_mutex as well which are already hold by dlm_lowcomms_close() and ends in a deadlock situation. [67170.703046] ====================================================== [67170.703965] WARNING: possible circular locking dependency detected [67170.704758] 5.11.0-rc4+ #22 Tainted: G W [67170.705433] ------------------------------------------------------ [67170.706228] dlm_controld/280 is trying to acquire lock: [67170.706915] ffff9f2f475a6948 ((wq_completion)dlm_recv){+.+.}-{0:0}, at: __flush_work+0x203/0x4c0 [67170.708026] but task is already holding lock: [67170.708758] ffffffffa132f878 (&clusters_root.subsys.su_mutex){+.+.}-{3:3}, at: configfs_rmdir+0x29b/0x310 [67170.710016] which lock already depends on the new lock. The new behaviour adds the mark value to the node address configuration which doesn't require to held the clusters_root.subsys.su_mutex by accessing mark values in a separate datastructure. However the mark values can be set now only after a node address was set which is the case when the user is using dlm_controld. Signed-off-by: Alexander Aring Signed-off-by: David Teigland Signed-off-by: Sasha Levin commit ee2202dc67bcbbeebd977ab20d0adc1af8ee897e Author: Alexander Aring Date: Mon Mar 1 17:05:08 2021 -0500 fs: dlm: fix debugfs dump [ Upstream commit 92c48950b43f4a767388cf87709d8687151a641f ] This patch fixes the following message which randomly pops up during glocktop call: seq_file: buggy .next function table_seq_next did not update position index The issue is that seq_read_iter() in fs/seq_file.c also needs an increment of the index in an non next record case as well which this patch fixes otherwise seq_read_iter() will print out the above message. Signed-off-by: Alexander Aring Signed-off-by: David Teigland Signed-off-by: Sasha Levin commit ecfbec245e9131e7ad2813ff0f5dc90385a73875 Author: Nicolas MURE Date: Mon Mar 1 16:27:26 2021 +0100 ALSA: usb-audio: Add Pioneer DJM-850 to quirks-table [ Upstream commit a3c30b0cb6d05f5bf66d1a5d42e876f31753a447 ] Declare the Pioneer DJM-850 interfaces for capture and playback. See https://github.com/nm2107/Pioneer-DJM-850-driver-reverse-engineering/blob/172fb9a61055960c88c67b7c416fe5bf3609807b/doc/usb-device-specifications.md for the complete device spec. Signed-off-by: Nicolas MURE Link: https://lore.kernel.org/r/20210301152729.18094-2-nicolas.mure2019@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 122a4838d02277d7956080f18b5fe9050c3b6a72 Author: Pradeep Kumar Chitrapu Date: Thu Feb 18 10:27:08 2021 -0800 ath11k: fix thermal temperature read [ Upstream commit e3de5bb7ac1a4cb262f8768924fd3ef6182b10bb ] Fix dangling pointer in thermal temperature event which causes incorrect temperature read. Tested-on: IPQ8074 AHB WLAN.HK.2.4.0.1-00041-QCAHKSWPL_SILICONZ-1 Signed-off-by: Pradeep Kumar Chitrapu Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210218182708.8844-1-pradeepc@codeaurora.org Signed-off-by: Sasha Levin commit 90ada0c77449eac8ade01634c548cfd2452d0985 Author: David Matlack Date: Thu May 6 15:24:43 2021 +0000 kvm: Cap halt polling at kvm->max_halt_poll_ns commit 258785ef08b323bddd844b4926a32c2b2045a1b0 upstream. When growing halt-polling, there is no check that the poll time exceeds the per-VM limit. It's possible for vcpu->halt_poll_ns to grow past kvm->max_halt_poll_ns and stay there until a halt which takes longer than kvm->halt_poll_ns. Signed-off-by: David Matlack Signed-off-by: Venkatesh Srinivas Message-Id: <20210506152442.4010298-1-venkateshs@chromium.org> Cc: stable@vger.kernel.org Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 94fdc966c7d98597cef4b0ed973a36610431fb74 Author: Rafael J. Wysocki Date: Wed Apr 21 19:40:56 2021 +0200 cpufreq: intel_pstate: Use HWP if enabled by platform firmware commit e5af36b2adb858e982d78d41d7363d05d951a19a upstream. It turns out that there are systems where HWP is enabled during initialization by the platform firmware (BIOS), but HWP EPP support is not advertised. After commit 7aa1031223bc ("cpufreq: intel_pstate: Avoid enabling HWP if EPP is not supported") intel_pstate refuses to use HWP on those systems, but the fallback PERF_CTL interface does not work on them either because of enabled HWP, and once enabled, HWP cannot be disabled. Consequently, the users of those systems cannot control CPU performance scaling. Address this issue by making intel_pstate use HWP unconditionally if it is enabled already when the driver starts. Fixes: 7aa1031223bc ("cpufreq: intel_pstate: Avoid enabling HWP if EPP is not supported") Reported-by: Srinivas Pandruvada Tested-by: Srinivas Pandruvada Signed-off-by: Rafael J. Wysocki Cc: 5.9+ # 5.9+ Signed-off-by: Greg Kroah-Hartman commit 8c6d2e0ee501dc34ec0e7b5126783f2f51fca483 Author: Tony Lindgren Date: Wed May 5 14:09:15 2021 +0300 PM: runtime: Fix unpaired parent child_count for force_resume commit c745253e2a691a40c66790defe85c104a887e14a upstream. As pm_runtime_need_not_resume() relies also on usage_count, it can return a different value in pm_runtime_force_suspend() compared to when called in pm_runtime_force_resume(). Different return values can happen if anything calls PM runtime functions in between, and causes the parent child_count to increase on every resume. So far I've seen the issue only for omapdrm that does complicated things with PM runtime calls during system suspend for legacy reasons: omap_atomic_commit_tail() for omapdrm.0 dispc_runtime_get() wakes up 58000000.dss as it's the dispc parent dispc_runtime_resume() rpm_resume() increases parent child_count dispc_runtime_put() won't idle, PM runtime suspend blocked pm_runtime_force_suspend() for 58000000.dss, !pm_runtime_need_not_resume() __update_runtime_status() system suspended pm_runtime_force_resume() for 58000000.dss, pm_runtime_need_not_resume() pm_runtime_enable() only called because of pm_runtime_need_not_resume() omap_atomic_commit_tail() for omapdrm.0 dispc_runtime_get() wakes up 58000000.dss as it's the dispc parent dispc_runtime_resume() rpm_resume() increases parent child_count dispc_runtime_put() won't idle, PM runtime suspend blocked ... rpm_suspend for 58000000.dss but parent child_count is now unbalanced Let's fix the issue by adding a flag for needs_force_resume and use it in pm_runtime_force_resume() instead of pm_runtime_need_not_resume(). Additionally omapdrm system suspend could be simplified later on to avoid lots of unnecessary PM runtime calls and the complexity it adds. The driver can just use internal functions that are shared between the PM runtime and system suspend related functions. Fixes: 4918e1f87c5f ("PM / runtime: Rework pm_runtime_force_suspend/resume()") Signed-off-by: Tony Lindgren Reviewed-by: Ulf Hansson Tested-by: Tomi Valkeinen Cc: 4.16+ # 4.16+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 2cff742523ab1ba2e403a87b54383491d9c49715 Author: Sumeet Pawnikar Date: Tue May 11 23:31:42 2021 +0530 ACPI: PM: Add ACPI ID of Alder Lake Fan commit 2404b8747019184002823dba7d2f0ecf89d802b7 upstream. Add a new unique fan ACPI device ID for Alder Lake to support it in acpi_dev_pm_attach() function. Fixes: 38748bcb940e ("ACPI: DPTF: Support Alder Lake") Signed-off-by: Sumeet Pawnikar Acked-by: Zhang Rui Cc: 5.10+ # 5.10+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit d25c24102b17cbbddfdddad1500a33cdc42511fa Author: Lai Jiangshan Date: Tue May 4 21:50:14 2021 +0200 KVM/VMX: Invoke NMI non-IST entry instead of IST entry commit a217a6593cec8b315d4c2f344bae33660b39b703 upstream. In VMX, the host NMI handler needs to be invoked after NMI VM-Exit. Before commit 1a5488ef0dcf6 ("KVM: VMX: Invoke NMI handler via indirect call instead of INTn"), this was done by INTn ("int $2"). But INTn microcode is relatively expensive, so the commit reworked NMI VM-Exit handling to invoke the kernel handler by function call. But this missed a detail. The NMI entry point for direct invocation is fetched from the IDT table and called on the kernel stack. But on 64-bit the NMI entry installed in the IDT expects to be invoked on the IST stack. It relies on the "NMI executing" variable on the IST stack to work correctly, which is at a fixed position in the IST stack. When the entry point is unexpectedly called on the kernel stack, the RSP-addressed "NMI executing" variable is obviously also on the kernel stack and is "uninitialized" and can cause the NMI entry code to run in the wrong way. Provide a non-ist entry point for VMX which shares the C-function with the regular NMI entry and invoke the new asm entry point instead. On 32-bit this just maps to the regular NMI entry point as 32-bit has no ISTs and is not affected. [ tglx: Made it independent for backporting, massaged changelog ] Fixes: 1a5488ef0dcf6 ("KVM: VMX: Invoke NMI handler via indirect call instead of INTn") Signed-off-by: Lai Jiangshan Signed-off-by: Thomas Gleixner Tested-by: Lai Jiangshan Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/87r1imi8i1.ffs@nanos.tec.linutronix.de Signed-off-by: Greg Kroah-Hartman commit fd722a57fe0b80133dacae4e1c852ee4212f9b2e Author: Tom Lendacky Date: Fri Apr 9 09:38:42 2021 -0500 KVM: SVM: Make sure GHCB is mapped before updating commit a3ba26ecfb569f4aa3f867e80c02aa65f20aadad upstream. Access to the GHCB is mainly in the VMGEXIT path and it is known that the GHCB will be mapped. But there are two paths where it is possible the GHCB might not be mapped. The sev_vcpu_deliver_sipi_vector() routine will update the GHCB to inform the caller of the AP Reset Hold NAE event that a SIPI has been delivered. However, if a SIPI is performed without a corresponding AP Reset Hold, then the GHCB might not be mapped (depending on the previous VMEXIT), which will result in a NULL pointer dereference. The svm_complete_emulated_msr() routine will update the GHCB to inform the caller of a RDMSR/WRMSR operation about any errors. While it is likely that the GHCB will be mapped in this situation, add a safe guard in this path to be certain a NULL pointer dereference is not encountered. Fixes: f1c6366e3043 ("KVM: SVM: Add required changes to support intercepts under SEV-ES") Fixes: 647daca25d24 ("KVM: SVM: Add support for booting APs in an SEV-ES guest") Signed-off-by: Tom Lendacky Cc: stable@vger.kernel.org Message-Id: Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 188770ddad9bcb6e622f04fb644f7bc8d2192cb1 Author: Anand Jain Date: Fri Apr 30 19:59:51 2021 +0800 btrfs: fix unmountable seed device after fstrim commit 5e753a817b2d5991dfe8a801b7b1e8e79a1c5a20 upstream. The following test case reproduces an issue of wrongly freeing in-use blocks on the readonly seed device when fstrim is called on the rw sprout device. As shown below. Create a seed device and add a sprout device to it: $ mkfs.btrfs -fq -dsingle -msingle /dev/loop0 $ btrfstune -S 1 /dev/loop0 $ mount /dev/loop0 /btrfs $ btrfs dev add -f /dev/loop1 /btrfs BTRFS info (device loop0): relocating block group 290455552 flags system BTRFS info (device loop0): relocating block group 1048576 flags system BTRFS info (device loop0): disk added /dev/loop1 $ umount /btrfs Mount the sprout device and run fstrim: $ mount /dev/loop1 /btrfs $ fstrim /btrfs $ umount /btrfs Now try to mount the seed device, and it fails: $ mount /dev/loop0 /btrfs mount: /btrfs: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error. Block 5292032 is missing on the readonly seed device: $ dmesg -kt | tail BTRFS error (device loop0): bad tree block start, want 5292032 have 0 BTRFS warning (device loop0): couldn't read-tree root BTRFS error (device loop0): open_ctree failed From the dump-tree of the seed device (taken before the fstrim). Block 5292032 belonged to the block group starting at 5242880: $ btrfs inspect dump-tree -e /dev/loop0 | grep -A1 BLOCK_GROUP item 3 key (5242880 BLOCK_GROUP_ITEM 8388608) itemoff 16169 itemsize 24 block group used 114688 chunk_objectid 256 flags METADATA From the dump-tree of the sprout device (taken before the fstrim). fstrim used block-group 5242880 to find the related free space to free: $ btrfs inspect dump-tree -e /dev/loop1 | grep -A1 BLOCK_GROUP item 1 key (5242880 BLOCK_GROUP_ITEM 8388608) itemoff 16226 itemsize 24 block group used 32768 chunk_objectid 256 flags METADATA BPF kernel tracing the fstrim command finds the missing block 5292032 within the range of the discarded blocks as below: kprobe:btrfs_discard_extent { printf("freeing start %llu end %llu num_bytes %llu:\n", arg1, arg1+arg2, arg2); } freeing start 5259264 end 5406720 num_bytes 147456 Fix this by avoiding the discard command to the readonly seed device. Reported-by: Chris Murphy CC: stable@vger.kernel.org # 4.4+ Reviewed-by: Filipe Manana Signed-off-by: Anand Jain Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 36a6f5f0a7bb690fd1e3baa57397daca4b44fc6b Author: Jarkko Sakkinen Date: Mon May 10 15:28:31 2021 +0300 tpm, tpm_tis: Reserve locality in tpm_tis_resume() commit 8a2d296aaebadd68d9c1f6908667df1d1c84c051 upstream. Reserve locality in tpm_tis_resume(), as it could be unsert after waking up from a sleep state. Cc: stable@vger.kernel.org Cc: Lino Sanfilippo Reported-by: Hans de Goede Fixes: a3fbfae82b4c ("tpm: take TPM chip power gating out of tpm_transmit()") Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit 7dd1d6a54004d4c2290df1a37f72ac87311575c8 Author: Jarkko Sakkinen Date: Mon May 10 15:28:30 2021 +0300 tpm, tpm_tis: Extend locality handling to TPM2 in tpm_tis_gen_interrupt() commit e630af7dfb450d1c00c30077314acf33032ff9e4 upstream. The earlier fix (linked) only partially fixed the locality handling bug in tpm_tis_gen_interrupt(), i.e. only for TPM 1.x. Extend the locality handling to cover TPM2. Cc: Hans de Goede Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-integrity/20210220125534.20707-1-jarkko@kernel.org/ Fixes: a3fbfae82b4c ("tpm: take TPM chip power gating out of tpm_transmit()") Reported-by: Lino Sanfilippo Signed-off-by: Jarkko Sakkinen Tested-by: Lino Sanfilippo Signed-off-by: Greg Kroah-Hartman commit a85e9d1fae780cbd0c1f397fea3a38f5e409a02c Author: Zhen Lei Date: Wed May 12 21:39:26 2021 +0800 tpm: fix error return code in tpm2_get_cc_attrs_tbl() commit 1df83992d977355177810c2b711afc30546c81ce upstream. If the total number of commands queried through TPM2_CAP_COMMANDS is different from that queried through TPM2_CC_GET_CAPABILITY, it indicates an unknown error. In this case, an appropriate error code -EFAULT should be returned. However, we currently do not explicitly assign this error code to 'rc'. As a result, 0 was incorrectly returned. Cc: stable@vger.kernel.org Fixes: 58472f5cd4f6("tpm: validate TPM 2.0 commands") Reported-by: Hulk Robot Signed-off-by: Zhen Lei Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit 3e24fbd37e72e8a67b74991970fecc82d14f57af Author: Colin Ian King Date: Fri Apr 30 12:37:24 2021 +0100 KEYS: trusted: Fix memory leak on object td commit 83a775d5f9bfda95b1c295f95a3a041a40c7f321 upstream. Two error return paths are neglecting to free allocated object td, causing a memory leak. Fix this by returning via the error return path that securely kfree's td. Fixes clang scan-build warning: security/keys/trusted-keys/trusted_tpm1.c:496:10: warning: Potential memory leak [unix.Malloc] Cc: stable@vger.kernel.org Fixes: 5df16caada3f ("KEYS: trusted: Fix incorrect handling of tpm_get_random()") Signed-off-by: Colin Ian King Reviewed-by: Nick Desaulniers Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit 4bcf3b752d59b1ef839afcc4b1c0731652ef40d6 Author: Greg Kroah-Hartman Date: Fri May 14 10:53:07 2021 +0200 Linux 5.12.4 Tested-by: Florian Fainelli Tested-by: Jon Hunter Tested-by: Shuah Khan Tested-by: Jason Self Tested-by: Fox Chen Reported-by: Linux Kernel Functional Testing Tested-by: Justin M. Forbes Link: https://lore.kernel.org/r/20210512144837.204217980@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit f7a805d1bb53c61d9539e5801af564958d1974d7 Author: Xin Long Date: Mon May 3 05:11:42 2021 +0800 sctp: delay auto_asconf init until binding the first addr commit 34e5b01186858b36c4d7c87e1a025071e8e2401f upstream. As Or Cohen described: If sctp_destroy_sock is called without sock_net(sk)->sctp.addr_wq_lock held and sp->do_auto_asconf is true, then an element is removed from the auto_asconf_splist without any proper locking. This can happen in the following functions: 1. In sctp_accept, if sctp_sock_migrate fails. 2. In inet_create or inet6_create, if there is a bpf program attached to BPF_CGROUP_INET_SOCK_CREATE which denies creation of the sctp socket. This patch is to fix it by moving the auto_asconf init out of sctp_init_sock(), by which inet_create()/inet6_create() won't need to operate it in sctp_destroy_sock() when calling sk_common_release(). It also makes more sense to do auto_asconf init while binding the first addr, as auto_asconf actually requires an ANY addr bind, see it in sctp_addr_wq_timeout_handler(). This addresses CVE-2021-23133. Fixes: 610236587600 ("bpf: Add new cgroup attach type to enable sock modifications") Reported-by: Or Cohen Signed-off-by: Xin Long Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 3b31f6e8484986e0ffab2ed0b6af937e5f01b6fc Author: Xin Long Date: Mon May 3 05:11:41 2021 +0800 Revert "net/sctp: fix race condition in sctp_destroy_sock" commit 01bfe5e8e428b475982a98a46cca5755726f3f7f upstream. This reverts commit b166a20b07382b8bc1dcee2a448715c9c2c81b5b. This one has to be reverted as it introduced a dead lock, as syzbot reported: CPU0 CPU1 ---- ---- lock(&net->sctp.addr_wq_lock); lock(slock-AF_INET6); lock(&net->sctp.addr_wq_lock); lock(slock-AF_INET6); CPU0 is the thread of sctp_addr_wq_timeout_handler(), and CPU1 is that of sctp_close(). The original issue this commit fixed will be fixed in the next patch. Reported-by: syzbot+959223586843e69a2674@syzkaller.appspotmail.com Signed-off-by: Xin Long Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 2a8d740aac1b3063b24efe422e4f0756562fbf0e Author: Arnd Bergmann Date: Wed May 5 23:12:42 2021 +0200 smp: Fix smp_call_function_single_async prototype commit 1139aeb1c521eb4a050920ce6c64c36c4f2a3ab7 upstream. As of commit 966a967116e6 ("smp: Avoid using two cache lines for struct call_single_data"), the smp code prefers 32-byte aligned call_single_data objects for performance reasons, but the block layer includes an instance of this structure in the main 'struct request' that is more senstive to size than to performance here, see 4ccafe032005 ("block: unalign call_single_data in struct request"). The result is a violation of the calling conventions that clang correctly points out: block/blk-mq.c:630:39: warning: passing 8-byte aligned argument to 32-byte aligned parameter 2 of 'smp_call_function_single_async' may result in an unaligned pointer access [-Walign-mismatch] smp_call_function_single_async(cpu, &rq->csd); It does seem that the usage of the call_single_data without cache line alignment should still be allowed by the smp code, so just change the function prototype so it accepts both, but leave the default alignment unchanged for the other users. This seems better to me than adding a local hack to shut up an otherwise correct warning in the caller. Signed-off-by: Arnd Bergmann Signed-off-by: Peter Zijlstra (Intel) Acked-by: Jens Axboe Link: https://lkml.kernel.org/r/20210505211300.3174456-1-arnd@kernel.org [nc: Fix conflicts] Signed-off-by: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman commit e7d7bedd507bb732e600403b7a96f9fe48d0ca31 Author: Jonathon Reinhart Date: Sat May 1 04:28:22 2021 -0400 net: Only allow init netns to set default tcp cong to a restricted algo commit 8d432592f30fcc34ef5a10aac4887b4897884493 upstream. tcp_set_default_congestion_control() is netns-safe in that it writes to &net->ipv4.tcp_congestion_control, but it also sets ca->flags |= TCP_CONG_NON_RESTRICTED which is not namespaced. This has the unintended side-effect of changing the global net.ipv4.tcp_allowed_congestion_control sysctl, despite the fact that it is read-only: 97684f0970f6 ("net: Make tcp_allowed_congestion_control readonly in non-init netns") Resolve this netns "leak" by only allowing the init netns to set the default algorithm to one that is restricted. This restriction could be removed if tcp_allowed_congestion_control were namespace-ified in the future. This bug was uncovered with https://github.com/JonathonReinhart/linux-netns-sysctl-verify Fixes: 6670e1524477 ("tcp: Namespace-ify sysctl_tcp_default_congestion_control") Signed-off-by: Jonathon Reinhart Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit eb88d8466be546fdb60139e9283397ec4ac93f3b Author: Andrii Nakryiko Date: Tue May 4 16:38:00 2021 -0700 bpf: Prevent writable memory-mapping of read-only ringbuf pages commit 04ea3086c4d73da7009de1e84962a904139af219 upstream. Only the very first page of BPF ringbuf that contains consumer position counter is supposed to be mapped as writeable by user-space. Producer position is read-only and can be modified only by the kernel code. BPF ringbuf data pages are read-only as well and are not meant to be modified by user-code to maintain integrity of per-record headers. This patch allows to map only consumer position page as writeable and everything else is restricted to be read-only. remap_vmalloc_range() internally adds VM_DONTEXPAND, so all the established memory mappings can't be extended, which prevents any future violations through mremap()'ing. Fixes: 457f44363a88 ("bpf: Implement BPF ring buffer and verifier support for it") Reported-by: Ryota Shiga (Flatt Security) Reported-by: Thadeu Lima de Souza Cascardo Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: Alexei Starovoitov Signed-off-by: Greg Kroah-Hartman commit 53eb85cc663089f0eff42679f54ae915dcefc433 Author: Thadeu Lima de Souza Cascardo Date: Tue Apr 27 10:12:12 2021 -0300 bpf, ringbuf: Deny reserve of buffers larger than ringbuf commit 4b81ccebaeee885ab1aa1438133f2991e3a2b6ea upstream. A BPF program might try to reserve a buffer larger than the ringbuf size. If the consumer pointer is way ahead of the producer, that would be successfully reserved, allowing the BPF program to read or write out of the ringbuf allocated area. Reported-by: Ryota Shiga (Flatt Security) Fixes: 457f44363a88 ("bpf: Implement BPF ring buffer and verifier support for it") Signed-off-by: Thadeu Lima de Souza Cascardo Signed-off-by: Daniel Borkmann Acked-by: Andrii Nakryiko Acked-by: Alexei Starovoitov Signed-off-by: Greg Kroah-Hartman commit 9fdd1d10daac186e21a77290f9d22b41e175e1b9 Author: Daniel Borkmann Date: Mon May 10 13:10:44 2021 +0000 bpf: Fix alu32 const subreg bound tracking on bitwise operations commit 049c4e13714ecbca567b4d5f6d563f05d431c80e upstream. Fix a bug in the verifier's scalar32_min_max_*() functions which leads to incorrect tracking of 32 bit bounds for the simulation of and/or/xor bitops. When both the src & dst subreg is a known constant, then the assumption is that scalar_min_max_*() will take care to update bounds correctly. However, this is not the case, for example, consider a register R2 which has a tnum of 0xffffffff00000000, meaning, lower 32 bits are known constant and in this case of value 0x00000001. R2 is then and'ed with a register R3 which is a 64 bit known constant, here, 0x100000002. What can be seen in line '10:' is that 32 bit bounds reach an invalid state where {u,s}32_min_value > {u,s}32_max_value. The reason is scalar32_min_max_*() delegates 32 bit bounds updates to scalar_min_max_*(), however, that really only takes place when both the 64 bit src & dst register is a known constant. Given scalar32_min_max_*() is intended to be designed as closely as possible to scalar_min_max_*(), update the 32 bit bounds in this situation through __mark_reg32_known() which will set all {u,s}32_{min,max}_value to the correct constant, which is 0x00000000 after the fix (given 0x00000001 & 0x00000002 in 32 bit space). This is possible given var32_off already holds the final value as dst_reg->var_off is updated before calling scalar32_min_max_*(). Before fix, invalid tracking of R2: [...] 9: R0_w=inv1337 R1=ctx(id=0,off=0,imm=0) R2_w=inv(id=0,smin_value=-9223372036854775807 (0x8000000000000001),smax_value=9223372032559808513 (0x7fffffff00000001),umin_value=1,umax_value=0xffffffff00000001,var_off=(0x1; 0xffffffff00000000),s32_min_value=1,s32_max_value=1,u32_min_value=1,u32_max_value=1) R3_w=inv4294967298 R10=fp0 9: (5f) r2 &= r3 10: R0_w=inv1337 R1=ctx(id=0,off=0,imm=0) R2_w=inv(id=0,smin_value=0,smax_value=4294967296 (0x100000000),umin_value=0,umax_value=0x100000000,var_off=(0x0; 0x100000000),s32_min_value=1,s32_max_value=0,u32_min_value=1,u32_max_value=0) R3_w=inv4294967298 R10=fp0 [...] After fix, correct tracking of R2: [...] 9: R0_w=inv1337 R1=ctx(id=0,off=0,imm=0) R2_w=inv(id=0,smin_value=-9223372036854775807 (0x8000000000000001),smax_value=9223372032559808513 (0x7fffffff00000001),umin_value=1,umax_value=0xffffffff00000001,var_off=(0x1; 0xffffffff00000000),s32_min_value=1,s32_max_value=1,u32_min_value=1,u32_max_value=1) R3_w=inv4294967298 R10=fp0 9: (5f) r2 &= r3 10: R0_w=inv1337 R1=ctx(id=0,off=0,imm=0) R2_w=inv(id=0,smin_value=0,smax_value=4294967296 (0x100000000),umin_value=0,umax_value=0x100000000,var_off=(0x0; 0x100000000),s32_min_value=0,s32_max_value=0,u32_min_value=0,u32_max_value=0) R3_w=inv4294967298 R10=fp0 [...] Fixes: 3f50f132d840 ("bpf: Verifier, do explicit ALU32 bounds tracking") Fixes: 2921c90d4718 ("bpf: Fix a verifier failure with xor") Reported-by: Manfred Paul (@_manfp) Reported-by: Thadeu Lima de Souza Cascardo Signed-off-by: Daniel Borkmann Reviewed-by: John Fastabend Acked-by: Alexei Starovoitov Signed-off-by: Greg Kroah-Hartman commit d22f538e9ec61c8ba55a408f2f530c63167a1e9e Author: David Howells Date: Fri Apr 30 13:47:08 2021 +0100 afs: Fix speculative status fetches [ Upstream commit 22650f148126571be1098d34160eb4931fc77241 ] The generic/464 xfstest causes kAFS to emit occasional warnings of the form: kAFS: vnode modified {100055:8a} 30->31 YFS.StoreData64 (c=6015) This indicates that the data version received back from the server did not match the expected value (the DV should be incremented monotonically for each individual modification op committed to a vnode). What is happening is that a lookup call is doing a bulk status fetch speculatively on a bunch of vnodes in a directory besides getting the status of the vnode it's actually interested in. This is racing with a StoreData operation (though it could also occur with, say, a MakeDir op). On the client, a modification operation locks the vnode, but the bulk status fetch only locks the parent directory, so no ordering is imposed there (thereby avoiding an avenue to deadlock). On the server, the StoreData op handler doesn't lock the vnode until it's received all the request data, and downgrades the lock after committing the data until it has finished sending change notifications to other clients - which allows the status fetch to occur before it has finished. This means that: - a status fetch can access the target vnode either side of the exclusive section of the modification - the status fetch could start before the modification, yet finish after, and vice-versa. - the status fetch and the modification RPCs can complete in either order. - the status fetch can return either the before or the after DV from the modification. - the status fetch might regress the locally cached DV. Some of these are handled by the previous fix[1], but that's not sufficient because it checks the DV it received against the DV it cached at the start of the op, but the DV might've been updated in the meantime by a locally generated modification op. Fix this by the following means: (1) Keep track of when we're performing a modification operation on a vnode. This is done by marking vnode parameters with a 'modification' note that causes the AFS_VNODE_MODIFYING flag to be set on the vnode for the duration. (2) Alter the speculation race detection to ignore speculative status fetches if either the vnode is marked as being modified or the data version number is not what we expected. Note that whilst the "vnode modified" warning does get recovered from as it causes the client to refetch the status at the next opportunity, it will also invalidate the pagecache, so changes might get lost. Fixes: a9e5c87ca744 ("afs: Fix speculative status fetch going out of order wrt to modifications") Reported-by: Marc Dionne Signed-off-by: David Howells Tested-and-reviewed-by: Marc Dionne cc: linux-afs@lists.infradead.org Link: https://lore.kernel.org/r/160605082531.252452.14708077925602709042.stgit@warthog.procyon.org.uk/ [1] Link: https://lore.kernel.org/linux-fsdevel/161961335926.39335.2552653972195467566.stgit@warthog.procyon.org.uk/ # v1 Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 64055efc88bc75b7a991f4be525a9ca998086c45 Author: Jane Chu Date: Thu Apr 29 23:02:19 2021 -0700 mm/memory-failure: unnecessary amount of unmapping [ Upstream commit 4d75136be8bf3ae01b0bc3e725b2cdc921e103bd ] It appears that unmap_mapping_range() actually takes a 'size' as its third argument rather than a location, the current calling fashion causes unnecessary amount of unmapping to occur. Link: https://lkml.kernel.org/r/20210420002821.2749748-1-jane.chu@oracle.com Fixes: 6100e34b2526e ("mm, memory_failure: Teach memory_failure() about dev_pagemap pages") Signed-off-by: Jane Chu Reviewed-by: Dan Williams Reviewed-by: Naoya Horiguchi Cc: Dave Jiang Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit d1ebd228ceabcb86623cd5b105594d98146fa834 Author: Wang Wensheng Date: Thu Apr 29 22:57:58 2021 -0700 mm/sparse: add the missing sparse_buffer_fini() in error branch [ Upstream commit 2284f47fe9fe2ed2ef619e5474e155cfeeebd569 ] sparse_buffer_init() and sparse_buffer_fini() should appear in pair, or a WARN issue would be through the next time sparse_buffer_init() runs. Add the missing sparse_buffer_fini() in error branch. Link: https://lkml.kernel.org/r/20210325113155.118574-1-wangwensheng4@huawei.com Fixes: 85c77f791390 ("mm/sparse: add new sparse_init_nid() and sparse_init()") Signed-off-by: Wang Wensheng Reviewed-by: David Hildenbrand Reviewed-by: Oscar Salvador Cc: Pavel Tatashin Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit c3ae6a3f3ca4f02f6ccddf213c027302586580d0 Author: Muchun Song Date: Thu Apr 29 22:56:39 2021 -0700 mm: memcontrol: slab: fix obtain a reference to a freeing memcg [ Upstream commit 9f38f03ae8d5f57371b71aa6b4275765b65454fd ] Patch series "Use obj_cgroup APIs to charge kmem pages", v5. Since Roman's series "The new cgroup slab memory controller" applied. All slab objects are charged with the new APIs of obj_cgroup. The new APIs introduce a struct obj_cgroup to charge slab objects. It prevents long-living objects from pinning the original memory cgroup in the memory. But there are still some corner objects (e.g. allocations larger than order-1 page on SLUB) which are not charged with the new APIs. Those objects (include the pages which are allocated from buddy allocator directly) are charged as kmem pages which still hold a reference to the memory cgroup. E.g. We know that the kernel stack is charged as kmem pages because the size of the kernel stack can be greater than 2 pages (e.g. 16KB on x86_64 or arm64). If we create a thread (suppose the thread stack is charged to memory cgroup A) and then move it from memory cgroup A to memory cgroup B. Because the kernel stack of the thread hold a reference to the memory cgroup A. The thread can pin the memory cgroup A in the memory even if we remove the cgroup A. If we want to see this scenario by using the following script. We can see that the system has added 500 dying cgroups (This is not a real world issue, just a script to show that the large kmallocs are charged as kmem pages which can pin the memory cgroup in the memory). #!/bin/bash cat /proc/cgroups | grep memory cd /sys/fs/cgroup/memory echo 1 > memory.move_charge_at_immigrate for i in range{1..500} do mkdir kmem_test echo $$ > kmem_test/cgroup.procs sleep 3600 & echo $$ > cgroup.procs echo `cat kmem_test/cgroup.procs` > cgroup.procs rmdir kmem_test done cat /proc/cgroups | grep memory This patchset aims to make those kmem pages to drop the reference to memory cgroup by using the APIs of obj_cgroup. Finally, we can see that the number of the dying cgroups will not increase if we run the above test script. This patch (of 7): The rcu_read_lock/unlock only can guarantee that the memcg will not be freed, but it cannot guarantee the success of css_get (which is in the refill_stock when cached memcg changed) to memcg. rcu_read_lock() memcg = obj_cgroup_memcg(old) __memcg_kmem_uncharge(memcg) refill_stock(memcg) if (stock->cached != memcg) // css_get can change the ref counter from 0 back to 1. css_get(&memcg->css) rcu_read_unlock() This fix is very like the commit: eefbfa7fd678 ("mm: memcg/slab: fix use after free in obj_cgroup_charge") Fix this by holding a reference to the memcg which is passed to the __memcg_kmem_uncharge() before calling __memcg_kmem_uncharge(). Link: https://lkml.kernel.org/r/20210319163821.20704-1-songmuchun@bytedance.com Link: https://lkml.kernel.org/r/20210319163821.20704-2-songmuchun@bytedance.com Fixes: 3de7d4f25a74 ("mm: memcg/slab: optimize objcg stock draining") Signed-off-by: Muchun Song Reviewed-by: Shakeel Butt Acked-by: Roman Gushchin Acked-by: Johannes Weiner Cc: Michal Hocko Cc: Vladimir Davydov Cc: Xiongchun Duan Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 805e3b93c93fbae781d28e12c9f82605812da98d Author: Dan Carpenter Date: Thu Apr 29 22:54:15 2021 -0700 kfifo: fix ternary sign extension bugs [ Upstream commit 926ee00ea24320052b46745ef4b00d91c05bd03d ] The intent with this code was to return negative error codes but instead it returns positives. The problem is how type promotion works with ternary operations. These functions return long, "ret" is an int and "copied" is a u32. The negative error code is first cast to u32 so it becomes a high positive and then cast to long where it's still a positive. We could fix this by declaring "ret" as a ssize_t but let's just get rid of the ternaries instead. Link: https://lkml.kernel.org/r/YIE+/cK1tBzSuQPU@mwanda Fixes: 5bf2b19320ec ("kfifo: add example files to the kernel sample directory") Signed-off-by: Dan Carpenter Cc: Stefani Seibold Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 36550ef5418dc69ef0bea4be225aaa3af7e9cd6b Author: Sergei Trofimovich Date: Thu Apr 29 22:53:39 2021 -0700 ia64: fix EFI_DEBUG build [ Upstream commit e3db00b79d74caaf84cd9e1d4927979abfd0d7c9 ] When enabled local debugging via `#define EFI_DEBUG 1` noticed build failure: arch/ia64/kernel/efi.c:564:8: error: 'i' undeclared (first use in this function) While at it fixed benign string format mismatches visible only when EFI_DEBUG is enabled: arch/ia64/kernel/efi.c:589:11: warning: format '%lx' expects argument of type 'long unsigned int', but argument 5 has type 'u64' {aka 'long long unsigned int'} [-Wformat=] Link: https://lkml.kernel.org/r/20210328212246.685601-1-slyfox@gentoo.org Fixes: 14fb42090943559 ("efi: Merge EFI system table revision and vendor checks") Signed-off-by: Sergei Trofimovich Cc: Ard Biesheuvel Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 7ea1491f269701c1c237213e1ed09b4d05686a87 Author: Valentin Schneider Date: Thu Apr 29 22:53:27 2021 -0700 ia64: ensure proper NUMA distance and possible map initialization [ Upstream commit b22a8f7b4bde4e4ab73b64908ffd5d90ecdcdbfd ] John Paul reported a warning about bogus NUMA distance values spurred by commit: 620a6dc40754 ("sched/topology: Make sched_init_numa() use a set for the deduplicating sort") In this case, the afflicted machine comes up with a reported 256 possible nodes, all of which are 0 distance away from one another. This was previously silently ignored, but is now caught by the aforementioned commit. The culprit is ia64's node_possible_map which remains unchanged from its initialization value of NODE_MASK_ALL. In John's case, the machine doesn't have any SRAT nor SLIT table, but AIUI the possible map remains untouched regardless of what ACPI tables end up being parsed. Thus, !online && possible nodes remain with a bogus distance of 0 (distances \in [0, 9] are "reserved and have no meaning" as per the ACPI spec). Follow x86 / drivers/base/arch_numa's example and set the possible map to the parsed map, which in this case seems to be the online map. Link: http://lore.kernel.org/r/255d6b5d-194e-eb0e-ecdd-97477a534441@physik.fu-berlin.de Link: https://lkml.kernel.org/r/20210318130617.896309-1-valentin.schneider@arm.com Fixes: 620a6dc40754 ("sched/topology: Make sched_init_numa() use a set for the deduplicating sort") Signed-off-by: Valentin Schneider Reported-by: John Paul Adrian Glaubitz Tested-by: John Paul Adrian Glaubitz Tested-by: Sergei Trofimovich Cc: "Peter Zijlstra (Intel)" Cc: Ingo Molnar Cc: Vincent Guittot Cc: Dietmar Eggemann Cc: Anatoly Pugachev Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 1e05c2b9d691cfc1d01fc6813a0ba43418921e31 Author: Leo Yan Date: Wed Apr 28 20:09:14 2021 +0800 perf session: Add swap operation for event TIME_CONV [ Upstream commit 050ffc449008eeeafc187dec337d9cf1518f89bc ] Since commit d110162cafc8 ("perf tsc: Support cap_user_time_short for event TIME_CONV"), the event PERF_RECORD_TIME_CONV has extended the data structure for clock parameters. To be backwards-compatible, this patch adds a dedicated swap operation for the event PERF_RECORD_TIME_CONV, based on checking if the event contains field "time_cycles", it can support both for the old and new event formats. Fixes: d110162cafc8 ("perf tsc: Support cap_user_time_short for event TIME_CONV") Signed-off-by: Leo Yan Acked-by: Adrian Hunter Cc: Alexander Shishkin Cc: Gustavo A. R. Silva Cc: Ingo Molnar Cc: Jiri Olsa Cc: Kan Liang Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Steve MacLean Cc: Yonatan Goldschmidt Link: https://lore.kernel.org/r/20210428120915.7123-4-leo.yan@linaro.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 59bf7d961a808d33fb24e5a6f251c060d646a7bf Author: Leo Yan Date: Wed Apr 28 20:09:13 2021 +0800 perf jit: Let convert_timestamp() to be backwards-compatible [ Upstream commit aa616f5a8a2d22a179d5502ebd85045af66fa656 ] Commit d110162cafc80dad ("perf tsc: Support cap_user_time_short for event TIME_CONV") supports the extended parameters for event TIME_CONV, but it broke the backwards compatibility, so any perf data file with old event format fails to convert timestamp. This patch introduces a helper event_contains() to check if an event contains a specific member or not. For the backwards-compatibility, if the event size confirms the extended parameters are supported in the event TIME_CONV, then copies these parameters. Committer notes: To make this compiler backwards compatible add this patch: - struct perf_tsc_conversion tc = { 0 }; + struct perf_tsc_conversion tc = { .time_shift = 0, }; Fixes: d110162cafc8 ("perf tsc: Support cap_user_time_short for event TIME_CONV") Signed-off-by: Leo Yan Acked-by: Adrian Hunter Cc: Alexander Shishkin Cc: Gustavo A. R. Silva Cc: Ingo Molnar Cc: Jiri Olsa Cc: Kan Liang Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Steve MacLean Cc: Yonatan Goldschmidt Link: https://lore.kernel.org/r/20210428120915.7123-3-leo.yan@linaro.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit f57f2d897ff347be783ece0d66c93c5b8d82797c Author: Leo Yan Date: Wed Apr 28 20:09:12 2021 +0800 perf tools: Change fields type in perf_record_time_conv [ Upstream commit e1d380ea8b00db4bb14d1f513000d4b62aa9d3f0 ] C standard claims "An object declared as type _Bool is large enough to store the values 0 and 1", bool type size can be 1 byte or larger than 1 byte. Thus it's uncertian for bool type size with different compilers. This patch changes the bool type in structure perf_record_time_conv to __u8 type, and pads extra bytes for 8-byte alignment; this can give reliable structure size. Fixes: d110162cafc8 ("perf tsc: Support cap_user_time_short for event TIME_CONV") Suggested-by: Adrian Hunter Signed-off-by: Leo Yan Acked-by: Adrian Hunter Cc: Alexander Shishkin Cc: Gustavo A. R. Silva Cc: Ingo Molnar Cc: Jiri Olsa Cc: Kan Liang Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Steve MacLean Cc: Yonatan Goldschmidt Link: https://lore.kernel.org/r/20210428120915.7123-2-leo.yan@linaro.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit c899dc41655e892e8d79f258f62dd45360e1a38f Author: Lv Yunlong Date: Tue Apr 27 09:22:58 2021 -0700 net:nfc:digital: Fix a double free in digital_tg_recv_dep_req [ Upstream commit 75258586793efc521e5dd52a5bf6c7a4cf7002be ] In digital_tg_recv_dep_req, it calls nfc_tm_data_received(..,resp). If nfc_tm_data_received() failed, the callee will free the resp via kfree_skb() and return error. But in the exit branch, the resp will be freed again. My patch sets resp to NULL if nfc_tm_data_received() failed, to avoid the double free. Fixes: 1c7a4c24fbfd9 ("NFC Digital: Add target NFC-DEP support") Signed-off-by: Lv Yunlong Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 709d47b034946fd7a90d30a153a4932dec69e321 Author: Tobias Waldekranz Date: Mon Apr 26 18:17:34 2021 +0200 net: dsa: mv88e6xxx: Fix 6095/6097/6185 ports in non-SERDES CMODE [ Upstream commit 6066234aa33850e9e35e7be82d92b9e9091e774b ] The .serdes_get_lane op used the magic value 0xff to indicate a valid SERDES lane and 0 signaled that a non-SERDES mode was set on the port. Unfortunately, "0" is also a valid lane ID, so even when these ports where configured to e.g. RGMII the driver would set them up as SERDES ports. - Replace 0xff with 0 to indicate a valid lane ID. The number is on the one hand just as arbitrary, but it is at least the first valid one and therefore less of a surprise. - Follow the other .serdes_get_lane implementations and return -ENODEV in the case where no SERDES is assigned to the port. Fixes: f5be107c3338 ("net: dsa: mv88e6xxx: Support serdes ports on MV88E6097/6095/6185") Signed-off-by: Tobias Waldekranz Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4903918c10b4b511a7cc4b376c7a70ca5c377ae6 Author: Linus Lüssing Date: Sun Apr 25 17:27:35 2021 +0200 net: bridge: mcast: fix broken length + header check for MRDv6 Adv. [ Upstream commit 99014088156cd78867d19514a0bc771c4b86b93b ] The IPv6 Multicast Router Advertisements parsing has the following two issues: For one thing, ICMPv6 MRD Advertisements are smaller than ICMPv6 MLD messages (ICMPv6 MRD Adv.: 8 bytes vs. ICMPv6 MLDv1/2: >= 24 bytes, assuming MLDv2 Reports with at least one multicast address entry). When ipv6_mc_check_mld_msg() tries to parse an Multicast Router Advertisement its MLD length check will fail - and it will wrongly return -EINVAL, even if we have a valid MRD Advertisement. With the returned -EINVAL the bridge code will assume a broken packet and will wrongly discard it, potentially leading to multicast packet loss towards multicast routers. The second issue is the MRD header parsing in br_ip6_multicast_mrd_rcv(): It wrongly checks for an ICMPv6 header immediately after the IPv6 header (IPv6 next header type). However according to RFC4286, section 2 all MRD messages contain a Router Alert option (just like MLD). So instead there is an IPv6 Hop-by-Hop option for the Router Alert between the IPv6 and ICMPv6 header, again leading to the bridge wrongly discarding Multicast Router Advertisements. To fix these two issues, introduce a new return value -ENODATA to ipv6_mc_check_mld() to indicate a valid ICMPv6 packet with a hop-by-hop option which is not an MLD but potentially an MRD packet. This also simplifies further parsing in the bridge code, as ipv6_mc_check_mld() already fully checks the ICMPv6 header and hop-by-hop option. These issues were found and fixed with the help of the mrdisc tool (https://github.com/troglobit/mrdisc). Fixes: 4b3087c7e37f ("bridge: Snoop Multicast Router Advertisements") Signed-off-by: Linus Lüssing Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5b87fbb20483f421eed884faf02af800c311816b Author: Lv Yunlong Date: Mon Apr 26 07:06:14 2021 -0700 RDMA/bnxt_re: Fix a double free in bnxt_qplib_alloc_res [ Upstream commit 34b39efa5ae82fc0ad0acc27653c12a56328dbbe ] In bnxt_qplib_alloc_res, it calls bnxt_qplib_alloc_dpi_tbl(). Inside bnxt_qplib_alloc_dpi_tbl, dpit->dbr_bar_reg_iomem is freed via pci_iounmap() in unmap_io error branch. After the callee returns err code, bnxt_qplib_alloc_res calls bnxt_qplib_free_res()->bnxt_qplib_free_dpi_tbl() in the fail branch. Then dpit->dbr_bar_reg_iomem is freed in the second time by pci_iounmap(). My patch set dpit->dbr_bar_reg_iomem to NULL after it is freed by pci_iounmap() in the first time, to avoid the double free. Fixes: 1ac5a4047975 ("RDMA/bnxt_re: Add bnxt_re RoCE driver") Link: https://lore.kernel.org/r/20210426140614.6722-1-lyl2019@mail.ustc.edu.cn Signed-off-by: Lv Yunlong Reviewed-by: Leon Romanovsky Acked-by: Devesh Sharma Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit ad9ce7188432650469a6c7625bf479f5ed0b6155 Author: Lv Yunlong Date: Sun Apr 25 18:16:47 2021 -0700 RDMA/siw: Fix a use after free in siw_alloc_mr [ Upstream commit 3093ee182f01689b89e9f8797b321603e5de4f63 ] Our code analyzer reported a UAF. In siw_alloc_mr(), it calls siw_mr_add_mem(mr,..). In the implementation of siw_mr_add_mem(), mem is assigned to mr->mem and then mem is freed via kfree(mem) if xa_alloc_cyclic() failed. Here, mr->mem still point to a freed object. After, the execution continue up to the err_out branch of siw_alloc_mr, and the freed mr->mem is used in siw_mr_drop_mem(mr). My patch moves "mr->mem = mem" behind the if (xa_alloc_cyclic(..)<0) {} section, to avoid the uaf. Fixes: 2251334dcac9 ("rdma/siw: application buffer management") Link: https://lore.kernel.org/r/20210426011647.3561-1-lyl2019@mail.ustc.edu.cn Signed-off-by: Lv Yunlong Reviewed-by: Bernard Metzler Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit b64a9914918d4f2112fd244fe7bb6f98b20e8f60 Author: Daniel Borkmann Date: Fri Apr 23 13:59:55 2021 +0000 bpf: Fix propagation of 32 bit unsigned bounds from 64 bit bounds [ Upstream commit 10bf4e83167cc68595b85fd73bb91e8f2c086e36 ] Similarly as b02709587ea3 ("bpf: Fix propagation of 32-bit signed bounds from 64-bit bounds."), we also need to fix the propagation of 32 bit unsigned bounds from 64 bit counterparts. That is, really only set the u32_{min,max}_value when /both/ {umin,umax}_value safely fit in 32 bit space. For example, the register with a umin_value == 1 does /not/ imply that u32_min_value is also equal to 1, since umax_value could be much larger than 32 bit subregister can hold, and thus u32_min_value is in the interval [0,1] instead. Before fix, invalid tracking result of R2_w=inv1: [...] 5: R0_w=inv1337 R1=ctx(id=0,off=0,imm=0) R2_w=inv(id=0) R10=fp0 5: (35) if r2 >= 0x1 goto pc+1 [...] // goto path 7: R0=inv1337 R1=ctx(id=0,off=0,imm=0) R2=inv(id=0,umin_value=1) R10=fp0 7: (b6) if w2 <= 0x1 goto pc+1 [...] // goto path 9: R0=inv1337 R1=ctx(id=0,off=0,imm=0) R2=inv(id=0,smin_value=-9223372036854775807,smax_value=9223372032559808513,umin_value=1,umax_value=18446744069414584321,var_off=(0x1; 0xffffffff00000000),s32_min_value=1,s32_max_value=1,u32_max_value=1) R10=fp0 9: (bc) w2 = w2 10: R0=inv1337 R1=ctx(id=0,off=0,imm=0) R2_w=inv1 R10=fp0 [...] After fix, correct tracking result of R2_w=inv(id=0,umax_value=1,var_off=(0x0; 0x1)): [...] 5: R0_w=inv1337 R1=ctx(id=0,off=0,imm=0) R2_w=inv(id=0) R10=fp0 5: (35) if r2 >= 0x1 goto pc+1 [...] // goto path 7: R0=inv1337 R1=ctx(id=0,off=0,imm=0) R2=inv(id=0,umin_value=1) R10=fp0 7: (b6) if w2 <= 0x1 goto pc+1 [...] // goto path 9: R0=inv1337 R1=ctx(id=0,off=0,imm=0) R2=inv(id=0,smax_value=9223372032559808513,umax_value=18446744069414584321,var_off=(0x0; 0xffffffff00000001),s32_min_value=0,s32_max_value=1,u32_max_value=1) R10=fp0 9: (bc) w2 = w2 10: R0=inv1337 R1=ctx(id=0,off=0,imm=0) R2_w=inv(id=0,umax_value=1,var_off=(0x0; 0x1)) R10=fp0 [...] Thus, same issue as in b02709587ea3 holds for unsigned subregister tracking. Also, align __reg64_bound_u32() similarly to __reg64_bound_s32() as done in b02709587ea3 to make them uniform again. Fixes: 3f50f132d840 ("bpf: Verifier, do explicit ALU32 bounds tracking") Reported-by: Manfred Paul (@_manfp) Signed-off-by: Daniel Borkmann Reviewed-by: John Fastabend Acked-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit e738b042761ae9c08b7f9a2138917eba86461b15 Author: Andrii Nakryiko Date: Mon Apr 26 12:29:49 2021 -0700 selftests/bpf: Fix core_reloc test runner [ Upstream commit bede0ebf0be87e9678103486a77f39e0334c6791 ] Fix failed tests checks in core_reloc test runner, which allowed failing tests to pass quietly. Also add extra check to make sure that expected to fail test cases with invalid names are caught as test failure anyway, as this is not an expected failure mode. Also fix mislabeled probed vs direct bitfield test cases. Fixes: 124a892d1c41 ("selftests/bpf: Test TYPE_EXISTS and TYPE_SIZE CO-RE relocations") Reported-by: Lorenz Bauer Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Lorenz Bauer Link: https://lore.kernel.org/bpf/20210426192949.416837-6-andrii@kernel.org Signed-off-by: Sasha Levin commit dade94cf32233b13e3e672fc10e2a4dc0eb871b5 Author: Andrii Nakryiko Date: Mon Apr 26 12:29:48 2021 -0700 selftests/bpf: Fix field existence CO-RE reloc tests [ Upstream commit 5a30eb23922b52f33222c6729b6b3ff1c37a6c66 ] Negative field existence cases for have a broken assumption that FIELD_EXISTS CO-RE relo will fail for fields that match the name but have incompatible type signature. That's not how CO-RE relocations generally behave. Types and fields that match by name but not by expected type are treated as non-matching candidates and are skipped. Error later is reported if no matching candidate was found. That's what happens for most relocations, but existence relocations (FIELD_EXISTS and TYPE_EXISTS) are more permissive and they are designed to return 0 or 1, depending if a match is found. This allows to handle name-conflicting but incompatible types in BPF code easily. Combined with ___flavor suffixes, it's possible to handle pretty much any structural type changes in kernel within the compiled once BPF source code. So, long story short, negative field existence test cases are invalid in their assumptions, so this patch reworks them into a single consolidated positive case that doesn't match any of the fields. Fixes: c7566a69695c ("selftests/bpf: Add field existence CO-RE relocs tests") Reported-by: Lorenz Bauer Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Lorenz Bauer Link: https://lore.kernel.org/bpf/20210426192949.416837-5-andrii@kernel.org Signed-off-by: Sasha Levin commit 4f11633d854949d14530df1590b4acb44f2efac9 Author: Andrii Nakryiko Date: Mon Apr 26 12:29:47 2021 -0700 selftests/bpf: Fix BPF_CORE_READ_BITFIELD() macro [ Upstream commit 0f20615d64ee2ad5e2a133a812382d0c4071589b ] Fix BPF_CORE_READ_BITFIELD() macro used for reading CO-RE-relocatable bitfields. Missing breaks in a switch caused 8-byte reads always. This can confuse libbpf because it does strict checks that memory load size corresponds to the original size of the field, which in this case quite often would be wrong. After fixing that, we run into another problem, which quite subtle, so worth documenting here. The issue is in Clang optimization and CO-RE relocation interactions. Without that asm volatile construct (also known as barrier_var()), Clang will re-order BYTE_OFFSET and BYTE_SIZE relocations and will apply BYTE_OFFSET 4 times for each switch case arm. This will result in the same error from libbpf about mismatch of memory load size and original field size. I.e., if we were reading u32, we'd still have *(u8 *), *(u16 *), *(u32 *), and *(u64 *) memory loads, three of which will fail. Using barrier_var() forces Clang to apply BYTE_OFFSET relocation first (and once) to calculate p, after which value of p is used without relocation in each of switch case arms, doing appropiately-sized memory load. Here's the list of relevant relocations and pieces of generated BPF code before and after this patch for test_core_reloc_bitfields_direct selftests. BEFORE ===== #45: core_reloc: insn #160 --> [5] + 0:5: byte_sz --> struct core_reloc_bitfields.u32 #46: core_reloc: insn #167 --> [5] + 0:5: byte_off --> struct core_reloc_bitfields.u32 #47: core_reloc: insn #174 --> [5] + 0:5: byte_off --> struct core_reloc_bitfields.u32 #48: core_reloc: insn #178 --> [5] + 0:5: byte_off --> struct core_reloc_bitfields.u32 #49: core_reloc: insn #182 --> [5] + 0:5: byte_off --> struct core_reloc_bitfields.u32 157: 18 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r2 = 0 ll 159: 7b 12 20 01 00 00 00 00 *(u64 *)(r2 + 288) = r1 160: b7 02 00 00 04 00 00 00 r2 = 4 ; BYTE_SIZE relocation here ^^^ 161: 66 02 07 00 03 00 00 00 if w2 s> 3 goto +7 162: 16 02 0d 00 01 00 00 00 if w2 == 1 goto +13 163: 16 02 01 00 02 00 00 00 if w2 == 2 goto +1 164: 05 00 12 00 00 00 00 00 goto +18 0000000000000528 : 165: 18 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r1 = 0 ll 167: 69 11 08 00 00 00 00 00 r1 = *(u16 *)(r1 + 8) ; BYTE_OFFSET relo here w/ WRONG size ^^^^^^^^^^^^^^^^ 168: 05 00 0e 00 00 00 00 00 goto +14 0000000000000548 : 169: 16 02 0a 00 04 00 00 00 if w2 == 4 goto +10 170: 16 02 01 00 08 00 00 00 if w2 == 8 goto +1 171: 05 00 0b 00 00 00 00 00 goto +11 0000000000000560 : 172: 18 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r1 = 0 ll 174: 79 11 08 00 00 00 00 00 r1 = *(u64 *)(r1 + 8) ; BYTE_OFFSET relo here w/ WRONG size ^^^^^^^^^^^^^^^^ 175: 05 00 07 00 00 00 00 00 goto +7 0000000000000580 : 176: 18 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r1 = 0 ll 178: 71 11 08 00 00 00 00 00 r1 = *(u8 *)(r1 + 8) ; BYTE_OFFSET relo here w/ WRONG size ^^^^^^^^^^^^^^^^ 179: 05 00 03 00 00 00 00 00 goto +3 00000000000005a0 : 180: 18 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r1 = 0 ll 182: 61 11 08 00 00 00 00 00 r1 = *(u32 *)(r1 + 8) ; BYTE_OFFSET relo here w/ RIGHT size ^^^^^^^^^^^^^^^^ 00000000000005b8 : 183: 67 01 00 00 20 00 00 00 r1 <<= 32 184: b7 02 00 00 00 00 00 00 r2 = 0 185: 16 02 02 00 00 00 00 00 if w2 == 0 goto +2 186: c7 01 00 00 20 00 00 00 r1 s>>= 32 187: 05 00 01 00 00 00 00 00 goto +1 00000000000005e0 : 188: 77 01 00 00 20 00 00 00 r1 >>= 32 AFTER ===== #30: core_reloc: insn #132 --> [5] + 0:5: byte_off --> struct core_reloc_bitfields.u32 #31: core_reloc: insn #134 --> [5] + 0:5: byte_sz --> struct core_reloc_bitfields.u32 129: 18 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r2 = 0 ll 131: 7b 12 20 01 00 00 00 00 *(u64 *)(r2 + 288) = r1 132: b7 01 00 00 08 00 00 00 r1 = 8 ; BYTE_OFFSET relo here ^^^ ; no size check for non-memory dereferencing instructions 133: 0f 12 00 00 00 00 00 00 r2 += r1 134: b7 03 00 00 04 00 00 00 r3 = 4 ; BYTE_SIZE relocation here ^^^ 135: 66 03 05 00 03 00 00 00 if w3 s> 3 goto +5 136: 16 03 09 00 01 00 00 00 if w3 == 1 goto +9 137: 16 03 01 00 02 00 00 00 if w3 == 2 goto +1 138: 05 00 0a 00 00 00 00 00 goto +10 0000000000000458 : 139: 69 21 00 00 00 00 00 00 r1 = *(u16 *)(r2 + 0) ; NO CO-RE relocation here ^^^^^^^^^^^^^^^^ 140: 05 00 08 00 00 00 00 00 goto +8 0000000000000468 : 141: 16 03 06 00 04 00 00 00 if w3 == 4 goto +6 142: 16 03 01 00 08 00 00 00 if w3 == 8 goto +1 143: 05 00 05 00 00 00 00 00 goto +5 0000000000000480 : 144: 79 21 00 00 00 00 00 00 r1 = *(u64 *)(r2 + 0) ; NO CO-RE relocation here ^^^^^^^^^^^^^^^^ 145: 05 00 03 00 00 00 00 00 goto +3 0000000000000490 : 146: 71 21 00 00 00 00 00 00 r1 = *(u8 *)(r2 + 0) ; NO CO-RE relocation here ^^^^^^^^^^^^^^^^ 147: 05 00 01 00 00 00 00 00 goto +1 00000000000004a0 : 148: 61 21 00 00 00 00 00 00 r1 = *(u32 *)(r2 + 0) ; NO CO-RE relocation here ^^^^^^^^^^^^^^^^ 00000000000004a8 : 149: 67 01 00 00 20 00 00 00 r1 <<= 32 150: b7 02 00 00 00 00 00 00 r2 = 0 151: 16 02 02 00 00 00 00 00 if w2 == 0 goto +2 152: c7 01 00 00 20 00 00 00 r1 s>>= 32 153: 05 00 01 00 00 00 00 00 goto +1 00000000000004d0 : 154: 77 01 00 00 20 00 00 00 r1 >>= 323 Fixes: ee26dade0e3b ("libbpf: Add support for relocatable bitfields") Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Lorenz Bauer Link: https://lore.kernel.org/bpf/20210426192949.416837-4-andrii@kernel.org Signed-off-by: Sasha Levin commit e407495ba6788a67d1bd41714158c079e340879b Author: Lv Yunlong Date: Mon Apr 26 09:06:25 2021 -0700 net:emac/emac-mac: Fix a use after free in emac_mac_tx_buf_send [ Upstream commit 6d72e7c767acbbdd44ebc7d89c6690b405b32b57 ] In emac_mac_tx_buf_send, it calls emac_tx_fill_tpd(..,skb,..). If some error happens in emac_tx_fill_tpd(), the skb will be freed via dev_kfree_skb(skb) in error branch of emac_tx_fill_tpd(). But the freed skb is still used via skb->len by netdev_sent_queue(,skb->len). As i observed that emac_tx_fill_tpd() haven't modified the value of skb->len, thus my patch assigns skb->len to 'len' before the possible free and use 'len' instead of skb->len later. Fixes: b9b17debc69d2 ("net: emac: emac gigabit ethernet controller driver") Signed-off-by: Lv Yunlong Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 0648941f4c8bbf8b4b6c0b270889ae7aa769b921 Author: Davide Caratti Date: Mon Apr 26 17:45:51 2021 +0200 net/sched: act_ct: fix wild memory access when clearing fragments [ Upstream commit f77bd544a6bbe69aa50d9ed09f13494cf36ff806 ] while testing re-assembly/re-fragmentation using act_ct, it's possible to observe a crash like the following one: KASAN: maybe wild-memory-access in range [0x0001000000000448-0x000100000000044f] CPU: 50 PID: 0 Comm: swapper/50 Tainted: G S 5.12.0-rc7+ #424 Hardware name: Dell Inc. PowerEdge R730/072T6D, BIOS 2.4.3 01/17/2017 RIP: 0010:inet_frag_rbtree_purge+0x50/0xc0 Code: 00 fc ff df 48 89 c3 31 ed 48 89 df e8 a9 7a 38 ff 4c 89 fe 48 89 df 49 89 c6 e8 5b 3a 38 ff 48 8d 7b 40 48 89 f8 48 c1 e8 03 <42> 80 3c 20 00 75 59 48 8d bb d0 00 00 00 4c 8b 6b 40 48 89 f8 48 RSP: 0018:ffff888c31449db8 EFLAGS: 00010203 RAX: 0000200000000089 RBX: 000100000000040e RCX: ffffffff989eb960 RDX: 0000000000000140 RSI: ffffffff97cfb977 RDI: 000100000000044e RBP: 0000000000000900 R08: 0000000000000000 R09: ffffed1186289350 R10: 0000000000000003 R11: ffffed1186289350 R12: dffffc0000000000 R13: 000100000000040e R14: 0000000000000000 R15: ffff888155e02160 FS: 0000000000000000(0000) GS:ffff888c31440000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005600cb70a5b8 CR3: 0000000a2c014005 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: inet_frag_destroy+0xa9/0x150 call_timer_fn+0x2d/0x180 run_timer_softirq+0x4fe/0xe70 __do_softirq+0x197/0x5a0 irq_exit_rcu+0x1de/0x200 sysvec_apic_timer_interrupt+0x6b/0x80 when act_ct temporarily stores an IP fragment, restoring the skb qdisc cb results in putting random data in FRAG_CB(), and this causes those "wild" memory accesses later, when the rbtree is purged. Never overwrite the skb cb in case tcf_ct_handle_fragments() returns -EINPROGRESS. Fixes: ae372cb1750f ("net/sched: act_ct: fix restore the qdisc_skb_cb after defrag") Fixes: 7baf2429a1a9 ("net/sched: cls_flower add CT_FLAGS_INVALID flag support") Reported-by: Shuang Li Signed-off-by: Davide Caratti Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 0d76da03a8a1a9af18d77b54afed6cf0a8169975 Author: Sean Christopherson Date: Wed Apr 21 19:11:13 2021 -0700 KVM: SVM: Disable SEV/SEV-ES if NPT is disabled [ Upstream commit fa13680f5668cff05302a2f4753c49334a83a064 ] Disable SEV and SEV-ES if NPT is disabled. While the APM doesn't clearly state that NPT is mandatory, it's alluded to by: The guest page tables, managed by the guest, may mark data memory pages as either private or shared, thus allowing selected pages to be shared outside the guest. And practically speaking, shadow paging can't work since KVM can't read the guest's page tables. Fixes: e9df09428996 ("KVM: SVM: Add sev module_param") Cc: Brijesh Singh Signed-off-by: Sean Christopherson Message-Id: <20210422021125.3417167-4-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 7399abdad9d334052a497b7062dfff6fbf03dc03 Author: Sean Christopherson Date: Wed Apr 21 19:11:12 2021 -0700 KVM: SVM: Free sev_asid_bitmap during init if SEV setup fails [ Upstream commit f31b88b35f90f6b7ae4abc1015494a285f459221 ] Free sev_asid_bitmap if the reclaim bitmap allocation fails, othwerise KVM will unnecessarily keep the bitmap when SEV is not fully enabled. Freeing the page is also necessary to avoid introducing a bug when a future patch eliminates svm_sev_enabled() in favor of using the global 'sev' flag directly. While sev_hardware_enabled() checks max_sev_asid, which is true even if KVM setup fails, 'sev' will be true if and only if KVM setup fully succeeds. Fixes: 33af3a7ef9e6 ("KVM: SVM: Reduce WBINVD/DF_FLUSH invocations") Cc: Tom Lendacky Signed-off-by: Sean Christopherson Message-Id: <20210422021125.3417167-3-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit b74a478a66eae230c1110628a4b9840f8b3b5aa8 Author: Sean Christopherson Date: Wed Apr 21 19:11:11 2021 -0700 KVM: SVM: Zero out the VMCB array used to track SEV ASID association [ Upstream commit 3b1902b87bf11f1c6a84368470dc13da6f3da3bd ] Zero out the array of VMCB pointers so that pre_sev_run() won't see garbage when querying the array to detect when an SEV ASID is being associated with a new VMCB. In practice, reading random values is all but guaranteed to be benign as a false negative (which is extremely unlikely on its own) can only happen on CPU0 on the first VMRUN and would only cause KVM to skip the ASID flush. For anything bad to happen, a previous instance of KVM would have to exit without flushing the ASID, _and_ KVM would have to not flush the ASID at any time while building the new SEV guest. Cc: Borislav Petkov Reviewed-by: Tom Lendacky Reviewed-by: Brijesh Singh Fixes: 70cd94e60c73 ("KVM: SVM: VMRUN should use associated ASID when SEV is enabled") Signed-off-by: Sean Christopherson Message-Id: <20210422021125.3417167-2-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 3461924cde0035016d332c4fc4ddb15cb7812023 Author: Sean Christopherson Date: Wed Apr 21 19:38:31 2021 -0700 KVM: VMX: Intercept FS/GS_BASE MSR accesses for 32-bit KVM [ Upstream commit dbdd096a5a74b94f6b786a47baef2085859b0dce ] Disable pass-through of the FS and GS base MSRs for 32-bit KVM. Intel's SDM unequivocally states that the MSRs exist if and only if the CPU supports x86-64. FS_BASE and GS_BASE are mostly a non-issue; a clever guest could opportunistically use the MSRs without issue. KERNEL_GS_BASE is a bigger problem, as a clever guest would subtly be broken if it were migrated, as KVM disallows software access to the MSRs, and unlike the direct variants, KERNEL_GS_BASE needs to be explicitly migrated as it's not captured in the VMCS. Fixes: 25c5f225beda ("KVM: VMX: Enable MSR Bitmap feature") Signed-off-by: Sean Christopherson Message-Id: <20210422023831.3473491-1-seanjc@google.com> [*NOT* for stable kernels. - Paolo] Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 3fbc5bc651d688fbea2a59cdc91520a2f5334d0a Author: Michael Chan Date: Fri Apr 23 18:13:19 2021 -0400 bnxt_en: Fix RX consumer index logic in the error path. [ Upstream commit bbd6f0a948139970f4a615dff189d9a503681a39 ] In bnxt_rx_pkt(), the RX buffers are expected to complete in order. If the RX consumer index indicates an out of order buffer completion, it means we are hitting a hardware bug and the driver will abort all remaining RX packets and reset the RX ring. The RX consumer index that we pass to bnxt_discard_rx() is not correct. We should be passing the current index (tmp_raw_cons) instead of the old index (raw_cons). This bug can cause us to be at the wrong index when trying to abort the next RX packet. It can crash like this: #0 [ffff9bbcdf5c39a8] machine_kexec at ffffffff9b05e007 #1 [ffff9bbcdf5c3a00] __crash_kexec at ffffffff9b111232 #2 [ffff9bbcdf5c3ad0] panic at ffffffff9b07d61e #3 [ffff9bbcdf5c3b50] oops_end at ffffffff9b030978 #4 [ffff9bbcdf5c3b78] no_context at ffffffff9b06aaf0 #5 [ffff9bbcdf5c3bd8] __bad_area_nosemaphore at ffffffff9b06ae2e #6 [ffff9bbcdf5c3c28] bad_area_nosemaphore at ffffffff9b06af24 #7 [ffff9bbcdf5c3c38] __do_page_fault at ffffffff9b06b67e #8 [ffff9bbcdf5c3cb0] do_page_fault at ffffffff9b06bb12 #9 [ffff9bbcdf5c3ce0] page_fault at ffffffff9bc015c5 [exception RIP: bnxt_rx_pkt+237] RIP: ffffffffc0259cdd RSP: ffff9bbcdf5c3d98 RFLAGS: 00010213 RAX: 000000005dd8097f RBX: ffff9ba4cb11b7e0 RCX: ffffa923cf6e9000 RDX: 0000000000000fff RSI: 0000000000000627 RDI: 0000000000001000 RBP: ffff9bbcdf5c3e60 R8: 0000000000420003 R9: 000000000000020d R10: ffffa923cf6ec138 R11: ffff9bbcdf5c3e83 R12: ffff9ba4d6f928c0 R13: ffff9ba4cac28080 R14: ffff9ba4cb11b7f0 R15: ffff9ba4d5a30000 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 Fixes: a1b0e4e684e9 ("bnxt_en: Improve RX consumer index validity check.") Reviewed-by: Pavan Chebbi Reviewed-by: Andy Gospodarek Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 0af76111c2a6326e4bb56f64a6e453c6ec6dd2da Author: Mat Martineau Date: Fri Apr 23 09:40:33 2021 -0700 mptcp: Retransmit DATA_FIN [ Upstream commit 6477dd39e62c3a67cfa368ddc127410b4ae424c6 ] With this change, the MPTCP-level retransmission timer is used to resend DATA_FIN. The retranmit timer is not stopped while waiting for a MPTCP-level ACK of DATA_FIN, and retransmitted DATA_FINs are sent on all subflows. The retry interval starts at TCP_RTO_MIN and then doubles on each attempt, up to TCP_RTO_MAX. Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/146 Fixes: 43b54c6ee382 ("mptcp: Use full MPTCP-level disconnect state machine") Acked-by: Paolo Abeni Signed-off-by: Mat Martineau Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit dc4b143319f872d10c6548f943a1ff57b0520304 Author: Danielle Ratson Date: Fri Apr 23 14:19:45 2021 +0200 selftests: mlxsw: Remove a redundant if statement in tc_flower_scale test [ Upstream commit 1f1c92139e36223b89d8140f2b72f75e79baf8bd ] Currently, the error return code of the failure condition is lost after using an if statement, so the test doesn't fail when it should. Remove the if statement that separates the condition and the error code check, so the test won't always pass. Fixes: abfce9e062021 ("selftests: mlxsw: Reduce running time using offload indication") Reported-by: Ido Schimmel Signed-off-by: Danielle Ratson Reviewed-by: Petr Machata Signed-off-by: Petr Machata Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 92aa8a27b47069c069ed7cc6373903d072b84462 Author: Danielle Ratson Date: Fri Apr 23 14:19:44 2021 +0200 selftests: mlxsw: Remove a redundant if statement in port_scale test [ Upstream commit b6fc2f212108b3676f54d00a2c38e3bc36753980 ] Currently, the error return code of the failure condition is lost after using an if statement, so the test doesn't fail when it should. Remove the if statement that separates the condition and the error code check, so the test won't always pass. Fixes: 5154b1b826d9b ("selftests: mlxsw: Add a scale test for physical ports") Reported-by: Ido Schimmel Signed-off-by: Danielle Ratson Reviewed-by: Petr Machata Signed-off-by: Petr Machata Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8334e4fbe50ab139399fec4902fbb00125b4763a Author: Petr Machata Date: Fri Apr 23 14:19:43 2021 +0200 selftests: net: mirror_gre_vlan_bridge_1q: Make an FDB entry static [ Upstream commit c8d0260cdd96fdccdef0509c4160e28a1012a5d7 ] The FDB roaming test installs a destination MAC address on the wrong interface of an FDB database and tests whether the mirroring fails, because packets are sent to the wrong port. The test by mistake installs the FDB entry as local. This worked previously, because drivers were notified of local FDB entries in the same way as of static entries. However that has been fixed in the commit 6ab4c3117aec ("net: bridge: don't notify switchdev for local FDB addresses"), and local entries are not notified anymore. As a result, the HW is not reconfigured for the FDB roam, and mirroring keeps working, failing the test. To fix the issue, mark the FDB entry as static. Fixes: 9c7c8a82442c ("selftests: forwarding: mirror_gre_vlan_bridge_1q: Add more tests") Signed-off-by: Petr Machata Reviewed-by: Ido Schimmel Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 21815f28af8081b258552c111774ff320cf38d38 Author: Phillip Potter Date: Fri Apr 23 00:49:45 2021 +0100 net: geneve: modify IP header check in geneve6_xmit_skb and geneve_xmit_skb [ Upstream commit d13f048dd40e8577260cd43faea8ec9b77520197 ] Modify the header size check in geneve6_xmit_skb and geneve_xmit_skb to use pskb_inet_may_pull rather than pskb_network_may_pull. This fixes two kernel selftest failures introduced by the commit introducing the checks: IPv4 over geneve6: PMTU exceptions IPv4 over geneve6: PMTU exceptions - nexthop objects It does this by correctly accounting for the fact that IPv4 packets may transit over geneve IPv6 tunnels (and vice versa), and still fixes the uninit-value bug fixed by the original commit. Reported-by: kernel test robot Fixes: 6628ddfec758 ("net: geneve: check skb is large enough for IPv4/IPv6 header") Suggested-by: Sabrina Dubroca Signed-off-by: Phillip Potter Acked-by: Sabrina Dubroca Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 485517a2beb2b41045ba3d73e885ea05fa533fdc Author: Kunihiko Hayashi Date: Fri Apr 23 02:31:49 2021 +0900 arm64: dts: uniphier: Change phy-mode to RGMII-ID to enable delay pins for RTL8211E [ Upstream commit dcabb06bf127b3e0d3fbc94a2b65dd56c2725851 ] UniPhier LD20 and PXs3 boards have RTL8211E ethernet phy, and the phy have the RX/TX delays of RGMII interface using pull-ups on the RXDLY and TXDLY pins. After the commit bbc4d71d6354 ("net: phy: realtek: fix rtl8211e rx/tx delay config"), the delays are working correctly, however, "rgmii" means no delay and the phy doesn't work. So need to set the phy-mode to "rgmii-id" to show that RX/TX delays are enabled. Fixes: c73730ee4c9a ("arm64: dts: uniphier: add AVE ethernet node") Signed-off-by: Kunihiko Hayashi Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9f794d2c67c70f392201dae83fbc44815b62f540 Author: Kunihiko Hayashi Date: Fri Apr 23 02:31:48 2021 +0900 ARM: dts: uniphier: Change phy-mode to RGMII-ID to enable delay pins for RTL8211E [ Upstream commit 9ba585cc5b56ea14a453ba6be9bdb984ed33471a ] UniPhier PXs2 boards have RTL8211E ethernet phy, and the phy have the RX/TX delays of RGMII interface using pull-ups on the RXDLY and TXDLY pins. After the commit bbc4d71d6354 ("net: phy: realtek: fix rtl8211e rx/tx delay config"), the delays are working correctly, however, "rgmii" means no delay and the phy doesn't work. So need to set the phy-mode to "rgmii-id" to show that RX/TX delays are enabled. Fixes: e3cc931921d2 ("ARM: dts: uniphier: add AVE ethernet node") Signed-off-by: Kunihiko Hayashi Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5878246cdf61e913e647004b198f8063054f0384 Author: Dan Carpenter Date: Thu Apr 22 12:10:28 2021 +0300 bnxt_en: fix ternary sign extension bug in bnxt_show_temp() [ Upstream commit 27537929f30d3136a71ef29db56127a33c92dad7 ] The problem is that bnxt_show_temp() returns long but "rc" is an int and "len" is a u32. With ternary operations the type promotion is quite tricky. The negative "rc" is first promoted to u32 and then to long so it ends up being a high positive value instead of a a negative as we intended. Fix this by removing the ternary. Fixes: d69753fa1ecb ("bnxt_en: return proper error codes in bnxt_show_temp") Signed-off-by: Dan Carpenter Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 69a6cf01a1f4dcaa1cb727523a0ffbba17e9e085 Author: Martin Willi Date: Mon Apr 19 16:15:59 2021 +0200 net, xdp: Update pkt_type if generic XDP changes unicast MAC [ Upstream commit 22b6034323fd736f260e00b9ea85c634abeb3446 ] If a generic XDP program changes the destination MAC address from/to multicast/broadcast, the skb->pkt_type is updated to properly handle the packet when passed up the stack. When changing the MAC from/to the NICs MAC, PACKET_HOST/OTHERHOST is not updated, though, making the behavior different from that of native XDP. Remember the PACKET_HOST/OTHERHOST state before calling the program in generic XDP, and update pkt_type accordingly if the destination MAC address has changed. As eth_type_trans() assumes a default pkt_type of PACKET_HOST, restore that before calling it. The use case for this is when a XDP program wants to push received packets up the stack by rewriting the MAC to the NICs MAC, for example by cluster nodes sharing MAC addresses. Fixes: 297249569932 ("net: fix generic XDP to handle if eth header was mangled") Signed-off-by: Martin Willi Signed-off-by: Daniel Borkmann Acked-by: Toke Høiland-Jørgensen Link: https://lore.kernel.org/bpf/20210419141559.8611-1-martin@strongswan.org Signed-off-by: Sasha Levin commit 9e4fd05376a373290b3d059a2784759324922bbd Author: Arnd Bergmann Date: Thu Apr 22 15:35:11 2021 +0200 net: enetc: fix link error again [ Upstream commit 74c97ea3b61e4ce149444f904ee8d4fc7073505b ] A link time bug that I had fixed before has come back now that another sub-module was added to the enetc driver: ERROR: modpost: "enetc_ierb_register_pf" [drivers/net/ethernet/freescale/enetc/fsl-enetc.ko] undefined! The problem is that the enetc Makefile is not actually used for the ierb module if that is the only built-in driver in there and everything else is a loadable module. Fix it by always entering the directory this time, regardless of which symbols are configured. This should reliably fix the problem and prevent it from coming back another time. Fixes: 112463ddbe82 ("net: dsa: felix: fix link error") Fixes: e7d48e5fbf30 ("net: enetc: add a mini driver for the Integrated Endpoint Register Block") Signed-off-by: Arnd Bergmann Acked-by: Vladimir Oltean Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit df9248ef56e654d9f421e3a05e8a77677df6d677 Author: Maxim Kochetkov Date: Thu Apr 22 13:46:44 2021 +0300 net: phy: marvell: fix m88e1111_set_downshift [ Upstream commit e7679c55a7249f1315256cfc672d53e84072e223 ] Changing downshift params without software reset has no effect, so call genphy_soft_reset() after change downshift params. As the datasheet says: Changes to these bits are disruptive to the normal operation therefore, any changes to these registers must be followed by software reset to take effect. Fixes: 5c6bc5199b5d ("net: phy: marvell: add downshift support for M88E1111") Signed-off-by: Maxim Kochetkov Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 99ce66766bde51331a9bb3a3034abda140ee693a Author: Maxim Kochetkov Date: Thu Apr 22 13:46:43 2021 +0300 net: phy: marvell: fix m88e1011_set_downshift [ Upstream commit 990875b299b8612aeb85cb2e2751796f1add65ff ] Changing downshift params without software reset has no effect, so call genphy_soft_reset() after change downshift params. As the datasheet says: Changes to these bits are disruptive to the normal operation therefore, any changes to these registers must be followed by software reset to take effect. Fixes: 911af5e149bb ("net: phy: marvell: fix downshift function naming") Signed-off-by: Maxim Kochetkov Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4305af7e959d33ea22b6439c5c4cb4a1dc2f6468 Author: Christophe Leroy Date: Wed Apr 21 17:24:03 2021 +0000 powerpc/52xx: Fix an invalid ASM expression ('addi' used instead of 'add') [ Upstream commit 8a87a507714386efc39c3ae6fa24d4f79846b522 ] AS arch/powerpc/platforms/52xx/lite5200_sleep.o arch/powerpc/platforms/52xx/lite5200_sleep.S: Assembler messages: arch/powerpc/platforms/52xx/lite5200_sleep.S:184: Warning: invalid register expression In the following code, 'addi' is wrong, has to be 'add' /* local udelay in sram is needed */ udelay: /* r11 - tb_ticks_per_usec, r12 - usecs, overwrites r13 */ mullw r12, r12, r11 mftb r13 /* start */ addi r12, r13, r12 /* end */ Fixes: ee983079ce04 ("[POWERPC] MPC5200 low power mode") Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/cb4cec9131c8577803367f1699209a7e104cec2a.1619025821.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin commit 5803e86e183749d929cb63bcbae39c9e1886ead8 Author: Athira Rajeev Date: Thu Mar 4 01:40:15 2021 -0500 powerpc/perf: Fix the threshold event selection for memory events in power10 [ Upstream commit 66d9b7492887d34c711bc05b36c22438acba51b4 ] Memory events (mem-loads and mem-stores) currently use the threshold event selection as issue to finish. Power10 supports issue to complete as part of thresholding which is more appropriate for mem-loads and mem-stores. Hence fix the event code for memory events to use issue to complete. Fixes: a64e697cef23 ("powerpc/perf: power10 Performance Monitoring support") Signed-off-by: Athira Rajeev Reviewed-by: Madhavan Srinivasan Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/1614840015-1535-1-git-send-email-atrajeev@linux.vnet.ibm.com Signed-off-by: Sasha Levin commit 7748383030f2dbffde9b4c24d0a899a7c0c621e8 Author: Colin Ian King Date: Mon Apr 19 15:14:05 2021 +0100 wlcore: Fix buffer overrun by snprintf due to incorrect buffer size [ Upstream commit a9a4c080deb33f44e08afe35f4ca4bb9ece89f4e ] The size of the buffer than can be written to is currently incorrect, it is always the size of the entire buffer even though the snprintf is writing as position pos into the buffer. Fix this by setting the buffer size to be the number of bytes left in the buffer, namely sizeof(buf) - pos. Addresses-Coverity: ("Out-of-bounds access") Fixes: 7b0e2c4f6be3 ("wlcore: fix overlapping snprintf arguments in debugfs") Signed-off-by: Colin Ian King Reviewed-by: Arnd Bergmann Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210419141405.180582-1-colin.king@canonical.com Signed-off-by: Sasha Levin commit 99a9906582c7bb38b4761beebaabd7e89ce5dc0d Author: Shuah Khan Date: Tue Apr 6 17:02:28 2021 -0600 ath10k: Fix ath10k_wmi_tlv_op_pull_peer_stats_info() unlock without lock [ Upstream commit eaaf52e4b866f265eb791897d622961293fd48c1 ] ath10k_wmi_tlv_op_pull_peer_stats_info() could try to unlock RCU lock winthout locking it first when peer reason doesn't match the valid cases for this function. Add a default case to return without unlocking. Fixes: 09078368d516 ("ath10k: hold RCU lock when calling ieee80211_find_sta_by_ifaddr()") Reported-by: Pavel Machek Signed-off-by: Shuah Khan Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210406230228.31301-1-skhan@linuxfoundation.org Signed-off-by: Sasha Levin commit 5e413c0831ff4700d1739db3fa3ae9f859744676 Author: Lv Yunlong Date: Mon Mar 29 05:01:54 2021 -0700 ath10k: Fix a use after free in ath10k_htc_send_bundle [ Upstream commit 8392df5d7e0b6a7d21440da1fc259f9938f4dec3 ] In ath10k_htc_send_bundle, the bundle_skb could be freed by dev_kfree_skb_any(bundle_skb). But the bundle_skb is used later by bundle_skb->len. As skb_len = bundle_skb->len, my patch replaces bundle_skb->len to skb_len after the bundle_skb was freed. Fixes: c8334512f3dd1 ("ath10k: add htt TX bundle for sdio") Signed-off-by: Lv Yunlong Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210329120154.8963-1-lyl2019@mail.ustc.edu.cn Signed-off-by: Sasha Levin commit 07eb006064c78f27bde79be8e057ff713bcee9cd Author: Toke Høiland-Jørgensen Date: Fri Mar 26 19:08:19 2021 +0100 ath9k: Fix error check in ath9k_hw_read_revisions() for PCI devices [ Upstream commit 7dd9a40fd6e0d0f1fd8e1931c007e080801dfdce ] When the error check in ath9k_hw_read_revisions() was added, it checked for -EIO which is what ath9k_regread() in the ath9k_htc driver uses. However, for plain ath9k, the register read function uses ioread32(), which just returns -1 on error. So if such a read fails, it still gets passed through and ends up as a weird mac revision in the log output. Fix this by changing ath9k_regread() to return -1 on error like ioread32() does, and fix the error check to look for that instead of -EIO. Fixes: 2f90c7e5d094 ("ath9k: Check for errors when reading SREV register") Signed-off-by: Toke Høiland-Jørgensen Reviewed-by: Lorenzo Bianconi Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210326180819.142480-1-toke@redhat.com Signed-off-by: Sasha Levin commit a84df7c80bdac598d6ac9268ae578da6928883e8 Author: Christophe Leroy Date: Tue Apr 20 13:32:48 2021 +0000 powerpc/64: Fix the definition of the fixmap area [ Upstream commit 9ccba66d4d2aff9a3909aa77d57ea8b7cc166f3c ] At the time being, the fixmap area is defined at the top of the address space or just below KASAN. This definition is not valid for PPC64. For PPC64, use the top of the I/O space. Because of circular dependencies, it is not possible to include asm/fixmap.h in asm/book3s/64/pgtable.h , so define a fixed size AREA at the top of the I/O space for fixmap and ensure during build that the size is big enough. Fixes: 265c3491c4bc ("powerpc: Add support for GENERIC_EARLY_IOREMAP") Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/0d51620eacf036d683d1a3c41328f69adb601dc0.1618925560.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin commit fa37a461bd6d9ee86e891ba3e4074a450e44c881 Author: Shay Drory Date: Sun Apr 18 16:55:54 2021 +0300 RDMA/core: Add CM to restrack after successful attachment to a device [ Upstream commit cb5cd0ea4eb3ce338a593a5331ddb4986ae20faa ] The device attach triggers addition of CM_ID to the restrack DB. However, when error occurs, we releasing this device, but defer CM_ID release. This causes to the situation where restrack sees CM_ID that is not valid anymore. As a solution, add the CM_ID to the resource tracking DB only after the attachment is finished. Found by syzcaller: infiniband syz0: added syz_tun rdma_rxe: ignoring netdev event = 10 for syz_tun infiniband syz0: set down infiniband syz0: ib_query_port failed (-19) restrack: ------------[ cut here ]------------ infiniband syz0: BUG: RESTRACK detected leak of resources restrack: User CM_ID object allocated by syz-executor716 is not freed restrack: ------------[ cut here ]------------ Fixes: b09c4d701220 ("RDMA/restrack: Improve readability in task name management") Link: https://lore.kernel.org/r/ab93e56ba831eac65c322b3256796fa1589ec0bb.1618753862.git.leonro@nvidia.com Signed-off-by: Shay Drory Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit b6ee57f610c6269298a6ead396d1bbfa8b76c58c Author: Bob Pearson Date: Tue Apr 20 22:59:53 2021 -0500 RDMA/rxe: Fix a bug in rxe_fill_ip_info() [ Upstream commit 45062f441590810772959d8e1f2b24ba57ce1bd9 ] Fix a bug in rxe_fill_ip_info() which was attempting to convert from RDMA_NETWORK_XXX to RXE_NETWORK_XXX. .._IPV6 should have mapped to .._IPV6 not .._IPV4. Fixes: edebc8407b88 ("RDMA/rxe: Fix small problem in network_type patch") Link: https://lore.kernel.org/r/20210421035952.4892-1-rpearson@hpe.com Suggested-by: Frank Zago Signed-off-by: Bob Pearson Acked-by: Zhu Yanjun Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit b13cbc536990ff609afa878b6211cd6f6265ba60 Author: Sean Wang Date: Mon Apr 19 23:58:05 2021 +0800 mt76: mt7921: fix possible invalid register access [ Upstream commit fe3fccde8870764ba3e60610774bd7bc9f8faeff ] Disable the interrupt and synchronze for the pending irq handlers to ensure the irq tasklet is not being scheduled after the suspend to avoid the possible invalid register access acts when the host pcie controller is suspended. [17932.910534] mt7921e 0000:01:00.0: pci_pm_suspend+0x0/0x22c returned 0 after 21375 usecs [17932.910590] pcieport 0000:00:00.0: calling pci_pm_suspend+0x0/0x22c @ 18565, parent: pci0000:00 [17932.910602] pcieport 0000:00:00.0: pci_pm_suspend+0x0/0x22c returned 0 after 8 usecs [17932.910671] mtk-pcie 11230000.pcie: calling platform_pm_suspend+0x0/0x60 @ 22783, parent: soc [17932.910674] mtk-pcie 11230000.pcie: platform_pm_suspend+0x0/0x60 returned 0 after 0 usecs ... 17933.615352] x1 : 00000000000d4200 x0 : ffffff8269ca2300 [17933.620666] Call trace: [17933.623127] mt76_mmio_rr+0x28/0xf0 [mt76] [17933.627234] mt7921_rr+0x38/0x44 [mt7921e] [17933.631339] mt7921_irq_tasklet+0x54/0x1d8 [mt7921e] [17933.636309] tasklet_action_common+0x12c/0x16c [17933.640754] tasklet_action+0x24/0x2c [17933.644418] __do_softirq+0x16c/0x344 [17933.648082] irq_exit+0xa8/0xac [17933.651224] scheduler_ipi+0xd4/0x148 [17933.654890] handle_IPI+0x164/0x2d4 [17933.658379] gic_handle_irq+0x140/0x178 [17933.662216] el1_irq+0xb8/0x180 [17933.665361] cpuidle_enter_state+0xf8/0x204 [17933.669544] cpuidle_enter+0x38/0x4c [17933.673122] do_idle+0x1a4/0x2a8 [17933.676352] cpu_startup_entry+0x24/0x28 [17933.680276] rest_init+0xd4/0xe0 [17933.683508] arch_call_rest_init+0x10/0x18 [17933.687606] start_kernel+0x340/0x3b4 [17933.691279] Code: aa0003f5 d503201f f953eaa8 8b344108 (b9400113) [17933.697373] ---[ end trace a24b8e26ffbda3c5 ]--- [17933.767846] Kernel panic - not syncing: Fatal exception in interrupt Fixes: ffa1bf97425b ("mt76: mt7921: introduce PM support") Signed-off-by: Sean Wang Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 28d7cb12d403f7f49e0914fd39b869ce5521f726 Author: Colin Ian King Date: Mon Apr 19 14:20:32 2021 +0100 mt76: mt7615: Fix a dereference of pointer sta before it is null checked [ Upstream commit 4a52d6abb193aea0f2923a2c917502bd2d718630 ] Currently the assignment of idx dereferences pointer sta before sta is null checked, leading to a potential null pointer dereference. Fix this by assigning idx when it is required after the null check on pointer sta. Addresses-Coverity: ("Dereference before null check") Fixes: a4a5a430b076 ("mt76: mt7615: fix TSF configuration") Signed-off-by: Colin Ian King Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit b2847bf30c4a9008630e7e741cca5677f68c4c21 Author: Martin Schiller Date: Wed Apr 21 07:50:47 2021 +0200 net: phy: intel-xway: enable integrated led functions [ Upstream commit 357a07c26697a770d39d28b6b111f978deb4017d ] The Intel xway phys offer the possibility to deactivate the integrated LED function and to control the LEDs manually. If this was set by the bootloader, it must be ensured that the integrated LED function is enabled for all LEDs when loading the driver. Before commit 6e2d85ec0559 ("net: phy: Stop with excessive soft reset") the LEDs were enabled by a soft-reset of the PHY (using genphy_soft_reset). Initialize the XWAY_MDIO_LED with it's default value (which is applied during a soft reset) instead of adding back the soft reset. This brings back the default LED configuration while still preventing an excessive amount of soft resets. Fixes: 6e2d85ec0559 ("net: phy: Stop with excessive soft reset") Signed-off-by: Martin Schiller Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7e62a88bf058eebb64acd96dc2561302b315bc15 Author: Yoshihiro Shimoda Date: Wed Apr 21 13:52:46 2021 +0900 net: renesas: ravb: Fix a stuck issue when a lot of frames are received [ Upstream commit 5718458b092bf6bf4482c5df32affba3c3259517 ] When a lot of frames were received in the short term, the driver caused a stuck of receiving until a new frame was received. For example, the following command from other device could cause this issue. $ sudo ping -f -l 1000 -c 1000 The previous code always cleared the interrupt flag of RX but checks the interrupt flags in ravb_poll(). So, ravb_poll() could not call ravb_rx() in the next time until a new RX frame was received if ravb_rx() returned true. To fix the issue, always calls ravb_rx() regardless the interrupt flags condition. Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper") Signed-off-by: Yoshihiro Shimoda Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b0b10216b579859cebaa172bd18a01abefe4bcd2 Author: Ong Boon Leong Date: Wed Apr 21 17:11:49 2021 +0800 net: stmmac: fix TSO and TBS feature enabling during driver open [ Upstream commit 5e6038b88a5718910dd74b949946d9d9cee9a041 ] TSO and TBS cannot co-exist and current implementation requires two fixes: 1) stmmac_open() does not need to call stmmac_enable_tbs() because the MAC is reset in stmmac_init_dma_engine() anyway. 2) Inside stmmac_hw_setup(), we should call stmmac_enable_tso() for TX Q that is _not_ configured for TBS. Fixes: 579a25a854d4 ("net: stmmac: Initial support for TBS") Signed-off-by: Ong Boon Leong Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a6ce99d59874f637316f71857145c13eb781d3fa Author: Yinjun Zhang Date: Wed Apr 21 11:24:15 2021 +0200 nfp: devlink: initialize the devlink port attribute "lanes" [ Upstream commit 90b669d65d99a3ee6965275269967cdee4da106e ] The number of lanes of devlink port should be correctly initialized when registering the port, so that the input check when running "devlink port split count " can pass. Fixes: a21cf0a8330b ("devlink: Add a new devlink port lanes attribute and pass to netlink") Signed-off-by: Yinjun Zhang Signed-off-by: Louis Peens Signed-off-by: Simon Horman Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 3d3cd0346916e0453582908cb306b2409628122c Author: Tobias Waldekranz Date: Wed Apr 21 14:04:53 2021 +0200 net: dsa: mv88e6xxx: Fix off-by-one in VTU devlink region size [ Upstream commit 281140a0a2ce4febf2c0ce5d29d0e7d961a826b1 ] In the unlikely event of the VTU being loaded to the brim with 4k entries, the last one was placed in the buffer, but the size reported to devlink was off-by-one. Make sure that the final entry is available to the caller. Fixes: ca4d632aef03 ("net: dsa: mv88e6xxx: Export VTU as devlink region") Signed-off-by: Tobias Waldekranz Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d161c03bd241ccddb67f2a749d1b15689e181ae2 Author: Sean Christopherson Date: Tue Apr 6 15:49:46 2021 -0700 crypto: ccp: Detect and reject "invalid" addresses destined for PSP [ Upstream commit 74c1f1366eb7714b8b211554f6c5cee315ff3fbc ] Explicitly reject using pointers that are not virt_to_phys() friendly as the source for SEV commands that are sent to the PSP. The PSP works with physical addresses, and __pa()/virt_to_phys() will not return the correct address in these cases, e.g. for a vmalloc'd pointer. At best, the bogus address will cause the command to fail, and at worst lead to system instability. While it's unlikely that callers will deliberately use a bad pointer for SEV buffers, a caller can easily use a vmalloc'd pointer unknowingly when running with CONFIG_VMAP_STACK=y as it's not obvious that putting the command buffers on the stack would be bad. The command buffers are relative small and easily fit on the stack, and the APIs to do not document that the incoming pointer must be a physically contiguous, __pa() friendly pointer. Cc: Brijesh Singh Cc: Borislav Petkov Cc: Tom Lendacky Cc: Christophe Leroy Fixes: 200664d5237f ("crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support") Signed-off-by: Sean Christopherson Message-Id: <20210406224952.4177376-3-seanjc@google.com> Reviewed-by: Brijesh Singh Acked-by: Tom Lendacky Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 8bef76325feb1ad3536e20cb4d72d120ad7cd519 Author: Leonardo Bras Date: Tue Apr 20 01:54:04 2021 -0300 powerpc/pseries/iommu: Fix window size for direct mapping with pmem [ Upstream commit a9d2f9bb225fd2a764aef57738ab6c7f38d782ae ] As of today, if the DDW is big enough to fit (1 << MAX_PHYSMEM_BITS) it's possible to use direct DMA mapping even with pmem region. But, if that happens, the window size (len) is set to (MAX_PHYSMEM_BITS - page_shift) instead of MAX_PHYSMEM_BITS, causing a pagesize times smaller DDW to be created, being insufficient for correct usage. Fix this so the correct window size is used in this case. Fixes: bf6e2d562bbc4 ("powerpc/dma: Fallback to dma_ops when persistent memory present") Signed-off-by: Leonardo Bras Reviewed-by: Alexey Kardashevskiy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210420045404.438735-1-leobras.c@gmail.com Signed-off-by: Sasha Levin commit e038f93363c309a542a648c8f17d644929db3393 Author: Lorenzo Bianconi Date: Fri Apr 16 00:21:54 2021 +0200 mt76: mt7921: run mt7921_mcu_fw_log_2_host holding mt76 mutex [ Upstream commit 987c8fb4de437344f19a23d074c06faf67520a11 ] Wake the chip before configuring the mcu log level Fixes: 1d8efc741df8 ("mt76: mt7921: introduce Runtime PM support") Signed-off-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit d754c80ae82a662e692a82faad71b8c218cb7f52 Author: Ryder Lee Date: Tue Apr 13 13:34:57 2021 +0800 mt76: mt7915: fix memleak when mt7915_unregister_device() [ Upstream commit e9d32af478cfc3744a45245c0b126738af4b3ac4 ] mt7915_tx_token_put() should get call before mt76_free_pending_txwi(). Fixes: f285dfb98562 ("mt76: mt7915: reset token when mac_reset happens") Signed-off-by: Ryder Lee Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 6c5b2b0c6e5a6ce2d8f9f85b8b72bfad60eaa506 Author: Ryder Lee Date: Tue Apr 13 13:34:56 2021 +0800 mt76: mt7615: fix memleak when mt7615_unregister_device() [ Upstream commit 8ab31da7b89f71c4c2defcca989fab7b42f87d71 ] mt7615_tx_token_put() should get call before mt76_free_pending_txwi(). Fixes: a6275e934605 ("mt76: mt7615: reset token when mac_reset happens") Signed-off-by: Ryder Lee Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit dd86a80bb97f920ec75e48a601376452048c10a9 Author: Po-Hao Huang Date: Thu Apr 15 16:47:03 2021 +0800 rtw88: refine napi deinit flow [ Upstream commit 7bd3760c71f7a18485d2c10ea0887e1d41519f4e ] We used to stop napi before disabling irqs. And it turns out to cause some problem when we try to stop device while interrupt arrives. To safely stop pci, we do three steps: 1. disable interrupt 2. synchronize_irq 3. stop_napi Since step 2 and 3 may not finish as expected when interrupt is enabled, use rtwpci->running to decide whether interrupt should be re-enabled at the time. Fixes: 9e2fd29864c5 ("rtw88: add napi support") Signed-off-by: Po-Hao Huang Signed-off-by: Ping-Ke Shih Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210415084703.27255-4-pkshih@realtek.com Signed-off-by: Sasha Levin commit 03b59d27a72b8f60fe04db565621aba9a92b9cdc Author: Colin Ian King Date: Tue Apr 20 18:16:14 2021 +0100 net: davinci_emac: Fix incorrect masking of tx and rx error channel [ Upstream commit d83b8aa5207d81f9f6daec9888390f079cc5db3f ] The bit-masks used for the TXERRCH and RXERRCH (tx and rx error channels) are incorrect and always lead to a zero result. The mask values are currently the incorrect post-right shifted values, fix this by setting them to the currect values. (I double checked these against the TMS320TCI6482 data sheet, section 5.30, page 127 to ensure I had the correct mask values for the TXERRCH and RXERRCH fields in the MACSTATUS register). Addresses-Coverity: ("Operands don't affect result") Fixes: a6286ee630f6 ("net: Add TI DaVinci EMAC driver") Signed-off-by: Colin Ian King Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9d1ba11fabdd8f25abb24272ef1621417981320b Author: Vadym Kochan Date: Tue Apr 20 16:31:51 2021 +0300 net: marvell: prestera: fix port event handling on init [ Upstream commit 333980481b99edb24ebd5d1a53af70a15d9146de ] For some reason there might be a crash during ports creation if port events are handling at the same time because fw may send initial port event with down state. The crash points to cancel_delayed_work() which is called when port went is down. Currently I did not find out the real cause of the issue, so fixed it by cancel port stats work only if previous port's state was up & runnig. The following is the crash which can be triggered: [ 28.311104] Unable to handle kernel paging request at virtual address 000071775f776600 [ 28.319097] Mem abort info: [ 28.321914] ESR = 0x96000004 [ 28.324996] EC = 0x25: DABT (current EL), IL = 32 bits [ 28.330350] SET = 0, FnV = 0 [ 28.333430] EA = 0, S1PTW = 0 [ 28.336597] Data abort info: [ 28.339499] ISV = 0, ISS = 0x00000004 [ 28.343362] CM = 0, WnR = 0 [ 28.346354] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000100bf7000 [ 28.352842] [000071775f776600] pgd=0000000000000000, p4d=0000000000000000 [ 28.359695] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 28.365310] Modules linked in: prestera_pci(+) prestera uio_pdrv_genirq [ 28.372005] CPU: 0 PID: 1291 Comm: kworker/0:1H Not tainted 5.11.0-rc4 #1 [ 28.378846] Hardware name: DNI AmazonGo1 A7040 board (DT) [ 28.384283] Workqueue: prestera_fw_wq prestera_fw_evt_work_fn [prestera_pci] [ 28.391413] pstate: 60000085 (nZCv daIf -PAN -UAO -TCO BTYPE=--) [ 28.397468] pc : get_work_pool+0x48/0x60 [ 28.401442] lr : try_to_grab_pending+0x6c/0x1b0 [ 28.406018] sp : ffff80001391bc60 [ 28.409358] x29: ffff80001391bc60 x28: 0000000000000000 [ 28.414725] x27: ffff000104fc8b40 x26: ffff80001127de88 [ 28.420089] x25: 0000000000000000 x24: ffff000106119760 [ 28.425452] x23: ffff00010775dd60 x22: ffff00010567e000 [ 28.430814] x21: 0000000000000000 x20: ffff80001391bcb0 [ 28.436175] x19: ffff00010775deb8 x18: 00000000000000c0 [ 28.441537] x17: 0000000000000000 x16: 000000008d9b0e88 [ 28.446898] x15: 0000000000000001 x14: 00000000000002ba [ 28.452261] x13: 80a3002c00000002 x12: 00000000000005f4 [ 28.457622] x11: 0000000000000030 x10: 000000000000000c [ 28.462985] x9 : 000000000000000c x8 : 0000000000000030 [ 28.468346] x7 : ffff800014400000 x6 : ffff000106119758 [ 28.473708] x5 : 0000000000000003 x4 : ffff00010775dc60 [ 28.479068] x3 : 0000000000000000 x2 : 0000000000000060 [ 28.484429] x1 : 000071775f776600 x0 : ffff00010775deb8 [ 28.489791] Call trace: [ 28.492259] get_work_pool+0x48/0x60 [ 28.495874] cancel_delayed_work+0x38/0xb0 [ 28.500011] prestera_port_handle_event+0x90/0xa0 [prestera] [ 28.505743] prestera_evt_recv+0x98/0xe0 [prestera] [ 28.510683] prestera_fw_evt_work_fn+0x180/0x228 [prestera_pci] [ 28.516660] process_one_work+0x1e8/0x360 [ 28.520710] worker_thread+0x44/0x480 [ 28.524412] kthread+0x154/0x160 [ 28.527670] ret_from_fork+0x10/0x38 [ 28.531290] Code: a8c17bfd d50323bf d65f03c0 9278dc21 (f9400020) [ 28.537429] ---[ end trace 5eced933df3a080b ]--- Fixes: 501ef3066c89 ("net: marvell: prestera: Add driver for Prestera family ASIC devices") Signed-off-by: Vadym Kochan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 37c38674ef2f8d7e8629e5d433c37d6c1273d16b Author: Stefano Garzarella Date: Tue Apr 20 13:07:27 2021 +0200 vsock/virtio: free queued packets when closing socket [ Upstream commit 8432b8114957235f42e070a16118a7f750de9d39 ] As reported by syzbot [1], there is a memory leak while closing the socket. We partially solved this issue with commit ac03046ece2b ("vsock/virtio: free packets during the socket release"), but we forgot to drain the RX queue when the socket is definitely closed by the scheduled work. To avoid future issues, let's use the new virtio_transport_remove_sock() to drain the RX queue before removing the socket from the af_vsock lists calling vsock_remove_sock(). [1] https://syzkaller.appspot.com/bug?extid=24452624fc4c571eedd9 Fixes: ac03046ece2b ("vsock/virtio: free packets during the socket release") Reported-and-tested-by: syzbot+24452624fc4c571eedd9@syzkaller.appspotmail.com Signed-off-by: Stefano Garzarella Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit fde3756222f9e46b6786ae56bcf768ddfed55315 Author: Edward Cree Date: Tue Apr 20 13:29:35 2021 +0100 sfc: ef10: fix TX queue lookup in TX event handling [ Upstream commit 172e269edfce34bac7c61c15551816bda4b0f140 ] We're starting from a TXQ label, not a TXQ type, so efx_channel_get_tx_queue() is inappropriate. This worked by chance, because labels and types currently match on EF10, but we shouldn't rely on that. Fixes: 12804793b17c ("sfc: decouple TXQ type from label") Signed-off-by: Edward Cree Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 6a8aaa46a6e407f129f5f72e6f29048f14f76ec4 Author: Colin Ian King Date: Tue Apr 20 14:47:19 2021 +0100 ALSA: usb: midi: don't return -ENOMEM when usb_urb_ep_type_check fails [ Upstream commit cfd577acb769301b19c31361d45ae1f145318b7a ] Currently when the call to usb_urb_ep_type_check fails (returning -EINVAL) the error return path returns -ENOMEM via the exit label "error". Other uses of the same error exit label set the err variable to -ENOMEM but this is not being used. I believe the original intent was for the error exit path to return the value in err rather than the hard coded -ENOMEM, so return this rather than the hard coded -ENOMEM. Addresses-Coverity: ("Unused value") Fixes: 738d9edcfd44 ("ALSA: usb-audio: Add sanity checks for invalid EPs") Signed-off-by: Colin Ian King Link: https://lore.kernel.org/r/20210420134719.381409-1-colin.king@canonical.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit a589a9122fce601951acb2e4427b7e13b45fbf70 Author: Sindhu Devale Date: Thu Apr 15 19:21:04 2021 -0500 RDMA/i40iw: Fix error unwinding when i40iw_hmc_sd_one fails [ Upstream commit 783a11bf2400e5d5c42a943c3083dc0330751842 ] When i40iw_hmc_sd_one fails, chunk is freed without the deletion of chunk entry in the PBLE info list. Fix it by adding the chunk entry to the PBLE info list only after successful addition of SD in i40iw_hmc_sd_one. This fixes a static checker warning reported here: https://lore.kernel.org/linux-rdma/YHV4CFXzqTm23AOZ@mwanda/ Fixes: 9715830157be ("i40iw: add pble resource files") Link: https://lore.kernel.org/r/20210416002104.323-1-shiraz.saleem@intel.com Reported-by: Dan Carpenter Signed-off-by: Sindhu Devale Signed-off-by: Shiraz Saleem Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 8b7b075f53a9d9c38ee084c425f25987b6e228f4 Author: Potnuri Bharat Teja Date: Thu Apr 15 20:44:22 2021 +0530 RDMA/cxgb4: add missing qpid increment [ Upstream commit 3a6684385928d00b29acac7658a5ae1f2a44494c ] missing qpid increment leads to skipping few qpids while allocating QP. This eventually leads to adapter running out of qpids after establishing fewer connections than it actually supports. Current patch increments the qpid correctly. Fixes: cfdda9d76436 ("RDMA/cxgb4: Add driver for Chelsio T4 RNIC") Link: https://lore.kernel.org/r/20210415151422.9139-1-bharat@chelsio.com Signed-off-by: Potnuri Bharat Teja Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 673de75d1e446c511d47f6f7ba13d051d938c75c Author: Alexander Lobakin Date: Mon Apr 19 12:53:06 2021 +0000 gro: fix napi_gro_frags() Fast GRO breakage due to IP alignment check [ Upstream commit 7ad18ff6449cbd6beb26b53128ddf56d2685aa93 ] Commit 38ec4944b593 ("gro: ensure frag0 meets IP header alignment") did the right thing, but missed the fact that napi_gro_frags() logics calls for skb_gro_reset_offset() *before* pulling Ethernet header to the skb linear space. That said, the introduced check for frag0 address being aligned to 4 always fails for it as Ethernet header is obviously 14 bytes long, and in case with NET_IP_ALIGN its start is not aligned to 4. Fix this by adding @nhoff argument to skb_gro_reset_offset() which tells if an IP header is placed right at the start of frag0 or not. This restores Fast GRO for napi_gro_frags() that became very slow after the mentioned commit, and preserves the introduced check to avoid silent unaligned accesses. From v1 [0]: - inline tiny skb_gro_reset_offset() to let the code be optimized more efficively (esp. for the !NET_IP_ALIGN case) (Eric); - pull in Reviewed-by from Eric. [0] https://lore.kernel.org/netdev/20210418114200.5839-1-alobakin@pm.me Fixes: 38ec4944b593 ("gro: ensure frag0 meets IP header alignment") Reviewed-by: Eric Dumazet Signed-off-by: Alexander Lobakin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 53a032f047693cd0316f68cbdfcfda0501b9051a Author: Linus Walleij Date: Sun Apr 18 20:28:53 2021 +0200 net: ethernet: ixp4xx: Set the DMA masks explicitly [ Upstream commit 8d892d60941b00c86d2029c8a99db24ab4979673 ] The former fix only papered over the actual problem: the ethernet core expects the netdev .dev member to have the proper DMA masks set, or there will be BUG_ON() triggered in kernel/dma/mapping.c. Fix this by simply copying dma_mask and dma_mask_coherent from the parent device. Fixes: e45d0fad4a5f ("net: ethernet: ixp4xx: Use parent dev for DMA pool") Signed-off-by: Linus Walleij Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 1b57024de437dfbadd8087ea151833f0c1855144 Author: Florent Revest Date: Mon Apr 19 17:52:41 2021 +0200 libbpf: Initialize the bpf_seq_printf parameters array field by field [ Upstream commit 83cd92b46484aa8f64cdc0bff8ac6940d1f78519 ] When initializing the __param array with a one liner, if all args are const, the initial array value will be placed in the rodata section but because libbpf does not support relocation in the rodata section, any pointer in this array will stay NULL. Fixes: c09add2fbc5a ("tools/libbpf: Add bpf_iter support") Signed-off-by: Florent Revest Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20210419155243.1632274-5-revest@chromium.org Signed-off-by: Sasha Levin commit d234618d2ec6067ad3e4a54a6968e9de28ae5522 Author: Stefano Garzarella Date: Fri Apr 16 12:44:16 2021 +0200 vsock/vmci: log once the failed queue pair allocation [ Upstream commit e16edc99d658cd41c60a44cc14d170697aa3271f ] VMCI feature is not supported in conjunction with the vSphere Fault Tolerance (FT) feature. VMware Tools can repeatedly try to create a vsock connection. If FT is enabled the kernel logs is flooded with the following messages: qp_alloc_hypercall result = -20 Could not attach to queue pair with -20 "qp_alloc_hypercall result = -20" was hidden by commit e8266c4c3307 ("VMCI: Stop log spew when qp allocation isn't possible"), but "Could not attach to queue pair with -20" is still there flooding the log. Since the error message can be useful in some cases, print it only once. Fixes: d021c344051a ("VSOCK: Introduce VM Sockets") Signed-off-by: Stefano Garzarella Reviewed-by: Jorgen Hansen Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d0287ef91ea579c41a01bd9ecced9cdbb23ebfb6 Author: Pablo Neira Ayuso Date: Mon Apr 12 14:20:55 2021 +0200 netfilter: nftables_offload: special ethertype handling for VLAN [ Upstream commit 783003f3bb8a565326e89d18bbd948ad8ffc816a ] The nftables offload parser sets FLOW_DISSECTOR_KEY_BASIC .n_proto to the ethertype field in the ethertype frame. However: - FLOW_DISSECTOR_KEY_BASIC .n_proto field always stores either IPv4 or IPv6 ethertypes. - FLOW_DISSECTOR_KEY_VLAN .vlan_tpid stores either the 802.1q and 802.1ad ethertypes. Same as for FLOW_DISSECTOR_KEY_CVLAN. This function adjusts the flow dissector to handle two scenarios: 1) FLOW_DISSECTOR_KEY_VLAN .vlan_tpid is set to 802.1q or 802.1ad. Then, transfer: - the .n_proto field to FLOW_DISSECTOR_KEY_VLAN .tpid. - the original FLOW_DISSECTOR_KEY_VLAN .tpid to the FLOW_DISSECTOR_KEY_CVLAN .tpid - the original FLOW_DISSECTOR_KEY_CVLAN .tpid to the .n_proto field. 2) .n_proto is set to 802.1q or 802.1ad. Then, transfer: - the .n_proto field to FLOW_DISSECTOR_KEY_VLAN .tpid. - the original FLOW_DISSECTOR_KEY_VLAN .tpid to the .n_proto field. Fixes: a82055af5959 ("netfilter: nft_payload: add VLAN offload support") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit b988433b1b3422d07f06b04759f28342c14ca494 Author: Pablo Neira Ayuso Date: Mon Apr 12 14:20:15 2021 +0200 netfilter: nftables_offload: VLAN id needs host byteorder in flow dissector [ Upstream commit ff4d90a89d3d4d9814e0a2696509a7d495be4163 ] The flow dissector representation expects the VLAN id in host byteorder. Add the NFT_OFFLOAD_F_NETWORK2HOST flag to swap the bytes from nft_cmp. Fixes: a82055af5959 ("netfilter: nft_payload: add VLAN offload support") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit d78fa64c87fa00c317f8809452bc69120147edba Author: Pablo Neira Ayuso Date: Mon Apr 12 14:11:39 2021 +0200 netfilter: nft_payload: fix C-VLAN offload support [ Upstream commit 14c20643ef9457679cc6934d77adc24296505214 ] - add another struct flow_dissector_key_vlan for C-VLAN - update layer 3 dependency to allow to match on IPv4/IPv6 Fixes: 89d8fd44abfb ("netfilter: nft_payload: add C-VLAN offload support") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit a8d66b4c8903c8ce04f0d541da62e0d6b275d04f Author: Lv Yunlong Date: Fri Apr 2 11:26:27 2021 -0700 mwl8k: Fix a double Free in mwl8k_probe_hw [ Upstream commit a8e083ee8e2a6c94c29733835adae8bf5b832748 ] In mwl8k_probe_hw, hw->priv->txq is freed at the first time by dma_free_coherent() in the call chain: if(!priv->ap_fw)->mwl8k_init_txqs(hw)->mwl8k_txq_init(hw, i). Then in err_free_queues of mwl8k_probe_hw, hw->priv->txq is freed at the second time by mwl8k_txq_deinit(hw, i)->dma_free_coherent(). My patch set txq->txd to NULL after the first free to avoid the double free. Fixes: a66098daacee2 ("mwl8k: Marvell TOPDOG wireless driver") Signed-off-by: Lv Yunlong Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210402182627.4256-1-lyl2019@mail.ustc.edu.cn Signed-off-by: Sasha Levin commit 7503993cea78acabb705fe45a02f52dc74a02d78 Author: Qii Wang Date: Sat Apr 17 14:46:51 2021 +0800 i2c: mediatek: Fix wrong dma sync flag [ Upstream commit 3186b880447ad3cc9b6487fa626a71d64b831524 ] The right flag is apdma_sync when apdma remove hand-shake signel. Fixes: 05f6f7271a38 ("i2c: mediatek: Fix apdma and i2c hand-shake timeout") Signed-off-by: Qii Wang Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 6d78450bbe69b694c4a791a7fb9e93cba0015bba Author: Sergey Shtylyov Date: Sat Apr 17 22:05:05 2021 +0300 i2c: sh7760: fix IRQ error path [ Upstream commit 92dfb27240fea2776f61c5422472cb6defca7767 ] While adding the invalid IRQ check after calling platform_get_irq(), I managed to overlook that the driver has a complex error path in its probe() method, thus a simple *return* couldn't be used. Use a proper *goto* instead! Fixes: e5b2e3e74201 ("i2c: sh7760: add IRQ check") Signed-off-by: Sergey Shtylyov Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit f5f2fd30be85a5dd71856e09db9623385e61590f Author: Arnd Bergmann Date: Tue Mar 23 13:57:14 2021 +0100 wlcore: fix overlapping snprintf arguments in debugfs [ Upstream commit 7b0e2c4f6be3ec68bf807c84e985e81c21404cd1 ] gcc complains about undefined behavior in calling snprintf() with the same buffer as input and output: drivers/net/wireless/ti/wl18xx/debugfs.c: In function 'diversity_num_of_packets_per_ant_read': drivers/net/wireless/ti/wl18xx/../wlcore/debugfs.h:86:3: error: 'snprintf' argument 4 overlaps destination object 'buf' [-Werror=restrict] 86 | snprintf(buf, sizeof(buf), "%s[%d] = %d\n", \ | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 87 | buf, i, stats->sub.name[i]); \ | ~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/net/wireless/ti/wl18xx/debugfs.c:24:2: note: in expansion of macro 'DEBUGFS_FWSTATS_FILE_ARRAY' 24 | DEBUGFS_FWSTATS_FILE_ARRAY(a, b, c, wl18xx_acx_statistics) | ^~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/net/wireless/ti/wl18xx/debugfs.c:159:1: note: in expansion of macro 'WL18XX_DEBUGFS_FWSTATS_FILE_ARRAY' 159 | WL18XX_DEBUGFS_FWSTATS_FILE_ARRAY(diversity, num_of_packets_per_ant, There are probably other ways of handling the debugfs file, without using on-stack buffers, but a simple workaround here is to remember the current position in the buffer and just keep printing in there. Fixes: bcca1bbdd412 ("wlcore: add debugfs macro to help print fw statistics arrays") Signed-off-by: Arnd Bergmann Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210323125723.1961432-1-arnd@kernel.org Signed-off-by: Sasha Levin commit a32b50a26745c4569d4d510045ac3a6f052fe2c3 Author: Ping-Ke Shih Date: Fri Feb 19 13:26:07 2021 +0800 rtlwifi: 8821ae: upgrade PHY and RF parameters [ Upstream commit 18fb0bedb5fc2fddc057dbe48b7360a6ffda34b3 ] The signal strength of 5G is quite low, so user can't connect to an AP far away. New parameters with new format and its parser are updated by the commit 84d26fda52e2 ("rtlwifi: Update 8821ae new phy parameters and its parser."), but some parameters are missing. Use this commit to update to the novel parameters that use new format. Fixes: 84d26fda52e2 ("rtlwifi: Update 8821ae new phy parameters and its parser") Signed-off-by: Ping-Ke Shih Tested-by: Kai-Heng Feng Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210219052607.7323-1-pkshih@realtek.com Signed-off-by: Sasha Levin commit 07f85449d230eea7a3e6763ac3fb2949bb6e2e4c Author: David Edmondson Date: Thu Mar 18 12:08:37 2021 +0000 KVM: x86: dump_vmcs should not assume GUEST_IA32_EFER is valid [ Upstream commit d9e46d344e62a0d56fd86a8289db5bed8a57c92e ] If the VM entry/exit controls for loading/saving MSR_EFER are either not available (an older processor or explicitly disabled) or not used (host and guest values are the same), reading GUEST_IA32_EFER from the VMCS returns an inaccurate value. Because of this, in dump_vmcs() don't use GUEST_IA32_EFER to decide whether to print the PDPTRs - always do so if the fields exist. Fixes: 4eb64dce8d0a ("KVM: x86: dump VMCS on invalid entry") Signed-off-by: David Edmondson Message-Id: <20210318120841.133123-2-david.edmondson@oracle.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 6c9607314b37d10a7bc8e4a05076277b5490ad1b Author: Srikar Dronamraju Date: Thu Apr 15 17:39:32 2021 +0530 powerpc/smp: Reintroduce cpu_core_mask [ Upstream commit c47f892d7aa62765bf0689073f75990b4517a4cf ] Daniel reported that with Commit 4ca234a9cbd7 ("powerpc/smp: Stop updating cpu_core_mask") QEMU was unable to set single NUMA node SMP topologies such as: -smp 8,maxcpus=8,cores=2,threads=2,sockets=2 i.e he expected 2 sockets in one NUMA node. The above commit helped to reduce boot time on Large Systems for example 4096 vCPU single socket QEMU instance. PAPR is silent on having more than one socket within a NUMA node. cpu_core_mask and cpu_cpu_mask for any CPU would be same unless the number of sockets is different from the number of NUMA nodes. One option is to reintroduce cpu_core_mask but use a slightly different method to arrive at the cpu_core_mask. Previously each CPU's chip-id would be compared with all other CPU's chip-id to verify if both the CPUs were related at the chip level. Now if a CPU 'A' is found related / (unrelated) to another CPU 'B', all the thread siblings of 'A' and thread siblings of 'B' are automatically marked as related / (unrelated). Also if a platform doesn't support ibm,chip-id property, i.e its cpu_to_chip_id returns -1, cpu_core_map holds a copy of cpu_cpu_mask(). Fixes: 4ca234a9cbd7 ("powerpc/smp: Stop updating cpu_core_mask") Reported-by: Daniel Henrique Barboza Signed-off-by: Srikar Dronamraju Tested-by: Daniel Henrique Barboza Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210415120934.232271-2-srikar@linux.vnet.ibm.com Signed-off-by: Sasha Levin commit f32116261e8e8694615edf3bdb8db9ee876dfe67 Author: Geliang Tang Date: Fri Apr 16 15:38:02 2021 -0700 mptcp: fix format specifiers for unsigned int [ Upstream commit e4b6135134a75f530bd634ea7c168efaf0f9dff3 ] Some of the sequence numbers are printed as the negative ones in the debug log: [ 46.250932] MPTCP: DSS [ 46.250940] MPTCP: data_fin=0 dsn64=0 use_map=0 ack64=1 use_ack=1 [ 46.250948] MPTCP: data_ack=2344892449471675613 [ 46.251012] MPTCP: msk=000000006e157e3f status=10 [ 46.251023] MPTCP: msk=000000006e157e3f snd_data_fin_enable=0 pending=0 snd_nxt=2344892449471700189 write_seq=2344892449471700189 [ 46.251343] MPTCP: msk=00000000ec44a129 ssk=00000000f7abd481 sending dfrag at seq=-1658937016627538668 len=100 already sent=0 [ 46.251360] MPTCP: data_seq=16787807057082012948 subflow_seq=1 data_len=100 dsn64=1 This patch used the format specifier %u instead of %d for the unsigned int values to fix it. Fixes: d9ca1de8c0cd ("mptcp: move page frag allocation in mptcp_sendmsg()") Reviewed-by: Matthieu Baerts Signed-off-by: Geliang Tang Signed-off-by: Mat Martineau Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5cad9e2caa9613fdcd246bd4ebf0ffbec1cba2ca Author: Dafna Hirschfeld Date: Fri Apr 16 12:54:49 2021 +0200 iommu/mediatek: Always enable the clk on resume [ Upstream commit b34ea31fe013569d42b7e8681ef3f717f77c5b72 ] In mtk_iommu_runtime_resume always enable the clk, even if m4u_dom is null. Otherwise the 'suspend' cb might disable the clk which is already disabled causing the warning: [ 1.586104] infra_m4u already disabled [ 1.586133] WARNING: CPU: 0 PID: 121 at drivers/clk/clk.c:952 clk_core_disable+0xb0/0xb8 [ 1.594391] mtk-iommu 10205000.iommu: bound 18001000.larb (ops mtk_smi_larb_component_ops) [ 1.598108] Modules linked in: [ 1.598114] CPU: 0 PID: 121 Comm: kworker/0:2 Not tainted 5.12.0-rc5 #69 [ 1.609246] mtk-iommu 10205000.iommu: bound 14027000.larb (ops mtk_smi_larb_component_ops) [ 1.617487] Hardware name: Google Elm (DT) [ 1.617491] Workqueue: pm pm_runtime_work [ 1.620545] mtk-iommu 10205000.iommu: bound 19001000.larb (ops mtk_smi_larb_component_ops) [ 1.627229] pstate: 60000085 (nZCv daIf -PAN -UAO -TCO BTYPE=--) [ 1.659297] pc : clk_core_disable+0xb0/0xb8 [ 1.663475] lr : clk_core_disable+0xb0/0xb8 [ 1.667652] sp : ffff800011b9bbe0 [ 1.670959] x29: ffff800011b9bbe0 x28: 0000000000000000 [ 1.676267] x27: ffff800011448000 x26: ffff8000100cfd98 [ 1.681574] x25: ffff800011b9bd48 x24: 0000000000000000 [ 1.686882] x23: 0000000000000000 x22: ffff8000106fad90 [ 1.692189] x21: 000000000000000a x20: ffff0000c0048500 [ 1.697496] x19: ffff0000c0048500 x18: ffffffffffffffff [ 1.702804] x17: 0000000000000000 x16: 0000000000000000 [ 1.708112] x15: ffff800011460300 x14: fffffffffffe0000 [ 1.713420] x13: ffff8000114602d8 x12: 0720072007200720 [ 1.718727] x11: 0720072007200720 x10: 0720072007200720 [ 1.724035] x9 : ffff800011b9bbe0 x8 : ffff800011b9bbe0 [ 1.729342] x7 : 0000000000000009 x6 : ffff8000114b8328 [ 1.734649] x5 : 0000000000000000 x4 : 0000000000000000 [ 1.739956] x3 : 00000000ffffffff x2 : ffff800011460298 [ 1.745263] x1 : 1af1d7de276f4500 x0 : 0000000000000000 [ 1.750572] Call trace: [ 1.753010] clk_core_disable+0xb0/0xb8 [ 1.756840] clk_core_disable_lock+0x24/0x40 [ 1.761105] clk_disable+0x20/0x30 [ 1.764501] mtk_iommu_runtime_suspend+0x88/0xa8 [ 1.769114] pm_generic_runtime_suspend+0x2c/0x48 [ 1.773815] __rpm_callback+0xe0/0x178 [ 1.777559] rpm_callback+0x24/0x88 [ 1.781041] rpm_suspend+0xdc/0x470 [ 1.784523] rpm_idle+0x12c/0x170 [ 1.787831] pm_runtime_work+0xa8/0xc0 [ 1.791573] process_one_work+0x1e8/0x360 [ 1.795580] worker_thread+0x44/0x478 [ 1.799237] kthread+0x150/0x158 [ 1.802460] ret_from_fork+0x10/0x30 [ 1.806034] ---[ end trace 82402920ef64573b ]--- [ 1.810728] ------------[ cut here ]------------ In addition, we now don't need to enable the clock from the function mtk_iommu_hw_init since it is already enabled by the resume. Fixes: c0b57581b73b ("iommu/mediatek: Add power-domain operation") Signed-off-by: Dafna Hirschfeld Reviewed-by: Yong Wu Link: https://lore.kernel.org/r/20210416105449.4744-1-dafna.hirschfeld@collabora.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit cf6fcf26f60daf8da250511ea80493460b00fe11 Author: Tyrel Datwyler Date: Thu Feb 11 12:24:35 2021 -0600 powerpc/pseries: extract host bridge from pci_bus prior to bus removal [ Upstream commit 38d0b1c9cec71e6d0f3bddef0bbce41d05a3e796 ] The pci_bus->bridge reference may no longer be valid after pci_bus_remove() resulting in passing a bad value to device_unregister() for the associated bridge device. Store the host_bridge reference in a separate variable prior to pci_bus_remove(). Fixes: 7340056567e3 ("powerpc/pci: Reorder pci bus/bridge unregistration during PHB removal") Signed-off-by: Tyrel Datwyler Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210211182435.47968-1-tyreld@linux.ibm.com Signed-off-by: Sasha Levin commit 1de6095db28fd5dca5e9568e1bd77796234ad88d Author: Ilya Lipnitskiy Date: Tue Apr 13 20:12:37 2021 -0700 MIPS: pci-legacy: stop using of_pci_range_to_resource [ Upstream commit 3ecb9dc1581eebecaee56decac70e35365260866 ] Mirror commit aeba3731b150 ("powerpc/pci: Fix IO space breakage after of_pci_range_to_resource() change"). Most MIPS platforms do not define PCI_IOBASE, nor implement pci_address_to_pio(). Moreover, IO_SPACE_LIMIT is 0xffff for most MIPS platforms. of_pci_range_to_resource passes the _start address_ of the IO range into pci_address_to_pio, which then checks it against IO_SPACE_LIMIT and fails, because for MIPS platforms that use pci-legacy (pci-lantiq, pci-rt3883, pci-mt7620), IO ranges start much higher than 0xffff. In fact, pci-mt7621 in staging already works around this problem, see commit 09dd629eeabb ("staging: mt7621-pci: fix io space and properly set resource limits") So just stop using of_pci_range_to_resource, which does not work for MIPS. Fixes PCI errors like: pci_bus 0000:00: root bus resource [io 0xffffffff] Fixes: 0b0b0893d49b ("of/pci: Fix the conversion of IO ranges into IO resources") Signed-off-by: Ilya Lipnitskiy Cc: Liviu Dudau Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit e44ec34641f7af667525e550aa0cb8f3bc635f23 Author: Dan Carpenter Date: Wed Apr 14 08:59:22 2021 +0300 drm/amd/pm: fix error code in smu_set_power_limit() [ Upstream commit bbdfe5aaef3c1d5c5e62fa235ef13f064e4c1c17 ] We should return -EINVAL instead of success if the "limit" is too high. Fixes: e098bc9612c2 ("drm/amd/pm: optimize the power related source code layout") Signed-off-by: Dan Carpenter Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 04ee044a877e14cfd7bdd9d1f4342983aed28978 Author: Dan Carpenter Date: Wed Apr 14 08:58:55 2021 +0300 drm/amdgpu: fix an error code in init_pmu_entry_by_type_and_add() [ Upstream commit 90cb3d8aca1baea9471d28f28d5de1528dd5e424 ] If the kmemdup() fails then this should return a negative error code but it currently returns success Fixes: b4a7db71ea06 ("drm/amdgpu: add per device user friendly xgmi events for vega20") Signed-off-by: Dan Carpenter Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 5f54b9be4ce507598ed3f2285010f2f9e74b5ea2 Author: Vitaly Chikunov Date: Wed Apr 14 21:27:23 2021 +0300 perf beauty: Fix fsconfig generator [ Upstream commit 2e1daee14e67fbf9b27280b974e2c680a22cabea ] After gnulib update sed stopped matching `[[:space:]]*+' as before, causing the following compilation error: In file included from builtin-trace.c:719: trace/beauty/generated/fsconfig_arrays.c:2:3: error: expected expression before ']' token 2 | [] = "", | ^ trace/beauty/generated/fsconfig_arrays.c:2:3: error: array index in initializer not of integer type trace/beauty/generated/fsconfig_arrays.c:2:3: note: (near initialization for 'fsconfig_cmds') Fix this by correcting the regular expression used in the generator. Also, clean up the script by removing redundant egrep, xargs, and printf invocations. Committer testing: Continues to work: $ cat tools/perf/trace/beauty/fsconfig.sh #!/bin/sh # SPDX-License-Identifier: LGPL-2.1 if [ $# -ne 1 ] ; then linux_header_dir=tools/include/uapi/linux else linux_header_dir=$1 fi linux_mount=${linux_header_dir}/mount.h printf "static const char *fsconfig_cmds[] = {\n" ms='[[:space:]]*' sed -nr "s/^${ms}FSCONFIG_([[:alnum:]_]+)${ms}=${ms}([[:digit:]]+)${ms},.*/\t[\2] = \"\1\",/p" \ ${linux_mount} printf "};\n" $ tools/perf/trace/beauty/fsconfig.sh static const char *fsconfig_cmds[] = { [0] = "SET_FLAG", [1] = "SET_STRING", [2] = "SET_BINARY", [3] = "SET_PATH", [4] = "SET_PATH_EMPTY", [5] = "SET_FD", [6] = "CMD_CREATE", [7] = "CMD_RECONFIGURE", }; $ Fixes: d35293004a5e4 ("perf beauty: Add generator for fsconfig's 'cmd' arg values") Signed-off-by: Vitaly Chikunov Co-authored-by: Dmitry V. Levin Tested-by: Arnaldo Carvalho de Melo Link: http://lore.kernel.org/lkml/20210414182723.1670663-1-vt@altlinux.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 969d259ed6708d28058c140dcf93e69411a18951 Author: Paul Menzel Date: Mon Apr 12 20:01:41 2021 +0200 iommu/amd: Put newline after closing bracket in warning [ Upstream commit 304c73ba69459d4c18c2a4b843be6f5777b4b85c ] Currently, on the Dell OptiPlex 5055 the EFR mismatch warning looks like below. [ 1.479774] smpboot: CPU0: AMD Ryzen 5 PRO 1500 Quad-Core Processor (family: 0x17, model: 0x1, stepping: 0x1) […] [ 2.507370] AMD-Vi: [Firmware Warn]: EFR mismatch. Use IVHD EFR (0xf77ef22294ada : 0x400f77ef22294ada ). Add the newline after the `).`, so it’s on one line. Fixes: a44092e326d4 ("iommu/amd: Use IVHD EFR for early initialization of IOMMU features") Cc: iommu@lists.linux-foundation.org Cc: Suravee Suthikulpanit Cc: Brijesh Singh Cc: Robert Richter Signed-off-by: Paul Menzel Link: https://lore.kernel.org/r/20210412180141.29605-1-pmenzel@molgen.mpg.de Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 6532647bf264e4f12b6e5af81f040f72ce6f7921 Author: Christophe JAILLET Date: Sun Apr 11 09:08:17 2021 +0200 iommu/vt-d: Fix an error handling path in 'intel_prepare_irq_remapping()' [ Upstream commit 745610c4a3e3baaebf6d1f8cd5b4d82892432520 ] If 'intel_cap_audit()' fails, we should return directly, as already done in the surrounding error handling path. Fixes: ad3d19029979 ("iommu/vt-d: Audit IOMMU Capabilities and add helper functions") Signed-off-by: Christophe JAILLET Acked-by: Lu Baolu Link: https://lore.kernel.org/r/98d531caabe66012b4fffc7813fd4b9470afd517.1618124777.git.christophe.jaillet@wanadoo.fr Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 038bf959af53693309c5d3c2e8db8604dd513dc0 Author: Dan Carpenter Date: Wed Apr 14 09:01:38 2021 +0300 drm/i915/gvt: Fix error code in intel_gvt_init_device() [ Upstream commit 329328ec6a87f2c1275f50d979d55513de458409 ] The intel_gvt_init_vgpu_type_groups() function is only called from intel_gvt_init_device(). If it fails then the intel_gvt_init_device() prints the error code and propagates it back again. That's a bug because false is zero/success. The fix is to modify it to return zero or negative error codes and make everything consistent. Fixes: c5d71cb31723 ("drm/i915/gvt: Move vGPU type related code into gvt file") Signed-off-by: Dan Carpenter Signed-off-by: Zhenyu Wang Link: http://patchwork.freedesktop.org/patch/msgid/YHaFQtk/DIVYK1u5@mwanda Reviewed-by: Zhenyu Wang Signed-off-by: Sasha Levin commit 4fd6cb342547045e9dfa64467da0cea5f523dd1e Author: Eric Dumazet Date: Wed Apr 14 12:36:44 2021 -0700 net/packet: remove data races in fanout operations [ Upstream commit 94f633ea8ade8418634d152ad0931133338226f6 ] af_packet fanout uses RCU rules to ensure f->arr elements are not dismantled before RCU grace period. However, it lacks rcu accessors to make sure KCSAN and other tools wont detect data races. Stupid compilers could also play games. Fixes: dc99f600698d ("packet: Add fanout support.") Signed-off-by: Eric Dumazet Reported-by: "Gong, Sishuai" Cc: Willem de Bruijn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 841bbc0da84179657c8138ca81c64a28ec22ba92 Author: Colin Ian King Date: Tue Apr 6 17:53:46 2021 +0100 net/mlx5: Fix bit-wise and with zero [ Upstream commit 82c3ba31c370b6001cbf90689e98da1fb6f26aef ] The bit-wise and of the action field with MLX5_ACCEL_ESP_ACTION_DECRYPT is incorrect as MLX5_ACCEL_ESP_ACTION_DECRYPT is zero and not intended to be a bit-flag. Fix this by using the == operator as was originally intended. Addresses-Coverity: ("Logically dead code") Fixes: 7dfee4b1d79e ("net/mlx5: IPsec, Refactor SA handle creation and destruction") Signed-off-by: Colin Ian King Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 2d63c969c4360422c089629130b6d7a3c6044332 Author: Shengjiu Wang Date: Wed Apr 14 14:33:43 2021 +0800 ASoC: ak5558: correct reset polarity [ Upstream commit 0b93bbc977af55fd10687f2c96c807cba95cb927 ] Reset (aka power off) happens when the reset gpio is made active. The reset gpio is GPIO_ACTIVE_LOW Fixes: 920884777480 ("ASoC: ak5558: Add support for AK5558 ADC driver") Signed-off-by: Shengjiu Wang Link: https://lore.kernel.org/r/1618382024-31725-1-git-send-email-shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 403ec295830501e0e0c20de3de313641bd691f49 Author: Nicholas Piggin Date: Tue Mar 16 20:41:55 2021 +1000 powerpc/syscall: switch user_exit_irqoff and trace_hardirqs_off order [ Upstream commit 5a5a893c4ad897b8a36f846602895515b7407a71 ] user_exit_irqoff() -> __context_tracking_exit -> vtime_user_exit warns in __seqprop_assert due to lockdep thinking preemption is enabled because trace_hardirqs_off() has not yet been called. Switch the order of these two calls, which matches their ordering in interrupt_enter_prepare. Fixes: 5f0b6ac3905f ("powerpc/64/syscall: Reconcile interrupts") Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210316104206.407354-2-npiggin@gmail.com Signed-off-by: Sasha Levin commit 3b35c9e484cbddab54d89e5eeea391011ac866dd Author: Cédric Le Goater Date: Wed Mar 31 16:45:12 2021 +0200 powerpc/xive: Fix xmon command "dxi" [ Upstream commit 33e4bc5946432a4ac173fd08e8e30a13ab94d06d ] When under xmon, the "dxi" command dumps the state of the XIVE interrupts. If an interrupt number is specified, only the state of the associated XIVE interrupt is dumped. This form of the command lacks an irq_data parameter which is nevertheless used by xmon_xive_get_irq_config(), leading to an xmon crash. Fix that by doing a lookup in the system IRQ mapping to query the IRQ descriptor data. Invalid interrupt numbers, or not belonging to the XIVE IRQ domain, OPAL event interrupt number for instance, should be caught by the previous query done at the firmware level. Fixes: 97ef27507793 ("powerpc/xive: Fix xmon support on the PowerNV platform") Reported-by: kernel test robot Reported-by: Dan Carpenter Signed-off-by: Cédric Le Goater Tested-by: Greg Kurz Reviewed-by: Greg Kurz Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210331144514.892250-8-clg@kaod.org Signed-off-by: Sasha Levin commit d7de92e4355ed4a34a93b6dccf641226b44aede5 Author: Cédric Le Goater Date: Wed Mar 31 16:45:10 2021 +0200 powerpc/xive: Drop check on irq_data in xive_core_debug_show() [ Upstream commit a74ce5926b20cd0e6d624a9b2527073a96dfed7f ] When looping on IRQ descriptor, irq_data is always valid. Fixes: 930914b7d528 ("powerpc/xive: Add a debugfs file to dump internal XIVE state") Reported-by: kernel test robot Reported-by: Dan Carpenter Signed-off-by: Cédric Le Goater Reviewed-by: Greg Kurz Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210331144514.892250-6-clg@kaod.org Signed-off-by: Sasha Levin commit a5436462939ae8445f56b1400638db201f513688 Author: Mukesh Sisodiya Date: Sun Apr 11 13:25:44 2021 +0300 iwlwifi: dbg: disable ini debug in 9000 family and below [ Upstream commit 7c81a025054cd0aeeeaf17aba2e9757f0a6a38a1 ] Yoyo based debug is not applicable to old devices. As init debug is enabled by default in the driver, it needs to be disabled to work the old debug mechanism in old devices. Signed-off-by: Mukesh Sisodiya Fixes: b0d8d2c27007 ("iwlwifi: yoyo: enable yoyo by default") Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20210411132130.805401a1b8ec.I30db38184a418cfc1c5ca1a305cc14a52501d415@changeid Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin commit fc23413efc1d592b5220a2db58c863985e306a0b Author: Mordechay Goodstein Date: Sun Apr 11 12:46:30 2021 +0300 iwlwifi: rs-fw: don't support stbc for HE 160 [ Upstream commit a9174578262b86f15cb1882f35e53b1fae0649fd ] Our HE doesn't support it so never set HE 160 stbc Fixes: 3e467b8e4cf4 ("iwlwifi: rs-fw: enable STBC in he correctly") Signed-off-by: Mordechay Goodstein Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20210411124418.550fd1903eb7.I8ddbc2f87044a5ef78d916c9c59be797811a1b7f@changeid Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin commit 4d267335c51a8bdc5b47bf4be333fc0455c4a953 Author: Alessio Balsini Date: Fri Mar 19 15:05:14 2021 +0000 fuse: fix matching of FUSE_DEV_IOC_CLONE command [ Upstream commit 6076f5f341e612152879bfda99f0b76c1953bf0b ] With commit f8425c939663 ("fuse: 32-bit user space ioctl compat for fuse device") the matching constraints for the FUSE_DEV_IOC_CLONE ioctl command are relaxed, limited to the testing of command type and number. As Arnd noticed, this is wrong as it wouldn't ensure the correctness of the data size or direction for the received FUSE device ioctl. Fix by bringing back the comparison of the ioctl received by the FUSE device to the originally generated FUSE_DEV_IOC_CLONE. Fixes: f8425c939663 ("fuse: 32-bit user space ioctl compat for fuse device") Reported-by: Arnd Bergmann Signed-off-by: Alessio Balsini Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit e6f5e2039d99268976a61f6415cb958436637a70 Author: Sergey Shtylyov Date: Sat Apr 10 23:25:10 2021 +0300 i2c: sh7760: add IRQ check [ Upstream commit e5b2e3e742015dd2aa6bc7bcef2cb59b2de1221c ] The driver neglects to check the result of platform_get_irq()'s call and blithely passes the negative error codes to devm_request_irq() (which takes *unsigned* IRQ #), causing it to fail with -EINVAL, overriding an original error code. Stop calling devm_request_irq() with invalid IRQ #s. Fixes: a26c20b1fa6d ("i2c: Renesas SH7760 I2C master driver") Signed-off-by: Sergey Shtylyov Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit adabb74795708bf52d8a751a697f668006e15905 Author: Sergey Shtylyov Date: Sat Apr 10 23:23:33 2021 +0300 i2c: rcar: add IRQ check [ Upstream commit 147178cf03a6dcb337e703d4dacd008683022a58 ] The driver neglects to check the result of platform_get_irq()'s call and blithely passes the negative error codes to devm_request_irq() (which takes *unsigned* IRQ #), causing it to fail with -EINVAL, overriding an original error code. Stop calling devm_request_irq() with the invalid IRQ #s. Fixes: 6ccbe607132b ("i2c: add Renesas R-Car I2C driver") Signed-off-by: Sergey Shtylyov Reviewed-by: Geert Uytterhoeven Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 2dada8877293d25c7f1c38b0727e64b9ba55d113 Author: Sergey Shtylyov Date: Sat Apr 10 23:20:49 2021 +0300 i2c: mlxbf: add IRQ check [ Upstream commit 0d3bf53e897dce943b98d975bbde77156af6cd81 ] The driver neglects to check the result of platform_get_irq()'s call and blithely passes the negative error codes to devm_request_irq() (which takes *unsigned* IRQ #), causing it to fail with -EINVAL, overriding an original error code. Stop calling devm_request_irq() with invalid IRQ #s. Fixes: b5b5b32081cd ("i2c: mlxbf: I2C SMBus driver for Mellanox BlueField SoC") Signed-off-by: Sergey Shtylyov Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 60c6bc467bcadb5432de3cff858b81b4f7eef2f5 Author: Sergey Shtylyov Date: Sat Apr 10 23:18:31 2021 +0300 i2c: jz4780: add IRQ check [ Upstream commit c5e5f7a8d931fb4beba245bdbc94734175fda9de ] The driver neglects to check the result of platform_get_irq()'s call and blithely passes the negative error codes to devm_request_irq() (which takes *unsigned* IRQ #), causing it to fail with -EINVAL, overriding an original error code. Stop calling devm_request_irq() with invalid IRQ #s. Fixes: ba92222ed63a ("i2c: jz4780: Add i2c bus controller driver for Ingenic JZ4780") Signed-off-by: Sergey Shtylyov Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit ee714ab6e4899b050f933a4abcf302a22d90d3b3 Author: Sergey Shtylyov Date: Sat Apr 10 23:16:41 2021 +0300 i2c: emev2: add IRQ check [ Upstream commit bb6129c32867baa7988f7fd2066cf18ed662d240 ] The driver neglects to check the result of platform_get_irq()'s call and blithely passes the negative error codes to devm_request_irq() (which takes *unsigned* IRQ #), causing it to fail with -EINVAL, overriding an original error code. Stop calling devm_request_irq() with invalid IRQ #s. Fixes: 5faf6e1f58b4 ("i2c: emev2: add driver") Signed-off-by: Sergey Shtylyov Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit cbf441180bf1bbe0ee6390cb372b4fedeeacf483 Author: Sergey Shtylyov Date: Sat Apr 10 23:14:35 2021 +0300 i2c: cadence: add IRQ check [ Upstream commit 5581c2c5d02bc63a0edb53e061c8e97cd490646e ] The driver neglects to check the result of platform_get_irq()'s call and blithely passes the negative error codes to devm_request_irq() (which takes *unsigned* IRQ #), causing it to fail with -EINVAL, overriding an original error code. Stop calling devm_request_irq() with invalid IRQ #s. Fixes: df8eb5691c48 ("i2c: Add driver for Cadence I2C controller") Signed-off-by: Sergey Shtylyov Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit a42ac16e6573f19c78f556ea292f5b534fcc4514 Author: Qinglang Miao Date: Tue Dec 1 17:31:46 2020 +0800 i2c: xiic: fix reference leak when pm_runtime_get_sync fails [ Upstream commit a85c5c7a3aa8041777ff691400b4046e56149fd3 ] The PM reference count is not expected to be incremented on return in xiic_xfer and xiic_i2c_remove. However, pm_runtime_get_sync will increment the PM reference count even failed. Forgetting to putting operation will result in a reference leak here. Replace it with pm_runtime_resume_and_get to keep usage counter balanced. Fixes: 10b17004a74c ("i2c: xiic: Fix the clocking across bind unbind") Reported-by: Hulk Robot Signed-off-by: Qinglang Miao Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit c7ea772c9fcf711ed566814b92eecaffc0e2bfd0 Author: Qinglang Miao Date: Tue Dec 1 17:31:45 2020 +0800 i2c: stm32f7: fix reference leak when pm_runtime_get_sync fails [ Upstream commit 2c662660ce2bd3b09dae21a9a9ac9395e1e6c00b ] The PM reference count is not expected to be incremented on return in these stm32f7_i2c_xx serious functions. However, pm_runtime_get_sync will increment the PM reference count even failed. Forgetting to putting operation will result in a reference leak here. Replace it with pm_runtime_resume_and_get to keep usage counter balanced. Fixes: ea6dd25deeb5 ("i2c: stm32f7: add PM_SLEEP suspend/resume support") Reported-by: Hulk Robot Signed-off-by: Qinglang Miao Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit d3406ab52097328a3bc4cbe124bfd8f6d51fb86f Author: Qinglang Miao Date: Tue Dec 1 17:31:44 2020 +0800 i2c: sprd: fix reference leak when pm_runtime_get_sync fails [ Upstream commit 3a4f326463117cee3adcb72999ca34a9aaafda93 ] The PM reference count is not expected to be incremented on return in sprd_i2c_master_xfer() and sprd_i2c_remove(). However, pm_runtime_get_sync will increment the PM reference count even failed. Forgetting to putting operation will result in a reference leak here. Replace it with pm_runtime_resume_and_get to keep usage counter balanced. Fixes: 8b9ec0719834 ("i2c: Add Spreadtrum I2C controller driver") Reported-by: Hulk Robot Signed-off-by: Qinglang Miao Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit d6fdc153091dc29edf84393f2ce9a7c2aa1a3090 Author: Qinglang Miao Date: Tue Dec 1 17:31:43 2020 +0800 i2c: omap: fix reference leak when pm_runtime_get_sync fails [ Upstream commit 780f629741257ed6c54bd3eb53b57f648eabf200 ] The PM reference count is not expected to be incremented on return in omap_i2c_probe() and omap_i2c_remove(). However, pm_runtime_get_sync will increment the PM reference count even failed. Forgetting to putting operation will result in a reference leak here. I Replace it with pm_runtime_resume_and_get to keep usage counter balanced. What's more, error path 'err_free_mem' seems not like a proper name any more. So I change the name to err_disable_pm and move pm_runtime_disable below, for pm_runtime of 'pdev->dev' should be disabled when pm_runtime_resume_and_get fails. Fixes: 3b0fb97c8dc4 ("I2C: OMAP: Handle error check for pm runtime") Reported-by: Hulk Robot Signed-off-by: Qinglang Miao Reviewed-by: Grygorii Strashko Reviewed-by: Vignesh Raghavendra Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit ff406f6cd09c273337ab4854292e4aca48f8affd Author: Qinglang Miao Date: Tue Dec 1 17:31:41 2020 +0800 i2c: imx: fix reference leak when pm_runtime_get_sync fails [ Upstream commit 47ff617217ca6a13194fcb35c6c3a0c57c080693 ] In i2c_imx_xfer() and i2c_imx_remove(), the pm reference count is not expected to be incremented on return. However, pm_runtime_get_sync will increment pm reference count even failed. Forgetting to putting operation will result in a reference leak here. Replace it with pm_runtime_resume_and_get to keep usage counter balanced. Fixes: 3a5ee18d2a32 ("i2c: imx: implement master_xfer_atomic callback") Reported-by: Hulk Robot Signed-off-by: Qinglang Miao Reviewed-by: Oleksij Rempel Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit b100650d80cd2292f6c152f5f2943b5944b3e8ce Author: Qinglang Miao Date: Tue Dec 1 17:31:40 2020 +0800 i2c: imx-lpi2c: fix reference leak when pm_runtime_get_sync fails [ Upstream commit 278e5bbdb9a94fa063c0f9bcde2479d0b8042462 ] The PM reference count is not expected to be incremented on return in lpi2c_imx_master_enable. However, pm_runtime_get_sync will increment the PM reference count even failed. Forgetting to putting operation will result in a reference leak here. Replace it with pm_runtime_resume_and_get to keep usage counter balanced. Fixes: 13d6eb20fc79 ("i2c: imx-lpi2c: add runtime pm support") Reported-by: Hulk Robot Signed-off-by: Qinglang Miao Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 7ee35cde1e810ad6ca589980b9ec2b7b62946a5b Author: Qinglang Miao Date: Tue Dec 1 17:31:39 2020 +0800 i2c: img-scb: fix reference leak when pm_runtime_get_sync fails [ Upstream commit 223125e37af8a641ea4a09747a6a52172fc4b903 ] The PM reference count is not expected to be incremented on return in functions img_i2c_xfer and img_i2c_init. However, pm_runtime_get_sync will increment the PM reference count even failed. Forgetting to putting operation will result in a reference leak here. Replace it with pm_runtime_resume_and_get to keep usage counter balanced. Fixes: 93222bd9b966 ("i2c: img-scb: Add runtime PM") Reported-by: Hulk Robot Signed-off-by: Qinglang Miao Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit a45fc41beed8e0fe31864619c34aa00797fb60c1 Author: Qinglang Miao Date: Tue Dec 1 17:31:17 2020 +0800 i2c: cadence: fix reference leak when pm_runtime_get_sync fails [ Upstream commit 23ceb8462dc6f4b4decdb5536a7e5fc477cdf0b6 ] The PM reference count is not expected to be incremented on return in functions cdns_i2c_master_xfer and cdns_reg_slave. However, pm_runtime_get_sync will increment pm usage counter even failed. Forgetting to putting operation will result in a reference leak here. Replace it with pm_runtime_resume_and_get to keep usage counter balanced. Fixes: 7fa32329ca03 ("i2c: cadence: Move to sensible power management") Reported-by: Hulk Robot Signed-off-by: Qinglang Miao Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 8b3ffa5814f0f94b09712bf2fc2b4ba29189fa45 Author: Tudor Ambarus Date: Fri Apr 9 11:25:22 2021 +0300 pinctrl: at91-pio4: Fix slew rate disablement [ Upstream commit cbde6c823bfaa553fb162257a5926ba15ebaaa43 ] The slew rate was enabled by default for each configuration of the pin. In case the pin had more than one configuration, even if we set the slew rate as disabled in the device tree, the next pin configuration would set again the slew rate enabled by default, overwriting the slew rate disablement. Instead of enabling the slew rate by default for each pin configuration, enable the slew rate by default just once per pin, regardless of the number of configurations. This way the slew rate disablement will also work for cases where pins have multiple configurations. Fixes: c709135e576b ("pinctrl: at91-pio4: add support for slew-rate") Signed-off-by: Tudor Ambarus Reviewed-by: Claudiu Beznea Acked-by: Ludovic Desroches Link: https://lore.kernel.org/r/20210409082522.625168-1-tudor.ambarus@microchip.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit d3cca8067d43dfee4a3535c645b55f618708dccb Author: Gioh Kim Date: Mon Apr 12 10:40:02 2021 +0200 RDMA/rtrs-clt: destroy sysfs after removing session from active list [ Upstream commit 7f4a8592ff29f19c5a2ca549d0973821319afaad ] A session can be removed dynamically by sysfs interface "remove_path" that eventually calls rtrs_clt_remove_path_from_sysfs function. The current rtrs_clt_remove_path_from_sysfs first removes the sysfs interfaces and frees sess->stats object. Second it removes the session from the active list. Therefore some functions could access non-connected session and access the freed sess->stats object even-if they check the session status before accessing the session. For instance rtrs_clt_request and get_next_path_min_inflight check the session status and try to send IO to the session. The session status could be changed when they are trying to send IO but they could not catch the change and update the statistics information in sess->stats object, and generate use-after-free problem. (see: "RDMA/rtrs-clt: Check state of the rtrs_clt_sess before reading its stats") This patch changes the rtrs_clt_remove_path_from_sysfs to remove the session from the active session list and then destroy the sysfs interfaces. Each function still should check the session status because closing or error recovery paths can change the status. Fixes: 6a98d71daea1 ("RDMA/rtrs: client: main functionality") Link: https://lore.kernel.org/r/20210412084002.33582-1-gi-oh.kim@ionos.com Signed-off-by: Gioh Kim Reviewed-by: Jack Wang Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit bd8fbee40c8786e9b44255871caea0bb957cf38e Author: Wang Wensheng Date: Thu Apr 8 11:31:32 2021 +0000 RDMA/srpt: Fix error return code in srpt_cm_req_recv() [ Upstream commit 6bc950beff0c440ac567cdc4e7f4542a9920953d ] Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: db7683d7deb2 ("IB/srpt: Fix login-related race conditions") Link: https://lore.kernel.org/r/20210408113132.87250-1-wangwensheng4@huawei.com Reported-by: Hulk Robot Signed-off-by: Wang Wensheng Reviewed-by: Bart Van Assche Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit a46b536cd60c0dbd4bf767c62a8774dec52bf099 Author: Sean Wang Date: Tue Apr 6 11:34:36 2021 +0800 mt76: mt7921: fix kernel crash when the firmware fails to download [ Upstream commit e230f0c44f011f3270680a506b19b7e84c5e8923 ] Fix kernel crash when the firmware is missing or fails to download. [ 9.444758] kernel BUG at drivers/pci/msi.c:375! [ 9.449363] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP [ 9.501033] pstate: a0400009 (NzCv daif +PAN -UAO) [ 9.505814] pc : free_msi_irqs+0x180/0x184 [ 9.509897] lr : free_msi_irqs+0x40/0x184 [ 9.513893] sp : ffffffc015193870 [ 9.517194] x29: ffffffc015193870 x28: 00000000f0e94fa2 [ 9.522492] x27: 0000000000000acd x26: 000000000000009a [ 9.527790] x25: ffffffc0152cee58 x24: ffffffdbb383e0d8 [ 9.533087] x23: ffffffdbb38628d0 x22: 0000000000040200 [ 9.538384] x21: ffffff8cf7de7318 x20: ffffff8cd65a2480 [ 9.543681] x19: ffffff8cf7de7000 x18: 0000000000000000 [ 9.548979] x17: ffffff8cf9ca03b4 x16: ffffffdc13ad9a34 [ 9.554277] x15: 0000000000000000 x14: 0000000000080800 [ 9.559575] x13: ffffff8cd65a2980 x12: 0000000000000000 [ 9.564873] x11: ffffff8cfa45d820 x10: ffffff8cfa45d6d0 [ 9.570171] x9 : 0000000000000040 x8 : ffffff8ccef1b780 [ 9.575469] x7 : aaaaaaaaaaaaaaaa x6 : 0000000000000000 [ 9.580766] x5 : ffffffdc13824900 x4 : ffffff8ccefe0000 [ 9.586063] x3 : 0000000000000000 x2 : 0000000000000000 [ 9.591362] x1 : 0000000000000125 x0 : ffffff8ccefe0000 [ 9.596660] Call trace: [ 9.599095] free_msi_irqs+0x180/0x184 [ 9.602831] pci_disable_msi+0x100/0x130 [ 9.606740] pci_free_irq_vectors+0x24/0x30 [ 9.610915] mt7921_pci_probe+0xbc/0x250 [mt7921e] [ 9.615693] pci_device_probe+0xd4/0x14c [ 9.619604] really_probe+0x134/0x2ec [ 9.623252] driver_probe_device+0x64/0xfc [ 9.627335] device_driver_attach+0x4c/0x6c [ 9.631506] __driver_attach+0xac/0xc0 [ 9.635243] bus_for_each_dev+0x8c/0xd4 [ 9.639066] driver_attach+0x2c/0x38 [ 9.642628] bus_add_driver+0xfc/0x1d0 [ 9.646365] driver_register+0x64/0xf8 [ 9.650101] __pci_register_driver+0x6c/0x7c [ 9.654360] init_module+0x28/0xfdc [mt7921e] [ 9.658704] do_one_initcall+0x13c/0x2d0 [ 9.662615] do_init_module+0x58/0x1e8 [ 9.666351] load_module+0xd80/0xeb4 [ 9.669912] __arm64_sys_finit_module+0xa8/0xe0 [ 9.674430] el0_svc_common+0xa4/0x16c [ 9.678168] el0_svc_compat_handler+0x2c/0x40 [ 9.682511] el0_svc_compat+0x8/0x10 [ 9.686076] Code: a94257f6 f9400bf7 a8c47bfd d65f03c0 (d4210000) [ 9.692155] ---[ end trace 7621f966afbf0a29 ]--- [ 9.697385] Kernel panic - not syncing: Fatal exception [ 9.702599] SMP: stopping secondary CPUs [ 9.706549] Kernel Offset: 0x1c03600000 from 0xffffffc010000000 [ 9.712456] PHYS_OFFSET: 0xfffffff440000000 [ 9.716625] CPU features: 0x080026,2a80aa18 [ 9.720795] Memory Limit: none Fixes: 5c14a5f944b9 ("mt76: mt7921: introduce mt7921e support") Reported-by: Claire Chang Co-developed-by: YN Chen Signed-off-by: YN Chen Signed-off-by: Sean Wang Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit ab2dcb9083f2f7605c754a8a058a66a532e0cf5b Author: Colin Ian King Date: Fri Apr 9 14:07:26 2021 +0100 net: thunderx: Fix unintentional sign extension issue [ Upstream commit e701a25840360706fe4cf5de0015913ca19c274b ] The shifting of the u8 integers rq->caching by 26 bits to the left will be promoted to a 32 bit signed int and then sign-extended to a u64. In the event that rq->caching is greater than 0x1f then all then all the upper 32 bits of the u64 end up as also being set because of the int sign-extension. Fix this by casting the u8 values to a u64 before the 26 bit left shift. Addresses-Coverity: ("Unintended sign extension") Fixes: 4863dea3fab0 ("net: Adding support for Cavium ThunderX network controller") Signed-off-by: Colin Ian King Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4c20ede4c22e2087cbe00ee7797e6cf08f3fe5e7 Author: Colin Ian King Date: Fri Apr 9 12:08:57 2021 +0100 cxgb4: Fix unintentional sign extension issues [ Upstream commit dd2c79677375c37f8f9f8d663eb4708495d595ef ] The shifting of the u8 integers f->fs.nat_lip[] by 24 bits to the left will be promoted to a 32 bit signed int and then sign-extended to a u64. In the event that the top bit of the u8 is set then all then all the upper 32 bits of the u64 end up as also being set because of the sign-extension. Fix this by casting the u8 values to a u64 before the 24 bit left shift. Addresses-Coverity: ("Unintended sign extension") Fixes: 12b276fbf6e0 ("cxgb4: add support to create hash filters") Signed-off-by: Colin Ian King Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c86386cc21bfe4394729307d458fe504635383cb Author: Wang Wensheng Date: Thu Apr 8 11:31:37 2021 +0000 RDMA/bnxt_re: Fix error return code in bnxt_qplib_cq_process_terminal() [ Upstream commit 22efb0a8d130c6379c1eb64cbace1542b27e37ff ] Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: 1ac5a4047975 ("RDMA/bnxt_re: Add bnxt_re RoCE driver") Link: https://lore.kernel.org/r/20210408113137.97202-1-wangwensheng4@huawei.com Reported-by: Hulk Robot Signed-off-by: Wang Wensheng Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 1500e32939057b8a75c6f87a3f2c12d603b283af Author: Wang Wensheng Date: Thu Apr 8 11:31:40 2021 +0000 IB/hfi1: Fix error return code in parse_platform_config() [ Upstream commit 4c7d9c69adadfc31892c7e8e134deb3546552106 ] Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: 7724105686e7 ("IB/hfi1: add driver files") Link: https://lore.kernel.org/r/20210408113140.103032-1-wangwensheng4@huawei.com Reported-by: Hulk Robot Signed-off-by: Wang Wensheng Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 296eb4ca08e47ec77b27d5e476c19bf23f91f6cd Author: Wang Wensheng Date: Thu Apr 8 11:31:35 2021 +0000 RDMA/qedr: Fix error return code in qedr_iw_connect() [ Upstream commit 10dd83dbcd157baf7a78a09ddb2f84c627bc7f1d ] Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: 82af6d19d8d9 ("RDMA/qedr: Fix synchronization methods and memory leaks in qedr") Link: https://lore.kernel.org/r/20210408113135.92165-1-wangwensheng4@huawei.com Reported-by: Hulk Robot Signed-off-by: Wang Wensheng Acked-by: Michal Kalderon  Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 6354991d0bf5a9636b9d76783ff09b4f3153db0e Author: Amir Goldstein Date: Sun Apr 11 12:22:23 2021 +0300 ovl: invalidate readdir cache on changes to dir with origin [ Upstream commit 65cd913ec9d9d71529665924c81015b7ab7d9381 ] The test in ovl_dentry_version_inc() was out-dated and did not include the case where readdir cache is used on a non-merge dir that has origin xattr, indicating that it may contain leftover whiteouts. To make the code more robust, use the same helper ovl_dir_is_real() to determine if readdir cache should be used and if readdir cache should be invalidated. Fixes: b79e05aaa166 ("ovl: no direct iteration for dir with origin xattr") Link: https://lore.kernel.org/linux-unionfs/CAOQ4uxht70nODhNHNwGFMSqDyOKLXOKrY0H6g849os4BQ7cokA@mail.gmail.com/ Cc: Chris Murphy Signed-off-by: Amir Goldstein Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit eecb662975c0cc8964a9456f038b908cf79cd0e8 Author: Giuseppe Scrivano Date: Thu Mar 4 17:45:15 2021 +0100 ovl: show "userxattr" in the mount data [ Upstream commit 321b46b904816241044e177c1d6282ad20f17416 ] This was missed when adding the option. Signed-off-by: Giuseppe Scrivano Reviewed-by: Vivek Goyal Fixes: 2d2f2d7322ff ("ovl: user xattr") Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit 947573d8b7255861ec656bc971fde7952a4f9872 Author: Nicholas Piggin Date: Mon Apr 12 11:48:34 2021 +1000 KVM: PPC: Book3S HV P9: Restore host CTRL SPR after guest exit [ Upstream commit 5088eb4092df12d701af8e0e92860b7186365279 ] The host CTRL (runlatch) value is not restored after guest exit. The host CTRL should always be 1 except in CPU idle code, so this can result in the host running with runlatch clear, and potentially switching to a different vCPU which then runs with runlatch clear as well. This has little effect on P9 machines, CTRL is only responsible for some PMU counter logic in the host and so other than corner cases of software relying on that, or explicitly reading the runlatch value (Linux does not appear to be affected but it's possible non-Linux guests could be), there should be no execution correctness problem, though it could be used as a covert channel between guests. There may be microcontrollers, firmware or monitoring tools that sample the runlatch value out-of-band, however since the register is writable by guests, these values would (should) not be relied upon for correct operation of the host, so suboptimal performance or incorrect reporting should be the worst problem. Fixes: 95a6432ce9038 ("KVM: PPC: Book3S HV: Streamlined guest entry/exit path on P9 for radix guests") Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210412014845.1517916-2-npiggin@gmail.com Signed-off-by: Sasha Levin commit 0e36eb66f179792affac799c42105b21a63de8bd Author: Sean Wang Date: Tue Apr 6 11:34:35 2021 +0800 mt76: mt7921: fix the dwell time control [ Upstream commit 9db419f0cb39a63fb2f645a846cae17b81cd5c96 ] dwell time for the scan is not configurable according to the current firmware submitted into linux-firmware.git, so leave the dwell time 0 to indicate the dwell time always determined by the firmware. Fixes: 399090ef9605 ("mt76: mt76_connac: move hw_scan and sched_scan routine in mt76_connac_mcu module") Suggested-by: Soul Huang Co-developed-by: YN Chen Signed-off-by: YN Chen Signed-off-by: Sean Wang Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 1aa32d64fad46ed968b306b253eba4eef075518a Author: Sean Wang Date: Tue Apr 6 11:34:34 2021 +0800 mt76: mt7921: fix inappropriate WoW setup with the missing ARP informaiton [ Upstream commit 9c9d83213424679b087267600d53a35acfa0201f ] Fix the Wake-on-WoWLAN failure should rely on ARP Information is being updated in time to the firmware. Fixes: ffa1bf97425b ("mt76: mt7921: introduce PM support") Signed-off-by: Sean Wang Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 5ac6fcde7c70c8cafb9de7b6b606818e7754ada4 Author: Lorenzo Bianconi Date: Sat Apr 3 14:26:39 2021 +0200 mt76: mt7921: always wake the device in mt7921_remove_interface [ Upstream commit 859c85fd19715349ce01539459095fd5fc7e483a ] Make sure the mcu is not in sleep mode before sending mcu messages in mt7921_remove_interface routine. Fixes: 1d8efc741df80 ("mt76: mt7921: introduce Runtime PM support") Co-developed-by: Sean Wang Signed-off-by: Sean Wang Co-developed-by: Leon Yen Signed-off-by: Leon Yen Signed-off-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 6c8e96ad4114db0efdb133212e838f8e4c6721a6 Author: Ryder Lee Date: Fri Mar 26 02:28:56 2021 +0800 mt76: mt7915: cleanup mcu tx queue in mt7915_dma_reset() [ Upstream commit 1ebea45ef027ee31cd50ed92903071391e792edb ] Cleanup mcu queues in mt7915_mac_reset_work(). Fixes: e637763b606b ("mt76: move mcu queues to mt76_dev q_mcu array") Signed-off-by: Ryder Lee Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 9ed3f7370ac240691bef3664815c9a5ebeed1553 Author: Ryder Lee Date: Thu Mar 25 16:06:02 2021 +0800 mt76: mt7615: cleanup mcu tx queue in mt7615_dma_reset() [ Upstream commit 69e74d7f23d515fb559b2e0bebfdf4c458d9507d ] With this patch, mt7615_mac_reset_work() can recover system back. Fixes: e637763b606b ("mt76: move mcu queues to mt76_dev q_mcu array") Signed-off-by: Ryder Lee Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 7ecb3748e3ba3a98ac80911c2036db849316342d Author: Sean Wang Date: Thu Mar 4 21:25:23 2021 +0800 mt76: mt7663s: fix the possible device hang in high traffic [ Upstream commit 45247a85614b49b07b9dc59a4e6783b17e766ff2 ] Use the additional memory barrier to ensure the skb list up-to-date between the skb producer and consumer to avoid the invalid skb content written into sdio controller and then cause device hang due to mcu assert caught by WR_TIMEOUT_INT. Fixes: 1522ff731f84 ("mt76: mt7663s: introduce sdio tx aggregation") Signed-off-by: Sean Wang Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit cd0261e1bf531f20a8332cdf5418b2731c6af0db Author: Sean Wang Date: Thu Mar 4 21:25:22 2021 +0800 mt76: mt7663s: make all of packets 4-bytes aligned in sdio tx aggregation [ Upstream commit 455ae5aabcc72fed7e5c803d59d122415500dc08 ] Each packet should be padded with the additional zero to become 4-bytes alignment in sdio tx aggregation. Fixes: 1522ff731f84 ("mt76: mt7663s: introduce sdio tx aggregation") Signed-off-by: Sean Wang Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit ab28d7d1b205587e25056df9ee4bff4c18f48d6c Author: Sean Wang Date: Thu Mar 4 21:25:21 2021 +0800 mt76: mt7663: fix when beacon filter is being applied [ Upstream commit 4bec61d9fb9629c21e60cd24a97235ea1f6020ec ] HW beacon filter command is being applied until we're in associated state because the command would rely on the associated access point's beacon interval and DTIM information. Fixes: 7124198ab1a4 ("mt76: mt7615: enable beacon filtering by default for offload fw") Signed-off-by: Sean Wang Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 4bd926e5ca88eac4d95eacb806b229f8729bc62e Author: Ryder Lee Date: Wed Mar 3 18:38:00 2021 +0800 mt76: mt7915: fix txrate reporting [ Upstream commit f43b941fd61003659a3f0e039595e5e525917aa8 ] Properly check rate_info to fix unexpected reporting. [ 1215.161863] Call trace: [ 1215.164307] cfg80211_calculate_bitrate+0x124/0x200 [cfg80211] [ 1215.170139] ieee80211s_update_metric+0x80/0xc0 [mac80211] [ 1215.175624] ieee80211_tx_status_ext+0x508/0x838 [mac80211] [ 1215.181190] mt7915_mcu_get_rx_rate+0x28c/0x8d0 [mt7915e] [ 1215.186580] mt7915_mac_tx_free+0x324/0x7c0 [mt7915e] [ 1215.191623] mt7915_queue_rx_skb+0xa8/0xd0 [mt7915e] [ 1215.196582] mt76_dma_cleanup+0x7b0/0x11d0 [mt76] [ 1215.201276] __napi_poll+0x38/0xf8 [ 1215.204668] napi_workfn+0x40/0x80 [ 1215.208062] process_one_work+0x1fc/0x390 [ 1215.212062] worker_thread+0x48/0x4d0 [ 1215.215715] kthread+0x120/0x128 [ 1215.218935] ret_from_fork+0x10/0x1c Fixes: e57b7901469f ("mt76: add mac80211 driver for MT7915 PCIe-based chipsets") Fixes: e4c5ead632ff ("mt76: mt7915: rename mt7915_mcu_get_rate_info to mt7915_mcu_get_tx_rate") Reported-by: Evelyn Tsai Signed-off-by: Ryder Lee Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit b9d3a9e108d90ed0402373f871e46d45406fcad1 Author: Ryder Lee Date: Wed Mar 3 18:37:59 2021 +0800 mt76: mt7915: fix rxrate reporting [ Upstream commit 7883906d22c1e73f1f316bd84fc4a7ff8edd12aa ] Avoid directly updating sinfo->rxrate from firmware since rate_info might be overwritten by wrong results even mt7915_mcu_get_rx_rate() fails check. Add more error handlings accordingly. Fixes: 11553d88d0b9 ("mt76: mt7915: query station rx rate from firmware") Signed-off-by: Ryder Lee Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit f8d03ca3bb4aebcdb1f37aee884fce6b59899a2f Author: Sean Wang Date: Fri Feb 26 16:23:27 2021 +0800 mt76: mt7921: fix the base of the dynamic remap [ Upstream commit 53a8fb4afdc877f8f2d5e1e15cc5ad66155987a6 ] We should change the base for the dynamic remap into another one, because the current base (0xe0000) have been the one used to operate the device ownership. Fixes: 163f4d22c118 ("mt76: mt7921: add MAC support") Co-developed-by: YN Chen Signed-off-by: YN Chen Signed-off-by: Sean Wang Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit a24470fbbdeb82742c54e7fd78bfcf8d929f3d15 Author: Sean Wang Date: Fri Feb 26 16:23:26 2021 +0800 mt76: mt7921: fix the base of PCIe interrupt [ Upstream commit 23c1d2dc9ed5be1d0df7987335f5646e3826a461 ] Should use 0x10000 as the base to operate PCIe interrupt according to the vendor reference driver. Fixes: ffa1bf97425b ("mt76: mt7921: introduce PM support") Co-developed-by: YN Chen Signed-off-by: YN Chen Signed-off-by: Sean Wang Tested-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 65d1c9b2a2ff09d69e1e02406b72644e2269f595 Author: Lorenzo Bianconi Date: Wed Feb 24 12:29:34 2021 +0100 mt76: check return value of mt76_txq_send_burst in mt76_txq_schedule_list [ Upstream commit 57b8b57516c5108b0078051a31c68dc9dfcbf68f ] Since mt76_txq_send_burst routine can report a negative error code, check the returned value before incrementing the number of transmitted frames in mt76_txq_schedule_list routine. Return -EBUSY directly if the device is in reset or in power management. Fixes: 90fdc1717b186 ("mt76: use mac80211 txq scheduling") Signed-off-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 2554b9cb4b5e097c6071ec3ed5bc7c665c477ca7 Author: Lorenzo Bianconi Date: Tue Feb 23 18:28:43 2021 +0100 mt76: connac: fix kernel warning adding monitor interface [ Upstream commit c996f0346e40e3b1ac2ebaf0681df898fb157f60 ] Fix the following kernel warning adding a monitor interface in mt76_connac_mcu_uni_add_dev routine. [ 507.984882] ------------[ cut here ]------------ [ 507.989515] WARNING: CPU: 1 PID: 3017 at mt76_connac_mcu_uni_add_dev+0x178/0x190 [mt76_connac_lib] [ 508.059379] CPU: 1 PID: 3017 Comm: ifconfig Not tainted 5.4.98 #0 [ 508.065461] Hardware name: MT7622_MT7531 RFB (DT) [ 508.070156] pstate: 80000005 (Nzcv daif -PAN -UAO) [ 508.074939] pc : mt76_connac_mcu_uni_add_dev+0x178/0x190 [mt76_connac_lib] [ 508.081806] lr : mt7921_eeprom_init+0x1288/0x1cb8 [mt7921e] [ 508.087367] sp : ffffffc013a33930 [ 508.090671] x29: ffffffc013a33930 x28: ffffff801e628ac0 [ 508.095973] x27: ffffff801c7f1200 x26: ffffff801c7eb008 [ 508.101275] x25: ffffff801c7eaef0 x24: ffffff801d025610 [ 508.106577] x23: ffffff801d022990 x22: ffffff801d024de8 [ 508.111879] x21: ffffff801d0226a0 x20: ffffff801c7eaee8 [ 508.117181] x19: ffffff801d0226a0 x18: 000000005d00b000 [ 508.122482] x17: 00000000ffffffff x16: 0000000000000000 [ 508.127785] x15: 0000000000000080 x14: ffffff801d704000 [ 508.133087] x13: 0000000000000040 x12: 0000000000000002 [ 508.138389] x11: 000000000000000c x10: 0000000000000000 [ 508.143691] x9 : 0000000000000020 x8 : 0000000000000001 [ 508.148992] x7 : 0000000000000000 x6 : 0000000000000000 [ 508.154294] x5 : ffffff801c7eaee8 x4 : 0000000000000006 [ 508.159596] x3 : 0000000000000001 x2 : 0000000000000000 [ 508.164898] x1 : ffffff801c7eac08 x0 : ffffff801d0226a0 [ 508.170200] Call trace: [ 508.172640] mt76_connac_mcu_uni_add_dev+0x178/0x190 [mt76_connac_lib] [ 508.179159] mt7921_eeprom_init+0x1288/0x1cb8 [mt7921e] [ 508.184394] drv_add_interface+0x34/0x88 [mac80211] [ 508.189271] ieee80211_add_virtual_monitor+0xe0/0xb48 [mac80211] [ 508.195277] ieee80211_do_open+0x86c/0x918 [mac80211] [ 508.200328] ieee80211_do_open+0x900/0x918 [mac80211] [ 508.205372] __dev_open+0xcc/0x150 [ 508.208763] __dev_change_flags+0x134/0x198 [ 508.212937] dev_change_flags+0x20/0x60 [ 508.216764] devinet_ioctl+0x3e8/0x748 [ 508.220503] inet_ioctl+0x1e4/0x350 [ 508.223983] sock_do_ioctl+0x48/0x2a0 [ 508.227635] sock_ioctl+0x310/0x4f8 [ 508.231116] do_vfs_ioctl+0xa4/0xac0 [ 508.234681] ksys_ioctl+0x44/0x90 [ 508.237985] __arm64_sys_ioctl+0x1c/0x48 [ 508.241901] el0_svc_common.constprop.1+0x7c/0x100 [ 508.246681] el0_svc_handler+0x18/0x20 [ 508.250421] el0_svc+0x8/0x1c8 [ 508.253465] ---[ end trace c7b90fee13d72c39 ]--- [ 508.261278] ------------[ cut here ]------------ Fixes: d0e274af2f2e4 ("mt76: mt76_connac: create mcu library") Signed-off-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit fe1ea83b76ada1479c80f3632d5d1f7114f76794 Author: Ryder Lee Date: Tue Feb 23 22:00:36 2021 +0800 mt76: mt7915: fix mib stats counter reporting to mac80211 [ Upstream commit 2b35050a321865859fd2f12a3c18ed7be27858c9 ] In order to properly report MIB counters to mac80211, resets stats in mt7915_get_stats routine() and hold mt76 mutex accessing MIB counters. Sum up MIB counters in mt7915_mac_update_mib_stats routine. Fixes: e57b7901469f ("mt76: add mac80211 driver for MT7915 PCIe-based chipsets") Signed-off-by: Ryder Lee Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit d5d23c2dbc6e646f207401f46cb20a43de4e59e5 Author: Lorenzo Bianconi Date: Tue Feb 23 11:42:49 2021 +0100 mt76: mt7615: fix mib stats counter reporting to mac80211 [ Upstream commit 2eb6f6c437745bce46bd7a8f3a22a732d5b9becb ] In order to properly report MIB counters to mac80211, resets stats in mt7615_get_stats routine and hold mt76 mutex accessing MIB counters. Sum up MIB counters in mt7615_mac_update_mib_stats routine. Fixes: c388d8584bc83 ("mt76: mt7615: add a get_stats() callback") Signed-off-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit fb2e48febf56c8993c5355dd2084c3d36b70c110 Author: Ryder Lee Date: Tue Feb 23 16:43:11 2021 +0800 mt76: mt7615: fix TSF configuration [ Upstream commit a4a5a430b076860691e95337787bc666c8ab28ff ] The index of TSF counters should follow HWBSSID. Fixes: d8d59f66d136 ("mt76: mt7615: support 16 interfaces") Signed-off-by: Ryder Lee Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 09e89893b92677df901958d982d10ba398793a4d Author: Lorenzo Bianconi Date: Mon Feb 22 19:17:49 2021 +0100 mt76: mt7921: fix stats register definitions [ Upstream commit f76e9019913bffee0e49b096068e6f6b12f9b0e0 ] Fix register definitions for mac80211 stats reporting. Move mib counter reset to mt7921_get_stats routine. Fixes: 163f4d22c118d ("mt76: mt7921: add MAC support") Signed-off-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 358af1c797a0c6f77e60e2ce3583b4c509b4133e Author: Lorenzo Bianconi Date: Mon Feb 22 02:14:36 2021 +0100 mt76: mt7915: fix aggr len debugfs node [ Upstream commit 9fb9d755fae20b5ad62ef8b4e9289e5baea2c6fc ] Similar to mt7921, fix 802.11 aggr len debugfs reporting for mt7915 driver. Fixes: e57b7901469fc ("mt76: add mac80211 driver for MT7915 PCIe-based chipsets") Signed-off-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit abf1eac51e38a731ab7822b13952a07426016f85 Author: Lorenzo Bianconi Date: Mon Feb 22 02:12:09 2021 +0100 mt76: mt7921: fix aggr length histogram [ Upstream commit 461e3b7f45766f38eeb24ca7354ff01d993b5b47 ] Fix register definitions for 802.11 aggr length histogram estimation. Fixes: 474a9f21e2e2 ("mt76: mt7921: add debugfs support") Signed-off-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 54b989653c5531bc4416ced33f146b9cb633d978 Author: Lorenzo Bianconi Date: Fri Feb 19 18:22:11 2021 +0100 mt76: mt7615: fix memory leak in mt7615_coredump_work [ Upstream commit 49cc85059a2cb656f96ff3693f891e8fe8f669a9 ] Similar to the issue fixed in mt7921_coredump_work, fix a possible memory leak in mt7615_coredump_work routine. Fixes: d2bf7959d9c0f ("mt76: mt7663: introduce coredump support") Signed-off-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 3182896668e1a4d47e9f23d060d0f697ca5fb368 Author: Sean Wang Date: Fri Feb 19 18:28:48 2021 +0100 mt76: mt7921: fixup rx bitrate statistics [ Upstream commit 0940605a2a70803fc3362eeccba4c31adf4e70e7 ] Since the related rx bitrate fields have been moved to group3 in Rxv, fix rx bitrate statistics in mt7921_mac_fill_rx routine. Fixes: 163f4d22c118d ("mt76: mt7921: add MAC support") Signed-off-by: Sean Wang Signed-off-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit bca02a4a79de71b191148a7ad357e5dc7656dbb3 Author: Sean Wang Date: Fri Feb 19 18:28:47 2021 +0100 mt76: connac: fix up the setting for ht40 mode in mt76_connac_mcu_uni_add_bss [ Upstream commit a7e3033fcdb60ad51b03896ae99ad9447389bed0 ] Use proper value for ht40 mode configuration in mt76_connac_mcu_uni_add_bss routine and not ht20 one Fixes: d0e274af2f2e4 ("mt76: mt76_connac: create mcu library") Co-developed-by: Soul Huang Signed-off-by: Soul Huang Signed-off-by: Sean Wang Signed-off-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 4811226374453607175ea057777faa7e7f752204 Author: Sean Wang Date: Fri Feb 19 18:28:45 2021 +0100 mt76: mt7921: fix memory leak in mt7921_coredump_work [ Upstream commit 782b3e86ea970e899f8e723db9f64708a15ca30e ] Fix possible memory leak in mt7921_coredump_work. Fixes: 1c099ab44727c ("mt76: mt7921: add MCU support") Signed-off-by: Sean Wang Signed-off-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit c2918dd9000384ca74c2c260c40c848b50df11b8 Author: Sean Wang Date: Fri Feb 19 18:28:44 2021 +0100 mt76: mt7921: fix suspend/resume sequence [ Upstream commit 5e30931494b4940ba74fa5796ca0b6d7e4c84e88 ] Any pcie access should happen in pci D0 state and we should give ownership back to the device at the end of the suspend procedure. Fixes: 1d8efc741df80 ("mt76: mt7921: introduce Runtime PM support") Signed-off-by: Sean Wang Signed-off-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit e2cdc9cb33c5963efe1a7c022753386f9463d1b7 Author: Felix Fietkau Date: Sat Feb 13 18:44:10 2021 +0100 mt76: mt7915: fix tx skb dma unmap [ Upstream commit 7dcf3c04f0aca746517a77433b33d40868ca4749 ] The first pointer in the txp needs to be unmapped as well, otherwise it will leak DMA mapping entries Reported-by: Ben Greear Fixes: 27d5c528a7ca ("mt76: fix double DMA unmap of the first buffer on 7615/7915") Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 821ae236ccea989a1fcc6abfc4d5b74ad4ba39d2 Author: Felix Fietkau Date: Sat Feb 13 18:42:15 2021 +0100 mt76: mt7615: fix tx skb dma unmap [ Upstream commit ebee7885bb12a8fe2c2f9bac87dbd87a05b645f9 ] The first pointer in the txp needs to be unmapped as well, otherwise it will leak DMA mapping entries Fixes: 27d5c528a7ca ("mt76: fix double DMA unmap of the first buffer on 7615/7915") Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 88eee5ffb3b27b737235a32d8676eb74919804da Author: Colin Ian King Date: Thu Feb 25 18:32:41 2021 +0000 mt7601u: fix always true expression [ Upstream commit 87fce88658ba047ae62e83497d3f3c5dc22fa6f9 ] Currently the expression ~nic_conf1 is always true because nic_conf1 is a u16 and according to 6.5.3.3 of the C standard the ~ operator promotes the u16 to an integer before flipping all the bits. Thus the top 16 bits of the integer result are all set so the expression is always true. If the intention was to flip all the bits of nic_conf1 then casting the integer result back to a u16 is a suitabel fix. Interestingly static analyzers seem to thing a bitwise ! should be used instead of ~ for this scenario, so I think the original intent of the expression may need some extra consideration. Addresses-Coverity: ("Logical vs. bitwise operator") Fixes: c869f77d6abb ("add mt7601u driver") Signed-off-by: Colin Ian King Acked-by: Jakub Kicinski Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210225183241.1002129-1-colin.king@canonical.com Signed-off-by: Sasha Levin commit ae5ef5358a89d7855c35f7f3ef280e0a6ca685bc Author: Dan Carpenter Date: Mon Mar 15 12:23:37 2021 +0300 rtw88: Fix an error code in rtw_debugfs_set_rsvd_page() [ Upstream commit c9eaee0c2ec6b1002044fb698cdfb5d9ef4ed28c ] The sscanf() function returns the number of matches (0 or 1 in this case). It doesn't return error codes. We should return -EINVAL if the string is invalid Fixes: c376c1fc87b7 ("rtw88: add h2c command in debugfs") Signed-off-by: Dan Carpenter Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/YE8nmatMDBDDWkjq@mwanda Signed-off-by: Sasha Levin commit 0d724bf90a2dceb249b9dfe01af3eb4501bfc8dd Author: Colin Ian King Date: Fri Apr 9 10:27:34 2021 -0700 xfs: fix return of uninitialized value in variable error [ Upstream commit 3b6dd9a9aeeada19d0c820ff68e979243a888bb6 ] A previous commit removed a call to xfs_attr3_leaf_read that assigned an error return code to variable error. We now have a few early error return paths to label 'out' that return error if error is set; however error now is uninitialized so potentially garbage is being returned. Fix this by setting error to zero to restore the original behaviour where error was zero at the label 'restart'. Addresses-Coverity: ("Uninitialized scalar variable") Fixes: 07120f1abdff ("xfs: Add xfs_has_attr and subroutines") Signed-off-by: Colin Ian King Reviewed-by: Brian Foster Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Sasha Levin commit 269c23fa1b8ef50434023d6c71883a04a093a11f Author: Weihang Li Date: Fri Apr 2 17:07:27 2021 +0800 RDMA/hns: Fix missing assignment of max_inline_data [ Upstream commit 9eab614338cdfe08db343954454fa5191d082a11 ] When querying QP, the ULPs should be informed of the max length of inline data supported by the hardware. Fixes: 30b707886aeb ("RDMA/hns: Support inline data in extented sge space for RC") Link: https://lore.kernel.org/r/1617354454-47840-3-git-send-email-liweihang@huawei.com Signed-off-by: Weihang Li Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit ab5530a9c1038050c887f378254b987f43887a77 Author: Smita Koralahalli Date: Tue Apr 6 16:59:41 2021 -0500 perf vendor events amd: Fix broken L2 Cache Hits from L2 HWPF metric [ Upstream commit 86c2bc3da769124e3e856b6e9457be3667c30919 ] Commit 08ed77e414ab2342 ("perf vendor events amd: Add recommended events") added the hits event "L2 Cache Hits from L2 HWPF" with the same metric expression as the accesses event "L2 Cache Accesses from L2 HWPF": $ perf list --details ... l2_cache_accesses_from_l2_hwpf [L2 Cache Accesses from L2 HWPF] [l2_pf_hit_l2 + l2_pf_miss_l2_hit_l3 + l2_pf_miss_l2_l3] l2_cache_hits_from_l2_hwpf [L2 Cache Hits from L2 HWPF] [l2_pf_hit_l2 + l2_pf_miss_l2_hit_l3 + l2_pf_miss_l2_l3] ... This was wrong and led to counting hits the same as accesses. Section 2.1.15.2 "Performance Measurement" of "PPR for AMD Family 17h Model 31h B0 - 55803 Rev 0.54 - Sep 12, 2019", documents the hits event with EventCode 0x70 which is the same as l2_pf_hit_l2. Fix this, and massage the description for l2_pf_hit_l2 as the hits event is now the duplicate of l2_pf_hit_l2. AMD recommends using the recommended event over other events if the duplicate exists and maintain both for consistency. Hence, l2_cache_hits_from_l2_hwpf should override l2_pf_hit_l2. Before: # perf stat -M l2_cache_accesses_from_l2_hwpf,l2_cache_hits_from_l2_hwpf sleep 1 Performance counter stats for 'sleep 1': 1,436 l2_pf_miss_l2_l3 # 11114.00 l2_cache_accesses_from_l2_hwpf # 11114.00 l2_cache_hits_from_l2_hwpf 4,482 l2_pf_hit_l2 5,196 l2_pf_miss_l2_hit_l3 1.001765339 seconds time elapsed After: # perf stat -M l2_cache_accesses_from_l2_hwpf sleep 1 Performance counter stats for 'sleep 1': 1,477 l2_pf_miss_l2_l3 # 10442.00 l2_cache_accesses_from_l2_hwpf 3,978 l2_pf_hit_l2 4,987 l2_pf_miss_l2_hit_l3 1.001491186 seconds time elapsed # perf stat -e l2_cache_hits_from_l2_hwpf sleep 1 Performance counter stats for 'sleep 1': 3,983 l2_cache_hits_from_l2_hwpf 1.001329970 seconds time elapsed Note the difference in performance counter values for the accesses versus the hits after the fix, and the hits event now counting the same as l2_pf_hit_l2. Fixes: 08ed77e414ab ("perf vendor events amd: Add recommended events") Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=206537 Reviewed-by: Robert Richter Signed-off-by: Smita Koralahalli Tested-by: Arnaldo Carvalho de Melo # On a 3900X Cc: Alexander Shishkin Cc: Ian Rogers Cc: Ingo Molnar Cc: Jiri Olsa Cc: Kim Phillips Cc: Mark Rutland Cc: Martin Liška Cc: Michael Petlan Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Vijay Thakkar Cc: linux-perf-users@vger.kernel.org Link: https://lore.kernel.org/r/20210406215944.113332-2-Smita.KoralahalliChannabasappa@amd.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 02101c6645b20f8baf925f583669ee0344a24c8f Author: Johannes Berg Date: Thu Apr 8 14:31:50 2021 +0200 mac80211: bail out if cipher schemes are invalid [ Upstream commit db878e27a98106a70315d264cc92230d84009e72 ] If any of the cipher schemes specified by the driver are invalid, bail out and fail the registration rather than just warning. Otherwise, we might later crash when we try to use the invalid cipher scheme, e.g. if the hdr_len is (significantly) less than the pn_offs + pn_len, we'd have an out-of-bounds access in RX validation. Fixes: 2475b1cc0d52 ("mac80211: add generic cipher scheme support") Link: https://lore.kernel.org/r/20210408143149.38a3a13a1b19.I6b7f5790fa0958ed8049cf02ac2a535c61e9bc96@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 42667ed491b2e0cff0170abc7fa5d4cd36294b8f Author: Randy Dunlap Date: Sun Apr 4 12:26:23 2021 -0700 powerpc: iommu: fix build when neither PCI or IBMVIO is set [ Upstream commit b27dadecdf9102838331b9a0b41ffc1cfe288154 ] When neither CONFIG_PCI nor CONFIG_IBMVIO is set/enabled, iommu.c has a build error. The fault injection code is not useful in that kernel config, so make the FAIL_IOMMU option depend on PCI || IBMVIO. Prevents this build error (warning escalated to error): ../arch/powerpc/kernel/iommu.c:178:30: error: 'fail_iommu_bus_notifier' defined but not used [-Werror=unused-variable] 178 | static struct notifier_block fail_iommu_bus_notifier = { Fixes: d6b9a81b2a45 ("powerpc: IOMMU fault injection") Reported-by: kernel test robot Suggested-by: Michael Ellerman Signed-off-by: Randy Dunlap Acked-by: Randy Dunlap # build-tested Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210404192623.10697-1-rdunlap@infradead.org Signed-off-by: Sasha Levin commit 822ea5559c518d22163cad4e6abdb7e21642475a Author: Athira Rajeev Date: Tue Apr 6 12:16:01 2021 -0400 powerpc/perf: Fix PMU constraint check for EBB events [ Upstream commit 10f8f96179ecc7f69c927f6d231f6d02736cea83 ] The power PMU group constraints includes check for EBB events to make sure all events in a group must agree on EBB. This will prevent scheduling EBB and non-EBB events together. But in the existing check, settings for constraint mask and value is interchanged. Patch fixes the same. Before the patch, PMU selftest "cpu_event_pinned_vs_ebb_test" fails with below in dmesg logs. This happens because EBB event gets enabled along with a non-EBB cpu event. [35600.453346] cpu_event_pinne[41326]: illegal instruction (4) at 10004a18 nip 10004a18 lr 100049f8 code 1 in cpu_event_pinned_vs_ebb_test[10000000+10000] Test results after the patch: $ ./pmu/ebb/cpu_event_pinned_vs_ebb_test test: cpu_event_pinned_vs_ebb tags: git_version:v5.12-rc5-93-gf28c3125acd3-dirty Binding to cpu 8 EBB Handler is at 0x100050c8 read error on event 0x7fffe6bd4040! PM_RUN_INST_CMPL: result 9872 running/enabled 37930432 success: cpu_event_pinned_vs_ebb This bug was hidden by other logic until commit 1908dc911792 (perf: Tweak perf_event_attr::exclusive semantics). Fixes: 4df489991182 ("powerpc/perf: Add power8 EBB support") Reported-by: Thadeu Lima de Souza Cascardo Signed-off-by: Athira Rajeev [mpe: Mention commit 1908dc911792] Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/1617725761-1464-1-git-send-email-atrajeev@linux.vnet.ibm.com Signed-off-by: Sasha Levin commit d6dba51f6e0c95ae8a3e3da9f5ef0961b095c9f4 Author: Michael Ellerman Date: Wed Mar 31 11:38:42 2021 +1100 powerpc/64s: Use htab_convert_pte_flags() in hash__mark_rodata_ro() [ Upstream commit 2c02e656a29d5f64193eb93da92781bcf0517146 ] In hash__mark_rodata_ro() we pass the raw PP_RXXX value to hash__change_memory_range(). That has the effect of setting the key to zero, because PP_RXXX contains no key value. Fix it by using htab_convert_pte_flags(), which knows how to convert a pgprot into a pp value, including the key. Fixes: d94b827e89dc ("powerpc/book3s64/kuap: Use Key 3 for kernel mapping with hash translation") Signed-off-by: Michael Ellerman Reviewed-by: Daniel Axtens Link: https://lore.kernel.org/r/20210331003845.216246-3-mpe@ellerman.id.au Signed-off-by: Sasha Levin commit defbe7df388365917e333fb4b33f1d6ed80cb3cf Author: Michael Ellerman Date: Wed Mar 31 11:38:41 2021 +1100 powerpc/pseries: Add key to flags in pSeries_lpar_hpte_updateboltedpp() [ Upstream commit b56d55a5aa4aa9fc166595a7feb57f153ef7b555 ] The flags argument to plpar_pte_protect() (aka. H_PROTECT), includes the key in bits 9-13, but currently we always set those bits to zero. In the past that hasn't been a problem because we always used key 0 for the kernel, and updateboltedpp() is only used for kernel mappings. However since commit d94b827e89dc ("powerpc/book3s64/kuap: Use Key 3 for kernel mapping with hash translation") we are now inadvertently changing the key (to zero) when we call plpar_pte_protect(). That hasn't broken anything because updateboltedpp() is only used for STRICT_KERNEL_RWX, which is currently disabled on 64s due to other bugs. But we want to fix that, so first we need to pass the key correctly to plpar_pte_protect(). We can't pass our newpp value directly in, we have to convert it into the form expected by the hcall. The hcall we're using here is H_PROTECT, which is specified in section 14.5.4.1.6 of LoPAPR v1.1. It takes a `flags` parameter, and the description for flags says: * flags: AVPN, pp0, pp1, pp2, key0-key4, n, and for the CMO option: CMO Option flags as defined in Table 189‚ If you then go to the start of the parent section, 14.5.4.1, on page 405, it says: Register Linkage (For hcall() tokens 0x04 - 0x18) * On Call * R3 function call token * R4 flags (see Table 178‚ “Page Frame Table Access flags field definition‚” on page 401) Then you have to go to section 14.5.3, and on page 394 there is a list of hcalls and their tokens (table 176), and there you can see that H_PROTECT == 0x18. Finally you can look at table 178, on page 401, where it specifies the layout of the bits for the key: Bit Function ----------------- 50-54 | key0-key4 Those are big-endian bit numbers, converting to normal bit numbers you get bits 9-13, or 0x3e00. In the kernel we have: #define HPTE_R_KEY_HI ASM_CONST(0x3000000000000000) #define HPTE_R_KEY_LO ASM_CONST(0x0000000000000e00) So the LO bits of newpp are already in the right place, and the HI bits need to be shifted down by 48. Fixes: d94b827e89dc ("powerpc/book3s64/kuap: Use Key 3 for kernel mapping with hash translation") Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210331003845.216246-2-mpe@ellerman.id.au Signed-off-by: Sasha Levin commit e40c52ee67b155ad59f59e73ea136d02685f0e0d Author: Jordan Niethe Date: Mon Feb 8 14:29:56 2021 +1100 powerpc/64s: Fix pte update for kernel memory on radix [ Upstream commit b8b2f37cf632434456182e9002d63cbc4cccc50c ] When adding a PTE a ptesync is needed to order the update of the PTE with subsequent accesses otherwise a spurious fault may be raised. radix__set_pte_at() does not do this for performance gains. For non-kernel memory this is not an issue as any faults of this kind are corrected by the page fault handler. For kernel memory these faults are not handled. The current solution is that there is a ptesync in flush_cache_vmap() which should be called when mapping from the vmalloc region. However, map_kernel_page() does not call flush_cache_vmap(). This is troublesome in particular for code patching with Strict RWX on radix. In do_patch_instruction() the page frame that contains the instruction to be patched is mapped and then immediately patched. With no ordering or synchronization between setting up the PTE and writing to the page it is possible for faults. As the code patching is done using __put_user_asm_goto() the resulting fault is obscured - but using a normal store instead it can be seen: BUG: Unable to handle kernel data access on write at 0xc008000008f24a3c Faulting instruction address: 0xc00000000008bd74 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV Modules linked in: nop_module(PO+) [last unloaded: nop_module] CPU: 4 PID: 757 Comm: sh Tainted: P O 5.10.0-rc5-01361-ge3c1b78c8440-dirty #43 NIP: c00000000008bd74 LR: c00000000008bd50 CTR: c000000000025810 REGS: c000000016f634a0 TRAP: 0300 Tainted: P O (5.10.0-rc5-01361-ge3c1b78c8440-dirty) MSR: 9000000000009033 CR: 44002884 XER: 00000000 CFAR: c00000000007c68c DAR: c008000008f24a3c DSISR: 42000000 IRQMASK: 1 This results in the kind of issue reported here: https://lore.kernel.org/linuxppc-dev/15AC5B0E-A221-4B8C-9039-FA96B8EF7C88@lca.pw/ Chris Riedl suggested a reliable way to reproduce the issue: $ mount -t debugfs none /sys/kernel/debug $ (while true; do echo function > /sys/kernel/debug/tracing/current_tracer ; echo nop > /sys/kernel/debug/tracing/current_tracer ; done) & Turning ftrace on and off does a large amount of code patching which in usually less then 5min will crash giving a trace like: ftrace-powerpc: (____ptrval____): replaced (4b473b11) != old (60000000) ------------[ ftrace bug ]------------ ftrace failed to modify [] napi_busy_loop+0xc/0x390 actual: 11:3b:47:4b Setting ftrace call site to call ftrace function ftrace record flags: 80000001 (1) expected tramp: c00000000006c96c ------------[ cut here ]------------ WARNING: CPU: 4 PID: 809 at kernel/trace/ftrace.c:2065 ftrace_bug+0x28c/0x2e8 Modules linked in: nop_module(PO-) [last unloaded: nop_module] CPU: 4 PID: 809 Comm: sh Tainted: P O 5.10.0-rc5-01360-gf878ccaf250a #1 NIP: c00000000024f334 LR: c00000000024f330 CTR: c0000000001a5af0 REGS: c000000004c8b760 TRAP: 0700 Tainted: P O (5.10.0-rc5-01360-gf878ccaf250a) MSR: 900000000282b033 CR: 28008848 XER: 20040000 CFAR: c0000000001a9c98 IRQMASK: 0 GPR00: c00000000024f330 c000000004c8b9f0 c000000002770600 0000000000000022 GPR04: 00000000ffff7fff c000000004c8b6d0 0000000000000027 c0000007fe9bcdd8 GPR08: 0000000000000023 ffffffffffffffd8 0000000000000027 c000000002613118 GPR12: 0000000000008000 c0000007fffdca00 0000000000000000 0000000000000000 GPR16: 0000000023ec37c5 0000000000000000 0000000000000000 0000000000000008 GPR20: c000000004c8bc90 c0000000027a2d20 c000000004c8bcd0 c000000002612fe8 GPR24: 0000000000000038 0000000000000030 0000000000000028 0000000000000020 GPR28: c000000000ff1b68 c000000000bf8e5c c00000000312f700 c000000000fbb9b0 NIP ftrace_bug+0x28c/0x2e8 LR ftrace_bug+0x288/0x2e8 Call Trace: ftrace_bug+0x288/0x2e8 (unreliable) ftrace_modify_all_code+0x168/0x210 arch_ftrace_update_code+0x18/0x30 ftrace_run_update_code+0x44/0xc0 ftrace_startup+0xf8/0x1c0 register_ftrace_function+0x4c/0xc0 function_trace_init+0x80/0xb0 tracing_set_tracer+0x2a4/0x4f0 tracing_set_trace_write+0xd4/0x130 vfs_write+0xf0/0x330 ksys_write+0x84/0x140 system_call_exception+0x14c/0x230 system_call_common+0xf0/0x27c To fix this when updating kernel memory PTEs using ptesync. Fixes: f1cb8f9beba8 ("powerpc/64s/radix: avoid ptesync after set_pte and ptep_set_access_flags") Signed-off-by: Jordan Niethe Reviewed-by: Nicholas Piggin [mpe: Tidy up change log slightly] Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210208032957.1232102-1-jniethe5@gmail.com Signed-off-by: Sasha Levin commit 79f754d58e529e922b9084f4137555d58ff2efe7 Author: Mike Marciniszyn Date: Mon Mar 29 09:54:14 2021 -0400 IB/hfi1: Use kzalloc() for mmu_rb_handler allocation [ Upstream commit ca5f72568e034e1295a7ae350b1f786fcbfb2848 ] The code currently assumes that the mmu_notifier struct embedded in mmu_rb_handler only contains two fields. There are now extra fields: struct mmu_notifier { struct hlist_node hlist; const struct mmu_notifier_ops *ops; struct mm_struct *mm; struct rcu_head rcu; unsigned int users; }; Given that there in no init for the mmu_notifier, a kzalloc() should be used to insure that any newly added fields are given a predictable initial value of zero. Fixes: 06e0ffa69312 ("IB/hfi1: Re-factor MMU notification code") Link: https://lore.kernel.org/r/1617026056-50483-9-git-send-email-dennis.dalessandro@cornelisnetworks.com Reviewed-by: Adam Goldman Signed-off-by: Mike Marciniszyn Signed-off-by: Dennis Dalessandro Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 769003fd970c05a2ad21fee5429dd5a49feefd09 Author: Colin Ian King Date: Wed Apr 7 11:12:48 2021 +0100 liquidio: Fix unintented sign extension of a left shift of a u16 [ Upstream commit 298b58f00c0f86868ea717426beb5c1198772f81 ] The macro CN23XX_PEM_BAR1_INDEX_REG is being used to shift oct->pcie_port (a u16) left 24 places. There are two subtle issues here, first the shift gets promoted to an signed int and then sign extended to a u64. If oct->pcie_port is 0x80 or more then the upper bits get sign extended to 1. Secondly shfiting a u16 24 bits will lead to an overflow so it needs to be cast to a u64 for all the bits to not overflow. It is entirely possible that the u16 port value is never large enough for this to fail, but it is useful to fix unintended overflows such as this. Fix this by casting the port parameter to the macro to a u64 before the shift. Addresses-Coverity: ("Unintended sign extension") Fixes: 5bc67f587ba7 ("liquidio: CN23XX register definitions") Signed-off-by: Colin Ian King Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 66b672eab0ae206c5123a2a91198ce23dd41d1e4 Author: Krzysztof Kozlowski Date: Wed Apr 7 11:20:27 2021 +0200 ASoC: simple-card: fix possible uninitialized single_cpu local variable [ Upstream commit fa74c223b6fd78a5314b4c61b9abdbed3c2185b4 ] The 'single_cpu' local variable is assigned by asoc_simple_parse_dai() and later used in a asoc_simple_canonicalize_cpu() call, assuming the entire function did not exit on errors. However the first function returns 0 if passed device_node is NULL, thus leaving the variable uninitialized and reporting success. Addresses-Coverity: Uninitialized scalar variable Fixes: 8f7f298a3337 ("ASoC: simple-card-utils: separate asoc_simple_card_parse_dai()") Signed-off-by: Krzysztof Kozlowski Acked-by: Sameer Pujar Link: https://lore.kernel.org/r/20210407092027.60769-1-krzysztof.kozlowski@canonical.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit b4a6de2e3d484b86ed693778015d504fa05516be Author: Alexandru Elisei Date: Wed Apr 7 15:48:57 2021 +0100 KVM: arm64: Initialize VCPU mdcr_el2 before loading it [ Upstream commit 263d6287da1433aba11c5b4046388f2cdf49675c ] When a VCPU is created, the kvm_vcpu struct is initialized to zero in kvm_vm_ioctl_create_vcpu(). On VHE systems, the first time vcpu.arch.mdcr_el2 is loaded on hardware is in vcpu_load(), before it is set to a sensible value in kvm_arm_setup_debug() later in the run loop. The result is that KVM executes for a short time with MDCR_EL2 set to zero. This has several unintended consequences: * Setting MDCR_EL2.HPMN to 0 is constrained unpredictable according to ARM DDI 0487G.a, page D13-3820. The behavior specified by the architecture in this case is for the PE to behave as if MDCR_EL2.HPMN is set to a value less than or equal to PMCR_EL0.N, which means that an unknown number of counters are now disabled by MDCR_EL2.HPME, which is zero. * The host configuration for the other debug features controlled by MDCR_EL2 is temporarily lost. This has been harmless so far, as Linux doesn't use the other fields, but that might change in the future. Let's avoid both issues by initializing the VCPU's mdcr_el2 field in kvm_vcpu_vcpu_first_run_init(), thus making sure that the MDCR_EL2 register has a consistent value after each vcpu_load(). Fixes: d5a21bcc2995 ("KVM: arm64: Move common VHE/non-VHE trap config in separate functions") Signed-off-by: Alexandru Elisei Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20210407144857.199746-3-alexandru.elisei@arm.com Signed-off-by: Sasha Levin commit 117740621dbc24265aa4989c82e9819699dcdc8d Author: Hans de Goede Date: Sun Apr 4 10:04:29 2021 +0200 HID: lenovo: Map mic-mute button to KEY_F20 instead of KEY_MICMUTE [ Upstream commit 617103246cfd19af837e4cb614ba9f877c4f7779 ] Mapping the mic-mute button to KEY_MICMUTE is technically correct but KEY_MICMUTE translates to a scancode of 256 (248 + 8) under X, which does not fit in 8 bits, so it does not work. Because of this userspace is expecting KEY_F20 instead, theoretically KEY_MICMUTE should work under Wayland but even there it does not work, because the desktop-environment is listening only for KEY_F20 and not for KEY_MICMUTE. Fixes: bc04b37ea0ec ("HID: lenovo: Add ThinkPad 10 Ultrabook Keyboard support") Reviewed-by: Marek Behún Signed-off-by: Hans de Goede Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 59fcf294a3dd0c41352435cde0741465b29b4bdb Author: Hans de Goede Date: Sun Apr 4 10:04:26 2021 +0200 HID: lenovo: Check hid_get_drvdata() returns non NULL in lenovo_event() [ Upstream commit 34348a8661e3cd67dcf6938f08c8bb77522301f7 ] The HID lenovo probe function only attaches drvdata to one of the USB interfaces, but lenovo_event() will get called for all USB interfaces to which hid-lenovo is bound. This allows a malicious device to fake being a device handled by hid-lenovo, which generates events for which lenovo_event() has special handling (and thus dereferences hid_get_drvdata()) on another interface triggering a NULL pointer exception. Add a check for hid_get_drvdata() returning NULL, avoiding this possible NULL pointer exception. Fixes: bc04b37ea0ec ("HID: lenovo: Add ThinkPad 10 Ultrabook Keyboard support") Reviewed-by: Marek Behún Signed-off-by: Hans de Goede Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit da317e93f353b8f803cf262b2bac142052e1b8c8 Author: Hans de Goede Date: Sun Apr 4 10:04:25 2021 +0200 HID: lenovo: Fix lenovo_led_set_tp10ubkbd() error handling [ Upstream commit 658d04e6eb6be1601ae95d7bee92bbf4096cdc1e ] Fix the following issues with lenovo_led_set_tp10ubkbd() error handling: 1. On success hid_hw_raw_request() returns the number of bytes sent. So we should check for (ret != 3) rather then for (ret != 0). 2. Actually propagate errors to the caller. 3. Since the LEDs are part of an USB keyboard-dock the mute LEDs can go away at any time. Don't log an error when ret == -ENODEV and set the LED_HW_PLUGGABLE flag to avoid errors getting logged when the USB gets disconnected. Fixes: bc04b37ea0ec ("HID: lenovo: Add ThinkPad 10 Ultrabook Keyboard support") Reviewed-by: Marek Behún Signed-off-by: Hans de Goede Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 217c22918c3a5fb7f5f0c8a105073f1a8a202c57 Author: Hans de Goede Date: Sun Apr 4 10:04:24 2021 +0200 HID: lenovo: Use brightness_set_blocking callback for setting LEDs brightness [ Upstream commit bbf62645255f120bc2e7488c237e3f04da42ec70 ] The lenovo_led_brightness_set function may sleep, so we should have the the led_class_dev's brightness_set_blocking callback point to it, rather then the regular brightness_set callback. When toggled through sysfs this is not a problem, but the brightness_set callback may be called from atomic context when using LED-triggers. Fixes: bc04b37ea0ec ("HID: lenovo: Add ThinkPad 10 Ultrabook Keyboard support") Reviewed-by: Marek Behún Acked-by: Pavel Machek Signed-off-by: Hans de Goede Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit eefc81ca6f3000f1ab99721bd1c80c73caf3b394 Author: Takashi Iwai Date: Tue Apr 6 13:35:34 2021 +0200 ALSA: usb-audio: Add error checks for usb_driver_claim_interface() calls [ Upstream commit 5fb45414ae03421255593fd5556aa2d1d82303aa ] There are a few calls of usb_driver_claim_interface() but all of those miss the proper error checks, as reported by Coverity. This patch adds those missing checks. Along with it, replace the magic pointer with -1 with a constant USB_AUDIO_IFACE_UNUSED for better readability. Reported-by: coverity-bot Addresses-Coverity-ID: 1475943 ("Error handling issues") Addresses-Coverity-ID: 1475944 ("Error handling issues") Addresses-Coverity-ID: 1475945 ("Error handling issues") Fixes: b1ce7ba619d9 ("ALSA: usb-audio: claim autodetected PCM interfaces all at once") Fixes: e5779998bf8b ("ALSA: usb-audio: refactor code") Link: https://lore.kernel.org/r/202104051059.FB7F3016@keescook Link: https://lore.kernel.org/r/20210406113534.30455-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 0fbef3697f0fd74b43f36e35c71175b7b074a451 Author: Lu Baolu Date: Sat Mar 20 10:54:13 2021 +0800 iommu/vt-d: Invalidate PASID cache when root/context entry changed [ Upstream commit c0474a606ecb9326227b4d68059942f9db88a897 ] When the Intel IOMMU is operating in the scalable mode, some information from the root and context table may be used to tag entries in the PASID cache. Software should invalidate the PASID-cache when changing root or context table entries. Suggested-by: Ashok Raj Fixes: 7373a8cc38197 ("iommu/vt-d: Setup context and enable RID2PASID support") Signed-off-by: Lu Baolu Link: https://lore.kernel.org/r/20210320025415.641201-4-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 66c24699f266ff310381a9552d3576eea8ad6e20 Author: Lu Baolu Date: Sat Mar 20 10:54:12 2021 +0800 iommu/vt-d: Remove WO permissions on second-level paging entries [ Upstream commit eea53c5816889ee8b64544fa2e9311a81184ff9c ] When the first level page table is used for IOVA translation, it only supports Read-Only and Read-Write permissions. The Write-Only permission is not supported as the PRESENT bit (implying Read permission) should always set. When using second level, we still give separate permissions that allows WriteOnly which seems inconsistent and awkward. We want to have consistent behavior. After moving to 1st level, we don't want things to work sometimes, and break if we use 2nd level for the same mappings. Hence remove this configuration. Suggested-by: Ashok Raj Fixes: b802d070a52a1 ("iommu/vt-d: Use iova over first level") Signed-off-by: Lu Baolu Link: https://lore.kernel.org/r/20210320025415.641201-3-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 160faa083e5d4c4806f6fe6b6a900eb6fdff0148 Author: Lu Baolu Date: Sat Mar 20 10:54:11 2021 +0800 iommu/vt-d: Report the right page fault address [ Upstream commit 03d205094af45bca4f8e0498c461a893aa3ec6d9 ] The Address field of the Page Request Descriptor only keeps bit [63:12] of the offending address. Convert it to a full address before reporting it to device drivers. Fixes: eb8d93ea3c1d3 ("iommu/vt-d: Report page request faults for guest SVA") Signed-off-by: Lu Baolu Link: https://lore.kernel.org/r/20210320025415.641201-2-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 943cf2a239f8a77e00c23efd6e9f6ce976233ace Author: Lu Baolu Date: Tue Mar 30 10:11:45 2021 +0800 iommu/vt-d: Report right snoop capability when using FL for IOVA [ Upstream commit 6c00612d0cba10f7d0917cf1f73c945003ed4cd7 ] The Intel VT-d driver checks wrong register to report snoop capablility when using first level page table for GPA to HPA translation. This might lead the IOMMU driver to say that it supports snooping control, but in reality, it does not. Fix this by always setting PASID-table-entry.PGSNP whenever a pasid entry is setting up for GPA to HPA translation so that the IOMMU driver could report snoop capability as long as it runs in the scalable mode. Fixes: b802d070a52a1 ("iommu/vt-d: Use iova over first level") Suggested-by: Rajesh Sankaran Suggested-by: Kevin Tian Suggested-by: Ashok Raj Signed-off-by: Lu Baolu Link: https://lore.kernel.org/r/20210330021145.13824-1-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 32a874c6dedae438d0fc3df27ce5296bb0fe38e5 Author: Xiang Chen Date: Thu Mar 25 11:38:24 2021 +0800 iommu: Fix a boundary issue to avoid performance drop [ Upstream commit 3431c3f660a39f6ced954548a59dba6541ce3eb1 ] After the change of patch ("iommu: Switch gather->end to the inclusive end"), the performace drops from 1600+K IOPS to 1200K in our kunpeng ARM64 platform. We find that the range [start1, end1) actually is joint from the range [end1, end2), but it is considered as disjoint after the change, so it needs more times of TLB sync, and spends more time on it. So fix the boundary issue to avoid performance drop. Fixes: 862c3715de8f ("iommu: Switch gather->end to the inclusive end") Signed-off-by: Xiang Chen Acked-by: Will Deacon Link: https://lore.kernel.org/r/1616643504-120688-1-git-send-email-chenxiang66@hisilicon.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit e89f28b8be6564ec84a16186704067339756353d Author: Lu Baolu Date: Sat Mar 20 10:41:56 2021 +0800 iommu/vt-d: Don't set then clear private data in prq_event_thread() [ Upstream commit 1d421058c815d54113d9afdf6db3f995c788cf0d ] The VT-d specification (section 7.6) requires that the value in the Private Data field of a Page Group Response Descriptor must match the value in the Private Data field of the respective Page Request Descriptor. The private data field of a page group response descriptor is set then immediately cleared in prq_event_thread(). This breaks the rule defined by the VT-d specification. Fix it by moving clearing code up. Fixes: 5b438f4ba315d ("iommu/vt-d: Support page request in scalable mode") Cc: Jacob Pan Reviewed-by: Liu Yi L Signed-off-by: Lu Baolu Link: https://lore.kernel.org/r/20210320024156.640798-1-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 77e74a050dcea86725273a270c47ded358549775 Author: Wang Wensheng Date: Tue Apr 6 12:17:59 2021 +0000 KVM: arm64: Fix error return code in init_hyp_mode() [ Upstream commit 52b9e265d22bccc5843e167da76ab119874e2883 ] Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: eeeee7193df0 ("KVM: arm64: Bootstrap PSCI SMC handler in nVHE EL2") Reported-by: Hulk Robot Signed-off-by: Wang Wensheng Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20210406121759.5407-1-wangwensheng4@huawei.com Signed-off-by: Sasha Levin commit 793d43c4329795807697dc3afb3a2fd8a9355930 Author: Álvaro Fernández Rojas Date: Sun Mar 14 17:43:46 2021 +0100 mips: bmips: fix syscon-reboot nodes [ Upstream commit cde58b861a1d365568588adda59d42351c0c4ad3 ] Commit a23c4134955e added the clock controller nodes, incorrectly changing the syscon-reboot nodes addresses. Fixes: a23c4134955e ("MIPS: BMIPS: add clock controller nodes") Signed-off-by: Álvaro Fernández Rojas Acked-by: Florian Fainelli Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit facdf32dfcd060e947a1fd8f8e156ec61321eb97 Author: Salil Mehta Date: Mon Apr 5 18:28:25 2021 +0100 net: hns3: Limiting the scope of vector_ring_chain variable [ Upstream commit d392ecd1bc29ae15b0e284d5f732c2d36f244271 ] Limiting the scope of the variable vector_ring_chain to the block where it is used. Fixes: 424eb834a9be ("net: hns3: Unified HNS3 {VF|PF} Ethernet Driver for hip08 SoC") Signed-off-by: Salil Mehta Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8e82bcb775faaa421a42eaa7d1d757d40d639594 Author: Dan Carpenter Date: Fri Apr 2 14:44:42 2021 +0300 nfc: pn533: prevent potential memory corruption [ Upstream commit ca4d4c34ae9aa5c3c0da76662c5e549d2fc0cc86 ] If the "type_a->nfcid_len" is too large then it would lead to memory corruption in pn533_target_found_type_a() when we do: memcpy(nfc_tgt->nfcid1, tgt_type_a->nfcid_data, nfc_tgt->nfcid1_len); Fixes: c3b1e1e8a76f ("NFC: Export NFCID1 from pn533") Signed-off-by: Dan Carpenter Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 59bbdeee1dcbed943adf9bc140d1fee64e6a67df Author: Håkon Bugge Date: Mon Mar 22 14:35:32 2021 +0100 RDMA/core: Fix corrupted SL on passive side [ Upstream commit 194f64a3cad3ab9e381e996a13089de3215d1887 ] On RoCE systems, a CM REQ contains a Primary Hop Limit > 1 and Primary Subnet Local is zero. In cm_req_handler(), the cm_process_routed_req() function is called. Since the Primary Subnet Local value is zero in the request, and since this is RoCE (Primary Local LID is permissive), the following statement will be executed: IBA_SET(CM_REQ_PRIMARY_SL, req_msg, wc->sl); This corrupts SL in req_msg if it was different from zero. In other words, a request to setup a connection using an SL != zero, will not be honored, and a connection using SL zero will be created instead. Fixed by not calling cm_process_routed_req() on RoCE systems, the cm_process_route_req() is only for IB anyhow. Fixes: 3971c9f6dbf2 ("IB/cm: Add interim support for routed paths") Link: https://lore.kernel.org/r/1616420132-31005-1-git-send-email-haakon.bugge@oracle.com Signed-off-by: Håkon Bugge Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit af5a6af4d450c54619126dfea00218dcc051d8d1 Author: Andrew Scull Date: Thu Mar 18 14:33:07 2021 +0000 bug: Remove redundant condition check in report_bug [ Upstream commit 3ad1a6cb0abc63d036fc866bd7c2c5983516dec5 ] report_bug() will return early if it cannot find a bug corresponding to the provided address. The subsequent test for the bug will always be true so remove it. Fixes: 1b4cfe3c0a30d ("lib/bug.c: exclude non-BUG/WARN exceptions from report_bug()") Signed-off-by: Andrew Scull Cc: Peter Zijlstra Cc: "Steven Rostedt (VMware)" Reviewed-by: Steven Rostedt (VMware) Acked-by: Will Deacon Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20210318143311.839894-2-ascull@google.com Signed-off-by: Sasha Levin commit 5528b6014c49f7b150f38919b27f5e267ec61111 Author: Yang Yingliang Date: Wed Mar 31 16:36:02 2021 +0800 net/tipc: fix missing destroy_workqueue() on error in tipc_crypto_start() [ Upstream commit ac1db7acea67777be1ba86e36e058c479eab6508 ] Add the missing destroy_workqueue() before return from tipc_crypto_start() in the error handling case. Fixes: 1ef6f7c9390f ("tipc: add automatic session key exchange") Reported-by: Hulk Robot Signed-off-by: Yang Yingliang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8bc9833f5622d5996978889c251b0e5e0541bd2c Author: Michael Ellerman Date: Tue Mar 16 12:09:38 2021 +1100 powerpc/pseries: Only register vio drivers if vio bus exists [ Upstream commit 11d92156f7a862091009d7655d19c1e7de37fc7a ] The vio bus is a fake bus, which we use on pseries LPARs (guests) to discover devices provided by the hypervisor. There's no need or sense in creating the vio bus on bare metal systems. Which is why commit 4336b9337824 ("powerpc/pseries: Make vio and ibmebus initcalls pseries specific") made the initialisation of the vio bus only happen in LPARs. However as a result of that commit we now see errors at boot on bare metal systems: Driver 'hvc_console' was unable to register with bus_type 'vio' because the bus was not initialized. Driver 'tpm_ibmvtpm' was unable to register with bus_type 'vio' because the bus was not initialized. This happens because those drivers are built-in, and are calling vio_register_driver(). It in turn calls driver_register() with a reference to vio_bus_type, but we haven't registered vio_bus_type with the driver core. Fix it by also guarding vio_register_driver() with a check to see if we are on pseries. Fixes: 4336b9337824 ("powerpc/pseries: Make vio and ibmebus initcalls pseries specific") Reported-by: Paul Menzel Signed-off-by: Michael Ellerman Tested-by: Paul Menzel Reviewed-by: Tyrel Datwyler Link: https://lore.kernel.org/r/20210316010938.525657-1-mpe@ellerman.id.au Signed-off-by: Sasha Levin commit 4c5e5cea64d1e1df758d7dca15bd82046ee4c5d2 Author: Paolo Abeni Date: Tue Mar 30 12:28:52 2021 +0200 udp: never accept GSO_FRAGLIST packets [ Upstream commit 78352f73dc5047f3f744764cc45912498c52f3c9 ] Currently the UDP protocol delivers GSO_FRAGLIST packets to the sockets without the expected segmentation. This change addresses the issue introducing and maintaining a couple of new fields to explicitly accept SKB_GSO_UDP_L4 or GSO_FRAGLIST packets. Additionally updates udp_unexpected_gso() accordingly. UDP sockets enabling UDP_GRO stil keep accept_udp_fraglist zeroed. v1 -> v2: - use 2 bits instead of a whole GSO bitmask (Willem) Fixes: 9fd1ff5d2ac7 ("udp: Support UDP fraglist GRO/GSO.") Signed-off-by: Paolo Abeni Reviewed-by: Willem de Bruijn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 450687386cd16d081b58cd7a342acff370a96078 Author: Paolo Abeni Date: Tue Mar 30 12:28:50 2021 +0200 udp: skip L4 aggregation for UDP tunnel packets [ Upstream commit 18f25dc399901426dff61e676ba603ff52c666f7 ] If NETIF_F_GRO_FRAGLIST or NETIF_F_GRO_UDP_FWD are enabled, and there are UDP tunnels available in the system, udp_gro_receive() could end-up doing L4 aggregation (either SKB_GSO_UDP_L4 or SKB_GSO_FRAGLIST) at the outer UDP tunnel level for packets effectively carrying and UDP tunnel header. That could cause inner protocol corruption. If e.g. the relevant packets carry a vxlan header, different vxlan ids will be ignored/ aggregated to the same GSO packet. Inner headers will be ignored, too, so that e.g. TCP over vxlan push packets will be held in the GRO engine till the next flush, etc. Just skip the SKB_GSO_UDP_L4 and SKB_GSO_FRAGLIST code path if the current packet could land in a UDP tunnel, and let udp_gro_receive() do GRO via udp_sk(sk)->gro_receive. The check implemented in this patch is broader than what is strictly needed, as the existing UDP tunnel could be e.g. configured on top of a different device: we could end-up skipping GRO at-all for some packets. Anyhow, that is a very thin corner case and covering it will add quite a bit of complexity. v1 -> v2: - hopefully clarify the commit message Fixes: 9fd1ff5d2ac7 ("udp: Support UDP fraglist GRO/GSO.") Fixes: 36707061d6ba ("udp: allow forwarding of plain (non-fraglisted) UDP GRO packets") Reviewed-by: Willem de Bruijn Signed-off-by: Paolo Abeni Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5b86b44b9a4d776a83abffaf8ad9a4ff147d8dc2 Author: Andre Edich Date: Mon Mar 29 11:45:36 2021 +0200 net: phy: lan87xx: fix access to wrong register of LAN87xx [ Upstream commit fdb5cc6ab3b6a1c0122d3644a63ef9dc7a610d35 ] The function lan87xx_config_aneg_ext was introduced to configure LAN95xxA but as well writes to undocumented register of LAN87xx. This fix prevents that access. The function lan87xx_config_aneg_ext gets more suitable for the new behavior name. Reported-by: Måns Rullgård Fixes: 05b35e7eb9a1 ("smsc95xx: add phylib support") Signed-off-by: Andre Edich Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ff4fed6152e756e102c79e19c02ae80f30645821 Author: Jia Zhou Date: Tue Mar 30 13:19:23 2021 +0200 ALSA: core: remove redundant spin_lock pair in snd_card_disconnect [ Upstream commit abc21649b3e5c34b143bf86f0c78e33d5815e250 ] modification in commit 2a3f7221acdd ("ALSA: core: Fix card races between register and disconnect") resulting in this problem. Fixes: 2a3f7221acdd ("ALSA: core: Fix card races between register and disconnect") Signed-off-by: Jia Zhou Signed-off-by: Yi Wang Link: https://lore.kernel.org/r/1616989007-34429-1-git-send-email-wang.yi59@zte.com.cn Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 62413972f5266568848a36fd15160397b211fa74 Author: Dmitry Baryshkov Date: Sat Mar 27 12:28:57 2021 +0300 ASoC: q6afe-clocks: fix reprobing of the driver [ Upstream commit 96fadf7e8ff49fdb74754801228942b67c3eeebd ] Q6afe-clocks driver can get reprobed. For example if the APR services are restarted after the firmware crash. However currently Q6afe-clocks driver will oops because hw.init will get cleared during first _probe call. Rewrite the driver to fill the clock data at runtime rather than using big static array of clocks. Signed-off-by: Dmitry Baryshkov Reviewed-by: Srinivas Kandagatla Reviewed-by: Stephen Boyd Fixes: 520a1c396d19 ("ASoC: q6afe-clocks: add q6afe clock controller") Link: https://lore.kernel.org/r/20210327092857.3073879-1-dmitry.baryshkov@linaro.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f52b9a88ebeb7301a374e72c0ead858548fecdb2 Author: Yang Yingliang Date: Sat Mar 27 16:37:04 2021 +0800 fs: dlm: fix missing unlock on error in accept_from_sock() [ Upstream commit 2fd8db2dd05d895961c7c7b9fa02d72f385560e4 ] Add the missing unlock before return from accept_from_sock() in the error handling case. Fixes: 6cde210a9758 ("fs: dlm: add helper for init connection") Reported-by: Hulk Robot Signed-off-by: Yang Yingliang Signed-off-by: David Teigland Signed-off-by: Sasha Levin commit 51c7eda8b1883c6b9cf393d5b0adad8126b03f8e Author: Álvaro Fernández Rojas Date: Wed Mar 24 09:19:02 2021 +0100 gpio: guard gpiochip_irqchip_add_domain() with GPIOLIB_IRQCHIP [ Upstream commit 9c7d24693d864f90b27aad5d15fbfe226c02898b ] The current code doesn't check if GPIOLIB_IRQCHIP is enabled, which results in a compilation error when trying to build gpio-regmap if CONFIG_GPIOLIB_IRQCHIP isn't enabled. Fixes: 6a45b0e2589f ("gpiolib: Introduce gpiochip_irqchip_add_domain()") Suggested-by: Michael Walle Signed-off-by: Álvaro Fernández Rojas Reviewed-by: Linus Walleij Reviewed-by: Michael Walle Acked-by: Bartosz Golaszewski Link: https://lore.kernel.org/r/20210324081923.20379-2-noltari@gmail.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 8737b781154cf967f8c7aa6a45bbb0c5862304f4 Author: Tiezhu Yang Date: Thu Mar 25 20:50:01 2021 +0800 MIPS/bpf: Enable bpf_probe_read{, str}() on MIPS again [ Upstream commit 66633abd0642f1e89d26e15f36fb13d3a1c535ff ] After commit 0ebeea8ca8a4 ("bpf: Restrict bpf_probe_read{, str}() only to archs where they work"), bpf_probe_read{, str}() functions were no longer available on MIPS, so there exist some errors when running bpf program: root@linux:/home/loongson/bcc# python examples/tracing/task_switch.py bpf: Failed to load program: Invalid argument [...] 11: (85) call bpf_probe_read#4 unknown func bpf_probe_read#4 [...] Exception: Failed to load BPF program count_sched: Invalid argument ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE should be restricted to archs with non-overlapping address ranges, but they can overlap in EVA mode on MIPS, so select ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE if !EVA in arch/mips/Kconfig, otherwise the bpf old helper bpf_probe_read() will not be available. This is similar with the commit d195b1d1d119 ("powerpc/bpf: Enable bpf_probe_read{, str}() on powerpc again"). Fixes: 0ebeea8ca8a4 ("bpf: Restrict bpf_probe_read{, str}() only to archs where they work") Signed-off-by: Tiezhu Yang Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 5a54afcc73bccd4c31a2c94b00fbb1ad733430ea Author: Chen Huang Date: Sat Mar 27 09:49:00 2021 +0000 powerpc: Fix HAVE_HARDLOCKUP_DETECTOR_ARCH build configuration [ Upstream commit 4fe529449d85e78972fa327999961ecc83a0b6db ] When compiling the powerpc with the SMP disabled, it shows the issue: arch/powerpc/kernel/watchdog.c: In function ‘watchdog_smp_panic’: arch/powerpc/kernel/watchdog.c:177:4: error: implicit declaration of function ‘smp_send_nmi_ipi’; did you mean ‘smp_send_stop’? [-Werror=implicit-function-declaration] 177 | smp_send_nmi_ipi(c, wd_lockup_ipi, 1000000); | ^~~~~~~~~~~~~~~~ | smp_send_stop cc1: all warnings being treated as errors make[2]: *** [scripts/Makefile.build:273: arch/powerpc/kernel/watchdog.o] Error 1 make[1]: *** [scripts/Makefile.build:534: arch/powerpc/kernel] Error 2 make: *** [Makefile:1980: arch/powerpc] Error 2 make: *** Waiting for unfinished jobs.... We found that powerpc used ipi to implement hardlockup watchdog, so the HAVE_HARDLOCKUP_DETECTOR_ARCH should depend on the SMP. Fixes: 2104180a5369 ("powerpc/64s: implement arch-specific hardlockup watchdog") Reported-by: Hulk Robot Signed-off-by: Chen Huang Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210327094900.938555-1-chenhuang5@huawei.com Signed-off-by: Sasha Levin commit 08be2d6596d4f6c6c3d4ff4d43d810ab720762e7 Author: Nicholas Piggin Date: Tue Mar 16 20:52:05 2021 +1000 powerpc/64s: Fix hash fault to use TRAP accessor [ Upstream commit 1479e3d3b7559133b0a107772b5841e9c2cad450 ] Hash faults use the trap vector to decide whether this is an instruction or data fault. This should use the TRAP accessor rather than open access regs->trap. This won't cause a problem at the moment because 64s only uses trap flags for system call interrupts (the norestart flag), but that could change if any other trap flags get used in future. Fixes: a4922f5442e7e ("powerpc/64s: move the hash fault handling logic to C") Suggested-by: Christophe Leroy Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210316105205.407767-1-npiggin@gmail.com Signed-off-by: Sasha Levin commit ad11f55f1898fc40a78125aaa05891e15c73f846 Author: Lv Yunlong Date: Mon Mar 22 09:13:25 2021 -0700 IB/isert: Fix a use after free in isert_connect_request [ Upstream commit adb76a520d068a54ee5ca82e756cf8e5a47363a4 ] The device is got by isert_device_get() with refcount is 1, and is assigned to isert_conn by isert_conn->device = device. When isert_create_qp() failed, device will be freed with isert_device_put(). Later, the device is used in isert_free_login_buf(isert_conn) by the isert_conn->device->ib_device statement. Free the device in the correct order. Fixes: ae9ea9ed38c9 ("iser-target: Split some logic in isert_connect_request to routines") Link: https://lore.kernel.org/r/20210322161325.7491-1-lyl2019@mail.ustc.edu.cn Signed-off-by: Lv Yunlong Acked-by: Sagi Grimberg Reviewed-by: Leon Romanovsky Reviewed-by: Max Gurtovoy Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 3f3e729578767823c7fceb598d4f1fca9bbfac54 Author: Maor Gottlieb Date: Thu Mar 18 15:51:23 2021 +0200 RDMA/mlx5: Fix drop packet rule in egress table [ Upstream commit c73700806d4e430d182c2be069d230076818a99a ] Initial drop action support missed that drop action can be added to egress flow tables as well. Add the missing support. This requires making sure that dest_type isn't set to PORT which in turn exposes a possibility of passing dst while indicating number of dsts as zero. Explicitly check for number of dsts and pass the appropriate pointer. Fixes: f29de9eee782 ("RDMA/mlx5: Add support for drop action in DV steering") Link: https://lore.kernel.org/r/20210318135123.680759-1-leon@kernel.org Reviewed-by: Mark Bloch Signed-off-by: Maor Gottlieb Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 3266682f91cccb7bda0aacfe8e5d24d13f6aff76 Author: Zhen Lei Date: Wed Mar 24 16:16:03 2021 +0800 iommu/arm-smmu-v3: add bit field SFM into GERROR_ERR_MASK [ Upstream commit 655c447c97d7fe462e6cd9e15809037be028bc70 ] In arm_smmu_gerror_handler(), the value of the SMMU_GERROR register is filtered by GERROR_ERR_MASK. However, the GERROR_ERR_MASK does not contain the SFM bit. As a result, the subsequent error processing is not performed when only the SFM error occurs. Fixes: 48ec83bcbcf5 ("iommu/arm-smmu: Add initial driver support for ARM SMMUv3 devices") Reported-by: Rui Zhu Signed-off-by: Zhen Lei Link: https://lore.kernel.org/r/20210324081603.1074-1-thunder.leizhen@huawei.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 6570a82def262144c6d15938b15b0b309ee12de3 Author: Shengjiu Wang Date: Wed Mar 3 11:07:42 2021 +0800 ASoC: wm8960: Remove bitclk relax condition in wm8960_configure_sysclk [ Upstream commit 99067c07e8d877035f6249d194a317c78b7d052d ] The call sequence in wm8960_configure_clocking is ret = wm8960_configure_sysclk(); if (ret >= 0) goto configure_clock; .... ret = wm8960_configure_pll(); configure_clock: ... wm8960_configure_sysclk is called before wm8960_configure_pll, as there is bitclk relax on both functions, so wm8960_configure_sysclk always return success, then wm8960_configure_pll() never be called. With this case: aplay -Dhw:0,0 -d 5 -r 48000 -f S24_LE -c 2 audio48k24b2c.wav the required bitclk is 48000 * 24 * 2 = 2304000, bitclk got from wm8960_configure_sysclk is 3072000, but if go to wm8960_configure_pll. it can get correct bitclk 2304000. So bitclk relax condition should be removed in wm8960_configure_sysclk, then wm8960_configure_pll can be called, and there is also bitclk relax function in wm8960_configure_pll. Fixes: 3c01b9ee2ab9 ("ASoC: codec: wm8960: Relax bit clock computation") Signed-off-by: Shengjiu Wang Signed-off-by: Daniel Baluta Acked-by: Charles Keepax Link: https://lore.kernel.org/r/1614740862-30196-1-git-send-email-shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 2b8bf48c216527d09730a2b646b6d1bfc44af93c Author: Huang Pei Date: Wed Mar 24 11:24:51 2021 +0800 MIPS: loongson64: fix bug when PAGE_SIZE > 16KB [ Upstream commit 509d36a941a3466b78d4377913623d210b162458 ] When page size larger than 16KB, arguments "vaddr + size(16KB)" in "ioremap_page_range(vaddr, vaddr + size,...)" called by "add_legacy_isa_io" is not page-aligned. As loongson64 needs at least page size 16KB to get rid of cache alias, and "vaddr" is 64KB-aligned, and 64KB is largest page size supported, rounding "size" up to PAGE_SIZE is enough for all page size supported. Fixes: 6d0068ad15e4 ("MIPS: Loongson64: Process ISA Node in DeviceTree") Signed-off-by: Huang Pei Acked-by: Jiaxun Yang Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 5d58e5fabc92f154c262d8441aeee9dab3eb68d3 Author: Hanna Hawa Date: Fri Mar 19 17:21:33 2021 +0200 pinctrl: pinctrl-single: fix pcs_pin_dbg_show() when bits_per_mux is not zero [ Upstream commit bd85125ea88513f637a62a72e8949c579c5c0a87 ] A System Error (SError, followed by kernel panic) was detected when trying to print the supported pins in a pinctrl device which supports multiple pins per register. This change fixes the pcs_pin_dbg_show() in pinctrl-single driver when bits_per_mux is not zero. In addition move offset calculation and pin offset in register to common function. Fixes: 4e7e8017a80e ("pinctrl: pinctrl-single: enhance to configure multiple pins of different modules") Signed-off-by: Hanna Hawa Reviewed-by: Andy Shevchenko Reviewed-by: Tony Lindgren Reviewed-by: Drew Fustini Link: https://lore.kernel.org/r/20210319152133.28705-4-hhhawa@amazon.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit eb7d63e4a37b31b983de0d3a3f5135937eb54cc3 Author: Hanna Hawa Date: Fri Mar 19 17:21:32 2021 +0200 pinctrl: pinctrl-single: remove unused parameter [ Upstream commit 8fa2ea202b13b6da81e26c399ff1d87488398453 ] Remove unused parameter 'pin_pos' from pcs_add_pin(). Signed-off-by: Hanna Hawa Reviewed-by: Tony Lindgren Reviewed-by: Drew Fustini Link: https://lore.kernel.org/r/20210319152133.28705-3-hhhawa@amazon.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 806245375ff907cc8771de7a11585992a96d7937 Author: Eric Dumazet Date: Wed Mar 24 14:53:37 2021 -0700 inet: use bigger hash table for IP ID generation [ Upstream commit aa6dd211e4b1dde9d5dc25d699d35f789ae7eeba ] In commit 73f156a6e8c1 ("inetpeer: get rid of ip_id_count") I used a very small hash table that could be abused by patient attackers to reveal sensitive information. Switch to a dynamic sizing, depending on RAM size. Typical big hosts will now use 128x more storage (2 MB) to get a similar increase in security and reduction of hash collisions. As a bonus, use of alloc_large_system_hash() spreads allocated memory among all NUMA nodes. Fixes: 73f156a6e8c1 ("inetpeer: get rid of ip_id_count") Reported-by: Amit Klein Signed-off-by: Eric Dumazet Cc: Willy Tarreau Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 33df5d11674c7dbf24c778d57753a7c41b12615b Author: Li Huafei Date: Wed Mar 3 11:28:24 2021 +0800 ima: Fix the error code for restoring the PCR value [ Upstream commit 7990ccafaa37dc6d8bb095d4d7cd997e8903fd10 ] In ima_restore_measurement_list(), hdr[HDR_PCR].data is pointing to a buffer of type u8, which contains the dumped 32-bit pcr value. Currently, only the least significant byte is used to restore the pcr value. We should convert hdr[HDR_PCR].data to a pointer of type u32 before fetching the value to restore the correct pcr value. Fixes: 47fdee60b47f ("ima: use ima_parse_buf() to parse measurements headers") Signed-off-by: Li Huafei Reviewed-by: Roberto Sassu Signed-off-by: Mimi Zohar Signed-off-by: Sasha Levin commit 58e90fbccd88f6776e2f98704b4332e507c1bdfa Author: Huang Pei Date: Tue Mar 23 10:34:02 2021 +0800 MIPS: fix local_irq_{disable,enable} in asmmacro.h [ Upstream commit 05c4e2721d7af0df7bc1378a23712a0fd16947b5 ] commit ba9196d2e005 ("MIPS: Make DIEI support as a config option") use CPU_HAS_DIEI to indicate whether di/ei is implemented correctly, without this patch, "local_irq_disable" from entry.S in 3A1000 (with buggy di/ei) lose protection of commit e97c5b609880 ("MIPS: Make irqflags.h functions preempt-safe for non-mipsr2 cpus") Fixes: ba9196d2e005 ("MIPS: Make DIEI support as a config option") Signed-off-by: Huang Pei Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 4b0a22c9017569e39c5b1841aa28b9009e35f7db Author: Nathan Chancellor Date: Tue Mar 2 13:08:29 2021 -0700 powerpc/prom: Mark identical_pvr_fixup as __init [ Upstream commit 1ef1dd9c7ed27b080445e1576e8a05957e0e4dfc ] If identical_pvr_fixup() is not inlined, there are two modpost warnings: WARNING: modpost: vmlinux.o(.text+0x54e8): Section mismatch in reference from the function identical_pvr_fixup() to the function .init.text:of_get_flat_dt_prop() The function identical_pvr_fixup() references the function __init of_get_flat_dt_prop(). This is often because identical_pvr_fixup lacks a __init annotation or the annotation of of_get_flat_dt_prop is wrong. WARNING: modpost: vmlinux.o(.text+0x551c): Section mismatch in reference from the function identical_pvr_fixup() to the function .init.text:identify_cpu() The function identical_pvr_fixup() references the function __init identify_cpu(). This is often because identical_pvr_fixup lacks a __init annotation or the annotation of identify_cpu is wrong. identical_pvr_fixup() calls two functions marked as __init and is only called by a function marked as __init so it should be marked as __init as well. At the same time, remove the inline keywork as it is not necessary to inline this function. The compiler is still free to do so if it feels it is worthwhile since commit 889b3c1245de ("compiler: remove CONFIG_OPTIMIZE_INLINING entirely"). Fixes: 14b3d926a22b ("[POWERPC] 4xx: update 440EP(x)/440GR(x) identical PVR issue workaround") Signed-off-by: Nathan Chancellor Signed-off-by: Michael Ellerman Link: https://github.com/ClangBuiltLinux/linux/issues/1316 Link: https://lore.kernel.org/r/20210302200829.2680663-1-nathan@kernel.org Signed-off-by: Sasha Levin commit 71db53905dba72853651e1edb6b1fb1ac831c849 Author: Nathan Chancellor Date: Tue Mar 2 12:50:14 2021 -0700 powerpc/fadump: Mark fadump_calculate_reserve_size as __init [ Upstream commit fbced1546eaaab57a32e56c974ea8acf10c6abd8 ] If fadump_calculate_reserve_size() is not inlined, there is a modpost warning: WARNING: modpost: vmlinux.o(.text+0x5196c): Section mismatch in reference from the function fadump_calculate_reserve_size() to the function .init.text:parse_crashkernel() The function fadump_calculate_reserve_size() references the function __init parse_crashkernel(). This is often because fadump_calculate_reserve_size lacks a __init annotation or the annotation of parse_crashkernel is wrong. fadump_calculate_reserve_size() calls parse_crashkernel(), which is marked as __init and fadump_calculate_reserve_size() is called from within fadump_reserve_mem(), which is also marked as __init. Mark fadump_calculate_reserve_size() as __init to fix the section mismatch. Additionally, remove the inline keyword as it is not necessary to inline this function; the compiler is still free to do so if it feels it is worthwhile since commit 889b3c1245de ("compiler: remove CONFIG_OPTIMIZE_INLINING entirely"). Fixes: 11550dc0a00b ("powerpc/fadump: reuse crashkernel parameter for fadump memory reservation") Signed-off-by: Nathan Chancellor Signed-off-by: Michael Ellerman Link: https://github.com/ClangBuiltLinux/linux/issues/1300 Link: https://lore.kernel.org/r/20210302195013.2626335-1-nathan@kernel.org Signed-off-by: Sasha Levin commit a3e3bd8b1cd4849d3231c783a957fb6fb8544ac3 Author: Sebastian Andrzej Siewior Date: Fri Feb 19 17:56:48 2021 +0100 powerpc/mm: Move the linear_mapping_mutex to the ifdef where it is used [ Upstream commit 9be77e11dade414d2fa63750aa5c754fac49d619 ] The mutex linear_mapping_mutex is defined at the of the file while its only two user are within the CONFIG_MEMORY_HOTPLUG block. A compile without CONFIG_MEMORY_HOTPLUG set fails on PREEMPT_RT because its mutex implementation is smart enough to realize that it is unused. Move the definition of linear_mapping_mutex to ifdef block where it is used. Fixes: 1f73ad3e8d755 ("powerpc/mm: print warning in arch_remove_linear_mapping()") Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210219165648.2505482-1-bigeasy@linutronix.de Signed-off-by: Sasha Levin commit a712a6a3891dad51b38743674bd7599151abbf0f Author: KP Singh Date: Fri Mar 19 19:21:17 2021 +0000 libbpf: Add explicit padding to btf_dump_emit_type_decl_opts [ Upstream commit ea24b19562fe5f72c78319dbb347b701818956d9 ] Similar to https://lore.kernel.org/bpf/20210313210920.1959628-2-andrii@kernel.org/ When DECLARE_LIBBPF_OPTS is used with inline field initialization, e.g: DECLARE_LIBBPF_OPTS(btf_dump_emit_type_decl_opts, opts, .field_name = var_ident, .indent_level = 2, .strip_mods = strip_mods, ); and compiled in debug mode, the compiler generates code which leaves the padding uninitialized and triggers errors within libbpf APIs which require strict zero initialization of OPTS structs. Adding anonymous padding field fixes the issue. Fixes: 9f81654eebe8 ("libbpf: Expose BTF-to-C type declaration emitting API") Suggested-by: Andrii Nakryiko Signed-off-by: KP Singh Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20210319192117.2310658-1-kpsingh@kernel.org Signed-off-by: Sasha Levin commit 3be43633d30fb0b2d51e196806769709cb4adc70 Author: Andrii Nakryiko Date: Thu Mar 18 12:40:34 2021 -0700 selftests/bpf: Re-generate vmlinux.h and BPF skeletons if bpftool changed [ Upstream commit cab62c37be057379a2a17b1b2eacd9dcba1e14dc ] Trigger vmlinux.h and BPF skeletons re-generation if detected that bpftool was re-compiled. Otherwise full `make clean` is required to get updated skeletons, if bpftool is modified. Fixes: acbd06206bbb ("selftests/bpf: Add vmlinux.h selftest exercising tracing of syscalls") Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20210318194036.3521577-11-andrii@kernel.org Signed-off-by: Sasha Levin commit cfd02c72e5f41edf19b69d890e7cb8417c074957 Author: Rafał Miłecki Date: Thu Mar 18 09:01:43 2021 +0100 net: dsa: bcm_sf2: fix BCM4908 RGMII reg(s) [ Upstream commit 6859d91549341c2ad769d482de58129f080c0f04 ] BCM4908 has only 1 RGMII reg for controlling port 7. Fixes: 73b7a6047971 ("net: dsa: bcm_sf2: support BCM4908's integrated switch") Signed-off-by: Rafał Miłecki Acked-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 69f38f9126d29538c9b9da558782fb3a3581d03e Author: Rafał Miłecki Date: Thu Mar 18 09:01:42 2021 +0100 net: dsa: bcm_sf2: add function finding RGMII register [ Upstream commit 55cfeb396965c3906a84d09a9c487d065e37773b ] Simple macro like REG_RGMII_CNTRL_P() is insufficient as: 1. It doesn't validate port argument 2. It doesn't support chipsets with non-lineral RGMII regs layout Missing port validation could result in getting register offset from out of array. Random memory -> random offset -> random reads/writes. It affected e.g. BCM4908 for REG_RGMII_CNTRL_P(7). Fixes: a78e86ed586d ("net: dsa: bcm_sf2: Prepare for different register layouts") Signed-off-by: Rafał Miłecki Acked-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 26a0b1f604e08deee8d1a2bd5b0660b1247b3fa8 Author: Dmitry Osipenko Date: Sun Mar 14 18:44:45 2021 +0300 ASoC: tegra30: i2s: Restore hardware state on runtime PM resume [ Upstream commit 0bbcecaaab15a74ba69f93df46c753f2a64eadca ] Tegra30 I2S driver syncs regmap cache only on resume from system suspend, but hardware is reset across the runtime suspend because RPM of the parent AHUB driver resets the I2S hardware, hence h/w state is lost after each RPM resume. The problem isn't visible because hardware happens to be fully reprogrammed after each RPM resume. Move hardware syncing to RPM resume in order to restore h/w state properly. Fixes: ed9ce1ed2239 ("ASoC: tegra: ahub: Reset hardware properly") Signed-off-by: Dmitry Osipenko Link: https://lore.kernel.org/r/20210314154459.15375-4-digetx@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 409c028892b1aa945be27ae843ec83d3b767c688 Author: Jacob Pan Date: Tue Mar 2 02:13:59 2021 -0800 iommu/vt-d: Reject unsupported page request modes [ Upstream commit 78a523fe73b81b4447beb2d6c78c9fafae24eebb ] When supervisor/privilige mode SVM is used, we bind init_mm.pgd with a supervisor PASID. There should not be any page fault for init_mm. Execution request with DMA read is also not supported. This patch checks PRQ descriptor for both unsupported configurations, reject them both with invalid responses. Fixes: 1c4f88b7f1f92 ("iommu/vt-d: Shared virtual address in scalable mode") Acked-by: Lu Baolu Signed-off-by: Jacob Pan Link: https://lore.kernel.org/r/1614680040-1989-4-git-send-email-jacob.jun.pan@linux.intel.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit ba5d584cd6e8431749bd9a320f55bd60cb561ac4 Author: Robin Murphy Date: Fri Mar 5 16:32:34 2021 +0000 iommu/dma: Resurrect the "forcedac" option [ Upstream commit 3542dcb15cef66c0b9e6c3b33168eb657e0d9520 ] In converting intel-iommu over to the common IOMMU DMA ops, it quietly lost the functionality of its "forcedac" option. Since this is a handy thing both for testing and for performance optimisation on certain platforms, reimplement it under the common IOMMU parameter namespace. For the sake of fixing the inadvertent breakage of the Intel-specific parameter, remove the dmar_forcedac remnants and hook it up as an alias while documenting the transition to the new common parameter. Fixes: c588072bba6b ("iommu/vt-d: Convert intel iommu driver to the iommu ops") Signed-off-by: Robin Murphy Acked-by: Lu Baolu Reviewed-by: John Garry Link: https://lore.kernel.org/r/7eece8e0ea7bfbe2cd0e30789e0d46df573af9b0.1614961776.git.robin.murphy@arm.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 346607ab09de2989dfa2797b02a913fa1d1c810a Author: Shameer Kolothum Date: Wed Mar 3 17:36:11 2021 +0000 iommu: Check dev->iommu in iommu_dev_xxx functions [ Upstream commit b9abb19fa5fd2d8a4be61c6cd4b2a48aa1a17f9c ] The device iommu probe/attach might have failed leaving dev->iommu to NULL and device drivers may still invoke these functions resulting in a crash in iommu vendor driver code. Hence make sure we check that. Fixes: a3a195929d40 ("iommu: Add APIs for multiple domains per device") Signed-off-by: Shameer Kolothum Reviewed-by: Robin Murphy Link: https://lore.kernel.org/r/20210303173611.520-1-shameerali.kolothum.thodi@huawei.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit ba07cf2b022282bd1e25d20e59325369547fe7be Author: Andrii Nakryiko Date: Sat Mar 13 13:09:18 2021 -0800 bpftool: Fix maybe-uninitialized warnings [ Upstream commit 4bbb3583687051ef99966ddaeb1730441b777d40 ] Somehow when bpftool is compiled in -Og mode, compiler produces new warnings about possibly uninitialized variables. Fix all the reported problems. Fixes: 2119f2189df1 ("bpftool: add C output format option to btf dump subcommand") Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20210313210920.1959628-3-andrii@kernel.org Signed-off-by: Sasha Levin commit 1bafc147d350e6332ebc1a89bcc758754327ea98 Author: Andrii Nakryiko Date: Sat Mar 13 13:09:17 2021 -0800 libbpf: Add explicit padding to bpf_xdp_set_link_opts [ Upstream commit dde7b3f5f2f458297aeccfd4783e53ab8ca046db ] Adding such anonymous padding fixes the issue with uninitialized portions of bpf_xdp_set_link_opts when using LIBBPF_DECLARE_OPTS macro with inline field initialization: DECLARE_LIBBPF_OPTS(bpf_xdp_set_link_opts, opts, .old_fd = -1); When such code is compiled in debug mode, compiler is generating code that leaves padding bytes uninitialized, which triggers error inside libbpf APIs that do strict zero initialization checks for OPTS structs. Adding anonymous padding field fixes the issue. Fixes: bd5ca3ef93cd ("libbpf: Add function to set link XDP fd while specifying old program") Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20210313210920.1959628-2-andrii@kernel.org Signed-off-by: Sasha Levin commit ca44f7cd20d9521bd96a9eb69266436abdcc8895 Author: Xie He Date: Wed Mar 10 23:23:09 2021 -0800 net: lapbether: Prevent racing when checking whether the netif is running [ Upstream commit 5acd0cfbfbb5a688da1bfb1a2152b0c855115a35 ] There are two "netif_running" checks in this driver. One is in "lapbeth_xmit" and the other is in "lapbeth_rcv". They serve to make sure that the LAPB APIs called in these functions are called before "lapb_unregister" is called by the "ndo_stop" function. However, these "netif_running" checks are unreliable, because it's possible that immediately after "netif_running" returns true, "ndo_stop" is called (which causes "lapb_unregister" to be called). This patch adds locking to make sure "lapbeth_xmit" and "lapbeth_rcv" can reliably check and ensure the netif is running while doing their work. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Xie He Acked-by: Martin Schiller Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 332e69eb3bd90370f2d9f2c2ca7974ff523dea17 Author: Jiri Kosina Date: Tue Mar 16 15:08:00 2021 +0100 Bluetooth: avoid deadlock between hci_dev->lock and socket lock [ Upstream commit 17486960d79b900c45e0bb8fbcac0262848582ba ] Commit eab2404ba798 ("Bluetooth: Add BT_PHY socket option") added a dependency between socket lock and hci_dev->lock that could lead to deadlock. It turns out that hci_conn_get_phy() is not in any way relying on hdev being immutable during the runtime of this function, neither does it even look at any of the members of hdev, and as such there is no need to hold that lock. This fixes the lockdep splat below: ====================================================== WARNING: possible circular locking dependency detected 5.12.0-rc1-00026-g73d464503354 #10 Not tainted ------------------------------------------------------ bluetoothd/1118 is trying to acquire lock: ffff8f078383c078 (&hdev->lock){+.+.}-{3:3}, at: hci_conn_get_phy+0x1c/0x150 [bluetooth] but task is already holding lock: ffff8f07e831d920 (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}-{0:0}, at: l2cap_sock_getsockopt+0x8b/0x610 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}-{0:0}: lock_sock_nested+0x72/0xa0 l2cap_sock_ready_cb+0x18/0x70 [bluetooth] l2cap_config_rsp+0x27a/0x520 [bluetooth] l2cap_sig_channel+0x658/0x1330 [bluetooth] l2cap_recv_frame+0x1ba/0x310 [bluetooth] hci_rx_work+0x1cc/0x640 [bluetooth] process_one_work+0x244/0x5f0 worker_thread+0x3c/0x380 kthread+0x13e/0x160 ret_from_fork+0x22/0x30 -> #2 (&chan->lock#2/1){+.+.}-{3:3}: __mutex_lock+0xa3/0xa10 l2cap_chan_connect+0x33a/0x940 [bluetooth] l2cap_sock_connect+0x141/0x2a0 [bluetooth] __sys_connect+0x9b/0xc0 __x64_sys_connect+0x16/0x20 do_syscall_64+0x33/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae -> #1 (&conn->chan_lock){+.+.}-{3:3}: __mutex_lock+0xa3/0xa10 l2cap_chan_connect+0x322/0x940 [bluetooth] l2cap_sock_connect+0x141/0x2a0 [bluetooth] __sys_connect+0x9b/0xc0 __x64_sys_connect+0x16/0x20 do_syscall_64+0x33/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae -> #0 (&hdev->lock){+.+.}-{3:3}: __lock_acquire+0x147a/0x1a50 lock_acquire+0x277/0x3d0 __mutex_lock+0xa3/0xa10 hci_conn_get_phy+0x1c/0x150 [bluetooth] l2cap_sock_getsockopt+0x5a9/0x610 [bluetooth] __sys_getsockopt+0xcc/0x200 __x64_sys_getsockopt+0x20/0x30 do_syscall_64+0x33/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae other info that might help us debug this: Chain exists of: &hdev->lock --> &chan->lock#2/1 --> sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP); lock(&chan->lock#2/1); lock(sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP); lock(&hdev->lock); *** DEADLOCK *** 1 lock held by bluetoothd/1118: #0: ffff8f07e831d920 (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}-{0:0}, at: l2cap_sock_getsockopt+0x8b/0x610 [bluetooth] stack backtrace: CPU: 3 PID: 1118 Comm: bluetoothd Not tainted 5.12.0-rc1-00026-g73d464503354 #10 Hardware name: LENOVO 20K5S22R00/20K5S22R00, BIOS R0IET38W (1.16 ) 05/31/2017 Call Trace: dump_stack+0x7f/0xa1 check_noncircular+0x105/0x120 ? __lock_acquire+0x147a/0x1a50 __lock_acquire+0x147a/0x1a50 lock_acquire+0x277/0x3d0 ? hci_conn_get_phy+0x1c/0x150 [bluetooth] ? __lock_acquire+0x2e1/0x1a50 ? lock_is_held_type+0xb4/0x120 ? hci_conn_get_phy+0x1c/0x150 [bluetooth] __mutex_lock+0xa3/0xa10 ? hci_conn_get_phy+0x1c/0x150 [bluetooth] ? lock_acquire+0x277/0x3d0 ? mark_held_locks+0x49/0x70 ? mark_held_locks+0x49/0x70 ? hci_conn_get_phy+0x1c/0x150 [bluetooth] hci_conn_get_phy+0x1c/0x150 [bluetooth] l2cap_sock_getsockopt+0x5a9/0x610 [bluetooth] __sys_getsockopt+0xcc/0x200 __x64_sys_getsockopt+0x20/0x30 do_syscall_64+0x33/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7fb73df33eee Code: 48 8b 0d 85 0f 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 37 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 52 0f 0c 00 f7 d8 64 89 01 48 RSP: 002b:00007fffcfbbbf08 EFLAGS: 00000203 ORIG_RAX: 0000000000000037 RAX: ffffffffffffffda RBX: 0000000000000019 RCX: 00007fb73df33eee RDX: 000000000000000e RSI: 0000000000000112 RDI: 0000000000000018 RBP: 0000000000000000 R08: 00007fffcfbbbf44 R09: 0000000000000000 R10: 00007fffcfbbbf3c R11: 0000000000000203 R12: 0000000000000000 R13: 0000000000000018 R14: 0000000000000000 R15: 0000556fcefc70d0 Fixes: eab2404ba798 ("Bluetooth: Add BT_PHY socket option") Signed-off-by: Jiri Kosina Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit bf628b366445b1e885cacd0d31776f33174f7939 Author: Sean Christopherson Date: Thu Feb 25 12:47:30 2021 -0800 KVM: x86/mmu: Retry page faults that hit an invalid memslot [ Upstream commit e0c378684b6545ad2d4403bb701d0ac4932b4e95 ] Retry page faults (re-enter the guest) that hit an invalid memslot instead of treating the memslot as not existing, i.e. handling the page fault as an MMIO access. When deleting a memslot, SPTEs aren't zapped and the TLBs aren't flushed until after the memslot has been marked invalid. Handling the invalid slot as MMIO means there's a small window where a page fault could replace a valid SPTE with an MMIO SPTE. The legacy MMU handles such a scenario cleanly, but the TDP MMU assumes such behavior is impossible (see the BUG() in __handle_changed_spte()). There's really no good reason why the legacy MMU should allow such a scenario, and closing this hole allows for additional cleanups. Fixes: 2f2fad0897cb ("kvm: x86/mmu: Add functions to handle changed TDP SPTEs") Cc: Ben Gardon Signed-off-by: Sean Christopherson Message-Id: <20210225204749.1512652-6-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit bcf8a9025dfa2d633275d607c8b42e46b3429742 Author: Marcus Folkesson Date: Wed Feb 24 17:37:06 2021 +0100 wilc1000: write value to WILC_INTR2_ENABLE register [ Upstream commit e21b6e5a54628cd3935f200049d4430c25c54e03 ] Write the value instead of reading it twice. Fixes: c5c77ba18ea6 ("staging: wilc1000: Add SDIO/SPI 802.11 driver") Signed-off-by: Marcus Folkesson Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210224163706.519658-1-marcus.folkesson@gmail.com Signed-off-by: Sasha Levin commit fa79dc1b5aaaf2a487c4f9f72246a1f6836d401a Author: Yevgeny Kliteynik Date: Sat Feb 6 22:41:41 2021 +0200 net/mlx5: DR, Add missing vhca_id consume from STEv1 [ Upstream commit cc82a2e6c8af956d894fa58a040dc0d532dd9978 ] The field source_eswitch_owner_vhca_id was not consumed in the same way as in STEv0. Added the missing set. Fixes: 10b694186410 ("net/mlx5: DR, Add HW STEv1 match logic") Signed-off-by: Alex Vesker Signed-off-by: Yevgeny Kliteynik Reviewed-by: Alex Vesker Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 54816e3144c46747b43ff870c60ad5721bb30456 Author: Mark Zhang Date: Thu Mar 4 14:45:17 2021 +0200 RDMA/mlx5: Fix mlx5 rates to IB rates map [ Upstream commit 6fe6e568639859db960c8fcef19a2ece1c2d7eae ] Correct the map between mlx5 rates and corresponding ib rates, as they don't always have a fixed offset between them. Fixes: e126ba97dba9 ("mlx5: Add driver for Mellanox Connect-IB adapters") Link: https://lore.kernel.org/r/20210304124517.1100608-4-leon@kernel.org Signed-off-by: Mark Zhang Reviewed-by: Maor Gottlieb Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 386bdf46a93e313304ef0e33a4db993acae9ff9e Author: Maor Gottlieb Date: Thu Mar 4 14:45:15 2021 +0200 RDMA/mlx5: Fix query RoCE port [ Upstream commit 7852546f524595245382a919e752468f73421451 ] mlx5_is_roce_enabled returns the devlink RoCE init value, therefore it should be used only when driver is loaded. Instead we just need to read the roce_en field. In addition, rename mlx5_is_roce_enabled to mlx5_is_roce_init_enabled. Fixes: 7a58779edd75 ("IB/mlx5: Improve query port for representor port") Link: https://lore.kernel.org/r/20210304124517.1100608-2-leon@kernel.org Signed-off-by: Maor Gottlieb Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 29f91bd26f3ba828a55cb446ecd44caacf0df026 Author: Jason Gunthorpe Date: Thu Mar 4 14:07:42 2021 +0200 RDMA/mlx5: Zero out ODP related items in the mlx5_ib_mr [ Upstream commit a639e66703ee45745dc4057c7c2013ed9e1963a7 ] All of the ODP code assumes when it calls mlx5_mr_cache_alloc() the ODP related fields are zero'd. This is true if the MR was just allocated, but if the MR is recycled through the cache then the values are never zero'd. This causes a bug in the odp_stats, they don't reset when the MR is reallocated, also is_odp_implicit is never 0'd. So we can use memset on a block of the mlx5_ib_mr reorganize the structure to put all the data that can be zero'd by the cache at the end. It is organized as an anonymous struct because the next patch will make this a union. Delete the unused smr_info. Don't set the kernel only desc_size on the user path. No longer any need to zero mr->parent before freeing it, the memset() will get it now. Fixes: a3de94e3d61e ("IB/mlx5: Introduce ODP diagnostic counters") Link: https://lore.kernel.org/r/20210304120745.1090751-2-leon@kernel.org Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 6db9ead40fca11a5bd1883621729a6f081cdb625 Author: Cezary Rojewski Date: Mon Jan 25 12:54:41 2021 +0100 ASoC: Intel: Skylake: Compile when any configuration is selected [ Upstream commit 1b99d50b9709a2cddaba4a7faf1862b4f7bec865 ] Skylake is dependent on SND_SOC_INTEL_SKYLAKE (aka "all SST platforms") whereas selecting specific configuration such as KBL-only will not cause driver code to compile. Switch to SND_SOC_INTEL_SKYLAKE_COMMON dependency so selecting any configuration causes the driver to be built. Reported-by: Kai-Heng Feng Suggested-by: Amadeusz Sławiński Fixes: 35bc99aaa1a3 ("ASoC: Intel: Skylake: Add more platform granularity") Signed-off-by: Cezary Rojewski Link: https://lore.kernel.org/r/20210125115441.10383-1-cezary.rojewski@intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 18a335dc25157eca3b893e12897a41f077f54f7b Author: Colin Ian King Date: Fri Feb 26 18:56:53 2021 +0000 ASoC: Intel: boards: sof-wm8804: add check for PLL setting [ Upstream commit 1730ef62874dbdc53dc2abfa430f09f0b304bafc ] Currently the return from snd_soc_dai_set_pll is not checking for failure, this is the only driver in the kernel that ignores this, so it probably should be added for sake of completeness. Fix this by adding an error return check. Addresses-Coverity: ("Unchecked return value") Fixes: f139546fb7d4 ("ASoC: Intel: boards: sof-wm8804: support for Hifiberry Digiplus boards") Signed-off-by: Colin Ian King Acked-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20210226185653.1071321-1-colin.king@canonical.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit bdda1efa656d49f94d0cf1da80936fe00ee4682b Author: Arnaldo Carvalho de Melo Date: Mon Mar 8 11:17:51 2021 -0300 perf symbols: Fix dso__fprintf_symbols_by_name() to return the number of printed chars [ Upstream commit 210e4c89ef61432040c6cd828fefa441f4887186 ] The 'ret' variable was initialized to zero but then it was not updated from the fprintf() return, fix it. Reported-by: Yang Li cc: Alexander Shishkin cc: Ingo Molnar cc: Jiri Olsa cc: Mark Rutland cc: Namhyung Kim Cc: Peter Zijlstra Cc: Srikar Dronamraju Fixes: 90f18e63fbd00513 ("perf symbols: List symbols in a dso in ascending name order") Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 140f1d7283624731b5db9b644aa2786376a2a10c Author: Maxim Mikityanskiy Date: Sun Feb 7 16:47:40 2021 +0200 HID: plantronics: Workaround for double volume key presses [ Upstream commit f567d6ef8606fb427636e824c867229ecb5aefab ] Plantronics Blackwire 3220 Series (047f:c056) sends HID reports twice for each volume key press. This patch adds a quirk to hid-plantronics for this product ID, which will ignore the second volume key press if it happens within 5 ms from the last one that was handled. The patch was tested on the mentioned model only, it shouldn't affect other models, however, this quirk might be needed for them too. Auto-repeat (when a key is held pressed) is not affected, because the rate is about 3 times per second, which is far less frequent than once in 5 ms. Fixes: 81bb773faed7 ("HID: plantronics: Update to map volume up/down controls") Signed-off-by: Maxim Mikityanskiy Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit b963d569fcbee25b9609a7e1c314a9e801dbe281 Author: Alexander Lobakin Date: Thu Feb 18 20:50:31 2021 +0000 xsk: Respect device's headroom and tailroom on generic xmit path [ Upstream commit 3914d88f7608e6c2e80e344474fa289370c32451 ] xsk_generic_xmit() allocates a new skb and then queues it for xmitting. The size of new skb's headroom is desc->len, so it comes to the driver/device with no reserved headroom and/or tailroom. Lots of drivers need some headroom (and sometimes tailroom) to prepend (and/or append) some headers or data, e.g. CPU tags, device-specific headers/descriptors (LSO, TLS etc.), and if case of no available space skb_cow_head() will reallocate the skb. Reallocations are unwanted on fast-path, especially when it comes to XDP, so generic XSK xmit should reserve the spaces declared in dev->needed_headroom and dev->needed tailroom to avoid them. Note on max(NET_SKB_PAD, L1_CACHE_ALIGN(dev->needed_headroom)): Usually, output functions reserve LL_RESERVED_SPACE(dev), which consists of dev->hard_header_len + dev->needed_headroom, aligned by 16. However, on XSK xmit hard header is already here in the chunk, so hard_header_len is not needed. But it'd still be better to align data up to cacheline, while reserving no less than driver requests for headroom. NET_SKB_PAD here is to double-insure there will be no reallocations even when the driver advertises no needed_headroom, but in fact need it (not so rare case). Fixes: 35fcde7f8deb ("xsk: support for Tx") Signed-off-by: Alexander Lobakin Signed-off-by: Daniel Borkmann Acked-by: Magnus Karlsson Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20210218204908.5455-5-alobakin@pm.me Signed-off-by: Sasha Levin commit 72e431005a815550cc11cfa6239438cbe3c8d038 Author: Lv Yunlong Date: Mon Apr 26 07:32:29 2021 -0700 drivers/block/null_blk/main: Fix a double free in null_init. [ Upstream commit 72ce11ddfa4e9e1879103581a60b7e34547eaa0a ] In null_init, null_add_dev(dev) is called. In null_add_dev, it calls null_free_zoned_dev(dev) to free dev->zones via kvfree(dev->zones) in out_cleanup_zone branch and returns err. Then null_init accept the err code and then calls null_free_dev(dev). But in null_free_dev(dev), dev->zones is freed again by null_free_zoned_dev(). My patch set dev->zones to NULL in null_free_zoned_dev() after kvfree(dev->zones) is called, to avoid the double free. Fixes: 2984c8684f962 ("nullb: factor disk parameters") Signed-off-by: Lv Yunlong Link: https://lore.kernel.org/r/20210426143229.7374-1-lyl2019@mail.ustc.edu.cn Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit ff8150b9cf8faf0749c65bc0ad0cce11a3f7c47a Author: Dan Carpenter Date: Wed Apr 21 13:19:45 2021 +0300 ataflop: fix off by one in ataflop_probe() [ Upstream commit b777f4c47781df6b23e3f4df6fdb92d9aceac7bb ] Smatch complains that the "type > NUM_DISK_MINORS" should be >= instead of >. We also need to subtract one from "type" at the start. Fixes: bf9c0538e485 ("ataflop: use a separate gendisk for each media format") Reported-by: kernel test robot Signed-off-by: Dan Carpenter Reviewed-by: Christoph Hellwig Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 2a3a8bbca28b899806844c00d49ed1b7ccb50957 Author: Dan Carpenter Date: Wed Apr 21 13:18:35 2021 +0300 ataflop: potential out of bounds in do_format() [ Upstream commit 1ffec389a6431782a8a28805830b6fae9bf00af1 ] The function uses "type" as an array index: q = unit[drive].disk[type]->queue; Unfortunately the bounds check on "type" isn't done until later in the function. Fix this by moving the bounds check to the start. Fixes: bf9c0538e485 ("ataflop: use a separate gendisk for each media format") Reported-by: kernel test robot Signed-off-by: Dan Carpenter Reviewed-by: Christoph Hellwig Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 163dd7fa459faebe055bcbebf9e088bae04f8e33 Author: Peter Zijlstra Date: Tue Apr 20 10:18:17 2021 +0200 kthread: Fix PF_KTHREAD vs to_kthread() race [ Upstream commit 3a7956e25e1d7b3c148569e78895e1f3178122a9 ] The kthread_is_per_cpu() construct relies on only being called on PF_KTHREAD tasks (per the WARN in to_kthread). This gives rise to the following usage pattern: if ((p->flags & PF_KTHREAD) && kthread_is_per_cpu(p)) However, as reported by syzcaller, this is broken. The scenario is: CPU0 CPU1 (running p) (p->flags & PF_KTHREAD) // true begin_new_exec() me->flags &= ~(PF_KTHREAD|...); kthread_is_per_cpu(p) to_kthread(p) WARN(!(p->flags & PF_KTHREAD) <-- *SPLAT* Introduce __to_kthread() that omits the WARN and is sure to check both values. Use this to remove the problematic pattern for kthread_is_per_cpu() and fix a number of other kthread_*() functions that have similar issues but are currently not used in ways that would expose the problem. Notably kthread_func() is only ever called on 'current', while kthread_probe_data() is only used for PF_WQ_WORKER, which implies the task is from kthread_create*(). Fixes: ac687e6e8c26 ("kthread: Extract KTHREAD_IS_PER_CPU") Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Valentin Schneider Link: https://lkml.kernel.org/r/YH6WJc825C4P0FCK@hirez.programming.kicks-ass.net Signed-off-by: Sasha Levin commit af813843d8e6dd8f955c7f4837fec91110993027 Author: Waiman Long Date: Thu Apr 15 15:54:26 2021 -0400 sched/debug: Fix cgroup_path[] serialization [ Upstream commit ad789f84c9a145f8a18744c0387cec22ec51651e ] The handling of sysrq key can be activated by echoing the key to /proc/sysrq-trigger or via the magic key sequence typed into a terminal that is connected to the system in some way (serial, USB or other mean). In the former case, the handling is done in a user context. In the latter case, it is likely to be in an interrupt context. Currently in print_cpu() of kernel/sched/debug.c, sched_debug_lock is taken with interrupt disabled for the whole duration of the calls to print_*_stats() and print_rq() which could last for the quite some time if the information dump happens on the serial console. If the system has many cpus and the sched_debug_lock is somehow busy (e.g. parallel sysrq-t), the system may hit a hard lockup panic depending on the actually serial console implementation of the system. The purpose of sched_debug_lock is to serialize the use of the global cgroup_path[] buffer in print_cpu(). The rests of the printk calls don't need serialization from sched_debug_lock. Calling printk() with interrupt disabled can still be problematic if multiple instances are running. Allocating a stack buffer of PATH_MAX bytes is not feasible because of the limited size of the kernel stack. The solution implemented in this patch is to allow only one caller at a time to use the full size group_path[], while other simultaneous callers will have to use shorter stack buffers with the possibility of path name truncation. A "..." suffix will be printed if truncation may have happened. The cgroup path name is provided for informational purpose only, so occasional path name truncation should not be a big problem. Fixes: efe25c2c7b3a ("sched: Reinstate group names in /proc/sched_debug") Suggested-by: Peter Zijlstra Signed-off-by: Waiman Long Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20210415195426.6677-1-longman@redhat.com Signed-off-by: Sasha Levin commit 9b7d064beb344b538c0073a17de7aa0ce87388f6 Author: Dima Stepanov Date: Mon Apr 19 09:37:21 2021 +0200 block/rnbd-clt-sysfs: Remove copy buffer overlap in rnbd_clt_get_path_name [ Upstream commit 3db7cf55d532a15ea26b4a14e8f8729ccd96fd22 ] cppcheck report the following error: rnbd/rnbd-clt-sysfs.c:522:36: error: The variable 'buf' is used both as a parameter and as destination in snprintf(). The origin and destination buffers overlap. Quote from glibc (C-library) documentation (http://www.gnu.org/software/libc/manual/html_mono/libc.html#Formatted-Output-Functions): "If copying takes place between objects that overlap as a result of a call to sprintf() or snprintf(), the results are undefined." [sprintfOverlappingData] Fix it by initializing the buf variable in the first snprintf call. Fixes: 91f4acb2801c ("block/rnbd-clt: support mapping two devices") Signed-off-by: Dima Stepanov Cc: Arnd Bergmann Signed-off-by: Jack Wang Signed-off-by: Gioh Kim Reviewed-by: Chaitanya Kulkarni Link: https://lore.kernel.org/r/20210419073722.15351-19-gi-oh.kim@ionos.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 84b8c266c4bfe9ed5128e13253c388deb74b1b03 Author: Pavel Begunkov Date: Thu Apr 15 13:07:39 2021 +0100 io_uring: fix overflows checks in provide buffers [ Upstream commit 38134ada0ceea3e848fe993263c0ff6207fd46e7 ] Colin reported before possible overflow and sign extension problems in io_provide_buffers_prep(). As Linus pointed out previous attempt did nothing useful, see d81269fecb8ce ("io_uring: fix provide_buffers sign extension"). Do that with help of check__overflow helpers. And fix struct io_provide_buf::len type, as it doesn't make much sense to keep it signed. Reported-by: Colin Ian King Fixes: efe68c1ca8f49 ("io_uring: validate the full range of provided buffers for access") Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/r/46538827e70fce5f6cdb50897cff4cacc490f380.1618488258.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 9fb875f2c2f991bbee0fe74225f6168e3cffaa6d Author: Nathan Chancellor Date: Wed Apr 14 17:11:12 2021 -0700 perf/amd/uncore: Fix sysfs type mismatch [ Upstream commit 5deac80d4571dffb51f452f0027979d72259a1b9 ] dev_attr_show() calls the __uncore_*_show() functions via an indirect call but their type does not currently match the type of the show() member in 'struct device_attribute', resulting in a Control Flow Integrity violation. $ cat /sys/devices/amd_l3/format/umask config:8-15 $ dmesg | grep "CFI failure" [ 1258.174653] CFI failure (target: __uncore_umask_show...): Update the type in the DEFINE_UNCORE_FORMAT_ATTR macro to match 'struct device_attribute' so that there is no more CFI violation. Fixes: 06f2c24584f3 ("perf/amd/uncore: Prepare to scale for more attributes that vary per family") Signed-off-by: Nathan Chancellor Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20210415001112.3024673-2-nathan@kernel.org Signed-off-by: Sasha Levin commit 3456263249c0baa2142affcfa0314e557428a498 Author: Nathan Chancellor Date: Wed Apr 14 17:11:11 2021 -0700 x86/events/amd/iommu: Fix sysfs type mismatch [ Upstream commit de5bc7b425d4c27ae5faa00ea7eb6b9780b9a355 ] dev_attr_show() calls _iommu_event_show() via an indirect call but _iommu_event_show()'s type does not currently match the type of the show() member in 'struct device_attribute', resulting in a Control Flow Integrity violation. $ cat /sys/devices/amd_iommu_1/events/mem_dte_hit csource=0x0a $ dmesg | grep "CFI failure" [ 3526.735140] CFI failure (target: _iommu_event_show...): Change _iommu_event_show() and 'struct amd_iommu_event_desc' to 'struct device_attribute' so that there is no more CFI violation. Fixes: 7be6296fdd75 ("perf/x86/amd: AMD IOMMU Performance Counter PERF uncore PMU implementation") Signed-off-by: Nathan Chancellor Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20210415001112.3024673-1-nathan@kernel.org Signed-off-by: Sasha Levin commit f61295900937186937e71152dc4cec86df4e02e2 Author: Dan Carpenter Date: Fri Apr 9 14:08:17 2021 +0300 HSI: core: fix resource leaks in hsi_add_client_from_dt() [ Upstream commit 5c08b0f75575648032f309a6f58294453423ed93 ] If some of the allocations fail between the dev_set_name() and the device_register() then the name will not be freed. Fix this by moving dev_set_name() directly in front of the call to device_register(). Fixes: a2aa24734d9d ("HSI: Add common DT binding for HSI client devices") Signed-off-by: Dan Carpenter Reviewed-by: Jason Gunthorpe Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit a961733c9a8e8f8fecd7578218047cd878ab6d44 Author: Jernej Skrabec Date: Mon Apr 12 17:43:49 2021 +0200 media: cedrus: Fix H265 status definitions [ Upstream commit 147d211cc9b4d753148d1640a1758b25edfbf437 ] Some of the H265 status flags are wrong. Redefine them to corespond to Allwinner CedarC open source userspace library. Only one of these flags is actually used and new value also matches value used in libvdpau-sunxi library, which is proven to be working. Note that wrong (old) value in right circumstances (in combination with another H265 decoding bug) causes driver lock up. With this fix decoding is still broken (green output) but at least driver doesn't lock up. Fixes: 86caab29da78 ("media: cedrus: Add HEVC/H.265 decoding support") Signed-off-by: Jernej Skrabec Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit af74515995284cbc53a9445ce9d246decc7ad165 Author: Neil Armstrong Date: Mon Apr 12 15:48:33 2021 +0200 media: meson-ge2d: fix rotation parameters [ Upstream commit 87e780db2253a1759822c2c9ea207135fcc059de ] With these settings, 90deg and 270deg rotation leads to inverted vertical, fix them to have correct rotation. Fixes: 59a635327ca7 ("media: meson: Add M2M driver for the Amlogic GE2D Accelerator Unit") Signed-off-by: Neil Armstrong Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 3709013f59ae15d2ce0e08f68d03077b05dcdde3 Author: Niklas Cassel Date: Fri Apr 9 20:12:55 2021 +0200 nvme-pci: don't simple map sgl when sgls are disabled [ Upstream commit e51183be1fa96dc6d3cd11b3c25a0f595807315e ] According to the module parameter description for sgl_threshold, a value of 0 means that SGLs are disabled. If SGLs are disabled, we should respect that, even for the case where the request is made up of a single physical segment. Fixes: 297910571f08 ("nvme-pci: optimize mapping single segment requests using SGLs") Signed-off-by: Niklas Cassel Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 8d14cda3129233d7bb3b3d860a681b7a8e7be3d5 Author: Elad Grupi Date: Wed Mar 31 17:13:14 2021 +0800 nvmet-tcp: fix a segmentation fault during io parsing error [ Upstream commit bdaf13279192c60b2b1fc99badef53b494fec055 ] In case there is an io that contains inline data and it goes to parsing error flow, command response will free command and iov before clearing the data on the socket buffer. This will delay the command response until receive flow is completed. Fixes: 872d26a391da ("nvmet-tcp: add NVMe over TCP target driver") Signed-off-by: Elad Grupi Signed-off-by: Hou Pu Reviewed-by: Sagi Grimberg Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit fee3fece9d842004aa78264c2d04f030595d8c8a Author: Fabrice Gasnier Date: Wed Mar 3 18:51:35 2021 +0100 mfd: stm32-timers: Avoid clearing auto reload register [ Upstream commit 4917e498c6894ba077867aff78f82cffd5ffbb5c ] The ARR register is cleared unconditionally upon probing, after the maximum value has been read. This initial condition is rather not intuitive, when considering the counter child driver. It rather expects the maximum value by default: - The counter interface shows a zero value by default for 'ceiling' attribute. - Enabling the counter without any prior configuration makes it doesn't count. The reset value of ARR register is the maximum. So Choice here is to backup it, and restore it then, instead of clearing its value. It also fixes the initial condition seen by the counter driver. Fixes: d0f949e220fd ("mfd: Add STM32 Timers driver") Signed-off-by: Fabrice Gasnier Acked-by: William Breathitt Gray Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 6aab92b5cb8aa6abb680fd0fe557488b6ab6af2e Author: Orson Zhai Date: Fri Mar 19 14:15:35 2021 +0800 mailbox: sprd: Introduce refcnt when clients requests/free channels [ Upstream commit 9468ab84032f96496e998cfa173cd1d0ac316bcd ] Unisoc mailbox has no way to be enabled/disabled for any single channel. They can only be set to startup or shutdown as a whole device at same time. Add a variable to count references to avoid mailbox FIFO being reset unexpectedly when clients are requesting or freeing channels. Also add a lock to dismiss possible conflicts from register r/w in different startup or shutdown threads. And fix the crash problem when early interrupts come from channel which has not been requested by client yet. Fixes: ca27fc26cd22 ("mailbox: sprd: Add Spreadtrum mailbox driver") Signed-off-by: Orson Zhai Reviewed-by: Baolin Wang Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 0dcc67960c6ce07d0fb93d96ce9b1b537815c76b Author: Brian King Date: Mon Apr 12 18:10:09 2021 -0600 scsi: ibmvfc: Fix invalid state machine BUG_ON() [ Upstream commit 15cfef8623a449d40d16541687afd58e78033be3 ] This fixes an issue hitting the BUG_ON() in ibmvfc_do_work(). When going through a host action of IBMVFC_HOST_ACTION_RESET, we change the action to IBMVFC_HOST_ACTION_TGT_DEL, then drop the host lock, and reset the CRQ, which changes the host state to IBMVFC_NO_CRQ. If, prior to setting the host state to IBMVFC_NO_CRQ, ibmvfc_init_host() is called, it can then end up changing the host action to IBMVFC_HOST_ACTION_INIT. If we then change the host state to IBMVFC_NO_CRQ, we will then hit the BUG_ON(). Make a couple of changes to avoid this. Leave the host action to be IBMVFC_HOST_ACTION_RESET or IBMVFC_HOST_ACTION_REENABLE until after we drop the host lock and reset or reenable the CRQ. Also harden the host state machine to ensure we cannot leave the reset / reenable state until we've finished processing the reset or reenable. Link: https://lore.kernel.org/r/20210413001009.902400-1-tyreld@linux.ibm.com Fixes: 73ee5d867287 ("[SCSI] ibmvfc: Fix soft lockup on resume") Signed-off-by: Brian King [tyreld: added fixes tag] Signed-off-by: Tyrel Datwyler [mkp: fix comment checkpatch warnings] Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 9a5b491ee9e0517dee4638f29abe88078c6e53a2 Author: Sergey Shtylyov Date: Tue Mar 30 20:45:12 2021 +0300 scsi: sni_53c710: Add IRQ check [ Upstream commit 1160d61bc51e87e509cfaf9da50a0060f67b6de4 ] The driver neglects to check the result of platform_get_irq()'s call and blithely passes the negative error codes to request_irq() (which takes *unsigned* IRQ #s), causing it to fail with -EINVAL (overridden by -ENODEV further below). Stop calling request_irq() with the invalid IRQ #s. Link: https://lore.kernel.org/r/8f4b8fa5-8251-b977-70a1-9099bcb4bb17@omprussia.ru Fixes: c27d85f3f3c5 ("[SCSI] SNI RM 53c710 driver") Signed-off-by: Sergey Shtylyov Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit a808b2b925be434f9edc93fb97245c392cd579af Author: Sergey Shtylyov Date: Tue Mar 30 20:44:08 2021 +0300 scsi: sun3x_esp: Add IRQ check [ Upstream commit 14b321380eb333c82853d7d612d0995f05f88fdc ] The driver neglects to check the result of platform_get_irq()'s call and blithely passes the negative error codes to request_irq() (which takes *unsigned* IRQ #), causing it to fail with -EINVAL, overriding the real error code. Stop calling request_irq() with the invalid IRQ #s. Link: https://lore.kernel.org/r/363eb4c8-a3bf-4dc9-2a9e-90f349030a15@omprussia.ru Fixes: 0bb67f181834 ("[SCSI] sun3x_esp: convert to esp_scsi") Signed-off-by: Sergey Shtylyov Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 47c242dc76c82aa29fbd8a059265019913688a4e Author: Sergey Shtylyov Date: Tue Mar 30 20:43:23 2021 +0300 scsi: jazz_esp: Add IRQ check [ Upstream commit 38fca15c29db6ed06e894ac194502633e2a7d1fb ] The driver neglects to check the result of platform_get_irq()'s call and blithely passes the negative error codes to request_irq() (which takes *unsigned* IRQ #), causing it to fail with -EINVAL, overriding the real error code. Stop calling request_irq() with the invalid IRQ #s. Link: https://lore.kernel.org/r/594aa9ae-2215-49f6-f73c-33bd38989912@omprussia.ru Fixes: 352e921f0dd4 ("[SCSI] jazz_esp: converted to use esp_core") Signed-off-by: Sergey Shtylyov Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 12e8332ac74fb745f2920e5457dbcbd0d9bcc7d6 Author: Sergey Shtylyov Date: Sat Apr 3 23:43:55 2021 +0300 scsi: hisi_sas: Fix IRQ checks [ Upstream commit 6c11dc060427e07ca144eacaccd696106b361b06 ] Commit df2d8213d9e3 ("hisi_sas: use platform_get_irq()") failed to take into account that irq_of_parse_and_map() and platform_get_irq() have a different way of indicating an error: the former returns 0 and the latter returns a negative error code. Fix up the IRQ checks! Link: https://lore.kernel.org/r/810f26d3-908b-1d6b-dc5c-40019726baca@omprussia.ru Fixes: df2d8213d9e3 ("hisi_sas: use platform_get_irq()") Acked-by: John Garry Signed-off-by: Sergey Shtylyov Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 0bb0751c28bb51a40532352c331af9f0d1c08534 Author: Sergey Shtylyov Date: Mon Mar 29 23:50:58 2021 +0300 scsi: ufs: ufshcd-pltfrm: Fix deferred probing [ Upstream commit 339c9b63cc7ce779ce45c675bf709cb58b807fc3 ] The driver overrides the error codes returned by platform_get_irq() to -ENODEV, so if it returns -EPROBE_DEFER, the driver would fail the probe permanently instead of the deferred probing. Propagate the error code upstream as it should have been done from the start... Link: https://lore.kernel.org/r/420364ca-614a-45e3-4e35-0e0653c7bc53@omprussia.ru Fixes: 2953f850c3b8 ("[SCSI] ufs: use devres functions for ufshcd") Signed-off-by: Sergey Shtylyov Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 27b44a8e143abb6a2e8f84212fe4f107164848ca Author: Colin Ian King Date: Wed Apr 7 14:58:40 2021 +0100 scsi: pm80xx: Fix potential infinite loop [ Upstream commit 40fa7394a1ad5706e795823276f2e394cca145d0 ] The for-loop iterates with a u8 loop counter i and compares this with the loop upper limit of pm8001_ha->max_q_num which is a u32 type. There is a potential infinite loop if pm8001_ha->max_q_num is larger than the u8 loop counter. Fix this by making the loop counter the same type as pm8001_ha->max_q_num. [mkp: this is purely theoretical, max_q_num is currently limited to 64] Link: https://lore.kernel.org/r/20210407135840.494747-1-colin.king@canonical.com Fixes: 65df7d1986a1 ("scsi: pm80xx: Fix chip initialization failure") Addresses-Coverity: ("Infinite loop") Reviewed-by: Johannes Thumshirn Signed-off-by: Colin Ian King Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit c9f61c4bb402a599d90cccc7354cca66cff13d30 Author: Igor Pylypiv Date: Tue Apr 6 11:05:33 2021 -0700 scsi: pm80xx: Increase timeout for pm80xx mpi_uninit_check() [ Upstream commit 3f744a14f331f56703a9d74e86520db045f11831 ] The mpi_uninit_check() takes longer for inbound doorbell register to be cleared. Increase the timeout substantially so that the driver does not fail to load. Previously, the inbound doorbell wait time was mistakenly increased in the mpi_init_check() instead of mpi_uninit_check(). It is okay to leave the mpi_init_check() wait time as-is as these are timeout values and if there is a failure, waiting longer is not an issue. Link: https://lore.kernel.org/r/20210406180534.1924345-2-ipylypiv@google.com Fixes: e90e236250e9 ("scsi: pm80xx: Increase timeout for pm80xx mpi_uninit_check") Reviewed-by: Vishakha Channapattan Acked-by: Jack Wang Signed-off-by: Igor Pylypiv Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit cbc1be3bf6f4dfbd83f1c7d8e42525933ae11025 Author: Colin Ian King Date: Fri Apr 9 10:01:03 2021 +0100 clk: uniphier: Fix potential infinite loop [ Upstream commit f6b1340dc751a6caa2a0567b667d0f4f4172cd58 ] The for-loop iterates with a u8 loop counter i and compares this with the loop upper limit of num_parents that is an int type. There is a potential infinite loop if num_parents is larger than the u8 loop counter. Fix this by making the loop counter the same type as num_parents. Also make num_parents an unsigned int to match the return type of the call to clk_hw_get_num_parents. Addresses-Coverity: ("Infinite loop") Fixes: 734d82f4a678 ("clk: uniphier: add core support code for UniPhier clock driver") Signed-off-by: Colin Ian King Reviewed-by: Masahiro Yamada Link: https://lore.kernel.org/r/20210409090104.629722-1-colin.king@canonical.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 4fa8634493253c3f8932410a65680f588c7b7e4a Author: Gustavo A. R. Silva Date: Sun Apr 11 21:43:15 2021 +0800 bcache: Use 64-bit arithmetic instead of 32-bit [ Upstream commit 62594f189e81caffa6a3bfa2fdb08eec2e347c76 ] Cast multiple variables to (int64_t) in order to give the compiler complete information about the proper arithmetic to use. Notice that these variables are being used in contexts that expect expressions of type int64_t (64 bit, signed). And currently, such expressions are being evaluated using 32-bit arithmetic. Fixes: d0cf9503e908 ("octeontx2-pf: ethtool fec mode support") Addresses-Coverity-ID: 1501724 ("Unintentional integer overflow") Addresses-Coverity-ID: 1501725 ("Unintentional integer overflow") Addresses-Coverity-ID: 1501726 ("Unintentional integer overflow") Signed-off-by: Gustavo A. R. Silva Signed-off-by: Coly Li Link: https://lore.kernel.org/r/20210411134316.80274-7-colyli@suse.de Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 545195b478a152fa854185a1ea63ed6d843d1239 Author: Yingjie Wang Date: Tue Apr 6 20:10:04 2021 -0700 drm/radeon: Fix a missing check bug in radeon_dp_mst_detect() [ Upstream commit 25315ebfaefcffd126a266116b37bb8a3d1c4620 ] In radeon_dp_mst_detect(), We should check whether or not @connector has been unregistered from userspace. If the connector is unregistered, we should return disconnected status. Fixes: 9843ead08f18 ("drm/radeon: add DisplayPort MST support (v2)") Signed-off-by: Yingjie Wang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 5d4dae4b6277bc39b7da77a7a31cb55828bb0b53 Author: Sefa Eyeoglu Date: Tue Mar 16 22:50:06 2021 +0100 drm/amd/display: check fb of primary plane [ Upstream commit 7df4ceb60fa9a3c5160cfd5b696657291934a2c9 ] Sometimes the primary plane might not be initialized (yet), which causes dm_check_crtc_cursor to divide by zero. Apparently a weird state before a S3-suspend causes the aforementioned divide-by-zero error when resuming from S3. This was explained in bug 212293 on Bugzilla. To avoid this divide-by-zero error we check if the primary plane's fb isn't NULL. If it's NULL the src_w and src_h attributes will be 0, which would cause a divide-by-zero. This fixes Bugzilla report 212293 Bug: https://bugzilla.kernel.org/show_bug.cgi?id=212293 Fixes: 12f4849a1cfd69f3 ("drm/amd/display: check cursor scaling") Reviewed-by: Simon Ser Reviewed-by: Harry Wentland Signed-off-by: Sefa Eyeoglu Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit fb4c0863779ec0edf94fffb8d3986da17b9205fa Author: Nirmoy Das Date: Wed Mar 17 11:38:11 2021 +0100 drm/amd/display: use GFP_ATOMIC in dcn20_resource_construct [ Upstream commit 3bb1105071fb974e3e3ca2f92ddfd69c81285ab6 ] Replace GFP_KERNEL with GFP_ATOMIC as dcn20_resource_construct() can't sleep. Partially fixes: https://bugzilla.kernel.org/show_bug.cgi?id=212311 as dcn20_resource_construct() also calls into SMU functions which does mutex_lock(). Reviewed-by: Harry Wentland Signed-off-by: Nirmoy Das Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 82c27430cab9e33e8f0b06ff53666ed96d69e696 Author: Chen Hui Date: Fri Apr 9 16:23:52 2021 +0800 clk: qcom: apss-ipq-pll: Add missing MODULE_DEVICE_TABLE [ Upstream commit d0a859edda46b45baeab9687d173102300d76e2b ] CONFIG_IPQ_APSS_PLL is tristate option and therefore this driver can be compiled as a module. This patch adds missing MODULE_DEVICE_TABLE definition which generates correct modalias for automatic loading of this driver when it is built as an external module. Fixes: ecd2bacfbbc4 ("clk: qcom: Add ipq apss pll driver") Signed-off-by: Chen Hui Reviewed-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20210409082352.233810-4-clare.chenhui@huawei.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 6b536656197483a778ac566a1242dea17bee1843 Author: Chen Hui Date: Fri Apr 9 16:23:51 2021 +0800 clk: qcom: a53-pll: Add missing MODULE_DEVICE_TABLE [ Upstream commit 790b516ada10a4dcc0f0a56dc0ced475d86d5820 ] CONFIG_QCOM_A53PLL is tristate option and therefore this driver can be compiled as a module. This patch adds missing MODULE_DEVICE_TABLE definition which generates correct modalias for automatic loading of this driver when it is built as an external module. Fixes: 0c6ab1b8f894 ("clk: qcom: Add A53 PLL support") Signed-off-by: Chen Hui Reviewed-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20210409082352.233810-3-clare.chenhui@huawei.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit f7246e5b14e7fe38071892ae851a88f81b5ddf77 Author: Chen Hui Date: Fri Apr 9 16:23:50 2021 +0800 clk: qcom: a7-pll: Add missing MODULE_DEVICE_TABLE [ Upstream commit 77a618b1481f6fdb41b7585ed0f67c47fb8401e5 ] CONFIG_QCOM_A7PLL is tristate option and therefore this driver can be compiled as a module. This patch adds missing MODULE_DEVICE_TABLE definition which generates correct modalias for automatic loading of this driver when it is built as an external module. Fixes: 5a5223ffd7ef ("clk: qcom: Add A7 PLL support") Signed-off-by: Chen Hui Reviewed-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20210409082352.233810-2-clare.chenhui@huawei.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 30a9ab25da0b8d16e7fee88c18f2e2e7313bc730 Author: Jacopo Mondi Date: Fri Mar 19 17:41:39 2021 +0100 media: i2c: rdamc21: Fix warning on u8 cast [ Upstream commit 5f58ac04f36e32507d8f60fd47266ae2a60a2fa8 ] Sparse reports a warning on a cast to u8 of a 16 bits constant. drivers/media/i2c/rdacm21.c:348:62: warning: cast truncates bits from constant value (300a becomes a) Even if the behaviour is intended, silence the sparse warning replacing the cast with a bitwise & operation. Fixes: a59f853b3b4b ("media: i2c: Add driver for RDACM21 camera module") Reported-by: Hans Verkuil Reviewed-by: Kieran Bingham Reviewed-by: Laurent Pinchart Signed-off-by: Jacopo Mondi Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 58a54902ec869b8d051a0a282f252c750c1f33c8 Author: Dan Carpenter Date: Tue Mar 30 12:31:52 2021 +0300 drm: xlnx: zynqmp: fix a memset in zynqmp_dp_train() [ Upstream commit 5842ab76bbfadb37eaea91e53c1efe34ae504e4a ] The dp->train_set[] for this driver is only two characters, not four so this memsets too much. Fortunately, this ends up corrupting a struct hole and not anything important. Fixes: d76271d22694 ("drm: xlnx: DRM/KMS driver for Xilinx ZynqMP DisplayPort Subsystem") Signed-off-by: Dan Carpenter Reviewed-by: Michal Simek Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/YGLwCBMotnrKZu6P@mwanda Signed-off-by: Sasha Levin commit ba158f2fb0c6b7dd40cc515e9667babe423fe0f5 Author: Quanyang Wang Date: Tue Apr 6 23:31:31 2021 +0800 clk: zynqmp: pll: add set_pll_mode to check condition in zynqmp_pll_enable [ Upstream commit 394cdb69a3c30b33524cf1204afe5cceaba69cdc ] If there is a IOCTL_SET_PLL_FRAC_MODE request sent to ATF ever, we shouldn't skip invoking PM_CLOCK_ENABLE fn even though this pll has been enabled. In ATF implementation, it will only assign the mode to the variable (struct pm_pll *)pll->mode when handling IOCTL_SET_PLL_FRAC_MODE call. Invoking PM_CLOCK_ENABLE can force ATF send request to PWU to set the pll mode to PLL's register. There is a scenario that happens in enabling VPLL_INT(clk_id:96): 1) VPLL_INT has been enabled during booting. 2) A driver calls clk_set_rate and according to the rate, the VPLL_INT should be set to FRAC mode. Then zynqmp_pll_set_mode is called to pass IOCTL_SET_PLL_FRAC_MODE to ATF. Note that at this point ATF just stores the mode to a variable. 3) This driver calls clk_prepare_enable and zynqmp_pll_enable is called to try to enable VPLL_INT pll. Because of 1), the function zynqmp_pll_enable just returns without doing anything after checking that this pll has been enabled. In the scenario above, the pll mode of VPLL_INT will never be set successfully. So adding set_pll_mode to check condition to fix it. Fixes: 3fde0e16d016 ("drivers: clk: Add ZynqMP clock driver") Signed-off-by: Quanyang Wang Tested-by: Laurent Pinchart Link: https://lore.kernel.org/r/20210406153131.601701-1-quanyang.wang@windriver.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 8e4e49b0e723b2ba4583320f4e48c1cc86e05015 Author: Quanyang Wang Date: Tue Apr 6 23:40:15 2021 +0800 clk: zynqmp: move zynqmp_pll_set_mode out of round_rate callback [ Upstream commit d7fd3f9f53df8bb2212dff70f66f12cae0e1a653 ] The round_rate callback should only perform rate calculation and not involve calling zynqmp_pll_set_mode to change the pll mode. So let's move zynqmp_pll_set_mode out of round_rate and to set_rate callback. Fixes: 3fde0e16d016 ("drivers: clk: Add ZynqMP clock driver") Reported-by: Laurent Pinchart Signed-off-by: Quanyang Wang Link: https://lore.kernel.org/r/20210406154015.602779-1-quanyang.wang@windriver.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit d2527bb1a700e2ad5023832ad11422a617212acd Author: Jason Gunthorpe Date: Tue Apr 6 16:40:25 2021 -0300 vfio/mdev: Do not allow a mdev_type to have a NULL parent pointer [ Upstream commit b5a1f8921d5040bb788492bf33a66758021e4be5 ] There is a small race where the parent is NULL even though the kobj has already been made visible in sysfs. For instance the attribute_group is made visible in sysfs_create_files() and the mdev_type_attr_show() does: ret = attr->show(kobj, type->parent->dev, buf); Which will crash on NULL parent. Move the parent setup to before the type pointer leaves the stack frame. Fixes: 7b96953bc640 ("vfio: Mediated device Core driver") Reviewed-by: Christoph Hellwig Reviewed-by: Kevin Tian Reviewed-by: Max Gurtovoy Reviewed-by: Cornelia Huck Signed-off-by: Jason Gunthorpe Message-Id: <2-v2-d36939638fc6+d54-vfio2_jgg@nvidia.com> Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit fe1ee6b61c598e5fe9c61e8fec2aac730ec2d3a5 Author: Dmitry Baryshkov Date: Thu Mar 18 13:54:35 2021 +0300 drm/msm/dpu: enable DPU_SSPP_QOS_8LVL for SM8250 [ Upstream commit 095eed898485312f86b7cb593da4f9cd5c43fdb0 ] SM8250 platform has a 8-Levels VIG QoS setting. This setting was missed due to bad interaction with b8dab65b5ac3 ("drm/msm/dpu: Move DPU_SSPP_QOS_8LVL bit to SDM845 and SC7180 masks"), which was applied in parallel. Fixes: d21fc5dfc3df ("drm/msm/dpu1: add support for qseed3lite used on sm8250") Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20210318105435.2011222-1-dmitry.baryshkov@linaro.org Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 5f5f4d297622ca45a0d08d2a0ce7d3094faab524 Author: Rob Clark Date: Wed Mar 31 18:27:20 2021 -0700 drm/msm: Fix debugfs deadlock [ Upstream commit 6ed0897cd800c38b92a33d335d9086c7b092eb15 ] In normal cases the gem obj lock is acquired first before mm_lock. The exception is iterating the various object lists. In the shrinker path, deadlock is avoided by using msm_gem_trylock() and skipping over objects that cannot be locked. But for debugfs the straightforward thing is to split things out into a separate list of all objects protected by it's own lock. Fixes: d984457b31c4 ("drm/msm: Add priv->mm_lock to protect active/inactive lists") Signed-off-by: Rob Clark Tested-by: Douglas Anderson Reviewed-by: Douglas Anderson Link: https://lore.kernel.org/r/20210401012722.527712-4-robdclark@gmail.com Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 6694b8daffac5a8661071f085608afc78f7acd08 Author: Jason Gunthorpe Date: Tue Mar 30 09:53:06 2021 -0600 vfio/pci: Re-order vfio_pci_probe() [ Upstream commit 4aeec3984ddc853f7c65903bde472ffdef738bae ] vfio_add_group_dev() must be called only after all of the private data in vdev is fully setup and ready, otherwise there could be races with user space instantiating a device file descriptor and starting to call ops. For instance vfio_pci_reflck_attach() sets vdev->reflck and vfio_pci_open(), called by fops open, unconditionally derefs it, which will crash if things get out of order. Fixes: cc20d7999000 ("vfio/pci: Introduce VF token") Fixes: e309df5b0c9e ("vfio/pci: Parallelize device open and release") Fixes: 6eb7018705de ("vfio-pci: Move idle devices to D3hot power state") Fixes: ecaa1f6a0154 ("vfio-pci: Add VGA arbiter client") Reviewed-by: Christoph Hellwig Reviewed-by: Max Gurtovoy Reviewed-by: Kevin Tian Reviewed-by: Cornelia Huck Reviewed-by: Eric Auger Signed-off-by: Jason Gunthorpe Message-Id: <8-v3-225de1400dfc+4e074-vfio1_jgg@nvidia.com> Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit cd48042b764bef895b855fff609b38d5957185e6 Author: Jason Gunthorpe Date: Tue Mar 30 09:53:06 2021 -0600 vfio/pci: Move VGA and VF initialization to functions [ Upstream commit 61e90817482871b614133c0f20feb1aba2faec86 ] vfio_pci_probe() is quite complicated, with optional VF and VGA sub components. Move these into clear init/uninit functions and have a linear flow in probe/remove. This fixes a few little buglets: - vfio_pci_remove() is in the wrong order, vga_client_register() removes a notifier and is after kfree(vdev), but the notifier refers to vdev, so it can use after free in a race. - vga_client_register() can fail but was ignored Organize things so destruction order is the reverse of creation order. Fixes: ecaa1f6a0154 ("vfio-pci: Add VGA arbiter client") Reviewed-by: Christoph Hellwig Reviewed-by: Kevin Tian Reviewed-by: Max Gurtovoy Reviewed-by: Cornelia Huck Reviewed-by: Eric Auger Signed-off-by: Jason Gunthorpe Message-Id: <7-v3-225de1400dfc+4e074-vfio1_jgg@nvidia.com> Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit d63e156085ac0bc7ece0d709ede19706229dbce6 Author: Jason Gunthorpe Date: Tue Mar 30 09:53:06 2021 -0600 vfio/fsl-mc: Re-order vfio_fsl_mc_probe() [ Upstream commit 2b1fe162e584a88ec7f12a651a2a50f94dd8cfac ] vfio_add_group_dev() must be called only after all of the private data in vdev is fully setup and ready, otherwise there could be races with user space instantiating a device file descriptor and starting to call ops. For instance vfio_fsl_mc_reflck_attach() sets vdev->reflck and vfio_fsl_mc_open(), called by fops open, unconditionally derefs it, which will crash if things get out of order. This driver started life with the right sequence, but two commits added stuff after vfio_add_group_dev(). Fixes: 2e0d29561f59 ("vfio/fsl-mc: Add irq infrastructure for fsl-mc devices") Fixes: f2ba7e8c947b ("vfio/fsl-mc: Added lock support in preparation for interrupt handling") Co-developed-by: Diana Craciun OSS Signed-off-by: Jason Gunthorpe Message-Id: <5-v3-225de1400dfc+4e074-vfio1_jgg@nvidia.com> Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit 4d285d8a767f6e770d2262b9e4f6e06d16ce5bf0 Author: Daniel Almeida Date: Tue Mar 23 19:57:09 2021 +0100 media: rkvdec: Do not require all controls to be present in every request [ Upstream commit 54676d5f5630b79f7b00c7c43882a58c1815aaf9 ] According to the v4l2 api, it is allowed to skip setting a control if its contents haven't changed for performance reasons: userspace should only update the controls that changed from last frame rather then updating them all. Still some ancient code that checks for mandatory controls has been left in this driver. Remove it. Fixes: cd33c830448b ("media: rkvdec: Add the rkvdec driver") Signed-off-by: Daniel Almeida Reviewed-by: Ezequiel Garcia Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit bde1744150a44a3486cac1f6bbfe335e030b57f1 Author: Hans Verkuil Date: Sat Mar 27 12:27:40 2021 +0100 media: v4l2-ctrls.c: fix race condition in hdl->requests list [ Upstream commit be7e8af98f3af729aa9f08b1053f9533a5cceb91 ] When a request is re-inited it will release all control handler objects that are still in the request. It does that by unbinding and putting all those objects. When the object is unbound the obj->req pointer is set to NULL, and the object's unbind op is called. When the object it put the object's release op is called to free the memory. For a request object that contains a control handler that means that v4l2_ctrl_handler_free() is called in the release op. A control handler used in a request has a pointer to the main control handler that is created by the driver and contains the current state of all controls. If the device is unbound (due to rmmod or a forced unbind), then that main handler is freed, again by calling v4l2_ctrl_handler_free(), and any outstanding request objects that refer to that main handler have to be unbound and put as well. It does that by this test: if (!hdl->req_obj.req && !list_empty(&hdl->requests)) { I.e. the handler has no pointer to a request, so is the main handler, and one or more request objects refer to this main handler. However, this test is wrong since hdl->req_obj.req is actually NULL when re-initing a request (the object unbind will set req to NULL), and the only reason this seemingly worked is that the requests list is typically empty since the request's unbind op will remove the handler from the requests list. But if another thread is at the same time adding a new control to a request, then there is a race condition where one thread is removing a control handler object from the requests list and another thread is adding one. The result is that hdl->requests is no longer empty and the code thinks that a main handler is being freed instead of a control handler that is part of a request. There are two bugs here: first the test for hdl->req_obj.req: this should be hdl->req_obj.ops since only the main control handler will have a NULL pointer there. The second is that adding or deleting request objects from the requests list of the main handler isn't protected by taking the main handler's lock. Signed-off-by: Hans Verkuil Reported-by: John Cox Fixes: 6fa6f831f095 ("media: v4l2-ctrls: add core request support") Tested-by: John Cox Reported-by: John Cox Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 8620674de11d59f56faf860e2730acb01cf70f7e Author: Lad Prabhakar Date: Thu Mar 11 10:52:05 2021 +0100 media: i2c: imx219: Balance runtime PM use-count [ Upstream commit dd90caa0111e178b52b21e56364bc2244a3973b3 ] Move incrementing/decrementing runtime PM count to imx219_start_streaming()/imx219_stop_streaming() functions respectively. This fixes an issue of unbalanced runtime PM count in resume callback error path where streaming is stopped and runtime PM count is left unbalanced. Fixes: 1283b3b8f82b9 ("media: i2c: Add driver for Sony IMX219 sensor") Reported-by: Pavel Machek Signed-off-by: Lad Prabhakar Reviewed-by: Laurent Pinchart Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 5ea9d36e03f68b26ee75d19c5ec0e443d401eacf Author: Lad Prabhakar Date: Thu Mar 11 10:52:04 2021 +0100 media: i2c: imx219: Move out locking/unlocking of vflip and hflip controls from imx219_set_stream [ Upstream commit 745d4612d2c853c00abadbf69799c8aee7f99c39 ] Move out locking/unlocking of vflip and hflip controls from imx219_set_stream() to the imx219_start_streaming()/ imx219_stop_streaming() respectively. This fixes an issue in resume callback error path where streaming is stopped and the controls are left in locked state. Fixes: 1283b3b8f82b9 ("media: i2c: Add driver for Sony IMX219 sensor") Reported-by: Pavel Machek Signed-off-by: Lad Prabhakar Reviewed-by: Laurent Pinchart Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 762e2b204fd939ed90aed9fae682d80244ae8798 Author: Sakari Ailus Date: Mon Feb 15 08:55:12 2021 +0100 media: ipu3-cio2: Fix pixel-rate derived link frequency [ Upstream commit a7de6eac6f6f73d48d97a6c93032107775f4593b ] The driver uses v4l2_get_link_freq() helper to obtain the link frequency using the LINK_FREQ but also the PIXEL_RATE control. The divisor for the pixel rate derived link frequency was wrong, missing the bus uses double data rate. Fix this. Reported-by: Laurent Pinchart Fixes: 4b6c129e87a3 ("media: ipu3-cio2: Use v4l2_get_link_freq helper") Signed-off-by: Sakari Ailus Reviewed-by: Laurent Pinchart Reviewed-by: Bingbu Cao Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 7e101ec9c8b0fe066965911b7fdc94101280b0e6 Author: Sakari Ailus Date: Tue Jan 5 15:21:11 2021 +0100 media: ccs: Fix sub-device function [ Upstream commit 8c43126e8c9f0990fa75fb5219c03b20d5ead7b7 ] Fix sub-device function for the pixel array and the scaler. It seems that the pixel array had gotten assigned as SCALER whereas the scaler had CAM_SENSOR function. Fix this by setting the pixel array function to CAM_SENSOR and that of scaler to SCALER. Fixes: 9ec2ac9bd0f9 ("media: ccs: Give all subdevs a function") Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 1b71d5587fa7c794031a5bf2830dc1af892a26ca Author: Hannes Reinecke Date: Sat Dec 5 16:29:01 2020 +0100 nvme: retrigger ANA log update if group descriptor isn't found [ Upstream commit dd8f7fa908f66dd44abcd83cbb50410524b9f8ef ] If ANA is enabled but no ANA group descriptor is found when creating a new namespace the ANA log is most likely out of date, so trigger a re-read. The namespace will be tagged with the NS_ANA_PENDING flag to exclude it from path selection until the ANA log has been re-read. Fixes: 32acab3181c7 ("nvme: implement multipath access to nvme subsystems") Reported-by: Martin George Signed-off-by: Hannes Reinecke Reviewed-by: Keith Busch Reviewed-by: Sagi Grimberg Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 59c2459bc180a2e4be57dac5ee9219074f069de4 Author: Ricardo Rivera-Matos Date: Wed Feb 10 16:56:46 2021 -0600 power: supply: bq25980: Move props from battery node [ Upstream commit 04722cec1436c732d39153ce6ae2ebf71ac3ade7 ] Currently POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT and POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE are exposed on the battery node and this is incorrect. This patch exposes both of them on the charger node rather than the battery node. Fixes: 5069185fc18e ("power: supply: bq25980: Add support for the BQ259xx family") Signed-off-by: Ricardo Rivera-Matos Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 81e4bfac2a49e30cd98802dc841fe028e75e0eb2 Author: Adam Ford Date: Sat Mar 13 06:28:17 2021 -0600 clk: imx: Fix reparenting of UARTs not associated with stdout [ Upstream commit 379c9a24cc239000b1dec53db02fe17a86947423 ] Most if not all i.MX SoC's call a function which enables all UARTS. This is a problem for users who need to re-parent the clock source, because any attempt to change the parent results in an busy error due to the fact that the clocks have been enabled already. clk: failed to reparent uart1 to sys_pll1_80m: -16 Instead of pre-initializing all UARTS, scan the device tree to see which UART clocks are associated to stdout, and only enable those UART clocks if it's needed early. This will move initialization of the remaining clocks until after the parenting of the clocks. When the clocks are shutdown, this mechanism will also disable any clocks that were pre-initialized. Fixes: 9461f7b33d11c ("clk: fix CLK_SET_RATE_GATE with clock rate protection") Suggested-by: Aisheng Dong Signed-off-by: Adam Ford Reviewed-by: Abel Vesa Tested-by: Ahmad Fatoum Signed-off-by: Abel Vesa Signed-off-by: Sasha Levin commit 906c538340dde6d891df89fe7dac8eaa724e40da Author: Sagi Grimberg Date: Sun Mar 21 00:08:49 2021 -0700 nvmet-tcp: fix incorrect locking in state_change sk callback [ Upstream commit b5332a9f3f3d884a1b646ce155e664cc558c1722 ] We are not changing anything in the TCP connection state so we should not take a write_lock but rather a read lock. This caused a deadlock when running nvmet-tcp and nvme-tcp on the same system, where state_change callbacks on the host and on the controller side have causal relationship and made lockdep report on this with blktests: ================================ WARNING: inconsistent lock state 5.12.0-rc3 #1 Tainted: G I -------------------------------- inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-R} usage. nvme/1324 [HC0[0]:SC0[0]:HE1:SE1] takes: ffff888363151000 (clock-AF_INET){++-?}-{2:2}, at: nvme_tcp_state_change+0x21/0x150 [nvme_tcp] {IN-SOFTIRQ-W} state was registered at: __lock_acquire+0x79b/0x18d0 lock_acquire+0x1ca/0x480 _raw_write_lock_bh+0x39/0x80 nvmet_tcp_state_change+0x21/0x170 [nvmet_tcp] tcp_fin+0x2a8/0x780 tcp_data_queue+0xf94/0x1f20 tcp_rcv_established+0x6ba/0x1f00 tcp_v4_do_rcv+0x502/0x760 tcp_v4_rcv+0x257e/0x3430 ip_protocol_deliver_rcu+0x69/0x6a0 ip_local_deliver_finish+0x1e2/0x2f0 ip_local_deliver+0x1a2/0x420 ip_rcv+0x4fb/0x6b0 __netif_receive_skb_one_core+0x162/0x1b0 process_backlog+0x1ff/0x770 __napi_poll.constprop.0+0xa9/0x5c0 net_rx_action+0x7b3/0xb30 __do_softirq+0x1f0/0x940 do_softirq+0xa1/0xd0 __local_bh_enable_ip+0xd8/0x100 ip_finish_output2+0x6b7/0x18a0 __ip_queue_xmit+0x706/0x1aa0 __tcp_transmit_skb+0x2068/0x2e20 tcp_write_xmit+0xc9e/0x2bb0 __tcp_push_pending_frames+0x92/0x310 inet_shutdown+0x158/0x300 __nvme_tcp_stop_queue+0x36/0x270 [nvme_tcp] nvme_tcp_stop_queue+0x87/0xb0 [nvme_tcp] nvme_tcp_teardown_admin_queue+0x69/0xe0 [nvme_tcp] nvme_do_delete_ctrl+0x100/0x10c [nvme_core] nvme_sysfs_delete.cold+0x8/0xd [nvme_core] kernfs_fop_write_iter+0x2c7/0x460 new_sync_write+0x36c/0x610 vfs_write+0x5c0/0x870 ksys_write+0xf9/0x1d0 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae irq event stamp: 10687 hardirqs last enabled at (10687): [] _raw_spin_unlock_irqrestore+0x2d/0x40 hardirqs last disabled at (10686): [] _raw_spin_lock_irqsave+0x68/0x90 softirqs last enabled at (10684): [] __do_softirq+0x608/0x940 softirqs last disabled at (10649): [] do_softirq+0xa1/0xd0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(clock-AF_INET); lock(clock-AF_INET); *** DEADLOCK *** 5 locks held by nvme/1324: #0: ffff8884a01fe470 (sb_writers#4){.+.+}-{0:0}, at: ksys_write+0xf9/0x1d0 #1: ffff8886e435c090 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x216/0x460 #2: ffff888104d90c38 (kn->active#255){++++}-{0:0}, at: kernfs_remove_self+0x22d/0x330 #3: ffff8884634538d0 (&queue->queue_lock){+.+.}-{3:3}, at: nvme_tcp_stop_queue+0x52/0xb0 [nvme_tcp] #4: ffff888363150d30 (sk_lock-AF_INET){+.+.}-{0:0}, at: inet_shutdown+0x59/0x300 stack backtrace: CPU: 26 PID: 1324 Comm: nvme Tainted: G I 5.12.0-rc3 #1 Hardware name: Dell Inc. PowerEdge R640/06NR82, BIOS 2.10.0 11/12/2020 Call Trace: dump_stack+0x93/0xc2 mark_lock_irq.cold+0x2c/0xb3 ? verify_lock_unused+0x390/0x390 ? stack_trace_consume_entry+0x160/0x160 ? lock_downgrade+0x100/0x100 ? save_trace+0x88/0x5e0 ? _raw_spin_unlock_irqrestore+0x2d/0x40 mark_lock+0x530/0x1470 ? mark_lock_irq+0x1d10/0x1d10 ? enqueue_timer+0x660/0x660 mark_usage+0x215/0x2a0 __lock_acquire+0x79b/0x18d0 ? tcp_schedule_loss_probe.part.0+0x38c/0x520 lock_acquire+0x1ca/0x480 ? nvme_tcp_state_change+0x21/0x150 [nvme_tcp] ? rcu_read_unlock+0x40/0x40 ? tcp_mtu_probe+0x1ae0/0x1ae0 ? kmalloc_reserve+0xa0/0xa0 ? sysfs_file_ops+0x170/0x170 _raw_read_lock+0x3d/0xa0 ? nvme_tcp_state_change+0x21/0x150 [nvme_tcp] nvme_tcp_state_change+0x21/0x150 [nvme_tcp] ? sysfs_file_ops+0x170/0x170 inet_shutdown+0x189/0x300 __nvme_tcp_stop_queue+0x36/0x270 [nvme_tcp] nvme_tcp_stop_queue+0x87/0xb0 [nvme_tcp] nvme_tcp_teardown_admin_queue+0x69/0xe0 [nvme_tcp] nvme_do_delete_ctrl+0x100/0x10c [nvme_core] nvme_sysfs_delete.cold+0x8/0xd [nvme_core] kernfs_fop_write_iter+0x2c7/0x460 new_sync_write+0x36c/0x610 ? new_sync_read+0x600/0x600 ? lock_acquire+0x1ca/0x480 ? rcu_read_unlock+0x40/0x40 ? lock_is_held_type+0x9a/0x110 vfs_write+0x5c0/0x870 ksys_write+0xf9/0x1d0 ? __ia32_sys_read+0xa0/0xa0 ? lockdep_hardirqs_on_prepare.part.0+0x198/0x340 ? syscall_enter_from_user_mode+0x27/0x70 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae Fixes: 872d26a391da ("nvmet-tcp: add NVMe over TCP target driver") Reported-by: Yi Zhang Signed-off-by: Sagi Grimberg Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit c7dee3feee3fdbca68235e4e6041edd6e7ed65c7 Author: Sagi Grimberg Date: Sun Mar 21 00:08:48 2021 -0700 nvme-tcp: block BH in sk state_change sk callback [ Upstream commit 8b73b45d54a14588f86792869bfb23098ea254cb ] The TCP stack can run from process context for a long time so we should disable BH here. Fixes: 3f2304f8c6d6 ("nvme-tcp: add NVMe over TCP host driver") Signed-off-by: Sagi Grimberg Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit f0240a9cac40a945a28bf067b7bea1447d74d094 Author: Dafna Hirschfeld Date: Tue Mar 30 13:09:02 2021 +0200 drm/mediatek: Don't support hdmi connector creation [ Upstream commit 2e477391522354e763aa62ee3e281c1ad9e8eb1b ] commit f01195148967 ("drm/mediatek: mtk_dpi: Create connector for bridges") broke the display support for elm device since mtk_dpi calls drm_bridge_attach with the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR while mtk_hdmi does not yet support this flag. Fix this by accepting DRM_BRIDGE_ATTACH_NO_CONNECTOR in bridge attachment. Implement the drm_bridge_funcs .detect() and .get_edid() operations, and call drm_bridge_hpd_notify() to report HPD. This provides the necessary API to support disabling connector creation. In addition, the field 'conn' is removed from the mtk_hdmi struct since mtk_hdmi don't create a connector. It is replaced with a pointer 'curr_conn' that points to the current connector which can be access through the global state. This patch is inspired by a similar patch for bridge/synopsys/dw-hdmi.c: commit ec971aaa6775 ("drm: bridge: dw-hdmi: Make connector creation optional") But with the difference that in mtk-hdmi only the option of not creating a connector is supported. Fixes: f01195148967 ("drm/mediatek: mtk_dpi: Create connector for bridges") Signed-off-by: Dafna Hirschfeld Reviewed-by: Laurent Pinchart Signed-off-by: Chun-Kuang Hu Signed-off-by: Sasha Levin commit bb995c38e42a649e1a5c77a45a2f2e51919dceb7 Author: Dafna Hirschfeld Date: Tue Mar 30 13:09:01 2021 +0200 drm/mediatek: Switch the hdmi bridge ops to the atomic versions [ Upstream commit 053d231f369ca05cd563ca9738b5a4c73908e697 ] The bridge operation '.enable' and the audio cb '.get_eld' access hdmi->conn. In the future we will want to support the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR and then we will not have direct access to the connector. The atomic version '.atomic_enable' allows accessing the current connector from the state. This patch switches the bridge to the atomic version to prepare access to the connector in later patches. Signed-off-by: Dafna Hirschfeld Reviewed-by: Laurent Pinchart Signed-off-by: Chun-Kuang Hu Signed-off-by: Sasha Levin commit 61e93fa3f3ed42cbc2532428c51aa62be975f94e Author: Kenta.Tada@sony.com Date: Sun Mar 21 15:52:19 2021 +0000 seccomp: Fix CONFIG tests for Seccomp_filters [ Upstream commit 64bdc0244054f7d4bb621c8b4455e292f4e421bc ] Strictly speaking, seccomp filters are only used when CONFIG_SECCOMP_FILTER. This patch fixes the condition to enable "Seccomp_filters" in /proc/$pid/status. Signed-off-by: Kenta Tada Fixes: c818c03b661c ("seccomp: Report number of loaded filters in /proc/$pid/status") Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/OSBPR01MB26772D245E2CF4F26B76A989F5669@OSBPR01MB2677.jpnprd01.prod.outlook.com Signed-off-by: Sasha Levin commit 79476f1fe410d52831a964473f15473a06b69fa0 Author: Sergey Shtylyov Date: Mon Mar 15 23:15:06 2021 +0300 ata: libahci_platform: fix IRQ check [ Upstream commit b30d0040f06159de97ad9c0b1536f47250719d7d ] Iff platform_get_irq() returns 0, ahci_platform_init_host() would return 0 early (as if the call was successful). Override IRQ0 with -EINVAL instead as the 'libata' regards 0 as "no IRQ" (thus polling) anyway... Fixes: c034640a32f8 ("ata: libahci: properly propagate return value of platform_get_irq()") Signed-off-by: Sergey Shtylyov Link: https://lore.kernel.org/r/4448c8cc-331f-2915-0e17-38ea34e251c8@omprussia.ru Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 5b695910d760584cc87feb24fb793c464e21717f Author: Sergey Shtylyov Date: Sun Mar 28 00:13:49 2021 +0300 sata_mv: add IRQ checks [ Upstream commit e6471a65fdd5efbb8dd2732dd0f063f960685ceb ] The function mv_platform_probe() neglects to check the results of the calls to platform_get_irq() and irq_of_parse_and_map() and blithely passes them to ata_host_activate() -- while the latter only checks for IRQ0 (treating it as a polling mode indicattion) and passes the negative values to devm_request_irq() causing it to fail as it takes unsigned values for the IRQ #... Add to mv_platform_probe() the proper IRQ checks to pass the positive IRQ #s to ata_host_activate(), propagate upstream the negative error codes, and override the IRQ0 with -EINVAL (as we don't want the polling mode). Fixes: f351b2d638c3 ("sata_mv: Support SoC controllers") Signed-off-by: Sergey Shtylyov Link: https://lore.kernel.org/r/51436f00-27a1-e20b-c21b-0e817e0a7c86@omprussia.ru Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 581f6ba4fe7fa4663302e3efd4f8cc28f695c0b7 Author: Sergey Shtylyov Date: Thu Mar 25 23:51:10 2021 +0300 pata_ipx4xx_cf: fix IRQ check [ Upstream commit e379b40cc0f179403ce0b82b7e539f635a568da5 ] The driver's probe() method is written as if platform_get_irq() returns 0 on error, while actually it returns a negative error code (with all the other values considered valid IRQs). Rewrite the driver's IRQ checking code to pass the positive IRQ #s to ata_host_activate(), propagate errors upstream, and treat IRQ0 as error, returning -EINVAL, as the libata code treats 0 as an indication that polling should be used anyway... Fixes: 0df0d0a0ea9f ("[libata] ARM: add ixp4xx PATA driver") Signed-off-by: Sergey Shtylyov Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 5b7b835e3fe33fa93d8025c95ec2372f46578e30 Author: Sergey Shtylyov Date: Thu Mar 25 23:50:24 2021 +0300 pata_arasan_cf: fix IRQ check [ Upstream commit c7e8f404d56b99c80990b19a402c3f640d74be05 ] The driver's probe() method is written as if platform_get_irq() returns 0 on error, while actually it returns a negative error code (with all the other values considered valid IRQs). Rewrite the driver's IRQ checking code to pass the positive IRQ #s to ata_host_activate(), propagate upstream -EPROBE_DEFER, and set up the driver to polling mode on (negative) errors and IRQ0 (libata treats IRQ #0 as a polling mode anyway)... Fixes: a480167b23ef ("pata_arasan_cf: Adding support for arasan compact flash host controller") Signed-off-by: Sergey Shtylyov Acked-by: Viresh Kumar Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 1be17895150c56f3bed508da8c431c7e29165ef9 Author: Ilya Leoshkevich Date: Wed Mar 3 01:44:20 2021 +0100 selftests: fix prepending $(OUTPUT) to $(TEST_PROGS) [ Upstream commit cb4969e6f9f5ee12521aec764fa3d4bbd91bc797 ] Currently the following command produces an error message: linux# make kselftest TARGETS=bpf O=/mnt/linux-build # selftests: bpf: test_libbpf.sh # ./test_libbpf.sh: line 23: ./test_libbpf_open: No such file or directory # test_libbpf: failed at file test_l4lb.o # selftests: test_libbpf [FAILED] The error message might not affect the return code of make, therefore one needs to grep make output in order to detect it. This is not the only instance of the same underlying problem; any test with more than one element in $(TEST_PROGS) fails the same way. Another example: linux# make O=/mnt/linux-build TARGETS=splice kselftest [...] # ./short_splice_read.sh: 15: ./splice_read: not found # FAIL: /sys/module/test_module/sections/.init.text 2 not ok 2 selftests: splice: short_splice_read.sh # exit=1 The current logic prepends $(OUTPUT) only to the first member of $(TEST_PROGS). After that, run_one() does cd `dirname $TEST` For all tests except the first one, `dirname $TEST` is ., which means they cannot access the files generated in $(OUTPUT). Fix by using $(addprefix) to prepend $(OUTPUT)/ to each member of $(TEST_PROGS). Fixes: 1a940687e424 ("selftests: lib.mk: copy test scripts and test files for make O=dir run") Signed-off-by: Ilya Leoshkevich Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 50798f4232d7e0643c4841112390ae3214431a9b Author: Yang Li Date: Tue Mar 23 17:34:53 2021 +0800 drm/omap: dsi: Add missing IRQF_ONESHOT [ Upstream commit 0cafc8d88e6df446751669ec15adc9b807af4501 ] fixed the following coccicheck: ./drivers/gpu/drm/omapdrm/dss/dsi.c:4329:7-27: ERROR: Threaded IRQ with no primary handler requested without IRQF_ONESHOT Reported-by: Abaci Robot Signed-off-by: Yang Li Reviewed-by: Sebastian Reichel Fixes: 4c1b935fea54 ("drm/omap: dsi: move TE GPIO handling into core") Signed-off-by: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/1616492093-68237-1-git-send-email-yang.lee@linux.alibaba.com Signed-off-by: Sasha Levin commit 5489d7355ec7b02091a3dfcc95a01cda1c015730 Author: Masami Hiramatsu Date: Thu Mar 25 19:08:31 2021 +0900 x86/kprobes: Fix to check non boostable prefixes correctly [ Upstream commit 6dd3b8c9f58816a1354be39559f630cd1bd12159 ] There are 2 bugs in the can_boost() function because of using x86 insn decoder. Since the insn->opcode never has a prefix byte, it can not find CS override prefix in it. And the insn->attr is the attribute of the opcode, thus inat_is_address_size_prefix( insn->attr) always returns false. Fix those by checking each prefix bytes with for_each_insn_prefix loop and getting the correct attribute for each prefix byte. Also, this removes unlikely, because this is a slow path. Fixes: a8d11cd0714f ("kprobes/x86: Consolidate insn decoder users for copying code") Signed-off-by: Masami Hiramatsu Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/161666691162.1120877.2808435205294352583.stgit@devnote2 Signed-off-by: Sasha Levin commit 71356449c216716d0f081d301811d7bfad714a7a Author: Bart Van Assche Date: Sat Mar 20 16:23:59 2021 -0700 scsi: qla2xxx: Check kzalloc() return value [ Upstream commit e5406d8ad4a1659f4d4d1b39fe203855c4eaef2d ] Instead of crashing if kzalloc() fails, make qla2x00_get_host_stats() return -ENOMEM. Link: https://lore.kernel.org/r/20210320232359.941-8-bvanassche@acm.org Fixes: dbf1f53cfd23 ("scsi: qla2xxx: Implementation to get and manage host, target stats and initiator port") Cc: Himanshu Madhani Cc: Saurav Kashyap Cc: Nilesh Javali Cc: Quinn Tran Cc: Mike Christie Cc: Daniel Wagner Cc: Lee Duncan Reviewed-by: Daniel Wagner Reviewed-by: Himanshu Madhani Acked-by: Saurav Kashyap Signed-off-by: Bart Van Assche Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 394374bedbbafdcb42b46f4706d321a7506e5388 Author: kernel test robot Date: Mon Mar 22 19:21:39 2021 +0100 of: overlay: fix for_each_child.cocci warnings [ Upstream commit c4d74f0f978ed5ceee62cd3f6708081042e582a1 ] Function "for_each_child_of_node" should have of_node_put() before goto. Generated by: scripts/coccinelle/iterators/for_each_child.cocci Fixes: 82c2d81361ec ("coccinelle: iterators: Add for_each_child.cocci script") CC: Sumera Priyadarsini Reported-by: kernel test robot Signed-off-by: kernel test robot Signed-off-by: Julia Lawall Reviewed-by: Frank Rowand Tested-by: Frank Rowand Link: https://lore.kernel.org/r/alpine.DEB.2.22.394.2103221918450.2918@hadrien Signed-off-by: Rob Herring Signed-off-by: Sasha Levin commit 296443139f893b554dddd56a99ba8471ab5802d4 Author: Victor Lu Date: Thu Mar 11 13:00:20 2021 -0500 drm/amd/display: Free local data after use [ Upstream commit 616cf23b6cf40ad6f03ffbddfa1b6c4eb68d8ae1 ] Fixes the following memory leak in dc_link_construct(): unreferenced object 0xffffa03e81471400 (size 1024): comm "amd_module_load", pid 2486, jiffies 4294946026 (age 10.544s) 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 00 00 00 00 ................ backtrace: [<000000000bdf5c4a>] kmem_cache_alloc_trace+0x30a/0x4a0 [<00000000e7c59f0e>] link_create+0xce/0xac0 [amdgpu] [<000000002fb6c072>] dc_create+0x370/0x720 [amdgpu] [<000000000094d1f3>] amdgpu_dm_init+0x18e/0x17a0 [amdgpu] [<00000000bec048fd>] dm_hw_init+0x12/0x20 [amdgpu] [<00000000a2bb7cf6>] amdgpu_device_init+0x1463/0x1e60 [amdgpu] [<0000000032d3bb13>] amdgpu_driver_load_kms+0x5b/0x330 [amdgpu] [<00000000a27834f9>] amdgpu_pci_probe+0x192/0x280 [amdgpu] [<00000000fec7d291>] local_pci_probe+0x47/0xa0 [<0000000055dbbfa7>] pci_device_probe+0xe3/0x180 [<00000000815da970>] really_probe+0x1c4/0x4e0 [<00000000b4b6974b>] driver_probe_device+0x62/0x150 [<000000000f9ecc61>] device_driver_attach+0x58/0x60 [<000000000f65c843>] __driver_attach+0xd6/0x150 [<000000002f5e3683>] bus_for_each_dev+0x6a/0xc0 [<00000000a1cfc897>] driver_attach+0x1e/0x20 Fixes: 3a00c04212d1cf ("drm/amd/display/dc/core/dc_link: Move some local data from the stack to the heap") Signed-off-by: Victor Lu Reviewed-by: Rodrigo Siqueira Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit cef7b9cc0c933c38002e4caf3d78d3c552ff16c5 Author: Felix Kuehling Date: Wed Mar 10 21:42:01 2021 -0500 drm/amdkfd: Fix recursive lock warnings [ Upstream commit 7816e4a98ce3bc7c562807240b4f14171e177420 ] memalloc_nofs_save/restore are no longer sufficient to prevent recursive lock warnings when holding locks that can be taken in MMU notifiers. Use memalloc_noreclaim_save/restore instead. Fixes: f920e413ff9c ("mm: track mmu notifiers in fs_reclaim_acquire/release") Signed-off-by: Felix Kuehling Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 220fe3b0f124e991457a17f78a706b330463f2dd Author: Felix Kuehling Date: Mon Mar 8 22:15:42 2021 -0500 drm/amdkfd: fix build error with AMD_IOMMU_V2=m [ Upstream commit 1e87068570a2cc4db5f95a881686add71729e769 ] Using 'imply AMD_IOMMU_V2' does not guarantee that the driver can link against the exported functions. If the GPU driver is built-in but the IOMMU driver is a loadable module, the kfd_iommu.c file is indeed built but does not work: x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function `kfd_iommu_bind_process_to_device': kfd_iommu.c:(.text+0x516): undefined reference to `amd_iommu_bind_pasid' x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function `kfd_iommu_unbind_process': kfd_iommu.c:(.text+0x691): undefined reference to `amd_iommu_unbind_pasid' x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function `kfd_iommu_suspend': kfd_iommu.c:(.text+0x966): undefined reference to `amd_iommu_set_invalidate_ctx_cb' x86_64-linux-ld: kfd_iommu.c:(.text+0x97f): undefined reference to `amd_iommu_set_invalid_ppr_cb' x86_64-linux-ld: kfd_iommu.c:(.text+0x9a4): undefined reference to `amd_iommu_free_device' x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function `kfd_iommu_resume': kfd_iommu.c:(.text+0xa9a): undefined reference to `amd_iommu_init_device' x86_64-linux-ld: kfd_iommu.c:(.text+0xadc): undefined reference to `amd_iommu_set_invalidate_ctx_cb' x86_64-linux-ld: kfd_iommu.c:(.text+0xaff): undefined reference to `amd_iommu_set_invalid_ppr_cb' x86_64-linux-ld: kfd_iommu.c:(.text+0xc72): undefined reference to `amd_iommu_bind_pasid' x86_64-linux-ld: kfd_iommu.c:(.text+0xe08): undefined reference to `amd_iommu_set_invalidate_ctx_cb' x86_64-linux-ld: kfd_iommu.c:(.text+0xe26): undefined reference to `amd_iommu_set_invalid_ppr_cb' x86_64-linux-ld: kfd_iommu.c:(.text+0xe42): undefined reference to `amd_iommu_free_device' Use IS_REACHABLE to only build IOMMU-V2 support if the amd_iommu symbols are reachable by the amdkfd driver. Output a warning if they are not, because that may not be what the user was expecting. Fixes: 64d1c3a43a6f ("drm/amdkfd: Centralize IOMMUv2 code and make it conditional") Reported-by: Arnd Bergmann Signed-off-by: Felix Kuehling Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 683200c61ca1b2cf8629337d3a8921d3d2cbb2f7 Author: Masami Hiramatsu Date: Wed Mar 3 00:25:24 2021 +0900 x86/kprobes: Retrieve correct opcode for group instruction [ Upstream commit d60ad3d46f1d04a282c56159f1deb675c12733fd ] Since the opcodes start from 0xff are group5 instruction group which is not 2 bytes opcode but the extended opcode determined by the MOD/RM byte. The commit abd82e533d88 ("x86/kprobes: Do not decode opcode in resume_execution()") used insn->opcode.bytes[1], but that is not correct. We have to refer the insn->modrm.bytes[1] instead. Fixes: abd82e533d88 ("x86/kprobes: Do not decode opcode in resume_execution()") Signed-off-by: Masami Hiramatsu Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/161469872400.49483.18214724458034233166.stgit@devnote2 Signed-off-by: Sasha Levin commit 8267ccd7b9df7ab682043507dd682fe0621cf045 Author: Dan Carpenter Date: Mon Dec 14 12:53:31 2020 +0100 media: atomisp: Fix use after free in atomisp_alloc_css_stat_bufs() [ Upstream commit ba11bbf303fafb33989e95473e409f6ab412b18d ] The "s3a_buf" is freed along with all the other items on the "asd->s3a_stats" list. It leads to a double free and a use after free. Link: https://lore.kernel.org/linux-media/X9dSO3RGf7r0pq2k@mwanda Fixes: ad85094b293e ("Revert "media: staging: atomisp: Remove driver"") Signed-off-by: Dan Carpenter Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit ac97be09d46f1a4e8a8d7601ce699d667b54200c Author: Colin Ian King Date: Wed Oct 7 14:16:28 2020 +0200 media: m88rs6000t: avoid potential out-of-bounds reads on arrays [ Upstream commit 9baa3d64e8e2373ddd11c346439e5dfccb2cbb0d ] There a 3 array for-loops that don't check the upper bounds of the index into arrays and this may lead to potential out-of-bounds reads. Fix this by adding array size upper bounds checks to be full safe. Addresses-Coverity: ("Out-of-bounds read") Link: https://lore.kernel.org/linux-media/20201007121628.20676-1-colin.king@canonical.com Fixes: 333829110f1d ("[media] m88rs6000t: add new dvb-s/s2 tuner for integrated chip M88RS6000") Signed-off-by: Colin Ian King Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 5cd0f16bc44fbae2d22c8b36eba291fa733de194 Author: Souptick Joarder Date: Sun Sep 27 17:08:04 2020 +0200 media: atomisp: Fixed error handling path [ Upstream commit 16a5dcf7fbc2f5cd10c1e6264262bfa3832fb7d5 ] Inside alloc_user_pages() based on flag value either pin_user_pages() or get_user_pages_fast() will be called. However, these API might fail. But free_user_pages() called in error handling path doesn't bother about return value and will try to unpin bo->pgnr pages, which is incorrect. Fix this by passing the page_nr to free_user_pages(). If page_nr > 0 pages will be unpinned based on bo->mem_type. This will also take care of non error handling path. allocation") Link: https://lore.kernel.org/linux-media/1601219284-13275-1-git-send-email-jrdr.linux@gmail.com Fixes: 14a638ab96c5 ("media: atomisp: use pin_user_pages() for memory Signed-off-by: Souptick Joarder Cc: John Hubbard Cc: Ira Weiny Reviewed-by: Dan Carpenter Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 27d2eab69f7da8e94e4751ac5c6d22d809275484 Author: Colin Ian King Date: Wed Sep 2 18:58:52 2020 +0200 media: [next] staging: media: atomisp: fix memory leak of object flash [ Upstream commit 6045b01dd0e3cd3759eafe7f290ed04c957500b1 ] In the case where the call to lm3554_platform_data_func returns an error there is a memory leak on the error return path of object flash. Fix this by adding an error return path that will free flash and rename labels fail2 to fail3 and fail1 to fail2. Link: https://lore.kernel.org/linux-media/20200902165852.201155-1-colin.king@canonical.com Fixes: 9289cdf39992 ("staging: media: atomisp: Convert to GPIO descriptors") Signed-off-by: Colin Ian King Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit a44db63cc56e91f07bc71cdeee0a4aa99044d89e Author: Liu Ying Date: Thu Mar 11 06:53:47 2021 +0100 media: docs: Fix data organization of MEDIA_BUS_FMT_RGB101010_1X30 [ Upstream commit c451ee146d449bbe39835fc3d9007b7f06332415 ] The media bus bit width of MEDIA_BUS_FMT_RGB101010_1X30 is 30. So, 'Bit31' and 'Bit30' cells for the 'MEDIA_BUS_FMT_RGB101010_1X30' row should be spaces instead of '0's. Fixes: 54f38fcae536 ("media: docs: move uAPI book to userspace-api/media") Signed-off-by: Liu Ying Reviewed-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit a5e2ebeb22cad7a7d717097a6cd35caa0d7f3c3d Author: Wei Yongjun Date: Mon Mar 8 13:28:02 2021 +0100 media: m88ds3103: fix return value check in m88ds3103_probe() [ Upstream commit e61f9ea271933d987ab895c689fa37744f6fc27f ] In case of error, the function i2c_new_dummy_device() returns ERR_PTR() and never returns NULL. The NULL test in the return value check should be replaced with IS_ERR(). Fixes: e6089feca460 ("media: m88ds3103: Add support for ds3103b demod") Reported-by: Hulk Robot Signed-off-by: Wei Yongjun Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 0faeb8a1127a44c018e88d8ac4a6d14aef5665fa Author: Jia-Ju Bai Date: Sat Mar 6 15:15:28 2021 +0100 media: platform: sunxi: sun6i-csi: fix error return code of sun6i_video_start_streaming() [ Upstream commit f3d384e36630e2a552d874e422835606d9cf230a ] When sun6i_video_remote_subdev() returns NULL to subdev, no error return code of sun6i_video_start_streaming() is assigned. To fix this bug, ret is assigned with -EINVAL in this case. Reported-by: TOTE Robot Signed-off-by: Jia-Ju Bai Fixes: 5cc7522d8965 ("media: sun6i: Add support for Allwinner CSI V3s") Acked-by: Chen-Yu Tsai Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 711acdf0228dc71601247f28b56f13e850e395c8 Author: Christophe JAILLET Date: Thu Jan 28 21:22:34 2021 +0100 media: venus: core: Fix some resource leaks in the error path of 'venus_probe()' [ Upstream commit 5a465c5391a856a0c1e9554964d660676c35d1b2 ] If an error occurs after a successful 'of_icc_get()' call, it must be undone. Use 'devm_of_icc_get()' instead of 'of_icc_get()' to avoid the leak. Update the remove function accordingly and axe the now unneeded 'icc_put()' calls. Fixes: 32f0a6ddc8c9 ("media: venus: Use on-chip interconnect API") Signed-off-by: Christophe JAILLET Signed-off-by: Stanimir Varbanov Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 521ed2a1ee95873c52b558af444d7a2961805d63 Author: Noralf Trønnes Date: Sat Mar 13 12:25:44 2021 +0100 drm/probe-helper: Check epoch counter in output_poll_execute() [ Upstream commit dc659a4e852b591771fc2e5abb60f4455b0cf316 ] drm_helper_hpd_irq_event() checks the epoch counter to determine connector status change. This was introduced in commit 5186421cbfe2 ("drm: Introduce epoch counter to drm_connector"). Do the same for output_poll_execute() so it can detect other changes beside connection status value changes. v2: - Add Fixes tag (Daniel) Fixes: 5186421cbfe2 ("drm: Introduce epoch counter to drm_connector") Reviewed-by: Daniel Vetter Signed-off-by: Noralf Trønnes Link: https://patchwork.freedesktop.org/patch/msgid/20210313112545.37527-3-noralf@tronnes.org Signed-off-by: Sasha Levin commit cfc0149e1fe71ad787623f450ab7e3811b755922 Author: Matthias Schiffer Date: Wed Mar 3 10:54:18 2021 +0100 power: supply: bq27xxx: fix sign of current_now for newer ICs [ Upstream commit b67fdcb7099e9c640bad625c4dd6399debb3376a ] Commit cd060b4d0868 ("power: supply: bq27xxx: fix polarity of current_now") changed the sign of current_now for all bq27xxx variants, but on BQ28Z610 I'm now seeing negated values *with* that patch. The GTA04/Openmoko device that was used for testing uses a BQ27000 or BQ27010 IC, so I assume only the BQ27XXX_O_ZERO code path was incorrect. Revert the behaviour for newer ICs. Fixes: cd060b4d0868 "power: supply: bq27xxx: fix polarity of current_now" Signed-off-by: Matthias Schiffer Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 15a6dff1b3f12f4154a99945fa3f2cf3585feeea Author: Douglas Anderson Date: Fri Jan 15 14:44:16 2021 -0800 drm/panel-simple: Undo enable if HPD never asserts [ Upstream commit 5e7222a3674ea7422370779884dd53aabe9e4a9d ] If the HPD signal never asserts in panel_simple_prepare() and we return an error, we should unset the enable GPIO and disable the regulator to make it consistent for the caller. At the moment I have some hardware where HPD sometimes doesn't assert. Obviously that needs to be debugged, but this patch makes it so that if I add a retry that I can make things work. Fixes: 48834e6084f1 ("drm/panel-simple: Support hpd-gpios for delaying prepare()") Signed-off-by: Douglas Anderson Reviewed-by: Stephen Boyd Reviewed-by: Linus Walleij Signed-off-by: Linus Walleij Link: https://patchwork.freedesktop.org/patch/msgid/20210115144345.v2.1.I33fcbd64ab409cfe4f9491bf449f51925a4d3281@changeid Signed-off-by: Sasha Levin commit 75321dc8aebe3f30eff226028fe6da340fe0bf02 Author: Jae Hyun Yoo Date: Mon Dec 21 23:32:25 2020 +0100 media: aspeed: fix clock handling logic [ Upstream commit 3536169f8531c2c5b153921dc7d1ac9fd570cda7 ] Video engine uses eclk and vclk for its clock sources and its reset control is coupled with eclk so the current clock enabling sequence works like below. Enable eclk De-assert Video Engine reset 10ms delay Enable vclk It introduces improper reset on the Video Engine hardware and eventually the hardware generates unexpected DMA memory transfers that can corrupt memory region in random and sporadic patterns. This issue is observed very rarely on some specific AST2500 SoCs but it causes a critical kernel panic with making a various shape of signature so it's extremely hard to debug. Moreover, the issue is observed even when the video engine is not actively used because udevd turns on the video engine hardware for a short time to make a query in every boot. To fix this issue, this commit changes the clock handling logic to make the reset de-assertion triggered after enabling both eclk and vclk. Also, it adds clk_unprepare call for a case when probe fails. clk: ast2600: fix reset settings for eclk and vclk Video engine reset setting should be coupled with eclk to match it with the setting for previous Aspeed SoCs which is defined in clk-aspeed.c since all Aspeed SoCs are sharing a single video engine driver. Also, reset bit 6 is defined as 'Video Engine' reset in datasheet so it should be de-asserted when eclk is enabled. This commit fixes the setting. Fixes: d2b4387f3bdf ("media: platform: Add Aspeed Video Engine driver") Signed-off-by: Jae Hyun Yoo Reviewed-by: Joel Stanley Reviewed-by: Eddie James Fixes: d3d04f6c330a ("clk: Add support for AST2600 SoC") Reviewed-by: Joel Stanley Acked-by: Stephen Boyd Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit a9545343a506aceecd1e131f5b0837c846c878f4 Author: Dafna Hirschfeld Date: Wed Dec 9 17:15:10 2020 +0100 media: rkisp1: rsz: crash fix when setting src format [ Upstream commit cbe8373ca7e7cbb4b263b6bf222ccc19f5e119d2 ] When setting the source media bus code in the resizer, we first check that the current media bus code in the source is yuv encoded format. This is done by retrieving the data from the formats list of the isp entity. This cause a crash when the media bus code on the source is YUYV8_1_5X8 which is not supported by the isp entity. Instead we should test the sink format of the resizer which is guaranteed to be supported by the isp entity. Fixes: 251b6eebb6c49 ("media: staging: rkisp1: rsz: Add support to more YUV encoded mbus codes on src pad") Signed-off-by: Dafna Hirschfeld Acked-by: Helen Koike Tested-by: Sebastian Fricke Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 818103e37793e044d08301d22066fb3307e35e0b Author: Yang Yingliang Date: Tue Nov 17 03:50:41 2020 +0100 media: omap4iss: return error code when omap4iss_get() failed [ Upstream commit 8938c48fa25b491842ece9eb38f0bea0fcbaca44 ] If omap4iss_get() failed, it need return error code in iss_probe(). Fixes: 59f0ad807681 ("[media] v4l: omap4iss: Add support for OMAP4...") Reported-by: Hulk Robot Signed-off-by: Yang Yingliang Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit ee43611a4f6cb484700014a29eff14d940036d8b Author: Tasos Sahanidis Date: Wed Mar 3 19:52:53 2021 +0100 media: saa7146: use sg_dma_len when building pgtable [ Upstream commit e56429b09d5e0802b86f84ec7c24025886c9f88b ] The new AMD IOMMU DMA implementation concatenates sglist entries under certain conditions, and because saa7146 accessed the length member directly, it did not support this scenario. This fixes IO_PAGE_FAULTs by using the sg_dma_len macro. Fixes: be62dbf554c5 ("iommu/amd: Convert AMD iommu driver to the dma-iommu api") Signed-off-by: Tasos Sahanidis Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit d05670a2e38d3e5cb0b51aa3d8734e832360826a Author: Tasos Sahanidis Date: Wed Mar 3 19:30:18 2021 +0100 media: saa7134: use sg_dma_len when building pgtable [ Upstream commit 4e1cb753c04d74e06d7ca826ea0bcb02526af03e ] The new AMD IOMMU DMA implementation concatenates sglist entries under certain conditions, and because saa7134 accessed the length member directly, it did not support this scenario. This fixes IO_PAGE_FAULTs and choppy DMA audio by using the sg_dma_len macro. Fixes: be62dbf554c5 ("iommu/amd: Convert AMD iommu driver to the dma-iommu api") Signed-off-by: Tasos Sahanidis Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit a6528fe467fc854e271c63dc88f63751cd9d4b81 Author: Colin Ian King Date: Thu Feb 25 16:43:27 2021 +0100 media: vivid: fix assignment of dev->fbuf_out_flags [ Upstream commit 5cde22fcc7271812a7944c47b40100df15908358 ] Currently the chroma_flags and alpha_flags are being zero'd with a bit-wise mask and the following statement should be bit-wise or'ing in the new flag bits but instead is making a direct assignment. Fix this by using the |= operator rather than an assignment. Addresses-Coverity: ("Unused value") Fixes: ef834f7836ec ("[media] vivid: add the video capture and output parts") Signed-off-by: Colin Ian King Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 8b8d969ec4bea9df003163456c812132bade7679 Author: Arnd Bergmann Date: Fri Feb 26 15:07:14 2021 +0100 media: mtk: fix mtk-smi dependency [ Upstream commit 4fade8329ab2be2b902fce8db3625fd12234b873 ] The mtk-smi driver can now be built as a loadable module, but this leads to a build time regression when the drivers that depend on it are built-in: aarch64-linux-ld: drivers/media/platform/mtk-mdp/mtk_mdp_comp.o: in function `mtk_mdp_comp_clock_on': mtk_mdp_comp.c:(.text.mtk_mdp_comp_clock_on+0x54): undefined reference to `mtk_smi_larb_get' aarch64-linux-ld: drivers/media/platform/mtk-mdp/mtk_mdp_comp.o: in function `mtk_mdp_comp_clock_off': mtk_mdp_comp.c:(.text.mtk_mdp_comp_clock_off+0x12c): undefined reference to `mtk_smi_larb_put' Add a dependency on the interface, but keep allowing compile-testing without that driver, as it was originally intended. Fixes: 50fc8d9232cd ("memory: mtk-smi: Allow building as module") Signed-off-by: Arnd Bergmann Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 8bdfbca9b17b2d1cc4701a6617bcbe658c80d4d0 Author: Zhouyi Zhou Date: Mon Jan 11 09:08:59 2021 +0800 rcu: Remove spurious instrumentation_end() in rcu_nmi_enter() [ Upstream commit 6494ccb93271bee596a12db32ff44867d5be2321 ] In rcu_nmi_enter(), there is an erroneous instrumentation_end() in the second branch of the "if" statement. Oddly enough, "objtool check -f vmlinux.o" fails to complain because it is unable to correctly cover all cases. Instead, objtool visits the third branch first, which marks following trace_rcu_dyntick() as visited. This commit therefore removes the spurious instrumentation_end(). Fixes: 04b25a495bd6 ("rcu: Mark rcu_nmi_enter() call to rcu_cleanup_after_idle() noinstr") Reported-by Neeraj Upadhyay Signed-off-by: Zhouyi Zhou Signed-off-by: Paul E. McKenney Signed-off-by: Sasha Levin commit 6ca5efcd15a87c0758f210e309dc4c76ea7c5c86 Author: David Howells Date: Wed Feb 10 08:59:52 2021 +0000 afs: Fix updating of i_mode due to 3rd party change [ Upstream commit 6e1eb04a87f954eb06a89ee6034c166351dfff6e ] Fix afs_apply_status() to mask off the irrelevant bits from status->mode when OR'ing them into i_mode. This can happen when a 3rd party chmod occurs. Also fix afs_inode_init_from_status() to mask off the mode bits when initialising i_mode. Fixes: 260a980317da ("[AFS]: Add "directory write" support.") Reported-by: Al Viro Signed-off-by: David Howells Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit ac67a8754fb12366049b107aa288b90f96c16e92 Author: John Ogness Date: Wed Mar 3 11:15:16 2021 +0100 printk: limit second loop of syslog_print_all [ Upstream commit bb07b16c44b2c6ddbafa44bb06454719002e828e ] The second loop of syslog_print_all() subtracts lengths that were added in the first loop. With commit b031a684bfd0 ("printk: remove logbuf_lock writer-protection of ringbuffer") it is possible that records are (over)written during syslog_print_all(). This allows the possibility of the second loop subtracting lengths that were never added in the first loop. This situation can result in syslog_print_all() filling the buffer starting from a later record, even though there may have been room to fit the earlier record(s) as well. Fixes: b031a684bfd0 ("printk: remove logbuf_lock writer-protection of ringbuffer") Signed-off-by: John Ogness Reviewed-by: Petr Mladek Signed-off-by: Petr Mladek Link: https://lore.kernel.org/r/20210303101528.29901-4-john.ogness@linutronix.de Signed-off-by: Sasha Levin commit 805cea93e66ca7deaaf6ad3b67224ce47c104c2f Author: Valentin Schneider Date: Thu Feb 25 17:56:56 2021 +0000 sched/fair: Fix shift-out-of-bounds in load_balance() [ Upstream commit 39a2a6eb5c9b66ea7c8055026303b3aa681b49a5 ] Syzbot reported a handful of occurrences where an sd->nr_balance_failed can grow to much higher values than one would expect. A successful load_balance() resets it to 0; a failed one increments it. Once it gets to sd->cache_nice_tries + 3, this *should* trigger an active balance, which will either set it to sd->cache_nice_tries+1 or reset it to 0. However, in case the to-be-active-balanced task is not allowed to run on env->dst_cpu, then the increment is done without any further modification. This could then be repeated ad nauseam, and would explain the absurdly high values reported by syzbot (86, 149). VincentG noted there is value in letting sd->cache_nice_tries grow, so the shift itself should be fixed. That means preventing: """ If the value of the right operand is negative or is greater than or equal to the width of the promoted left operand, the behavior is undefined. """ Thus we need to cap the shift exponent to BITS_PER_TYPE(typeof(lefthand)) - 1. I had a look around for other similar cases via coccinelle: @expr@ position pos; expression E1; expression E2; @@ ( E1 >> E2@pos | E1 >> E2@pos ) @cst depends on expr@ position pos; expression expr.E1; constant cst; @@ ( E1 >> cst@pos | E1 << cst@pos ) @script:python depends on !cst@ pos << expr.pos; exp << expr.E2; @@ # Dirty hack to ignore constexpr if exp.upper() != exp: coccilib.report.print_report(pos[0], "Possible UB shift here") The only other match in kernel/sched is rq_clock_thermal() which employs sched_thermal_decay_shift, and that exponent is already capped to 10, so that one is fine. Fixes: 5a7f55590467 ("sched/fair: Relax constraint on task's load during load balance") Reported-by: syzbot+d7581744d5fd27c9fbe1@syzkaller.appspotmail.com Signed-off-by: Valentin Schneider Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Link: http://lore.kernel.org/r/000000000000ffac1205b9a2112f@google.com Signed-off-by: Sasha Levin commit 9bdcfbed2a9fe24d2c7eaa1bad7c705e18de8cc7 Author: James Smart Date: Mon Mar 1 09:18:08 2021 -0800 scsi: lpfc: Fix null pointer dereference in lpfc_prep_els_iocb() [ Upstream commit 8dd1c125f7f838abad009b64bff5f0a11afe3cb6 ] It is possible to call lpfc_issue_els_plogi() passing a did for which no matching ndlp is found. A call is then made to lpfc_prep_els_iocb() with a null pointer to a lpfc_nodelist structure resulting in a null pointer dereference. Fix by returning an error status if no valid ndlp is found. Fix up comments regarding ndlp reference counting. Link: https://lore.kernel.org/r/20210301171821.3427-10-jsmart2021@gmail.com Fixes: 4430f7fd09ec ("scsi: lpfc: Rework locations of ndlp reference taking") Co-developed-by: Dick Kennedy Signed-off-by: Dick Kennedy Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit fe67c11fef93e44ef86d8bd30e06e1cec8f9ab37 Author: Linus Walleij Date: Thu Mar 4 01:41:38 2021 +0100 drm/mcde/panel: Inverse misunderstood flag [ Upstream commit d0c5ac04e7feedbc069f26f4dcbf35b521ae7fc5 ] A recent patch renaming MIPI_DSI_MODE_EOT_PACKET to MIPI_DSI_MODE_NO_EOT_PACKET brought to light the misunderstanding in the current MCDE driver and all its associated panel drivers that MIPI_DSI_MODE_EOT_PACKET would mean "use EOT packet" when in fact it means the reverse. Fix it up by implementing the flag right in the MCDE DSI driver and remove the flag from panels that actually want the EOT packet. Suggested-by: Nicolas Boichat Signed-off-by: Linus Walleij Reviewed-by: Nicolas Boichat Fixes: 5fc537bfd000 ("drm/mcde: Add new driver for ST-Ericsson MCDE") Fixes: 899f24ed8d3a ("drm/panel: Add driver for Novatek NT35510-based panels") Fixes: ac1d6d74884e ("drm/panel: Add driver for Samsung S6D16D0 panel") Fixes: 435e06c06cb2 ("drm/panel: s6e63m0: Add DSI transport") Fixes: 8152c2bfd780 ("drm/panel: Add driver for Sony ACX424AKP panel") Link: https://patchwork.freedesktop.org/patch/msgid/20210304004138.1785057-1-linus.walleij@linaro.org Signed-off-by: Sasha Levin commit 080bd41d6478a64edf96704fddcda52b1fd5fed7 Author: Dan Carpenter Date: Tue Mar 2 14:15:48 2021 +0300 drm/amd/display: Fix off by one in hdmi_14_process_transaction() [ Upstream commit 8e6fafd5a22e7a2eb216f5510db7aab54cc545c1 ] The hdcp_i2c_offsets[] array did not have an entry for HDCP_MESSAGE_ID_WRITE_CONTENT_STREAM_TYPE so it led to an off by one read overflow. I added an entry and copied the 0x0 value for the offset from similar code in drivers/gpu/drm/amd/display/modules/hdcp/hdcp_ddc.c. I also declared several of these arrays as having HDCP_MESSAGE_ID_MAX entries. This doesn't change the code, but it's just a belt and suspenders approach to try future proof the code. Fixes: 4c283fdac08a ("drm/amd/display: Add HDCP module") Reviewed-by: Bhawanpreet Lakha Signed-off-by: Dan Carpenter Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit bb62b23e950c3d3833dbcc3d9bcbf27b69221872 Author: Marek Vasut Date: Wed Jan 27 12:07:56 2021 +0100 drm/stm: Fix bus_flags handling [ Upstream commit 99e360442f223dd40fc23ae07c7a263836fd27e6 ] The drm_display_mode_to_videomode() does not populate DISPLAY_FLAGS_DE_LOW or DISPLAY_FLAGS_PIXDATA_NEGEDGE flags in struct videomode. Therefore, no matter what polarity the next bridge or display might require, these flags are never set, and thus the LTDC GCR_DEPOL and GCR_PCPOL bits are never set and the LTDC behaves as if both DISPLAY_FLAGS_PIXDATA_POSEDGE and DISPLAY_FLAGS_DE_HIGH were always set. The fix for this problem is taken almost verbatim from MXSFB driver. In case there is a bridge attached to the LTDC, the bridge might have extra polarity requirements, so extract bus_flags from the bridge and use them for LTDC configuration. Otherwise, extract bus_flags from the connector, which is the display. Fixes: b759012c5fa7 ("drm/stm: Add STM32 LTDC driver") Signed-off-by: Marek Vasut Signed-off-by: Yannick Fertre Cc: Alexandre Torgue Cc: Antonio Borneo Cc: Benjamin Gaignard Cc: Maxime Coquelin Cc: Philippe Cornu Cc: Sam Ravnborg Cc: Vincent Abriou Cc: Yannick Fertre Cc: linux-arm-kernel@lists.infradead.org Cc: linux-stm32@st-md-mailman.stormreply.com To: dri-devel@lists.freedesktop.org Tested-by: Yannick Fertre Signed-off-by: Philippe Cornu Link: https://patchwork.freedesktop.org/patch/msgid/20210127110756.125570-1-marex@denx.de Signed-off-by: Sasha Levin commit b3ed9569a7b2c82ea69a637c903deeb500e4a813 Author: Quanyang Wang Date: Tue Feb 9 16:24:15 2021 +0800 drm/tilcdc: send vblank event when disabling crtc [ Upstream commit f1a75f4dd8edf272b6b7cdccf6ba6254ec9d15fa ] When run xrandr to change resolution on Beaglebone Black board, it will print the error information: root@beaglebone:~# xrandr -display :0 --output HDMI-1 --mode 720x400 [drm:drm_crtc_commit_wait] *ERROR* flip_done timed out [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:32:tilcdc crtc] commit wait timed out [drm:drm_crtc_commit_wait] *ERROR* flip_done timed out [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CONNECTOR:34:HDMI-A-1] commit wait timed out [drm:drm_crtc_commit_wait] *ERROR* flip_done timed out [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [PLANE:31:plane-0] commit wait timed out tilcdc 4830e000.lcdc: already pending page flip! This is because there is operation sequence as below: drm_atomic_connector_commit_dpms(mode is DRM_MODE_DPMS_OFF): ... drm_atomic_helper_setup_commit <- init_completion(commit_A->flip_done) drm_atomic_helper_commit_tail tilcdc_crtc_atomic_disable tilcdc_plane_atomic_update <- drm_crtc_send_vblank_event in tilcdc_crtc_irq is skipped since tilcdc_crtc->enabled is 0 tilcdc_crtc_atomic_flush <- drm_crtc_send_vblank_event is skipped since crtc->state->event is set to be NULL in tilcdc_plane_atomic_update drm_mode_setcrtc: ... drm_atomic_helper_setup_commit <- init_completion(commit_B->flip_done) drm_atomic_helper_wait_for_dependencies drm_crtc_commit_wait <- wait for commit_A->flip_done completing Just as shown above, the steps which could complete commit_A->flip_done are all skipped and commit_A->flip_done will never be completed. This will result a time-out ERROR when drm_crtc_commit_wait check the commit_A->flip_done. So add drm_crtc_send_vblank_event in tilcdc_crtc_atomic_disable to complete commit_A->flip_done. Fixes: cb345decb4d2 ("drm/tilcdc: Use standard drm_atomic_helper_commit") Signed-off-by: Quanyang Wang Reviewed-by: Jyri Sarha Tested-by: Jyri Sarha Signed-off-by: Jyri Sarha Link: https://patchwork.freedesktop.org/patch/msgid/20210209082415.382602-1-quanyang.wang@windriver.com Signed-off-by: Sasha Levin commit f3e2b85d3059b1634283b60494f633b946f1f863 Author: Dan Carpenter Date: Fri Apr 23 09:39:19 2021 +0930 soc: aspeed: fix a ternary sign expansion bug [ Upstream commit 5ffa828534036348fa90fb3079ccc0972d202c4a ] The intent here was to return negative error codes but it actually returns positive values. The problem is that type promotion with ternary operations is quite complicated. "ret" is an int. "copied" is a u32. And the snoop_file_read() function returns long. What happens is that "ret" is cast to u32 and becomes positive then it's cast to long and it's still positive. Fix this by removing the ternary so that "ret" is type promoted directly to long. Fixes: 3772e5da4454 ("drivers/misc: Aspeed LPC snoop output using misc chardev") Signed-off-by: Dan Carpenter Signed-off-by: Joel Stanley Reviewed-by: Patrick Venture Link: https://lore.kernel.org/r/YIE90PSXsMTa2Y8n@mwanda Link: https://lore.kernel.org/r/20210423000919.1249474-1-joel@jms.id.au' Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin commit 620b84fc3544792e0a37768584fa01055fe8d221 Author: Paul Durrant Date: Tue Feb 2 17:56:59 2021 +0000 xen-blkback: fix compatibility bug with single page rings [ Upstream commit d75e7f63b7c95c527cde42efb5d410d7f961498f ] Prior to commit 4a8c31a1c6f5 ("xen/blkback: rework connect_ring() to avoid inconsistent xenstore 'ring-page-order' set by malicious blkfront"), the behaviour of xen-blkback when connecting to a frontend was: - read 'ring-page-order' - if not present then expect a single page ring specified by 'ring-ref' - else expect a ring specified by 'ring-refX' where X is between 0 and 1 << ring-page-order This was correct behaviour, but was broken by the afforementioned commit to become: - read 'ring-page-order' - if not present then expect a single page ring (i.e. ring-page-order = 0) - expect a ring specified by 'ring-refX' where X is between 0 and 1 << ring-page-order - if that didn't work then see if there's a single page ring specified by 'ring-ref' This incorrect behaviour works most of the time but fails when a frontend that sets 'ring-page-order' is unloaded and replaced by one that does not because, instead of reading 'ring-ref', xen-blkback will read the stale 'ring-ref0' left around by the previous frontend will try to map the wrong grant reference. This patch restores the original behaviour. Fixes: 4a8c31a1c6f5 ("xen/blkback: rework connect_ring() to avoid inconsistent xenstore 'ring-page-order' set by malicious blkfront") Signed-off-by: Paul Durrant Reviewed-by: Dongli Zhang Reviewed-by: "Roger Pau Monné" Link: https://lore.kernel.org/r/20210202175659.18452-1-paul@xen.org Signed-off-by: Juergen Gross Signed-off-by: Sasha Levin commit 15e7357f076bc18c77a4c25484ef2da4ef3855d9 Author: Quanyang Wang Date: Thu Apr 22 18:26:04 2021 +0800 spi: tools: make a symbolic link to the header file spi.h [ Upstream commit bc2e9578baed90f36abe6bb922b9598a327b0555 ] The header file spi.h in include/uapi/linux/spi is needed for spidev.h, so we also need make a symbolic link to it to eliminate the error message as below: In file included from spidev_test.c:24: include/linux/spi/spidev.h:28:10: fatal error: linux/spi/spi.h: No such file or directory 28 | #include | ^~~~~~~~~~~~~~~~~ compilation terminated. Fixes: f7005142dace ("spi: uapi: unify SPI modes into a single spi.h") Signed-off-by: Quanyang Wang Link: https://lore.kernel.org/r/20210422102604.3034217-1-quanyang.wang@windriver.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 3b61f2f020c7f13c06433bd7b164597d549c3260 Author: Dario Binacchi Date: Sun Apr 18 11:47:05 2021 +0200 serial: omap: fix rs485 half-duplex filtering [ Upstream commit e2a5e8448e7393e96ccde346c68764b40a52cc10 ] Data received during half-duplex transmission must be filtered. If the target device responds quickly, emptying the FIFO at the end of the transmission can erase not only the echo characters but also part of the response message. By keeping the receive interrupt enabled even during transmission, it allows you to filter each echo character and only in a number equal to those transmitted. The issue was generated by a target device that started responding 240us later having received a request in communication at 115200bps. Sometimes, some messages received by the target were missing some of the first bytes. Fixes: 3a13884abea0 ("tty/serial: omap: empty the RX FIFO at the end of half-duplex TX") Signed-off-by: Dario Binacchi Link: https://lore.kernel.org/r/20210418094705.27014-1-dariobin@libero.it Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit b641a97b1f0bc5e01a464f05fed5cd4867344945 Author: Dario Binacchi Date: Thu Apr 15 23:09:45 2021 +0200 serial: omap: don't disable rs485 if rts gpio is missing [ Upstream commit 45f6b6db53c80787b79044629b062dfcf2da71ec ] There are rs485 transceivers (e.g. MAX13487E/MAX13488E) which automatically disable or enable the driver and receiver to keep the bus in the correct state. In these cases we don't need a GPIO for flow control. Fixes: 4a0ac0f55b18 ("OMAP: add RS485 support") Signed-off-by: Dario Binacchi Link: https://lore.kernel.org/r/20210415210945.25863-1-dariobin@libero.it Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 59e0f581a8a9e03d126d42abc416f44031927939 Author: Tetsuo Handa Date: Thu Apr 15 09:22:22 2021 +0900 ttyprintk: Add TTY hangup callback. [ Upstream commit c0070e1e60270f6a1e09442a9ab2335f3eaeaad2 ] syzbot is reporting hung task due to flood of tty_warn(tty, "%s: tty->count = 1 port count = %d\n", __func__, port->count); message [1], for ioctl(TIOCVHANGUP) prevents tty_port_close() from decrementing port->count due to tty_hung_up_p() == true. ---------- #include #include #include #include #include int main(int argc, char *argv[]) { int i; int fd[10]; for (i = 0; i < 10; i++) fd[i] = open("/dev/ttyprintk", O_WRONLY); ioctl(fd[0], TIOCVHANGUP); for (i = 0; i < 10; i++) close(fd[i]); close(open("/dev/ttyprintk", O_WRONLY)); return 0; } ---------- When TTY hangup happens, port->count needs to be reset via "struct tty_operations"->hangup callback. [1] https://syzkaller.appspot.com/bug?id=39ea6caa479af471183997376dc7e90bc7d64a6a Reported-by: syzbot Reported-by: syzbot Tested-by: syzbot Signed-off-by: Tetsuo Handa Fixes: 24b4b67d17c308aa ("add ttyprintk driver") Link: https://lore.kernel.org/r/17e0652d-89b7-c8c0-fb53-e7566ac9add4@i-love.sakura.ne.jp Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit acb642ee0f655492306d1e562a03bf28bc6ad973 Author: Artur Petrosyan Date: Fri Apr 16 16:47:14 2021 +0400 usb: dwc2: Fix hibernation between host and device modes. [ Upstream commit 24d209dba5a3959b2ebde7cf3ad40c8015e814cf ] When core is in hibernation in host mode and a device cable was connected then driver exited from device hibernation. However, registers saved for host mode and when exited from device hibernation register restore would be done for device register which was wrong because there was no device registers stored to restore. - Added dwc_handle_gpwrdn_disc_det() function which handles gpwrdn disconnect detect flow and exits hibernation without restoring the registers. - Updated exiting from hibernation in GPWRDN_STS_CHGINT with calling dwc_handle_gpwrdn_disc_det() function. Here no register is restored which is the solution described above. Fixes: 65c9c4c6b01f ("usb: dwc2: Add dwc2_handle_gpwrdn_intr() handler") Acked-by: Minas Harutyunyan Signed-off-by: Artur Petrosyan Signed-off-by: Minas Harutyunyan Link: https://lore.kernel.org/r/20210416124715.75355A005D@mailhost.synopsys.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 36535a40b52c6f530ea6c22ac9598dac5cbb393a Author: Artur Petrosyan Date: Fri Apr 16 16:47:06 2021 +0400 usb: dwc2: Fix host mode hibernation exit with remote wakeup flow. [ Upstream commit c2db8d7b9568b10e014af83b3c15e39929e3579e ] Added setting "port_connect_status_change" flag to "1" in order to re-enumerate, because after exit from hibernation port connection status is not detected. Fixes: c5c403dc4336 ("usb: dwc2: Add host/device hibernation functions") Acked-by: Minas Harutyunyan Signed-off-by: Artur Petrosyan Link: https://lore.kernel.org/r/20210416124707.5EEC2A005D@mailhost.synopsys.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit b3fc9b21e5c6ba3cd593ea3f6a89f73f08fb2446 Author: Chris von Recklinghausen Date: Tue Apr 20 08:57:39 2021 -0400 PM: hibernate: x86: Use crc32 instead of md5 for hibernation e820 integrity check [ Upstream commit f5d1499ae2096d7ea301023c4cc54e427300eb0a ] Hibernation fails on a system in fips mode because md5 is used for the e820 integrity check and is not available. Use crc32 instead. The check is intended to detect whether the E820 memory map provided by the firmware after cold boot unexpectedly differs from the one that was in use when the hibernation image was created. In this case, the hibernation image cannot be restored, as it may cover memory regions that are no longer available to the OS. A non-cryptographic checksum such as CRC-32 is sufficient to detect such inadvertent deviations. Fixes: 62a03defeabd ("PM / hibernate: Verify the consistent of e820 memory map by md5 digest") Reviewed-by: Eric Biggers Tested-by: Dexuan Cui Reviewed-by: Dexuan Cui Signed-off-by: Chris von Recklinghausen [ rjw: Subject edit ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 682f486d18c616169e9cecaf193c45f9fbb0d42d Author: Michael Kelley Date: Mon Apr 19 21:48:09 2021 -0700 Drivers: hv: vmbus: Increase wait time for VMbus unload [ Upstream commit 77db0ec8b7764cb9b09b78066ebfd47b2c0c1909 ] When running in Azure, disks may be connected to a Linux VM with read/write caching enabled. If a VM panics and issues a VMbus UNLOAD request to Hyper-V, the response is delayed until all dirty data in the disk cache is flushed. In extreme cases, this flushing can take 10's of seconds, depending on the disk speed and the amount of dirty data. If kdump is configured for the VM, the current 10 second timeout in vmbus_wait_for_unload() may be exceeded, and the UNLOAD complete message may arrive well after the kdump kernel is already running, causing problems. Note that no problem occurs if kdump is not enabled because Hyper-V waits for the cache flush before doing a reboot through the BIOS/UEFI code. Fix this problem by increasing the timeout in vmbus_wait_for_unload() to 100 seconds. Also output periodic messages so that if anyone is watching the serial console, they won't think the VM is completely hung. Fixes: 911e1987efc8 ("Drivers: hv: vmbus: Add timeout to vmbus_wait_for_unload") Signed-off-by: Michael Kelley Reviewed-by: Vitaly Kuznetsov Link: https://lore.kernel.org/r/1618894089-126662-1-git-send-email-mikelley@microsoft.com Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit b877d36f134f89725f6feaae4e9b780cbc23117a Author: Dan Carpenter Date: Tue Apr 20 11:44:02 2021 +0300 platform/surface: aggregator: fix a bit test [ Upstream commit 366f0a30c8a01e79255221539a52909cc4c7bd25 ] The "funcs" variable is a u64. If "func" is more than 31 then the BIT() shift will wrap instead of testing the high bits. Fixes: c167b9c7e3d6 ("platform/surface: Add Surface Aggregator subsystem") Reported-by: kernel test robot Signed-off-by: Dan Carpenter Reviewed-by: Maximilian Luz Link: https://lore.kernel.org/r/YH6UUhJhGk3mk13b@mwanda Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit 3e4e2eca38edea3f6262c5c803ae184cdcec18fa Author: Paul Fertser Date: Fri Apr 16 13:29:04 2021 +0300 hwmon: (pmbus/pxe1610) don't bail out when not all pages are active [ Upstream commit f025314306ae17a3fdaf2874d7e878ce19cea363 ] Certain VRs might be configured to use only the first output channel and so the mode for the second will be 0. Handle this gracefully. Fixes: b9fa0a3acfd8 ("hwmon: (pmbus/core) Add support for vid mode detection per page bases") Signed-off-by: Paul Fertser Link: https://lore.kernel.org/r/20210416102926.13614-1-fercerpav@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 7b9b14d8ba4125c2e6936116699bc41b87e41258 Author: Ingo Molnar Date: Tue Apr 20 09:47:42 2021 +0200 x86/platform/uv: Fix !KEXEC build failure [ Upstream commit c2209ea55612efac75de0a58ef5f7394fae7fa0f ] When KEXEC is disabled, the UV build fails: arch/x86/platform/uv/uv_nmi.c:875:14: error: ‘uv_nmi_kexec_failed’ undeclared (first use in this function) Since uv_nmi_kexec_failed is only defined in the KEXEC_CORE #ifdef branch, this code cannot ever have been build tested: if (main) pr_err("UV: NMI kdump: KEXEC not supported in this kernel\n"); atomic_set(&uv_nmi_kexec_failed, 1); Nor is this use possible in uv_handle_nmi(): atomic_set(&uv_nmi_kexec_failed, 0); These bugs were introduced in this commit: d0a9964e9873: ("x86/platform/uv: Implement simple dump failover if kdump fails") Which added the uv_nmi_kexec_failed assignments to !KEXEC code, while making the definition KEXEC-only - apparently without testing the !KEXEC case. Instead of complicating the #ifdef maze, simplify the code by requiring X86_UV to depend on KEXEC_CORE. This pattern is present in other architectures as well. ( We'll remove the untested, 7 years old !KEXEC complications from the file in a separate commit. ) Fixes: d0a9964e9873: ("x86/platform/uv: Implement simple dump failover if kdump fails") Signed-off-by: Ingo Molnar Cc: Mike Travis Cc: linux-kernel@vger.kernel.org Signed-off-by: Sasha Levin commit c3a5a3597ea944985b12dab3f91842068fdcd054 Author: Arnd Bergmann Date: Tue Mar 23 15:31:19 2021 +0100 btrfs: zoned: bail out in btrfs_alloc_chunk for bad input [ Upstream commit bb05b298af8b2330db2b39971bf0029798e7ad59 ] gcc complains that the ctl->max_chunk_size member might be used uninitialized when none of the three conditions for initializing it in init_alloc_chunk_ctl_policy_zoned() are true: In function ‘init_alloc_chunk_ctl_policy_zoned’, inlined from ‘init_alloc_chunk_ctl’ at fs/btrfs/volumes.c:5023:3, inlined from ‘btrfs_alloc_chunk’ at fs/btrfs/volumes.c:5340:2: include/linux/compiler-gcc.h:48:45: error: ‘ctl.max_chunk_size’ may be used uninitialized [-Werror=maybe-uninitialized] 4998 | ctl->max_chunk_size = min(limit, ctl->max_chunk_size); | ^~~ fs/btrfs/volumes.c: In function ‘btrfs_alloc_chunk’: fs/btrfs/volumes.c:5316:32: note: ‘ctl’ declared here 5316 | struct alloc_chunk_ctl ctl; | ^~~ If we ever get into this condition, something is seriously wrong, as validity is checked in the callers btrfs_alloc_chunk init_alloc_chunk_ctl init_alloc_chunk_ctl_policy_zoned so the same logic as in init_alloc_chunk_ctl_policy_regular() and a few other places should be applied. This avoids both further data corruption, and the compile-time warning. Fixes: 1cd6121f2a38 ("btrfs: zoned: implement zoned chunk allocator") Signed-off-by: Arnd Bergmann Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 7b386cbdc3437b822ecb4e20ce01d7b87cd1ddd1 Author: Naohiro Aota Date: Wed Mar 24 23:23:11 2021 +0900 btrfs: zoned: move log tree node allocation out of log_root_tree->log_mutex [ Upstream commit e75f9fd194090e69c5ffd856ba89160683d343da ] Commit 6e37d2459941 ("btrfs: zoned: fix deadlock on log sync") pointed out a deadlock warning and removed mutex_{lock,unlock} of fs_info::tree_root->log_mutex. While it looks like it always cause a deadlock, we didn't see actual deadlock in fstests runs. The reason is log_root_tree->log_mutex != fs_info->tree_root->log_mutex, not taking the same lock. So, the warning was actually a false-positive. Since btrfs_alloc_log_tree_node() is protected only by fs_info->tree_root->log_mutex, we can (and should) move the code out of the lock scope of log_root_tree->log_mutex and silence the warning. Fixes: 6e37d2459941 ("btrfs: zoned: fix deadlock on log sync") Reviewed-by: Filipe Manana Reviewed-by: Johannes Thumshirn Signed-off-by: Naohiro Aota Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit bad5a23cf2b477fa78b85fd392736dae09a1e818 Author: Quanyang Wang Date: Fri Apr 16 08:46:52 2021 +0800 spi: spi-zynqmp-gqspi: return -ENOMEM if dma_map_single fails [ Upstream commit 126bdb606fd2802454e6048caef1be3e25dd121e ] The spi controller supports 44-bit address space on AXI in DMA mode, so set dma_addr_t width to 44-bit to avoid using a swiotlb mapping. In addition, if dma_map_single fails, it should return immediately instead of continuing doing the DMA operation which bases on invalid address. This fixes the following crash which occurs in reading a big block from flash: [ 123.633577] zynqmp-qspi ff0f0000.spi: swiotlb buffer is full (sz: 4194304 bytes), total 32768 (slots), used 0 (slots) [ 123.644230] zynqmp-qspi ff0f0000.spi: ERR:rxdma:memory not mapped [ 123.784625] Unable to handle kernel paging request at virtual address 00000000003fffc0 [ 123.792536] Mem abort info: [ 123.795313] ESR = 0x96000145 [ 123.798351] EC = 0x25: DABT (current EL), IL = 32 bits [ 123.803655] SET = 0, FnV = 0 [ 123.806693] EA = 0, S1PTW = 0 [ 123.809818] Data abort info: [ 123.812683] ISV = 0, ISS = 0x00000145 [ 123.816503] CM = 1, WnR = 1 [ 123.819455] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000805047000 [ 123.825887] [00000000003fffc0] pgd=0000000803b45003, p4d=0000000803b45003, pud=0000000000000000 [ 123.834586] Internal error: Oops: 96000145 [#1] PREEMPT SMP Fixes: 1c26372e5aa9 ("spi: spi-zynqmp-gqspi: Update driver to use spi-mem framework") Signed-off-by: Quanyang Wang Link: https://lore.kernel.org/r/20210416004652.2975446-6-quanyang.wang@windriver.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 23269ac9f123eca3aea7682d3345c02e71ed696c Author: Quanyang Wang Date: Fri Apr 16 08:46:51 2021 +0800 spi: spi-zynqmp-gqspi: fix use-after-free in zynqmp_qspi_exec_op [ Upstream commit a2c5bedb2d55dd27c642c7b9fb6886d7ad7bdb58 ] When handling op->addr, it is using the buffer "tmpbuf" which has been freed. This will trigger a use-after-free KASAN warning. Let's use temporary variables to store op->addr.val and op->cmd.opcode to fix this issue. Fixes: 1c26372e5aa9 ("spi: spi-zynqmp-gqspi: Update driver to use spi-mem framework") Signed-off-by: Quanyang Wang Link: https://lore.kernel.org/r/20210416004652.2975446-5-quanyang.wang@windriver.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 28b09dcdcf7d5232ce46295f16373cfebe59753f Author: Quanyang Wang Date: Fri Apr 16 08:46:49 2021 +0800 spi: spi-zynqmp-gqspi: fix hang issue when suspend/resume [ Upstream commit 799f923f0a66a9c99f0a3eaa078b306db7a8b33a ] After calling platform_set_drvdata(pdev, xqspi) in probe, the return value of dev_get_drvdata(dev) is a pointer to struct zynqmp_qspi but not struct spi_controller. A wrong structure type passing to the functions spi_controller_suspend/resume will hang the system. And we should check the return value of spi_controller_suspend, if an error is returned, return it to PM subsystem to stop suspend. Also, GQSPI_EN_MASK should be written to GQSPI_EN_OFST to enable the spi controller in zynqmp_qspi_resume since it was disabled in zynqmp_qspi_suspend before. Fixes: 1c26372e5aa9 ("spi: spi-zynqmp-gqspi: Update driver to use spi-mem framework") Signed-off-by: Quanyang Wang Link: https://lore.kernel.org/r/20210416004652.2975446-3-quanyang.wang@windriver.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 38671c4a5bf176fd6e77634c821e437d9e3aa3e6 Author: Quanyang Wang Date: Fri Apr 16 08:46:48 2021 +0800 spi: spi-zynqmp-gqspi: fix clk_enable/disable imbalance issue [ Upstream commit c6bdae08012b2ca3e94f3a41ef4ca8cfe7c9ab6f ] The clks "pclk" and "ref_clk" are enabled twice during the probe. The first time is in the function zynqmp_qspi_probe and the second time is in zynqmp_qspi_setup_op which is called by devm_spi_register_controller. Then calling zynqmp_qspi_remove (rmmod this module) to disable these clks will trigger a warning as below: [ 309.124604] Unpreparing enabled qspi_ref [ 309.128641] WARNING: CPU: 1 PID: 537 at drivers/clk/clk.c:824 clk_core_unprepare+0x108/0x110 Since pm_runtime works now, clks can be enabled/disabled by calling zynqmp_runtime_suspend/resume. So we don't need to enable these clks explicitly in zynqmp_qspi_setup_op. Remove them to fix this issue. And remove clk enabling/disabling in zynqmp_qspi_resume because there is no spi transfer operation so enabling ref_clk is redundant meanwhile pclk is not disabled for it is shared with other peripherals. Furthermore replace clk_enable/disable with clk_prepare_enable and clk_disable_unprepare in runtime_suspend/resume functions. Fixes: 1c26372e5aa9 ("spi: spi-zynqmp-gqspi: Update driver to use spi-mem framework") Signed-off-by: Quanyang Wang Link: https://lore.kernel.org/r/20210416004652.2975446-2-quanyang.wang@windriver.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 3fc537486d7c07b62f059b59043996b0923d16f9 Author: Ard Biesheuvel Date: Tue Apr 6 16:25:23 2021 +0200 crypto: arm64/aes-ce - deal with oversight in new CTR carry code [ Upstream commit 0f19dbc994dcb7f7137f2e056e813c84530b7538 ] The new carry handling code in the CTR driver can deal with a carry occurring in the 4x/5x parallel code path, by using a computed goto to jump into the carry sequence at the right place as to only apply the carry to a subset of the blocks being processed. If the lower half of the counter wraps and ends up at exactly 0x0, a carry needs to be applied to the counter, but not to the counter values taken for the 4x/5x parallel sequence. In this case, the computed goto skips all register assignments, and branches straight to the jump instruction that gets us back to the fast path. This produces the correct result, but due to the fact that this branch target does not carry the correct BTI annotation, this fails when BTI is enabled. Let's omit the computed goto entirely in this case, and jump straight back to the fast path after applying the carry to the main counter. Fixes: 5318d3db465d ("crypto: arm64/aes-ctr - improve tail handling") Signed-off-by: Ard Biesheuvel Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 2728f289b3270b0e273292b46c534421a33bbfd5 Author: Dan Carpenter Date: Tue Apr 13 13:50:04 2021 +0300 Drivers: hv: vmbus: Use after free in __vmbus_open() [ Upstream commit 3e9bf43f7f7a46f21ec071cb47be92d0874c48da ] The "open_info" variable is added to the &vmbus_connection.chn_msg_list, but the error handling frees "open_info" without removing it from the list. This will result in a use after free. First remove it from the list, and then free it. Fixes: 6f3d791f3006 ("Drivers: hv: vmbus: Fix rescind handling issues") Signed-off-by: Dan Carpenter Reviewed-by: Andrea Parri Link: https://lore.kernel.org/r/YHV3XLCot6xBS44r@mwanda Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit 6ee53ec981c1364ea0c16157527a11af1e1db7f8 Author: Eddie James Date: Tue Apr 13 14:43:06 2021 -0500 ARM: dts: aspeed: Rainier: Fix humidity sensor bus address [ Upstream commit 1d5d46a1adafafce2b0c9105eab563709c84e3db ] The si7021 was incorrectly placed at 0x20 on i2c bus 7. It is at 0x40. Fixes: 9c44db7096e0 ("ARM: dts: aspeed: rainier: Add i2c devices") Signed-off-by: Eddie James Reviewed-by: Joel Stanley Signed-off-by: Joel Stanley Signed-off-by: Sasha Levin commit 4b7c347672c2e483182790218b1d76d8dea691b1 Author: Dinghao Liu Date: Thu Apr 15 15:46:44 2021 +0800 spi: spi-zynqmp-gqspi: Fix runtime PM imbalance in zynqmp_qspi_probe [ Upstream commit a21fbc42807b15b74b0891bd557063e6acf4fcae ] When platform_get_irq() fails, a pairing PM usage counter increment is needed to keep the counter balanced. It's the same for the following error paths. Signed-off-by: Dinghao Liu Link: https://lore.kernel.org/r/20210408092559.3824-1-dinghao.liu@zju.edu.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit d7cd576b987f15b0587d5383dc41a6b4ba6ea890 Author: Badhri Jagan Sridharan Date: Tue Apr 13 19:39:58 2021 -0700 usb: typec: tcpm: Honour pSnkStdby requirement during negotiation [ Upstream commit 123086843372bc93d26f52edfb71dbf951cd2f17 ] >From PD Spec: The Sink Shall transition to Sink Standby before a positive or negative voltage transition of VBUS. During Sink Standby the Sink Shall reduce its power draw to pSnkStdby. This allows the Source to manage the voltage transition as well as supply sufficient operating current to the Sink to maintain PD operation during the transition. The Sink Shall complete this transition to Sink Standby within tSnkStdby after evaluating the Accept Message from the Source. The transition when returning to Sink operation from Sink Standby Shall be completed within tSnkNewPower. The pSnkStdby requirement Shall only apply if the Sink power draw is higher than this level. The above requirement needs to be met to prevent hard resets from port partner. Without the patch: (5V/3A during SNK_DISCOVERY all the way through explicit contract) [ 95.711984] CC1: 0 -> 0, CC2: 0 -> 5 [state TOGGLING, polarity 0, connected] [ 95.712007] state change TOGGLING -> SNK_ATTACH_WAIT [rev3 NONE_AMS] [ 95.712017] pending state change SNK_ATTACH_WAIT -> SNK_DEBOUNCED @ 170 ms [rev3 NONE_AMS] [ 95.837190] VBUS on [ 95.882075] state change SNK_ATTACH_WAIT -> SNK_DEBOUNCED [delayed 170 ms] [ 95.882082] state change SNK_DEBOUNCED -> SNK_ATTACHED [rev3 NONE_AMS] [ 95.882086] polarity 1 [ 95.883151] set_auto_vbus_discharge_threshold mode:0 pps_active:n vbus:5000 ret:0 [ 95.883441] enable vbus discharge ret:0 [ 95.883445] Requesting mux state 1, usb-role 2, orientation 2 [ 95.883776] state change SNK_ATTACHED -> SNK_STARTUP [rev3 NONE_AMS] [ 95.883879] pending state change SNK_STARTUP -> SNK_DISCOVERY @ 500 ms [rev3 NONE_AMS] [ 96.038960] VBUS on [ 96.383939] state change SNK_STARTUP -> SNK_DISCOVERY [delayed 500 ms] [ 96.383946] Setting voltage/current limit 5000 mV 3000 mA [ 96.383961] vbus=0 charge:=1 [ 96.386044] state change SNK_DISCOVERY -> SNK_WAIT_CAPABILITIES [rev3 NONE_AMS] [ 96.386309] pending state change SNK_WAIT_CAPABILITIES -> HARD_RESET_SEND @ 450 ms [rev3 NONE_AMS] [ 96.394404] PD RX, header: 0x2161 [1] [ 96.394408] PDO 0: type 0, 5000 mV, 3000 mA [E] [ 96.394410] PDO 1: type 0, 9000 mV, 2000 mA [] [ 96.394412] state change SNK_WAIT_CAPABILITIES -> SNK_NEGOTIATE_CAPABILITIES [rev2 POWER_NEGOTIATION] [ 96.394416] Setting usb_comm capable false [ 96.395083] cc=0 cc1=0 cc2=5 vbus=0 vconn=sink polarity=1 [ 96.395089] Requesting PDO 1: 9000 mV, 2000 mA [ 96.395093] PD TX, header: 0x1042 [ 96.397404] PD TX complete, status: 0 [ 96.397424] pending state change SNK_NEGOTIATE_CAPABILITIES -> HARD_RESET_SEND @ 60 ms [rev2 POWER_NEGOTIATION] [ 96.400826] PD RX, header: 0x363 [1] [ 96.400829] state change SNK_NEGOTIATE_CAPABILITIES -> SNK_TRANSITION_SINK [rev2 POWER_NEGOTIATION] [ 96.400832] pending state change SNK_TRANSITION_SINK -> HARD_RESET_SEND @ 500 ms [rev2 POWER_NEGOTIATION] [ 96.577315] PD RX, header: 0x566 [1] [ 96.577321] Setting voltage/current limit 9000 mV 2000 mA [ 96.578363] set_auto_vbus_discharge_threshold mode:3 pps_active:n vbus:9000 ret:0 [ 96.578370] state change SNK_TRANSITION_SINK -> SNK_READY [rev2 POWER_NEGOTIATION] With the patch: [ 168.398573] CC1: 0 -> 0, CC2: 0 -> 5 [state TOGGLING, polarity 0, connected] [ 168.398605] state change TOGGLING -> SNK_ATTACH_WAIT [rev3 NONE_AMS] [ 168.398619] pending state change SNK_ATTACH_WAIT -> SNK_DEBOUNCED @ 170 ms [rev3 NONE_AMS] [ 168.522348] VBUS on [ 168.568676] state change SNK_ATTACH_WAIT -> SNK_DEBOUNCED [delayed 170 ms] [ 168.568684] state change SNK_DEBOUNCED -> SNK_ATTACHED [rev3 NONE_AMS] [ 168.568688] polarity 1 [ 168.569867] set_auto_vbus_discharge_threshold mode:0 pps_active:n vbus:5000 ret:0 [ 168.570158] enable vbus discharge ret:0 [ 168.570161] Requesting mux state 1, usb-role 2, orientation 2 [ 168.570504] state change SNK_ATTACHED -> SNK_STARTUP [rev3 NONE_AMS] [ 168.570634] pending state change SNK_STARTUP -> SNK_DISCOVERY @ 500 ms [rev3 NONE_AMS] [ 169.070689] state change SNK_STARTUP -> SNK_DISCOVERY [delayed 500 ms] [ 169.070695] Setting voltage/current limit 5000 mV 3000 mA [ 169.070702] vbus=0 charge:=1 [ 169.072719] state change SNK_DISCOVERY -> SNK_WAIT_CAPABILITIES [rev3 NONE_AMS] [ 169.073145] pending state change SNK_WAIT_CAPABILITIES -> HARD_RESET_SEND @ 450 ms [rev3 NONE_AMS] [ 169.077162] PD RX, header: 0x2161 [1] [ 169.077172] PDO 0: type 0, 5000 mV, 3000 mA [E] [ 169.077178] PDO 1: type 0, 9000 mV, 2000 mA [] [ 169.077183] state change SNK_WAIT_CAPABILITIES -> SNK_NEGOTIATE_CAPABILITIES [rev2 POWER_NEGOTIATION] [ 169.077191] Setting usb_comm capable false [ 169.077753] cc=0 cc1=0 cc2=5 vbus=0 vconn=sink polarity=1 [ 169.077759] Requesting PDO 1: 9000 mV, 2000 mA [ 169.077762] PD TX, header: 0x1042 [ 169.079990] PD TX complete, status: 0 [ 169.080013] pending state change SNK_NEGOTIATE_CAPABILITIES -> HARD_RESET_SEND @ 60 ms [rev2 POWER_NEGOTIATION] [ 169.083183] VBUS on [ 169.084195] PD RX, header: 0x363 [1] [ 169.084200] state change SNK_NEGOTIATE_CAPABILITIES -> SNK_TRANSITION_SINK [rev2 POWER_NEGOTIATION] [ 169.084206] Setting standby current 5000 mV @ 500 mA [ 169.084209] Setting voltage/current limit 5000 mV 500 mA [ 169.084220] pending state change SNK_TRANSITION_SINK -> HARD_RESET_SEND @ 500 ms [rev2 POWER_NEGOTIATION] [ 169.260222] PD RX, header: 0x566 [1] [ 169.260227] Setting voltage/current limit 9000 mV 2000 mA [ 169.261315] set_auto_vbus_discharge_threshold mode:3 pps_active:n vbus:9000 ret:0 [ 169.261321] state change SNK_TRANSITION_SINK -> SNK_READY [rev2 POWER_NEGOTIATION] [ 169.261570] AMS POWER_NEGOTIATION finished Fixes: f0690a25a140b ("staging: typec: USB Type-C Port Manager (tcpm)") Reviewed-by: Guenter Roeck Reviewed-by: Heikki Krogerus Signed-off-by: Badhri Jagan Sridharan Link: https://lore.kernel.org/r/20210414024000.4175263-1-badhri@google.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit aabd4ef3a06555a151c4d3f4cdf9a636ee5da354 Author: Steffen Dirkwinkel Date: Mon Apr 12 15:30:06 2021 +0200 platform/x86: pmc_atom: Match all Beckhoff Automation baytrail boards with critclk_systems DMI table [ Upstream commit d21e5abd3a005253eb033090aab2e43bce090d89 ] pmc_plt_clk* clocks are used for ethernet controllers, so need to stay turned on. This adds the affected board family to critclk_systems DMI table, so the clocks are marked as CLK_CRITICAL and not turned off. This replaces the previously listed boards with a match for the whole device family CBxx63. CBxx63 matches only baytrail devices. There are new affected boards that would otherwise need to be listed. There are unaffected boards in the family, but having the clocks turned on is not an issue. Fixes: 648e921888ad ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL") Reviewed-by: Andy Shevchenko Signed-off-by: Steffen Dirkwinkel Link: https://lore.kernel.org/r/20210412133006.397679-1-linux-kernel-dev@beckhoff.com Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit af43779b6cc91ed6e0170f4adf11b28a2d863a56 Author: Zhihao Cheng Date: Fri Apr 9 09:12:01 2021 +0800 char: tpm: fix error return code in tpm_cr50_i2c_tis_recv() [ Upstream commit 3d785d73b4c1014839d9f9af0ee526f8d5706a73 ] Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: 3a253caaad11 ("char: tpm: add i2c driver for cr50") Reported-by: Hulk Robot Signed-off-by: Zhihao Cheng Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin commit 364400df2df9ea0410c126dde1ac1fc115231fd0 Author: James Bottomley Date: Wed Jan 27 11:06:15 2021 -0800 security: keys: trusted: fix TPM2 authorizations [ Upstream commit de66514d934d70ce73c302ce0644b54970fc7196 ] In TPM 1.2 an authorization was a 20 byte number. The spec actually recommended you to hash variable length passwords and use the sha1 hash as the authorization. Because the spec doesn't require this hashing, the current authorization for trusted keys is a 40 digit hex number. For TPM 2.0 the spec allows the passing in of variable length passwords and passphrases directly, so we should allow that in trusted keys for ease of use. Update the 'blobauth' parameter to take this into account, so we can now use plain text passwords for the keys. so before keyctl add trusted kmk "new 32 blobauth=f572d396fae9206628714fb2ce00f72e94f2258fkeyhandle=81000001" @u after we will accept both the old hex sha1 form as well as a new directly supplied password: keyctl add trusted kmk "new 32 blobauth=hello keyhandle=81000001" @u Since a sha1 hex code must be exactly 40 bytes long and a direct password must be 20 or less, we use the length as the discriminator for which form is input. Note this is both and enhancement and a potential bug fix. The TPM 2.0 spec requires us to strip leading zeros, meaning empyty authorization is a zero length HMAC whereas we're currently passing in 20 bytes of zeros. A lot of TPMs simply accept this as OK, but the Microsoft TPM emulator rejects it with TPM_RC_BAD_AUTH, so this patch makes the Microsoft TPM emulator work with trusted keys. Fixes: 0fe5480303a1 ("keys, trusted: seal/unseal with TPM 2.0 chips") Signed-off-by: James Bottomley Reviewed-by: Jarkko Sakkinen Tested-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin commit 4c5534ad27913a5a982b8a4af9ab0c27a2a14d83 Author: Krzysztof Kozlowski Date: Wed Apr 7 17:45:35 2021 +0200 memory: samsung: exynos5422-dmc: handle clk_set_parent() failure [ Upstream commit 132c17c3ff878c7beaba51bdd275d5cc654c0e33 ] clk_set_parent() can fail and ignoring such case could lead to invalid clock setup for given frequency. Addresses-Coverity: Unchecked return value Fixes: 6e7674c3c6df ("memory: Add DMC driver for Exynos5422") Signed-off-by: Krzysztof Kozlowski Reviewed-by: Lukasz Luba Link: https://lore.kernel.org/r/20210407154535.70756-1-krzysztof.kozlowski@canonical.com Signed-off-by: Sasha Levin commit a74cb41af7dbe019e4096171f8bc641c7ce910ad Author: Krzysztof Kozlowski Date: Wed Apr 7 17:43:57 2021 +0200 memory: renesas-rpc-if: fix possible NULL pointer dereference of resource [ Upstream commit 59e27d7c94aa02da039b000d33c304c179395801 ] The platform_get_resource_byname() can return NULL which would be immediately dereferenced by resource_size(). Instead dereference it after validating the resource. Addresses-Coverity: Dereference null return value Fixes: ca7d8b980b67 ("memory: add Renesas RPC-IF driver") Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20210407154357.70200-1-krzysztof.kozlowski@canonical.com Signed-off-by: Sasha Levin commit f476db2c0ffb36fd538860dcae765cbb94d42348 Author: Wei Yongjun Date: Mon Apr 12 16:00:25 2021 +0000 spi: spi-zynqmp-gqspi: Fix missing unlock on error in zynqmp_qspi_exec_op() [ Upstream commit 6043357263fbe2df0bf0736d971ad5dce7d19dc1 ] Add the missing unlock before return from function zynqmp_qspi_exec_op() in the error handling case. Fixes: a0f65be6e880 ("spi: spi-zynqmp-gqspi: add mutex locking for exec_op") Reported-by: Hulk Robot Signed-off-by: Wei Yongjun Link: https://lore.kernel.org/r/20210412160025.194171-1-weiyongjun1@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 512dbf4a089287a1e842a1d6e635b09d2937fc58 Author: Pawel Laszczak Date: Wed Apr 7 08:36:29 2021 +0200 usb: cdnsp: Fixes issue with Configure Endpoint command [ Upstream commit 10076de33b5ed5b1e049593a611d2fd9eba60565 ] Patch adds flag EP_UNCONFIGURED to detect whether endpoint was unconfigured. This flag is set in cdnsp_reset_device after Reset Device command. Among others this command disables all non control endpoints. Flag is used in cdnsp_gadget_ep_disable to protect controller against invoking Configure Endpoint command on disabled endpoint. Lack of this protection in some cases caused that Configure Endpoint command completed with Context State Error code completion. Fixes: 3d82904559f4 ("usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD Driver") Signed-off-by: Pawel Laszczak Signed-off-by: Peter Chen Signed-off-by: Sasha Levin commit 143f627f1979a866a88348d6961176b0c6cdb5f0 Author: Liam Howlett Date: Wed Apr 7 20:00:45 2021 +0000 m68k: Add missing mmap_read_lock() to sys_cacheflush() [ Upstream commit f829b4b212a315b912cb23fd10aaf30534bb5ce9 ] When the superuser flushes the entire cache, the mmap_read_lock() is not taken, but mmap_read_unlock() is called. Add the missing mmap_read_lock() call. Fixes: cd2567b6850b1648 ("m68k: call find_vma with the mmap_sem held in sys_cacheflush()") Signed-off-by: Liam R. Howlett Reviewed-by: Matthew Wilcox (Oracle) Link: https://lore.kernel.org/r/20210407200032.764445-1-Liam.Howlett@Oracle.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 795ad51102da51ee33d29484caef102b8ab23c3b Author: Ye Bin Date: Thu Apr 8 19:23:05 2021 +0800 usbip: vudc: fix missing unlock on error in usbip_sockfd_store() [ Upstream commit 1d08ed588c6a85a35a24c82eb4cf0807ec2b366a ] Add the missing unlock before return from function usbip_sockfd_store() in the error handling case. Fixes: bd8b82042269 ("usbip: vudc synchronize sysfs code paths") Reported-by: Hulk Robot Acked-by: Shuah Khan Signed-off-by: Ye Bin Link: https://lore.kernel.org/r/20210408112305.1022247-1-yebin10@huawei.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 8c2293dbe841ef1c5e88f95aaabca11311ef70f3 Author: Ayush Sawal Date: Sat Apr 3 00:55:48 2021 +0530 crypto: chelsio - Read rxchannel-id from firmware [ Upstream commit 16a9874fe468855e8ddd72883ca903f706d0a9d0 ] The rxchannel id is updated by the driver using the port no value, but this does not ensure that the value is correct. So now rx channel value is obtained from etoc channel map value. Fixes: 567be3a5d227 ("crypto: chelsio - Use multiple txq/rxq per...") Signed-off-by: Ayush Sawal Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit d5d7e473ee8ae21d216449fc12c1ce97e45ce24e Author: Dan Carpenter Date: Fri Apr 9 14:01:57 2021 +0300 node: fix device cleanups in error handling code [ Upstream commit 4ce535ec0084f0d712317cb99d383cad3288e713 ] We can't use kfree() to free device managed resources so the kfree(dev) is against the rules. It's easier to write this code if we open code the device_register() as a device_initialize() and device_add(). That way if dev_set_name() set name fails we can call put_device() and it will clean up correctly. Fixes: acc02a109b04 ("node: Add memory-side caching attributes") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/YHA0JUra+F64+NpB@mwanda Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 1395747ee5e9ab5d806424b17a49b697dc45c20b Author: He Ying Date: Tue Apr 6 05:42:00 2021 -0400 firmware: qcom-scm: Fix QCOM_SCM configuration [ Upstream commit 2954a6f12f250890ec2433cec03ba92784d613e8 ] When CONFIG_QCOM_SCM is y and CONFIG_HAVE_ARM_SMCCC is not set, compiling errors are encountered as follows: drivers/firmware/qcom_scm-smc.o: In function `__scm_smc_do_quirk': qcom_scm-smc.c:(.text+0x36): undefined reference to `__arm_smccc_smc' drivers/firmware/qcom_scm-legacy.o: In function `scm_legacy_call': qcom_scm-legacy.c:(.text+0xe2): undefined reference to `__arm_smccc_smc' drivers/firmware/qcom_scm-legacy.o: In function `scm_legacy_call_atomic': qcom_scm-legacy.c:(.text+0x1f0): undefined reference to `__arm_smccc_smc' Note that __arm_smccc_smc is defined when HAVE_ARM_SMCCC is y. So add dependency on HAVE_ARM_SMCCC in QCOM_SCM configuration. Fixes: 916f743da354 ("firmware: qcom: scm: Move the scm driver to drivers/firmware") Reported-by: Hulk Robot Signed-off-by: He Ying Link: https://lore.kernel.org/r/20210406094200.60952-1-heying24@huawei.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ac2c5480afd408167506910b1c0769bf2d044e7b Author: Johan Hovold Date: Wed Apr 7 11:52:08 2021 +0200 serial: core: return early on unsupported ioctls [ Upstream commit 79c5966cec7b148199386ef9933c31b999379065 ] Drivers can return -ENOIOCTLCMD when an ioctl is not recognised to tell the upper layers to continue looking for a handler. This is not the case for the RS485 and ISO7816 ioctls whose handlers should return -ENOTTY directly in case a serial driver does not implement the corresponding methods. Fixes: a5f276f10ff7 ("serial_core: Handle TIOC[GS]RS485 ioctls.") Fixes: ad8c0eaa0a41 ("tty/serial_core: add ISO7816 infrastructure") Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20210407095208.31838-9-johan@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a72d78d67043f1c6e2b23e5b98e51b28f043583c Author: Johan Hovold Date: Wed Apr 7 11:52:03 2021 +0200 tty: fix return value for unsupported termiox ioctls [ Upstream commit 8871de06ff78e9333d86c87d7071452b690e7c9b ] Drivers should return -ENOTTY ("Inappropriate I/O control operation") when an ioctl isn't supported, while -EINVAL is used for invalid arguments. Support for termiox was added by commit 1d65b4a088de ("tty: Add termiox") in 2008 but no driver support ever followed and it was recently ripped out by commit e0efb3168d34 ("tty: Remove dead termiox code"). Fix the return value for the unsupported termiox ioctls, which have always returned -EINVAL, by explicitly returning -ENOTTY rather than removing them completely and falling back to the default unrecognised- ioctl handling. Fixes: 1d65b4a088de ("tty: Add termiox") Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20210407095208.31838-4-johan@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 23598e43e2d95fe0b2df8bdd7cad1df9306056fc Author: Johan Hovold Date: Wed Apr 7 11:52:02 2021 +0200 tty: fix return value for unsupported ioctls [ Upstream commit 1b8b20868a6d64cfe8174a21b25b74367bdf0560 ] Drivers should return -ENOTTY ("Inappropriate I/O control operation") when an ioctl isn't supported, while -EINVAL is used for invalid arguments. Fix up the TIOCMGET, TIOCMSET and TIOCGICOUNT helpers which returned -EINVAL when a tty driver did not implement the corresponding operations. Note that the TIOCMGET and TIOCMSET helpers predate git and do not get a corresponding Fixes tag below. Fixes: d281da7ff6f7 ("tty: Make tiocgicount a handler") Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20210407095208.31838-3-johan@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit addeca42cc77f83b22371acf1cd96a304f08d767 Author: Johan Hovold Date: Wed Apr 7 11:52:01 2021 +0200 tty: actually undefine superseded ASYNC flags [ Upstream commit d09845e98a05850a8094ea8fd6dd09a8e6824fff ] Some kernel-internal ASYNC flags have been superseded by tty-port flags and should no longer be used by kernel drivers. Fix the misspelled "__KERNEL__" compile guards which failed their sole purpose to break out-of-tree drivers that have not yet been updated. Fixes: 5c0517fefc92 ("tty: core: Undefine ASYNC_* flags superceded by TTY_PORT* flags") Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20210407095208.31838-2-johan@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 7551577e6ce46990a7a00bdbf7b003a7e4208c25 Author: Johan Hovold Date: Thu Apr 8 15:16:02 2021 +0200 USB: cdc-acm: fix TIOCGSERIAL implementation [ Upstream commit 496960274153bdeb9d1f904ff1ea875cef8232c1 ] TIOCSSERIAL is a horrid, underspecified, legacy interface which for most serial devices is only useful for setting the close_delay and closing_wait parameters. The xmit_fifo_size parameter could be used to set the hardware transmit fifo size of a legacy UART when it could not be detected, but the interface is limited to eight bits and should be left unset when it is not used. Similarly, baud_base could be used to set the UART base clock when it could not be detected, but might as well be left unset when it is not known (which is the case for CDC). Fix the cdc-acm TIOCGSERIAL implementation by dropping its custom interpretation of the unused xmit_fifo_size and baud_base fields, which overflowed the former with the URB buffer size and set the latter to the current line speed. Also return the port line number, which is the only other value used besides the close parameters. Note that the current line speed can still be retrieved through the standard termios interfaces. Fixes: 18c75720e667 ("USB: allow users to run setserial with cdc-acm") Acked-by: Oliver Neukum Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20210408131602.27956-4-johan@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e48628060ca4fcc302f0246b2c2db2c1c1b39b6d Author: Johan Hovold Date: Thu Apr 8 15:16:01 2021 +0200 USB: cdc-acm: fix unprivileged TIOCCSERIAL [ Upstream commit dd5619582d60007139f0447382d2839f4f9e339b ] TIOCSSERIAL is a horrid, underspecified, legacy interface which for most serial devices is only useful for setting the close_delay and closing_wait parameters. A non-privileged user has only ever been able to set the since long deprecated ASYNC_SPD flags and trying to change any other *supported* feature should result in -EPERM being returned. Setting the current values for any supported features should return success. Fix the cdc-acm implementation which instead indicated that the TIOCSSERIAL ioctl was not even implemented when a non-privileged user set the current values. Fixes: ba2d8ce9db0a ("cdc-acm: implement TIOCSSERIAL to avoid blocking close(2)") Acked-by: Oliver Neukum Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20210408131602.27956-3-johan@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit b0e543b46b8d3c6ada114a405c35af33365dea35 Author: Colin Ian King Date: Tue Apr 6 19:45:10 2021 +0100 usb: gadget: r8a66597: Add missing null check on return from platform_get_resource [ Upstream commit 9c2076090c2815fe7c49676df68dde7e60a9b9fc ] The call to platform_get_resource can potentially return a NULL pointer on failure, so add this check and return -EINVAL if it fails. Fixes: c41442474a26 ("usb: gadget: R8A66597 peripheral controller support.") Signed-off-by: Colin Ian King Addresses-Coverity: ("Dereference null return") Link: https://lore.kernel.org/r/20210406184510.433497-1-colin.king@canonical.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 6a2b5cee0d31ab6cc51030c441135b0e31217282 Author: Wang Li Date: Fri Apr 9 09:54:30 2021 +0000 spi: fsl-lpspi: Fix PM reference leak in lpspi_prepare_xfer_hardware() [ Upstream commit a03675497970a93fcf25d81d9d92a59c2d7377a7 ] pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in reference leak here. Fix it by replacing it with pm_runtime_resume_and_get to keep usage counter balanced. Fixes: 944c01a889d9 ("spi: lpspi: enable runtime pm for lpspi") Reported-by: Hulk Robot Signed-off-by: Wang Li Link: https://lore.kernel.org/r/20210409095430.29868-1-wangli74@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit d11e1802f8aef81e8c68d775e5203f1ebf39935a Author: Quanyang Wang Date: Thu Apr 8 12:02:23 2021 +0800 spi: spi-zynqmp-gqspi: fix incorrect operating mode in zynqmp_qspi_read_op [ Upstream commit 41d310930084502433fcb3c4baf219e7424b7734 ] When starting a read operation, we should call zynqmp_qspi_setuprxdma first to set xqspi->mode according to xqspi->bytes_to_receive and to calculate correct xqspi->dma_rx_bytes. Then in the function zynqmp_qspi_fillgenfifo, generate the appropriate command with operating mode and bytes to transfer, and fill the GENFIFO with the command to perform the read operation. Calling zynqmp_qspi_fillgenfifo before zynqmp_qspi_setuprxdma will result in incorrect transfer length and operating mode. So change the calling order to fix this issue. Fixes: 1c26372e5aa9 ("spi: spi-zynqmp-gqspi: Update driver to use spi-mem framework") Signed-off-by: Quanyang Wang Reviewed-by: Amit Kumar Mahapatra Link: https://lore.kernel.org/r/20210408040223.23134-5-quanyang.wang@windriver.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 8d3d7eead4caf61d966f56fa36d91afdb2719737 Author: Quanyang Wang Date: Thu Apr 8 12:02:22 2021 +0800 spi: spi-zynqmp-gqspi: transmit dummy circles by using the controller's internal functionality [ Upstream commit 8ad07d79bd56a531990a1a3f3f1c0eb19d2de806 ] There is a data corruption issue that occurs in the reading operation (cmd:0x6c) when transmitting common data as dummy circles. The gqspi controller has the functionality to send dummy clock circles. When writing data with the fields [receive, transmit, data_xfer] = [0,0,1] to the Generic FIFO, and configuring the correct SPI mode, the controller will transmit dummy circles. So let's switch to hardware dummy cycles transfer to fix this issue. Fixes: 1c26372e5aa9 ("spi: spi-zynqmp-gqspi: Update driver to use spi-mem framework") Signed-off-by: Quanyang Wang Reviewed-by: Amit Kumar Mahapatra Link: https://lore.kernel.org/r/20210408040223.23134-4-quanyang.wang@windriver.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a5ec27dd6e37fc2ddc606c7e92f3e7ea4d23d289 Author: Quanyang Wang Date: Thu Apr 8 12:02:21 2021 +0800 spi: spi-zynqmp-gqspi: add mutex locking for exec_op [ Upstream commit a0f65be6e880a14d3445b75e7dc03d7d015fc922 ] The spi-mem framework has no locking to prevent ctlr->mem_ops->exec_op from concurrency. So add the locking to zynqmp_qspi_exec_op. Fixes: 1c26372e5aa9 ("spi: spi-zynqmp-gqspi: Update driver to use spi-mem framework") Signed-off-by: Quanyang Wang Reviewed-by: Amit Kumar Mahapatra Link: https://lore.kernel.org/r/20210408040223.23134-3-quanyang.wang@windriver.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 8fa511754543f9421c3fd6131d54f5634ca796e0 Author: Quanyang Wang Date: Thu Apr 8 12:02:20 2021 +0800 spi: spi-zynqmp-gqspi: use wait_for_completion_timeout to make zynqmp_qspi_exec_op not interruptible [ Upstream commit a16bff68b75fd082d36aa0b14b540bd7a3ebebbd ] When Ctrl+C occurs during the process of zynqmp_qspi_exec_op, the function wait_for_completion_interruptible_timeout will return a non-zero value -ERESTARTSYS immediately. This will disrupt the SPI memory operation because the data transmitting may begin before the command or address transmitting completes. Use wait_for_completion_timeout to prevent the process from being interruptible. This patch fixes the error as below: root@xilinx-zynqmp:~# flash_erase /dev/mtd3 0 0 Erasing 4 Kibyte @ 3d000 -- 4 % complete (Press Ctrl+C) [ 169.581911] zynqmp-qspi ff0f0000.spi: Chip select timed out [ 170.585907] zynqmp-qspi ff0f0000.spi: Chip select timed out [ 171.589910] zynqmp-qspi ff0f0000.spi: Chip select timed out [ 172.593910] zynqmp-qspi ff0f0000.spi: Chip select timed out [ 173.597907] zynqmp-qspi ff0f0000.spi: Chip select timed out [ 173.603480] spi-nor spi0.0: Erase operation failed. [ 173.608368] spi-nor spi0.0: Attempted to modify a protected sector. Fixes: 1c26372e5aa9 ("spi: spi-zynqmp-gqspi: Update driver to use spi-mem framework") Signed-off-by: Quanyang Wang Reviewed-by: Amit Kumar Mahapatra Link: https://lore.kernel.org/r/20210408040223.23134-2-quanyang.wang@windriver.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit d6c13a9896ae2bb859c5790f1df2a187eea63fb6 Author: Pali Rohár Date: Thu Apr 8 13:42:21 2021 +0200 cpufreq: armada-37xx: Fix determining base CPU frequency [ Upstream commit 8bad3bf23cbc40abe1d24cec08a114df6facf858 ] When current CPU load is not L0 then loading armada-37xx-cpufreq.ko driver fails with following error: # modprobe armada-37xx-cpufreq [ 502.702097] Unsupported CPU frequency 250 MHz This issue was partially fixed by commit 8db82563451f ("cpufreq: armada-37xx: fix frequency calculation for opp"), but only for calculating CPU frequency for opp. Fix this also for determination of base CPU frequency. Signed-off-by: Pali Rohár Acked-by: Gregory CLEMENT Tested-by: Tomasz Maciej Nowak Tested-by: Anders Trier Olesen Tested-by: Philip Soares Fixes: 92ce45fb875d ("cpufreq: Add DVFS support for Armada 37xx") Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit ae390626dc0e9fa079d6df5f0a29886fc9467b3b Author: Pali Rohár Date: Thu Apr 8 13:42:20 2021 +0200 cpufreq: armada-37xx: Fix driver cleanup when registration failed [ Upstream commit 92963903a8e11b9576eb7249f8e81eefa93b6f96 ] Commit 8db82563451f ("cpufreq: armada-37xx: fix frequency calculation for opp") changed calculation of frequency passed to the dev_pm_opp_add() function call. But the code for dev_pm_opp_remove() function call was not updated, so the driver cleanup phase does not work when registration fails. This fixes the issue by using the same frequency in both calls. Signed-off-by: Pali Rohár Acked-by: Gregory CLEMENT Tested-by: Tomasz Maciej Nowak Tested-by: Anders Trier Olesen Tested-by: Philip Soares Fixes: 8db82563451f ("cpufreq: armada-37xx: fix frequency calculation for opp") Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit fac19292b8c1a9019f443d758117b86c2a566ef4 Author: Pali Rohár Date: Thu Apr 8 13:42:19 2021 +0200 clk: mvebu: armada-37xx-periph: Fix workaround for switching from L1 to L0 [ Upstream commit e93033aff684641f71a436ca7a9d2a742126baaf ] When CPU frequency is at 250 MHz and set_rate() is called with 500 MHz (L1) quickly followed by a call with 1 GHz (L0), the CPU does not necessarily stay in L1 for at least 20ms as is required by Marvell errata. This situation happens frequently with the ondemand cpufreq governor and can be also reproduced with userspace governor. In most cases it causes CPU to crash. This change fixes the above issue and ensures that the CPU always stays in L1 for at least 20ms when switching from any state to L0. Signed-off-by: Marek Behún Signed-off-by: Pali Rohár Acked-by: Stephen Boyd Acked-by: Gregory CLEMENT Tested-by: Tomasz Maciej Nowak Tested-by: Anders Trier Olesen Tested-by: Philip Soares Fixes: 61c40f35f5cd ("clk: mvebu: armada-37xx-periph: Fix switching CPU rate from 300Mhz to 1.2GHz") Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 9db7efc1cef8a0585901391f06bb8a2c3f038357 Author: Pali Rohár Date: Thu Apr 8 13:42:18 2021 +0200 clk: mvebu: armada-37xx-periph: Fix switching CPU freq from 250 Mhz to 1 GHz [ Upstream commit 4decb9187589f61fe9fc2bc4d9b01160b0a610c5 ] It was observed that the workaround introduced by commit 61c40f35f5cd ("clk: mvebu: armada-37xx-periph: Fix switching CPU rate from 300Mhz to 1.2GHz") when base CPU frequency is 1.2 GHz is also required when base CPU frequency is 1 GHz. Otherwise switching CPU frequency directly from L2 (250 MHz) to L0 (1 GHz) causes a crash. When base CPU frequency is just 800 MHz no crashed were observed during switch from L2 to L0. Signed-off-by: Pali Rohár Acked-by: Stephen Boyd Acked-by: Gregory CLEMENT Tested-by: Tomasz Maciej Nowak Tested-by: Anders Trier Olesen Tested-by: Philip Soares Fixes: 2089dc33ea0e ("clk: mvebu: armada-37xx-periph: add DVFS support for cpu clocks") Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit ae1294896b133f39ae28945dd9fa073f0f9f92ea Author: Pali Rohár Date: Thu Apr 8 13:42:17 2021 +0200 cpufreq: armada-37xx: Fix the AVS value for load L1 [ Upstream commit d118ac2062b5b8331c8768ac81e016617e0996ee ] The original CPU voltage value for load L1 is too low for Armada 37xx SoC when base CPU frequency is 1000 or 1200 MHz. It leads to instabilities where CPU gets stuck soon after dynamic voltage scaling from load L1 to L0. Update the CPU voltage value for load L1 accordingly when base frequency is 1000 or 1200 MHz. The minimal L1 value for base CPU frequency 1000 MHz is updated from the original 1.05V to 1.108V and for 1200 MHz is updated to 1.155V. This minimal L1 value is used only in the case when it is lower than value for L0. This change fixes CPU instability issues on 1 GHz and 1.2 GHz variants of Espressobin and 1 GHz Turris Mox. Marvell previously for 1 GHz variant of Espressobin provided a patch [1] suitable only for their Marvell Linux kernel 4.4 fork which workarounded this issue. Patch forced CPU voltage value to 1.108V in all loads. But such change does not fix CPU instability issues on 1.2 GHz variants of Armada 3720 SoC. During testing we come to the conclusion that using 1.108V as minimal value for L1 load makes 1 GHz variants of Espressobin and Turris Mox boards stable. And similarly 1.155V for 1.2 GHz variant of Espressobin. These two values 1.108V and 1.155V are documented in Armada 3700 Hardware Specifications as typical initial CPU voltage values. Discussion about this issue is also at the Armbian forum [2]. [1] - https://github.com/MarvellEmbeddedProcessors/linux-marvell/commit/dc33b62c90696afb6adc7dbcc4ebbd48bedec269 [2] - https://forum.armbian.com/topic/10429-how-to-make-espressobin-v7-stable/ Signed-off-by: Pali Rohár Acked-by: Gregory CLEMENT Tested-by: Tomasz Maciej Nowak Tested-by: Anders Trier Olesen Tested-by: Philip Soares Fixes: 1c3528232f4b ("cpufreq: armada-37xx: Add AVS support") Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit b06442ced7760215b8ed567b1572432d97c7b3c2 Author: Marek Behún Date: Thu Apr 8 13:42:16 2021 +0200 clk: mvebu: armada-37xx-periph: remove .set_parent method for CPU PM clock [ Upstream commit 4e435a9dd26c46ac018997cc0562d50b1a96f372 ] Remove the .set_parent method in clk_pm_cpu_ops. This method was supposed to be needed by the armada-37xx-cpufreq driver, but was never actually called due to wrong assumptions in the cpufreq driver. After this was fixed in the cpufreq driver, this method is not needed anymore. Signed-off-by: Marek Behún Acked-by: Stephen Boyd Acked-by: Gregory CLEMENT Tested-by: Pali Rohár Tested-by: Tomasz Maciej Nowak Tested-by: Anders Trier Olesen Tested-by: Philip Soares Fixes: 2089dc33ea0e ("clk: mvebu: armada-37xx-periph: add DVFS support for cpu clocks") Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit ca9630b6522f794d11f9a2eec53025b8edd25edd Author: Marek Behún Date: Thu Apr 8 13:42:15 2021 +0200 cpufreq: armada-37xx: Fix setting TBG parent for load levels [ Upstream commit 22592df194e31baf371906cc720da38fa0ab68f5 ] With CPU frequency determining software [1] we have discovered that after this driver does one CPU frequency change, the base frequency of the CPU is set to the frequency of TBG-A-P clock, instead of the TBG that is parent to the CPU. This can be reproduced on EspressoBIN and Turris MOX: cd /sys/devices/system/cpu/cpufreq/policy0 echo powersave >scaling_governor echo performance >scaling_governor Running the mhz tool before this driver is loaded reports 1000 MHz, and after loading the driver and executing commands above the tool reports 800 MHz. The change of TBG clock selector is supposed to happen in function armada37xx_cpufreq_dvfs_setup. Before the function returns, it does this: parent = clk_get_parent(clk); clk_set_parent(clk, parent); The armada-37xx-periph clock driver has the .set_parent method implemented correctly for this, so if the method was actually called, this would work. But since the introduction of the common clock framework in commit b2476490ef11 ("clk: introduce the common clock..."), the clk_set_parent function checks whether the parent is actually changing, and if the requested new parent is same as the old parent (which is obviously the case for the code above), the .set_parent method is not called at all. This patch fixes this issue by filling the correct TBG clock selector directly in the armada37xx_cpufreq_dvfs_setup during the filling of other registers at the same address. But the determination of CPU TBG index cannot be done via the common clock framework, therefore we need to access the North Bridge Peripheral Clock registers directly in this driver. [1] https://github.com/wtarreau/mhz Signed-off-by: Marek Behún Acked-by: Gregory CLEMENT Tested-by: Pali Rohár Tested-by: Tomasz Maciej Nowak Tested-by: Anders Trier Olesen Tested-by: Philip Soares Fixes: 92ce45fb875d ("cpufreq: Add DVFS support for Armada 37xx") Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 5072029dae677a489aa50c5838c074088d61fdd3 Author: Lv Yunlong Date: Fri Apr 2 10:13:48 2021 -0700 crypto: qat - Fix a double free in adf_create_ring [ Upstream commit f7cae626cabb3350b23722b78fe34dd7a615ca04 ] In adf_create_ring, if the callee adf_init_ring() failed, the callee will free the ring->base_addr by dma_free_coherent() and return -EFAULT. Then adf_create_ring will goto err and the ring->base_addr will be freed again in adf_cleanup_ring(). My patch sets ring->base_addr to NULL after the first freed to avoid the double free. Fixes: a672a9dc872ec ("crypto: qat - Intel(R) QAT transport code") Signed-off-by: Lv Yunlong Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit b7bd0657c2036add71981d88a7fae50188150b6e Author: Colin Ian King Date: Thu Apr 1 16:28:39 2021 +0100 crypto: sa2ul - Fix memory leak of rxd [ Upstream commit 854b7737199848a91f6adfa0a03cf6f0c46c86e8 ] There are two error return paths that are not freeing rxd and causing memory leaks. Fix these. Addresses-Coverity: ("Resource leak") Fixes: 00c9211f60db ("crypto: sa2ul - Fix DMA mapping API usage") Signed-off-by: Colin Ian King Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit d3d702084d125689edb2b9395c707e09b471352e Author: Colin Ian King Date: Thu Apr 1 16:18:27 2021 +0100 crypto: sun8i-ss - Fix memory leak of pad [ Upstream commit 50274b01ac1689b1a3f6bc4b5b3dbf361a55dd3a ] It appears there are several failure return paths that don't seem to be free'ing pad. Fix these. Addresses-Coverity: ("Resource leak") Fixes: d9b45418a917 ("crypto: sun8i-ss - support hash algorithms") Signed-off-by: Colin Ian King Acked-by: Corentin Labbe Tested-by: Corentin Labbe Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit d385c6e4b3cc7b3ca2f7a216cccb1de09e8cce25 Author: Corentin Labbe Date: Mon Mar 29 22:12:00 2021 +0200 crypto: allwinner - add missing CRYPTO_ prefix [ Upstream commit ac1af1a788b2002eb9d6f5ca6054517ad27f1930 ] Some CONFIG select miss CRYPTO_. Reported-by: Chen-Yu Tsai Fixes: 56f6d5aee88d1 ("crypto: sun8i-ce - support hash algorithms") Fixes: d9b45418a9177 ("crypto: sun8i-ss - support hash algorithms") Signed-off-by: Corentin Labbe Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 5083a1723a33d8e3617c6128b8a282bdb6a33802 Author: Nathan Chancellor Date: Wed Apr 7 14:30:48 2021 -0700 ACPI: CPPC: Replace cppc_attr with kobj_attribute [ Upstream commit 2bc6262c6117dd18106d5aa50d53e945b5d99c51 ] All of the CPPC sysfs show functions are called via indirect call in kobj_attr_show(), where they should be of type ssize_t (*show)(struct kobject *kobj, struct kobj_attribute *attr, char *buf); because that is the type of the ->show() member in 'struct kobj_attribute' but they are actually of type ssize_t (*show)(struct kobject *kobj, struct attribute *attr, char *buf); because of the ->show() member in 'struct cppc_attr', resulting in a Control Flow Integrity violation [1]. $ cat /sys/devices/system/cpu/cpu0/acpi_cppc/highest_perf 3400 $ dmesg | grep "CFI failure" [ 175.970559] CFI failure (target: show_highest_perf+0x0/0x8): As far as I can tell, the only difference between 'struct cppc_attr' and 'struct kobj_attribute' aside from the type of the attr parameter is the type of the count parameter in the ->store() member (ssize_t vs. size_t), which does not actually matter because all of these nodes are read-only. Eliminate 'struct cppc_attr' in favor of 'struct kobj_attribute' to fix the violation. [1]: https://lore.kernel.org/r/20210401233216.2540591-1-samitolvanen@google.com/ Fixes: 158c998ea44b ("ACPI / CPPC: add sysfs support to compute delivered performance") Link: https://github.com/ClangBuiltLinux/linux/issues/1343 Signed-off-by: Nathan Chancellor Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 844b01c8fc6eca323a4da9304e55cb1a813cfaf2 Author: He Ying Date: Tue Apr 6 08:33:28 2021 -0400 cpuidle: Fix ARM_QCOM_SPM_CPUIDLE configuration [ Upstream commit 498ba2a8a2756694b6f3888857426dbc8a5e6b6c ] When CONFIG_ARM_QCOM_SPM_CPUIDLE is y and CONFIG_MMU is not set, compiling errors are encountered as follows: drivers/cpuidle/cpuidle-qcom-spm.o: In function `spm_dev_probe': cpuidle-qcom-spm.c:(.text+0x140): undefined reference to `cpu_resume_arm' cpuidle-qcom-spm.c:(.text+0x148): undefined reference to `cpu_resume_arm' Note that cpu_resume_arm is defined when MMU is set. So, add dependency on MMU in ARM_QCOM_SPM_CPUIDLE configuration. Fixes: a871be6b8eee ("cpuidle: Convert Qualcomm SPM driver to a generic CPUidle driver") Reported-by: Hulk Robot Signed-off-by: He Ying Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20210406123328.92904-1-heying24@huawei.com Signed-off-by: Sasha Levin commit a163df99821f8f16022fbb27b0ace6630cd7f1a1 Author: YueHaibing Date: Fri Apr 2 14:14:22 2021 +0800 PM: runtime: Replace inline function pm_runtime_callbacks_present() [ Upstream commit 953c1fd96b1a70bcbbfb10973c2126eba8d891c7 ] Commit 9a7875461fd0 ("PM: runtime: Replace pm_runtime_callbacks_present()") forgot to change the inline version. Fixes: 9a7875461fd0 ("PM: runtime: Replace pm_runtime_callbacks_present()") Signed-off-by: YueHaibing Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit c9c1ee0120fda8eb006b799533cf312fd63b9ab7 Author: Bjorn Andersson Date: Thu Jan 7 15:25:26 2021 -0800 soc: qcom: mdt_loader: Detect truncated read of segments [ Upstream commit 0648c55e3a21ccd816e99b6600d6199fbf39d23a ] Given that no validation of how much data the firmware loader read in for a given segment truncated segment files would best case result in a hash verification failure, without any indication of what went wrong. Improve this by validating that the firmware loader did return the amount of data requested. Fixes: 445c2410a449 ("soc: qcom: mdt_loader: Use request_firmware_into_buf()") Reviewed-by: Sibi Sankar Link: https://lore.kernel.org/r/20210107232526.716989-1-bjorn.andersson@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 0382a1e02cc36a8e9e9386824e15c1fba7a09e78 Author: Bjorn Andersson Date: Thu Jan 7 15:31:19 2021 -0800 soc: qcom: mdt_loader: Validate that p_filesz < p_memsz [ Upstream commit 84168d1b54e76a1bcb5192991adde5176abe02e3 ] The code validates that segments of p_memsz bytes of a segment will fit in the provided memory region, but does not validate that p_filesz bytes will, which means that an incorrectly crafted ELF header might write beyond the provided memory region. Fixes: 051fb70fd4ea ("remoteproc: qcom: Driver for the self-authenticating Hexagon v5") Reviewed-by: Sibi Sankar Link: https://lore.kernel.org/r/20210107233119.717173-1-bjorn.andersson@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 0eb78f53cae456d4320381cc52588f9c6f281a5b Author: Yang Yingliang Date: Thu Apr 1 22:03:50 2021 +0800 spi: fsl: add missing iounmap() on error in of_fsl_spi_probe() [ Upstream commit 5fed9fe5b41aea58e5b32be506dc50c9ab9a0e4d ] Add the missing iounmap() before return from of_fsl_spi_probe() in the error handling case. Fixes: 0f0581b24bd0 ("spi: fsl: Convert to use CS GPIO descriptors") Reported-by: Hulk Robot Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20210401140350.1677925-1-yangyingliang@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 8735248ebb918d25427965f0db07939ed0473ec6 Author: William A. Kennington III Date: Wed Apr 7 02:55:27 2021 -0700 spi: Fix use-after-free with devm_spi_alloc_* [ Upstream commit 794aaf01444d4e765e2b067cba01cc69c1c68ed9 ] We can't rely on the contents of the devres list during spi_unregister_controller(), as the list is already torn down at the time we perform devres_find() for devm_spi_release_controller. This causes devices registered with devm_spi_alloc_{master,slave}() to be mistakenly identified as legacy, non-devm managed devices and have their reference counters decremented below 0. ------------[ cut here ]------------ WARNING: CPU: 1 PID: 660 at lib/refcount.c:28 refcount_warn_saturate+0x108/0x174 [] (refcount_warn_saturate) from [] (kobject_put+0x90/0x98) [] (kobject_put) from [] (put_device+0x20/0x24) r4:b6700140 [] (put_device) from [] (devm_spi_release_controller+0x3c/0x40) [] (devm_spi_release_controller) from [] (release_nodes+0x84/0xc4) r5:b6700180 r4:b6700100 [] (release_nodes) from [] (devres_release_all+0x5c/0x60) r8:b1638c54 r7:b117ad94 r6:b1638c10 r5:b117ad94 r4:b163dc10 [] (devres_release_all) from [] (__device_release_driver+0x144/0x1ec) r5:b117ad94 r4:b163dc10 [] (__device_release_driver) from [] (device_driver_detach+0x84/0xa0) r9:00000000 r8:00000000 r7:b117ad94 r6:b163dc54 r5:b1638c10 r4:b163dc10 [] (device_driver_detach) from [] (unbind_store+0xe4/0xf8) Instead, determine the devm allocation state as a flag on the controller which is guaranteed to be stable during cleanup. Fixes: 5e844cc37a5c ("spi: Introduce device-managed SPI controller allocation") Signed-off-by: William A. Kennington III Link: https://lore.kernel.org/r/20210407095527.2771582-1-wak@google.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 27502a922ec03b970e95a455b8e5474c72ededde Author: Wei Yongjun Date: Mon Mar 8 12:30:31 2021 +0000 clocksource/drivers/ingenic_ost: Fix return value check in ingenic_ost_probe() [ Upstream commit 2a65f7e2772613debd03fa2492e76a635aa04545 ] In case of error, the function device_node_to_regmap() returns ERR_PTR() and never returns NULL. The NULL test in the return value check should be replaced with IS_ERR(). Fixes: ca7b72b5a5f2 ("clocksource: Add driver for the Ingenic JZ47xx OST") Reported-by: Hulk Robot Signed-off-by: Wei Yongjun Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20210308123031.2285083-1-weiyongjun1@huawei.com Signed-off-by: Sasha Levin commit bf2333393f33b9405727d5c3a0a151b0c558d01e Author: Tony Lindgren Date: Thu Mar 4 09:21:35 2021 +0200 clocksource/drivers/timer-ti-dm: Add missing set_state_oneshot_stopped [ Upstream commit ac4daf737674b4d29e19b7c300caff3bcf7160d8 ] To avoid spurious timer interrupts when KTIME_MAX is used, we need to configure set_state_oneshot_stopped(). Although implementing this is optional, it still affects things like power management for the extra timer interrupt. For more information, please see commit 8fff52fd5093 ("clockevents: Introduce CLOCK_EVT_STATE_ONESHOT_STOPPED state") and commit cf8c5009ee37 ("clockevents/drivers/arm_arch_timer: Implement ->set_state_oneshot_stopped()"). Fixes: 52762fbd1c47 ("clocksource/drivers/timer-ti-dm: Add clockevent and clocksource support") Signed-off-by: Tony Lindgren Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20210304072135.52712-4-tony@atomide.com Signed-off-by: Sasha Levin commit d510293acb68cbb4e5334b85908763cf09216fcd Author: Tony Lindgren Date: Thu Mar 4 09:21:33 2021 +0200 clocksource/drivers/timer-ti-dm: Fix posted mode status check order [ Upstream commit 212709926c5493a566ca4086ad4f4b0d4e66b553 ] When the timer is configured in posted mode, we need to check the write- posted status register (TWPS) before writing to the register. We now check TWPS after the write starting with commit 52762fbd1c47 ("clocksource/drivers/timer-ti-dm: Add clockevent and clocksource support"). For example, in the TRM for am571x the following is documented in chapter "22.2.4.13.1.1 Write Posting Synchronization Mode": "For each register, a status bit is provided in the timer write-posted status (TWPS) register. In this mode, it is mandatory that software check this status bit before any write access. If a write is attempted to a register with a previous access pending, the previous access is discarded without notice." The regression happened when I updated the code to use standard read/write accessors for the driver instead of using __omap_dm_timer_load_start(). We have__omap_dm_timer_load_start() check the TWPS status correctly using __omap_dm_timer_write(). Fixes: 52762fbd1c47 ("clocksource/drivers/timer-ti-dm: Add clockevent and clocksource support") Signed-off-by: Tony Lindgren Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20210304072135.52712-2-tony@atomide.com Signed-off-by: Sasha Levin commit c0053d344069b6a1035feb232129e9457f1eb09f Author: Dong Aisheng Date: Tue Mar 23 15:20:08 2021 +0800 PM / devfreq: Use more accurate returned new_freq as resume_freq [ Upstream commit 62453f1ba5d5def9d58e140a50f3f168f028da38 ] Use the more accurate returned new_freq as resume_freq. It's the same as how devfreq->previous_freq was updated. Fixes: 83f8ca45afbf0 ("PM / devfreq: add support for suspend/resume of a devfreq device") Signed-off-by: Dong Aisheng Signed-off-by: Chanwoo Choi Signed-off-by: Sasha Levin commit 4c3988bcc3e55f3b4a335fb2cb83ac1b5a24feb7 Author: Qinglang Miao Date: Wed Nov 25 14:50:34 2020 +0800 soc: qcom: pdr: Fix error return code in pdr_register_listener [ Upstream commit 769738fc49bb578e05d404b481a9241d18147d86 ] Fix to return the error code -EREMOTEIO from pdr_register_listener rather than 0. Fixes: fbe639b44a82 ("soc: qcom: Introduce Protection Domain Restart helpers") Reported-by: Hulk Robot Signed-off-by: Qinglang Miao Link: https://lore.kernel.org/r/20201125065034.154217-1-miaoqinglang@huawei.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 3222157c9d2d0ebd6cc07651f58173d66b85f552 Author: Hans de Goede Date: Sun Mar 21 13:16:07 2021 +0100 platform/x86: dell-wmi-sysman: Make init_bios_attributes() ACPI object parsing more robust [ Upstream commit 5e3f5973c8dfd2b80268f1825ed2f2ddf81d3267 ] Make init_bios_attributes() ACPI object parsing more robust: 1. Always check that the type of the return ACPI object is package, rather then only checking this for instance_id == 0 2. Check that the package has the minimum amount of elements which will be consumed by the populate_foo_data() for the attr_type Note/TODO: The populate_foo_data() functions should also be made more robust. The should check the type of each of the elements matches the type which they expect and in case of populate_enum_data() obj->package.count should be passed to it as an argument and it should re-check this itself since it consume a variable number of elements. Fixes: e8a60aa7404b ("platform/x86: Introduce support for Systems Management Driver over WMI for Dell Systems") Cc: Divya Bharathi Cc: Mario Limonciello Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20210321121607.35717-1-hdegoede@redhat.com Signed-off-by: Sasha Levin commit 9acb52e70c182c0ff1355c63de60b20e6e750348 Author: Johan Hovold Date: Wed Apr 7 12:23:24 2021 +0200 staging: greybus: uart: fix unprivileged TIOCCSERIAL [ Upstream commit 60c6b305c11b5fd167ce5e2ce42f3a9098c388f0 ] TIOCSSERIAL is a horrid, underspecified, legacy interface which for most serial devices is only useful for setting the close_delay and closing_wait parameters. A non-privileged user has only ever been able to set the since long deprecated ASYNC_SPD flags and trying to change any other *supported* feature should result in -EPERM being returned. Setting the current values for any supported features should return success. Fix the greybus implementation which instead indicated that the TIOCSSERIAL ioctl was not even implemented when a non-privileged user set the current values. Fixes: e68453ed28c5 ("greybus: uart-gb: now builds, more framework added") Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20210407102334.32361-7-johan@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 15ee91744b237129623afb798d9b9a585c06daa4 Author: Johan Hovold Date: Wed Apr 7 12:23:22 2021 +0200 staging: fwserial: fix TIOCGSERIAL implementation [ Upstream commit 5e84a66f3682af4f177bb24bb2ad5135c51f764a ] TIOCSSERIAL is a horrid, underspecified, legacy interface which for most serial devices is only useful for setting the close_delay and closing_wait parameters. The xmit_fifo_size parameter could be used to set the hardware transmit fifo size of a legacy UART when it could not be detected, but the interface is limited to eight bits and should be left unset when not used. Fix the fwserial implementation by dropping its custom interpretation of the unused xmit_fifo_size field, which was overflowed with the driver FIFO size. Also leave the type and flags fields unset as these cannot be changed. The close_delay and closing_wait parameters returned by TIOCGSERIAL are specified in centiseconds. The driver does not yet support changing closing_wait, but let's report back the default value actually used (30 seconds). Fixes: 7355ba3445f2 ("staging: fwserial: Add TTY-over-Firewire serial driver") Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20210407102334.32361-5-johan@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a6dae92dda49b7c938aea766507cdbede8f7e256 Author: Johan Hovold Date: Wed Apr 7 12:23:21 2021 +0200 staging: fwserial: fix TIOCSSERIAL implementation [ Upstream commit a7eaaa9d1032e68669bb479496087ba8fc155ab6 ] TIOCSSERIAL is a horrid, underspecified, legacy interface which for most serial devices is only useful for setting the close_delay and closing_wait parameters. A non-privileged user has only ever been able to set the since long deprecated ASYNC_SPD flags and trying to change any other *supported* feature should result in -EPERM being returned. Setting the current values for any supported features should return success. Fix the fwserial implementation which was returning -EPERM also for a privileged user when trying to change certain unsupported parameters, and instead return success consistently. Fixes: 7355ba3445f2 ("staging: fwserial: Add TTY-over-Firewire serial driver") Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20210407102334.32361-4-johan@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit faad1643e53bc3841aaab261e9dbdb82d9cf68a4 Author: Colin Ian King Date: Wed Apr 7 16:03:08 2021 +0100 staging: rtl8192u: Fix potential infinite loop [ Upstream commit f9b9263a25dc3d2eaaa829e207434db6951ca7bc ] The for-loop iterates with a u8 loop counter i and compares this with the loop upper limit of riv->ieee80211->LinkDetectInfo.SlotNum that is a u16 type. There is a potential infinite loop if SlotNum is larger than the u8 loop counter. Fix this by making the loop counter the same type as SlotNum. Addresses-Coverity: ("Infinite loop") Fixes: 8fc8598e61f6 ("Staging: Added Realtek rtl8192u driver to staging") Signed-off-by: Colin Ian King Link: https://lore.kernel.org/r/20210407150308.496623-1-colin.king@canonical.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 74b525963c794d624af589f8ad542187b5b8d8de Author: Ian Abbott Date: Wed Apr 7 15:01:38 2021 +0100 staging: comedi: tests: ni_routes_test: Fix compilation error [ Upstream commit 6db58ed2b2d9bb1792eace4f9aa70e8bdd730ffc ] The `ni_routes_test` module is not currently selectable using the Kconfig files, but can be built by specifying `CONFIG_COMEDI_TESTS=m` on the "make" command line. It currently fails to compile due to an extra parameter added to the `ni_assign_device_routes` function by commit e3b7ce73c578 ("staging: comedi: ni_routes: Allow alternate board name for routes"). Fix it by supplying the value `NULL` for the added `alt_board_name` parameter (which specifies that there is no alternate board name). Fixes: e3b7ce73c578 ("staging: comedi: ni_routes: Allow alternate board name for routes") Cc: Spencer E. Olson Signed-off-by: Ian Abbott Link: https://lore.kernel.org/r/20210407140142.447250-2-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 073b6c00f4a6f0efd76a91047e0c7b9b9b57972a Author: Arnd Bergmann Date: Tue Mar 23 14:18:35 2021 +0100 irqchip/gic-v3: Fix OF_BAD_ADDR error handling [ Upstream commit 8e13d96670a4c050d4883e6743a9e9858e5cfe10 ] When building with extra warnings enabled, clang points out a mistake in the error handling: drivers/irqchip/irq-gic-v3-mbi.c:306:21: error: result of comparison of constant 18446744073709551615 with expression of type 'phys_addr_t' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare] if (mbi_phys_base == OF_BAD_ADDR) { Truncate the constant to the same type as the variable it gets compared to, to shut make the check work and void the warning. Fixes: 505287525c24 ("irqchip/gic-v3: Add support for Message Based Interrupts as an MSI controller") Signed-off-by: Arnd Bergmann Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20210323131842.2773094-1-arnd@kernel.org Signed-off-by: Sasha Levin commit c8994829f8dada2c82b942e118a04f294995b88f Author: Lv Yunlong Date: Fri Apr 2 23:09:05 2021 -0700 mtd: rawnand: gpmi: Fix a double free in gpmi_nand_init [ Upstream commit 076de75de1e53160e9b099f75872c1f9adf41a0b ] If the callee gpmi_alloc_dma_buffer() failed to alloc memory for this->raw_buffer, gpmi_free_dma_buffer() will be called to free this->auxiliary_virt. But this->auxiliary_virt is still a non-NULL and valid ptr. Then gpmi_alloc_dma_buffer() returns err and gpmi_free_dma_buffer() is called again to free this->auxiliary_virt in err_out. This causes a double free. As gpmi_free_dma_buffer() has already called in gpmi_alloc_dma_buffer's error path, so it should return err directly instead of releasing the dma buffer again. Fixes: 4d02423e9afe6 ("mtd: nand: gpmi: Fix gpmi_nand_init() error path") Signed-off-by: Lv Yunlong Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210403060905.5251-1-lyl2019@mail.ustc.edu.cn Signed-off-by: Sasha Levin commit 0b5e17391e624764d62f9b65fa1a92c72d6b1acb Author: Alexandru Ardelean Date: Wed Mar 24 20:27:46 2021 +0200 iio: adc: Kconfig: make AD9467 depend on ADI_AXI_ADC symbol [ Upstream commit 194eafc9c1d49b53b59de9821fb63d423344cae3 ] Because a dependency on HAS_IOMEM and OF was added for the ADI AXI ADC driver, this makes the AD9467 driver have some build/dependency issues when OF is disabled (typically on ACPI archs like x86). This is because the selection of the AD9467 enforces the ADI_AXI_ADC symbol which is blocked by the OF (and potentially HAS_IOMEM) being disabled. To fix this, we make the AD9467 driver depend on the ADI_AXI_ADC symbol. The AD9467 driver cannot operate on it's own. It requires the ADI AXI ADC driver to stream data (or some similar IIO interface). So, the fix here is to make the AD9467 symbol depend on the ADI_AXI_ADC symbol. At some point this could become it's own subgroup of high-speed ADCs. Fixes: be24c65e9fa24 ("iio: adc: adi-axi-adc: add proper Kconfig dependencies") Reported-by: Randy Dunlap Signed-off-by: Alexandru Ardelean Acked-by: Randy Dunlap Link: https://lore.kernel.org/r/20210324182746.9337-1-aardelean@deviqon.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit ff2f0383b537118eeefe3565cfafdf165058d95c Author: Stephen Boyd Date: Tue Feb 23 13:45:36 2021 -0800 firmware: qcom_scm: Workaround lack of "is available" call on SC7180 [ Upstream commit 257f2935cbbf14b16912c635fcd8ff43345c953b ] Some SC7180 firmwares don't implement the QCOM_SCM_INFO_IS_CALL_AVAIL API, so we can't probe the calling convention. We detect the legacy calling convention on these firmwares, because the availability call always fails and legacy is the fallback. This leads to problems where the rmtfs driver fails to probe, because it tries to assign memory with a bad calling convention, which then leads to modem failing to load and all networking, even wifi, to fail. Ouch! Let's force the calling convention to be what it always is on this SoC, i.e. arm64. Of course, the calling convention is not the same thing as implementing the QCOM_SCM_INFO_IS_CALL_AVAIL API. The absence of the "is this call available" API from the firmware means that any call to __qcom_scm_is_call_available() fails. This is OK for now though because none of the calls that are checked for existence are implemented on firmware running on sc7180. If such a call needs to be checked for existence in the future, we presume that firmware will implement this API and then things will "just work". Cc: Elliot Berman Cc: Brian Masney Cc: Stephan Gerhold Cc: Jeffrey Hugo Cc: Douglas Anderson Fixes: 9a434cee773a ("firmware: qcom_scm: Dynamically support SMCCC and legacy conventions") Signed-off-by: Stephen Boyd Link: https://lore.kernel.org/r/20210223214539.1336155-4-swboyd@chromium.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 1fcaf5e2188f2b82d6259b3c17c4983ec23b8bc3 Author: Stephen Boyd Date: Tue Feb 23 13:45:35 2021 -0800 firmware: qcom_scm: Reduce locking section for __get_convention() [ Upstream commit f6ea568f0ddcdfad52807110ed8983e610f0e03b ] We shouldn't need to hold this spinlock here around the entire SCM call into the firmware and back. Instead, we should be able to query the firmware, potentially in parallel with other CPUs making the same convention detection firmware call, and then grab the lock to update the calling convention detected. The convention doesn't change at runtime so calling into firmware more than once is possibly wasteful but simpler. Besides, this is the slow path, not the fast path where we've already detected the convention used. More importantly, this allows us to add more logic here to workaround the case where the firmware call to check for availability isn't implemented in the firmware at all. In that case we can check the firmware node compatible string and force a calling convention. Note that we remove the 'has_queried' logic that is repeated twice. That could lead to the calling convention being printed multiple times to the kernel logs if the bool is true but __query_convention() is running on multiple CPUs. We also shorten the time where the lock is held, but we keep the lock held around the printk because it doesn't seem hugely important to drop it for that. Cc: Elliot Berman Cc: Brian Masney Cc: Stephan Gerhold Cc: Jeffrey Hugo Cc: Douglas Anderson Fixes: 9a434cee773a ("firmware: qcom_scm: Dynamically support SMCCC and legacy conventions") Signed-off-by: Stephen Boyd Link: https://lore.kernel.org/r/20210223214539.1336155-3-swboyd@chromium.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit cba3020b926485dbcbeca4b3b09a6a32db772ebe Author: Stephen Boyd Date: Tue Feb 23 13:45:34 2021 -0800 firmware: qcom_scm: Make __qcom_scm_is_call_available() return bool [ Upstream commit 9d11af8b06a811c5c4878625f51ce109e2af4e80 ] Make __qcom_scm_is_call_available() return bool instead of int. The function has "is" in the name, so it should return a bool to indicate the truth of the call being available. Unfortunately, it can return a number < 0 which also looks "true", but not all callers expect that and thus they think a call is available when really the check to see if the call is available failed to figure it out. Reviewed-by: Bjorn Andersson Cc: Elliot Berman Cc: Brian Masney Cc: Stephan Gerhold Cc: Jeffrey Hugo Cc: Douglas Anderson Fixes: 0f206514749b ("scsi: firmware: qcom_scm: Add support for programming inline crypto keys") Fixes: 0434a4061471 ("firmware: qcom: scm: add support to restore secure config to qcm_scm-32") Fixes: b0a1614fb1f5 ("firmware: qcom: scm: add OCMEM lock/unlock interface") Signed-off-by: Stephen Boyd Link: https://lore.kernel.org/r/20210223214539.1336155-2-swboyd@chromium.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 5d34225169346cab5145978d153b9ce90e9ace21 Author: Finn Thain Date: Tue Mar 30 18:37:51 2021 +1100 m68k: mvme147,mvme16x: Don't wipe PCC timer config bits [ Upstream commit 43262178c043032e7c42d00de44c818ba05f9967 ] Don't clear the timer 1 configuration bits when clearing the interrupt flag and counter overflow. As Michael reported, "This results in no timer interrupts being delivered after the first. Initialization then hangs in calibrate_delay as the jiffies counter is not updated." On mvme16x, enable the timer after requesting the irq, consistent with mvme147. Cc: Michael Pavone Fixes: 7529b90d051e ("m68k: mvme147: Handle timer counter overflow") Fixes: 19999a8b8782 ("m68k: mvme16x: Handle timer counter overflow") Reported-and-tested-by: Michael Pavone Signed-off-by: Finn Thain Link: https://lore.kernel.org/r/4fdaa113db089b8fb607f7dd818479f8cdcc4547.1617089871.git.fthain@telegraphics.com.au Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit effd2bd62b416f6629e18e3ce077c60de14cfdea Author: Rander Wang Date: Wed Mar 31 08:46:10 2021 +0800 soundwire: stream: fix memory leak in stream config error path [ Upstream commit 48f17f96a81763c7c8bf5500460a359b9939359f ] When stream config is failed, master runtime will release all slave runtime in the slave_rt_list, but slave runtime is not added to the list at this time. This patch frees slave runtime in the config error path to fix the memory leak. Fixes: 89e590535f32 ("soundwire: Add support for SoundWire stream management") Signed-off-by: Rander Wang Reviewed-by: Keyon Jie Reviewed-by: Guennadi Liakhovetski Reviewed-by: Pierre-Louis Bossart Signed-off-by: Bard Liao Link: https://lore.kernel.org/r/20210331004610.12242-1-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 60015b30417e6c8bfcb462da17e34bb647ea44c4 Author: gexueyuan Date: Wed Mar 31 11:10:56 2021 +0800 memory: pl353: fix mask of ECC page_size config register [ Upstream commit 25dcca7fedcd4e31cb368ad846bfd738c0c6307c ] The mask for page size of ECC Configuration Register should be 0x3, according to the datasheet of PL353 smc. Fixes: fee10bd22678 ("memory: pl353: Add driver for arm pl353 static memory controller") Signed-off-by: gexueyuan Link: https://lore.kernel.org/r/20210331031056.5326-1-gexueyuan@gmail.com Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit 8d2a65bf858ac7942566c1ef36fe6439afe24068 Author: Krzysztof Kozlowski Date: Wed Mar 3 19:28:16 2021 +0100 ARM: dts: qcom: msm8974-samsung-klte: correct fuel gauge interrupt trigger level [ Upstream commit 5fde3361ba57a9b4eb560dabf859176909d61004 ] The Maxim fuel gauge datasheets describe the interrupt line as active low with a requirement of acknowledge from the CPU. The falling edge interrupt will mostly work but it's not correct. Fixes: da8d46992e67 ("ARM: dts: qcom: msm8974-klte: Add fuel gauge") Signed-off-by: Krzysztof Kozlowski Acked-By: Iskren Chernev Tested-By: Iskren Chernev Link: https://lore.kernel.org/r/20210303182816.137255-2-krzk@kernel.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 7241c948b4122f53b0d79442cbffc56659b58bea Author: Krzysztof Kozlowski Date: Wed Mar 3 19:28:15 2021 +0100 ARM: dts: qcom: msm8974-lge-nexus5: correct fuel gauge interrupt trigger level [ Upstream commit 9d816b423dab5b59beec5e39b97428feac599ba7 ] The Maxim fuel gauge datasheets describe the interrupt line as active low with a requirement of acknowledge from the CPU. The falling edge interrupt will mostly work but it's not correct. Fixes: 45dfa741df86 ("ARM: dts: qcom: msm8974-lge-nexus5: Add fuel gauge") Signed-off-by: Krzysztof Kozlowski Acked-by: Iskren Chernev Link: https://lore.kernel.org/r/20210303182816.137255-1-krzk@kernel.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 57d5dee58ce7d8bc858bcf828413adb2277fe142 Author: Andy Shevchenko Date: Wed Mar 31 18:05:25 2021 +0300 driver core: platform: Declare early_platform_cleanup() prototype [ Upstream commit 1768289b44bae847612751d418fc5c5e680b5e5c ] Compiler is not happy: CC drivers/base/platform.o drivers/base/platform.c:1557:20: warning: no previous prototype for ‘early_platform_cleanup’ [-Wmissing-prototypes] 1557 | void __weak __init early_platform_cleanup(void) { } | ^~~~~~~~~~~~~~~~~~~~~~ Declare early_platform_cleanup() prototype in the header to make everyone happy. Fixes: eecd37e105f0 ("drivers: Fix boot problem on SuperH") Cc: Guenter Roeck Reviewed-by: Guenter Roeck Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210331150525.59223-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 8832b172ff0fbf3709a83ea45e3d913797d39a50 Author: Srinivas Kandagatla Date: Tue Mar 30 12:12:39 2021 +0100 nvmem: rmem: fix undefined reference to memremap [ Upstream commit cc1bc56fdc76a55bb8fae9a145a2e60bf22fb129 ] Fix below error reporte by kernel test robot rmem.c:(.text+0x14e): undefined reference to memremap s390x-linux-gnu-ld: rmem.c:(.text+0x1b6): undefined reference to memunmap Fixes: 5a3fa75a4d9c ("nvmem: Add driver to expose reserved memory as nvmem") Reported-by: kernel test robot Reviewed-by: Nicolas Saenz Julienne Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20210330111241.19401-9-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit df60888bf3e46c58c13632c29d4e1bdcc6483df8 Author: Ravi Kumar Bokka Date: Tue Mar 30 12:12:34 2021 +0100 drivers: nvmem: Fix voltage settings for QTI qfprom-efuse [ Upstream commit 9ec4f4b0e9fd3ad4b9a38bddb75b516ea09f4628 ] QFPROM controller hardware requires 1.8V min for fuse blowing. So, this change sets the voltage to 1.8V, required to blow the fuse for qfprom-efuse controller. To disable fuse blowing, we set the voltage to 0V since this may be a shared rail and may be able to run at a lower rate when we're not blowing fuses. Fixes: 93b4e49f8c86 ("nvmem: qfprom: Add fuse blowing support") Reported-by: Douglas Anderson Suggested-by: Douglas Anderson Reviewed-by: Douglas Anderson Signed-off-by: Ravi Kumar Bokka Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20210330111241.19401-4-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit b93e0b45015e6fc0fea4f3af8cb9328982c1ef46 Author: Yang Yingliang Date: Tue Mar 30 21:01:59 2021 +0800 USB: gadget: udc: fix wrong pointer passed to IS_ERR() and PTR_ERR() [ Upstream commit 2e3d055bf27d70204cae349335a62a4f9b7c165a ] IS_ERR() and PTR_ERR() use wrong pointer, it should be udc->virt_addr, fix it. Fixes: 1b9f35adb0ff ("usb: gadget: udc: Add Synopsys UDC Platform driver") Reported-by: Hulk Robot Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20210330130159.1051979-1-yangyingliang@huawei.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit df65ce0372349bc3b14cd04090df3f3cd95b26de Author: Tao Ren Date: Tue Mar 30 21:58:31 2021 -0700 usb: gadget: aspeed: fix dma map failure [ Upstream commit bd4d607044b961cecbf8c4c2f3bb5da4fb156993 ] Currently the virtual port_dev device is passed to DMA API, and this is wrong because the device passed to DMA API calls must be the actual hardware device performing the DMA. The patch replaces usb_gadget_map_request/usb_gadget_unmap_request APIs with usb_gadget_map_request_by_dev/usb_gadget_unmap_request_by_dev APIs so the DMA capable platform device can be passed to the DMA APIs. The patch fixes below backtrace detected on Facebook AST2500 OpenBMC platforms: [<80106550>] show_stack+0x20/0x24 [<80106868>] dump_stack+0x28/0x30 [<80823540>] __warn+0xfc/0x110 [<8011ac30>] warn_slowpath_fmt+0xb0/0xc0 [<8011ad44>] dma_map_page_attrs+0x24c/0x314 [<8016a27c>] usb_gadget_map_request_by_dev+0x100/0x1e4 [<805cedd8>] usb_gadget_map_request+0x1c/0x20 [<805cefbc>] ast_vhub_epn_queue+0xa0/0x1d8 [<7f02f710>] usb_ep_queue+0x48/0xc4 [<805cd3e8>] ecm_do_notify+0xf8/0x248 [<7f145920>] ecm_set_alt+0xc8/0x1d0 [<7f145c34>] composite_setup+0x680/0x1d30 [<7f00deb8>] ast_vhub_ep0_handle_setup+0xa4/0x1bc [<7f02ee94>] ast_vhub_dev_irq+0x58/0x84 [<7f0309e0>] ast_vhub_irq+0xb0/0x1c8 [<7f02e118>] __handle_irq_event_percpu+0x50/0x19c [<8015e5bc>] handle_irq_event_percpu+0x38/0x8c [<8015e758>] handle_irq_event+0x38/0x4c Fixes: 7ecca2a4080c ("usb/gadget: Add driver for Aspeed SoC virtual hub") Reviewed-by: Joel Stanley Signed-off-by: Tao Ren Link: https://lore.kernel.org/r/20210331045831.28700-1-rentao.bupt@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 4d8392fba0f27de35f884eab6cc5790f0eaa9677 Author: Giovanni Cabiddu Date: Thu Mar 25 08:34:18 2021 +0000 crypto: qat - fix error path in adf_isr_resource_alloc() [ Upstream commit 83dc1173d73f80cbce2fee4d308f51f87b2f26ae ] The function adf_isr_resource_alloc() is not unwinding correctly in case of error. This patch fixes the error paths and propagate the errors to the caller. Fixes: 7afa232e76ce ("crypto: qat - Intel(R) QAT DH895xcc accelerator") Signed-off-by: Giovanni Cabiddu Reviewed-by: Marco Chiappero Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit a542f220b4b1b02a5d36dec45e5fc9072b8577cc Author: Arnd Bergmann Date: Mon Mar 22 18:05:15 2021 +0100 crypto: poly1305 - fix poly1305_core_setkey() declaration [ Upstream commit 8d195e7a8ada68928f2aedb2c18302a4518fe68e ] gcc-11 points out a mismatch between the declaration and the definition of poly1305_core_setkey(): lib/crypto/poly1305-donna32.c:13:67: error: argument 2 of type ‘const u8[16]’ {aka ‘const unsigned char[16]’} with mismatched bound [-Werror=array-parameter=] 13 | void poly1305_core_setkey(struct poly1305_core_key *key, const u8 raw_key[16]) | ~~~~~~~~~^~~~~~~~~~~ In file included from lib/crypto/poly1305-donna32.c:11: include/crypto/internal/poly1305.h:21:68: note: previously declared as ‘const u8 *’ {aka ‘const unsigned char *’} 21 | void poly1305_core_setkey(struct poly1305_core_key *key, const u8 *raw_key); This is harmless in principle, as the calling conventions are the same, but the more specific prototype allows better type checking in the caller. Change the declaration to match the actual function definition. The poly1305_simd_init() is a bit suspicious here, as it previously had a 32-byte argument type, but looks like it needs to take the 16-byte POLY1305_BLOCK_SIZE array instead. Fixes: 1c08a104360f ("crypto: poly1305 - add new 32 and 64-bit generic versions") Signed-off-by: Arnd Bergmann Reviewed-by: Ard Biesheuvel Reviewed-by: Eric Biggers Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 8b37c99d66b45e1828e6ca46d3a2f6a4265169d0 Author: Olga Kornievskaia Date: Tue Mar 30 15:03:59 2021 -0400 NFSv4.2: fix copy stateid copying for the async copy [ Upstream commit e739b12042b6b079a397a3c234f96c09d1de0b40 ] This patch fixes Dan Carpenter's report that the static checker found a problem where memcpy() was copying into too small of a buffer. Reported-by: Dan Carpenter Fixes: e0639dc5805a ("NFSD introduce async copy feature") Signed-off-by: Olga Kornievskaia Signed-off-by: Chuck Lever Reviewed-by: Dai Ngo Signed-off-by: Sasha Levin commit 3f647a08416d12fdfb3b00aaaba2beecb484c41a Author: Fabien Parent Date: Tue Feb 23 23:18:26 2021 +0100 arm64: dts: mediatek: fix reset GPIO level on pumpkin [ Upstream commit a7dceafed43a4a610d340da3703653cca2c50c1d ] The tca6416 chip is active low. Fix the reset-gpios value. Fixes: e2a8fa1e0faa ("arm64: dts: mediatek: fix tca6416 reset GPIOs in pumpkin") Signed-off-by: Fabien Parent Link: https://lore.kernel.org/r/20210223221826.2063911-1-fparent@baylibre.com Signed-off-by: Matthias Brugger Signed-off-by: Sasha Levin commit fd8a29ca0d8f19a732a5eee34917daa1be785d32 Author: Wei Yongjun Date: Fri Mar 5 03:49:33 2021 +0000 phy: ingenic: Fix a typo in ingenic_usb_phy_probe() [ Upstream commit 446c200ee3e8f6faf189ef6f25a0f5bb294afae4 ] Fix the return value check typo which testing the wrong variable in ingenic_usb_phy_probe(). Fixes: 31de313dfdcf ("PHY: Ingenic: Add USB PHY driver using generic PHY framework.") Reported-by: Hulk Robot Signed-off-by: Wei Yongjun Acked-by: Paul Cercueil Link: https://lore.kernel.org/r/20210305034933.3240914-1-weiyongjun1@huawei.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 9249b7fa71a4da06a8d5a7ff778ecce3065faba5 Author: Wei Yongjun Date: Fri Mar 5 03:49:31 2021 +0000 phy: ralink: phy-mt7621-pci: fix return value check in mt7621_pci_phy_probe() [ Upstream commit b976c987511e34a2e9b23545de912a121a9eded5 ] Fix the return value check which testing the wrong variable in mt7621_pci_phy_probe(). Fixes: d87da32372a0 ("phy: ralink: Add PHY driver for MT7621 PCIe PHY") Reported-by: Hulk Robot Signed-off-by: Wei Yongjun Reviewed-by: Sergio Paracuellos Link: https://lore.kernel.org/r/20210305034931.3237558-1-weiyongjun1@huawei.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit fd5378456e4ec1a9a1cebd4d1d7f4502115341bd Author: Geert Uytterhoeven Date: Mon Feb 8 16:02:52 2021 +0100 phy: marvell: ARMADA375_USBCLUSTER_PHY should not default to y, unconditionally [ Upstream commit 6cb17707aad869de163d7bf42c253caf501be4e2 ] Merely enabling CONFIG_COMPILE_TEST should not enable additional code. To fix this, restrict the automatic enabling of ARMADA375_USBCLUSTER_PHY to MACH_ARMADA_375, and ask the user in case of compile-testing. Fixes: eee47538ec1f2619 ("phy: add support for USB cluster on the Armada 375 SoC") Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20210208150252.424706-1-geert+renesas@glider.be Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 4fd6c07cea3b50ea0b0ea30afb87f04dbad6cda3 Author: Sergio Paracuellos Date: Tue Mar 2 11:54:12 2021 +0100 phy: ralink: phy-mt7621-pci: fix XTAL bitmask [ Upstream commit 982313c38f2f3793b6435ff50997ae96a2274f5a ] When this was rewriten to get mainlined and start to use 'linux/bitfield.h' headers, XTAL_MASK was wrong. It must mask three bits but only two were used. Hence properly fix it to make things work. Fixes: d87da32372a0 ("phy: ralink: Add PHY driver for MT7621 PCIe PHY") Signed-off-by: Sergio Paracuellos Link: https://lore.kernel.org/r/20210302105412.16221-1-sergio.paracuellos@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit bb476294d362e312b9de58e773753c5da708e376 Author: Kishon Vijay Abraham I Date: Wed Mar 10 17:38:36 2021 +0530 phy: ti: j721e-wiz: Delete "clk_div_sel" clk provider during cleanup [ Upstream commit 7e52a39f1942b771213678c56002ce90a2f126d2 ] commit 091876cc355d ("phy: ti: j721e-wiz: Add support for WIZ module present in TI J721E SoC") modeled both MUX clocks and DIVIDER clocks in wiz. However during cleanup, it removed only the MUX clock provider. Remove the DIVIDER clock provider here. Fixes: 091876cc355d ("phy: ti: j721e-wiz: Add support for WIZ module present in TI J721E SoC") Signed-off-by: Kishon Vijay Abraham I Link: https://lore.kernel.org/r/20210310120840.16447-3-kishon@ti.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 15fe1e9adbbdab40272aa582f8a676156b263f54 Author: Enric Balletbo i Serra Date: Wed Mar 3 10:10:54 2021 +0100 soc: mediatek: pm-domains: Fix missing error code in scpsys_add_subdomain() [ Upstream commit 9950588a45241b0efcfc312ab0e414260ceca709 ] Adding one power domain in scpsys_add_subdomain is missing to assign an error code when it fails. Fix that assigning an error code to 'ret', this also fixes the follwowing smatch warning. drivers/soc/mediatek/mtk-pm-domains.c:492 scpsys_add_subdomain() warn: missing error code 'ret' Fixes: dd65030295e2 ("soc: mediatek: pm-domains: Don't print an error if child domain is deferred") Reported-by: kernel test robot Reported-by: Dan Carpenter Signed-off-by: Enric Balletbo i Serra Link: https://lore.kernel.org/r/20210303091054.796975-1-enric.balletbo@collabora.com Signed-off-by: Matthias Brugger Signed-off-by: Sasha Levin commit 75ec82fe259b535abff60622ad6664899abea360 Author: Srinivas Kandagatla Date: Tue Mar 9 10:48:16 2021 +0000 soundwire: bus: Fix device found flag correctly [ Upstream commit f03690f4f6992225d05dbd1171212e5be5a370dd ] found flag is used to indicate SoundWire devices that are both enumerated on the bus and available in the device list. However this flag is not reset correctly after one iteration, This could miss some of the devices that are enumerated on the bus but not in device list. So reset this correctly to fix this issue! Fixes: d52d7a1be02c ("soundwire: Add Slave status handling helpers") Signed-off-by: Srinivas Kandagatla Reviewed-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20210309104816.20350-1-srinivas.kandagatla@linaro.org Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit a35e98e0340e8cd1c311efb9d6b63eeae9bbbd1f Author: Jonathan Marek Date: Mon Mar 29 15:00:48 2021 +0300 arm64: dts: qcom: sm8250: fix display nodes [ Upstream commit 888771a9d04ff7bf96e5ecad37969002c88a95d7 ] Apply these fixes to the newly added sm8250 display ndoes - Remove "notused" interconnect (which apparently was blindly copied from my old patches) - Use dispcc node example from dt-bindings, removing clocks which aren't documented or used by the driver and fixing the region size. Fixes: 7c1dffd471b1 ("arm64: dts: qcom: sm8250.dtsi: add display system nodes") Signed-off-by: Jonathan Marek [DB: compatibility changes split into separate patch] Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20210329120051.3401567-2-dmitry.baryshkov@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit c6f8e0dc8da1cd78d640dee392071cc2326ec1b2 Author: Pan Bian Date: Thu Jan 21 03:49:07 2021 -0800 bus: qcom: Put child node before return [ Upstream commit ac6ad7c2a862d682bb584a4bc904d89fa7721af8 ] Put child node before return to fix potential reference count leak. Generally, the reference count of child is incremented and decremented automatically in the macro for_each_available_child_of_node() and should be decremented manually if the loop is broken in loop body. Reviewed-by: Linus Walleij Fixes: 335a12754808 ("bus: qcom: add EBI2 driver") Signed-off-by: Pan Bian Link: https://lore.kernel.org/r/20210121114907.109267-1-bianpan2016@163.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 91080d1baf4cb6d7117890837c1af6157b7c7482 Author: Chunfeng Yun Date: Thu Mar 18 14:18:48 2021 +0800 arm64: dts: mt8173: fix wrong power-domain phandle of pmic [ Upstream commit 4db2b9af3ee92e6c51c6a9a5dc2748e4bc1800f9 ] Due to power domain controller is added, the power domain's phanle is also changed from 'scpsys' to 'spm', but forget to modify pmic node's Fixes: 8b6562644df9 ("arm64: dts: mediatek: Add mt8173 power domain controller") Signed-off-by: Chunfeng Yun Reviewed-by: Enric Balletbo i Serra Link: https://lore.kernel.org/r/1616048328-13579-1-git-send-email-chunfeng.yun@mediatek.com Signed-off-by: Matthias Brugger Signed-off-by: Sasha Levin commit 3a2d02e9778d622c32323fd4a35db911d55f6fdb Author: Hsin-Yi Wang Date: Wed Mar 24 15:08:42 2021 +0800 arm64: dts: mt8183: Add gce client reg for display subcomponents [ Upstream commit b7a8f50a1437164607f73831075c06120aa1f3b3 ] Add mediatek,gce-client-reg for mmsys, ccorr, aal, gamma, dither. Fixes: 91f9c963ce79 ("arm64: dts: mt8183: Add display nodes for MT8183") Signed-off-by: Hsin-Yi Wang Tested-by: Enric Balletbo i Serra Link: https://lore.kernel.org/r/20210324070842.1037233-1-hsinyi@chromium.org Signed-off-by: Matthias Brugger Signed-off-by: Sasha Levin commit f56cf3fac1a1beef0c11e18d98a8a9ec73178789 Author: Yoshihiro Shimoda Date: Thu Mar 25 13:19:49 2021 +0900 arm64: dts: renesas: r8a779a0: Fix PMU interrupt [ Upstream commit bbbf6db5a0b56199702bb225132831bced2eee41 ] Should use PPI No.7 for the PMU. Otherwise, the perf command didn't show any information. Fixes: 834c310f5418 ("arm64: dts: renesas: Add Renesas R8A779A0 SoC support") Signed-off-by: Yoshihiro Shimoda Link: https://lore.kernel.org/r/20210325041949.925777-1-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit a08799d3e8c8088640956237c183f83463c39668 Author: Michael Walle Date: Wed Mar 3 16:57:35 2021 +0100 mtd: require write permissions for locking and badblock ioctls [ Upstream commit 1e97743fd180981bef5f01402342bb54bf1c6366 ] MEMLOCK, MEMUNLOCK and OTPLOCK modify protection bits. Thus require write permission. Depending on the hardware MEMLOCK might even be write-once, e.g. for SPI-NOR flashes with their WP# tied to GND. OTPLOCK is always write-once. MEMSETBADBLOCK modifies the bad block table. Fixes: f7e6b19bc764 ("mtd: properly check all write ioctls for permissions") Signed-off-by: Michael Walle Reviewed-by: Greg Kroah-Hartman Acked-by: Rafał Miłecki Acked-by: Richard Weinberger Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210303155735.25887-1-michael@walle.cc Signed-off-by: Sasha Levin commit f7f198e5b361fc146615b1d96af6d51c54393eca Author: dillon min Date: Fri Mar 26 19:15:02 2021 +0800 dt-bindings: serial: stm32: Use 'type: object' instead of false for 'additionalProperties' [ Upstream commit 9f299d3264c67a892af87337dbaa0bdd20830c0c ] To use additional properties 'bluetooth' on serial, need replace false with 'type: object' for 'additionalProperties' to make it as a node, else will run into dtbs_check warnings. 'arch/arm/boot/dts/stm32h750i-art-pi.dt.yaml: serial@40004800: 'bluetooth' does not match any of the regexes: 'pinctrl-[0-9]+' Fixes: af1c2d81695b ("dt-bindings: serial: Convert STM32 UART to json-schema") Reported-by: kernel test robot Tested-by: Valentin Caron Signed-off-by: dillon min Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/1616757302-7889-8-git-send-email-dillon.minfei@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 05933809ef465f2eec19daf4397c6a2c8a31ffc0 Author: Christophe JAILLET Date: Sat Mar 27 08:38:53 2021 +0100 usb: gadget: s3c: Fix the error handling path in 's3c2410_udc_probe()' [ Upstream commit e5242861ec6a0bce25b4cd10af0fc8a508fd067d ] Some 'clk_prepare_enable()' and 'clk_get()' must be undone in the error handling path of the probe function, as already done in the remove function. Fixes: 3fc154b6b813 ("USB Gadget driver for Samsung s3c2410 ARM SoC") Signed-off-by: Christophe JAILLET Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/2bee52e4ce968f48b4c32545cf8f3b2ab825ba82.1616830026.git.christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 4dcc2f1542e4f6f360d4f08029cde44cc90bd941 Author: Christophe JAILLET Date: Sat Mar 27 08:36:50 2021 +0100 usb: gadget: s3c: Fix incorrect resources releasing [ Upstream commit 42067ccd9eb2077979ac3ce8b7b95c694bd09e14 ] Since commit 188db4435ac6 ("usb: gadget: s3c: use platform resources"), 'request_mem_region()' and 'ioremap()' are no more used, so they don't need to be undone in the error handling path of the probe and in the remove function. Remove these calls and the unneeded 'rsrc_start' and 'rsrc_len' global variables. Fixes: 188db4435ac6 ("usb: gadget: s3c: use platform resources") Signed-off-by: Christophe JAILLET Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/b317638464f188159bd8eea44427dd359e480625.1616830026.git.christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit bc164215cb3723730816e3d3d3d3ef794f0afbfe Author: Fabian Vogt Date: Wed Mar 24 15:11:15 2021 +0100 fotg210-udc: Complete OUT requests on short packets [ Upstream commit 75bb93be0027123b5db6cbcce89eb62f0f6b3c5b ] A short packet indicates the end of a transfer and marks the request as complete. Fixes: b84a8dee23fd ("usb: gadget: add Faraday fotg210_udc driver") Signed-off-by: Fabian Vogt Link: https://lore.kernel.org/r/20210324141115.9384-8-fabian@ritter-vogt.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 456b9a9acf76dbe9f738e1b737c79f0b96737b68 Author: Fabian Vogt Date: Wed Mar 24 15:11:14 2021 +0100 fotg210-udc: Don't DMA more than the buffer can take [ Upstream commit 3e7c2510bdfe89a9ec223dd7acd6bfc8bb1cbeb6 ] Before this, it wrote as much as available into the buffer, even if it didn't fit. Fixes: b84a8dee23fd ("usb: gadget: add Faraday fotg210_udc driver") Signed-off-by: Fabian Vogt Link: https://lore.kernel.org/r/20210324141115.9384-7-fabian@ritter-vogt.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 2e1c5f9f3203a216ec83885bb51e09f1618096df Author: Fabian Vogt Date: Wed Mar 24 15:11:12 2021 +0100 fotg210-udc: Mask GRP2 interrupts we don't handle [ Upstream commit 9aee3a23d6455200702f3a57e731fa11e8408667 ] Currently it leaves unhandled interrupts unmasked, but those are never acked. In the case of a "device idle" interrupt, this leads to an effectively frozen system until plugging it in. Fixes: b84a8dee23fd ("usb: gadget: add Faraday fotg210_udc driver") Signed-off-by: Fabian Vogt Link: https://lore.kernel.org/r/20210324141115.9384-5-fabian@ritter-vogt.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 58fe85af6922994517c63476bdcdd964162b4809 Author: Fabian Vogt Date: Wed Mar 24 15:11:11 2021 +0100 fotg210-udc: Remove a dubious condition leading to fotg210_done [ Upstream commit c7f755b243494d6043aadcd9a2989cb157958b95 ] When the EP0 IN request was not completed but less than a packet sent, it would complete the request successfully. That doesn't make sense and can't really happen as fotg210_start_dma always sends min(length, maxpkt) bytes. Fixes: b84a8dee23fd ("usb: gadget: add Faraday fotg210_udc driver") Signed-off-by: Fabian Vogt Link: https://lore.kernel.org/r/20210324141115.9384-4-fabian@ritter-vogt.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 170f02ded842a906e83068a3b8e43070cd00023c Author: Fabian Vogt Date: Wed Mar 24 15:11:10 2021 +0100 fotg210-udc: Fix EP0 IN requests bigger than two packets [ Upstream commit 078ba935651e149c92c41161e0322e3372cc2705 ] For a 134 Byte packet, it sends the first two 64 Byte packets just fine, but then notice that less than a packet is remaining and call fotg210_done without actually sending the rest. Fixes: b84a8dee23fd ("usb: gadget: add Faraday fotg210_udc driver") Signed-off-by: Fabian Vogt Link: https://lore.kernel.org/r/20210324141115.9384-3-fabian@ritter-vogt.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 84d38ee7cc78bea9d55a43e3675ca62dce60e9d6 Author: Fabian Vogt Date: Wed Mar 24 15:11:09 2021 +0100 fotg210-udc: Fix DMA on EP0 for length > max packet size [ Upstream commit 755915fc28edfc608fa89a163014acb2f31c1e19 ] For a 75 Byte request, it would send the first 64 separately, then detect that the remaining 11 Byte fit into a single DMA, but due to this bug set the length to the original 75 Bytes. This leads to a DMA failure (which is ignored...) and the request completes without the remaining bytes having been sent. Fixes: b84a8dee23fd ("usb: gadget: add Faraday fotg210_udc driver") Signed-off-by: Fabian Vogt Link: https://lore.kernel.org/r/20210324141115.9384-2-fabian@ritter-vogt.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 1ea500ce6f7c9106e4a561d28e69215f3d451818 Author: Tong Zhang Date: Thu Mar 18 23:40:00 2021 -0400 crypto: qat - ADF_STATUS_PF_RUNNING should be set after adf_dev_init [ Upstream commit 8609f5cfdc872fc3a462efa6a3eca5cb1e2f6446 ] ADF_STATUS_PF_RUNNING is (only) used and checked by adf_vf2pf_shutdown() before calling adf_iov_putmsg()->mutex_lock(vf2pf_lock), however the vf2pf_lock is initialized in adf_dev_init(), which can fail and when it fail, the vf2pf_lock is either not initialized or destroyed, a subsequent use of vf2pf_lock will cause issue. To fix this issue, only set this flag if adf_dev_init() returns 0. [ 7.178404] BUG: KASAN: user-memory-access in __mutex_lock.isra.0+0x1ac/0x7c0 [ 7.180345] Call Trace: [ 7.182576] mutex_lock+0xc9/0xd0 [ 7.183257] adf_iov_putmsg+0x118/0x1a0 [intel_qat] [ 7.183541] adf_vf2pf_shutdown+0x4d/0x7b [intel_qat] [ 7.183834] adf_dev_shutdown+0x172/0x2b0 [intel_qat] [ 7.184127] adf_probe+0x5e9/0x600 [qat_dh895xccvf] Signed-off-by: Tong Zhang Reviewed-by: Andy Shevchenko Fixes: 25c6ffb249f6 ("crypto: qat - check if PF is running") Acked-by: Giovanni Cabiddu Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit a07e0ff34400909723d5ec8dbef154d95e48ed9d Author: Tong Zhang Date: Thu Mar 18 23:39:59 2021 -0400 crypto: qat - don't release uninitialized resources [ Upstream commit b66accaab3791e15ac99c92f236d0d3a6d5bd64e ] adf_vf_isr_resource_alloc() is not unwinding correctly when error happens and it want to release uninitialized resources. To fix this, only release initialized resources. [ 1.792845] Trying to free already-free IRQ 11 [ 1.793091] WARNING: CPU: 0 PID: 182 at kernel/irq/manage.c:1821 free_irq+0x202/0x380 [ 1.801340] Call Trace: [ 1.801477] adf_vf_isr_resource_free+0x32/0xb0 [intel_qat] [ 1.801785] adf_vf_isr_resource_alloc+0x14d/0x150 [intel_qat] [ 1.802105] adf_dev_init+0xba/0x140 [intel_qat] Signed-off-by: Tong Zhang Reviewed-by: Andy Shevchenko Fixes: dd0f368398ea ("crypto: qat - Add qat dh895xcc VF driver") Acked-by: Giovanni Cabiddu Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit b655b45919d7cf414cd9b051d8d36566cf647ddc Author: Rijo Thomas Date: Mon Mar 15 13:55:29 2021 +0530 crypto: ccp - fix command queuing to TEE ring buffer [ Upstream commit 00aa6e65aa04e500a11a2c91e92a11c37b9e234d ] Multiple threads or clients can submit a command to the TEE ring buffer. This patch helps to synchronize command submission to the ring. One thread shall write a command to a TEE ring buffer entry only if: - Trusted OS has notified that the TEE command for the given entry has been processed and driver has copied the TEE response into client buffer. - The command entry is empty and can be written into. After a command has been written to the TEE ring buffer, the global wptr (mutex protected) shall be incremented for use by next client. If PSP became unresponsive while processing TEE request from a client, then further command submission to queue will be disabled. Fixes: 33960acccfbd (crypto: ccp - add TEE support for Raven Ridge) Reviewed-by: Devaraj Rangasamy Signed-off-by: Rijo Thomas Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 01d6b0abcc662122d9701b2d7b137600564de64c Author: Andy Shevchenko Date: Tue Mar 23 17:36:26 2021 +0200 usb: gadget: pch_udc: Provide a GPIO line used on Intel Minnowboard (v1) [ Upstream commit 049d3db625a652e23488db88b6104de4d5b62f16 ] Intel Minnowboard (v1) uses SCH GPIO line SUS7 (i.e. 12) for VBUS sense. Provide a DMI based quirk to have it's being used. Fixes: e20849a8c883 ("usb: gadget: pch_udc: Convert to use GPIO descriptors") Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210323153626.54908-7-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 83349010475745b720ed6377a9d494f8ca5d9780 Author: Andy Shevchenko Date: Tue Mar 23 17:36:25 2021 +0200 usb: gadget: pch_udc: Initialize device pointer before use [ Upstream commit 971d080212be4ce2b91047d25a657f46d3e39635 ] During conversion to use GPIO descriptors the device pointer, which is applied to devm_gpiod_get(), is not yet initialized. Move initialization in the ->probe() in order to have it set before use. Fixes: e20849a8c883 ("usb: gadget: pch_udc: Convert to use GPIO descriptors") Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210323153626.54908-6-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 536e5a42e6cde6d0d1cea6f50e462ff07991050f Author: Andy Shevchenko Date: Tue Mar 23 17:36:22 2021 +0200 usb: gadget: pch_udc: Check for DMA mapping error [ Upstream commit 4a28d77e359009b846951b06f7c0d8eec8dce298 ] DMA mapping might fail, we have to check it with dma_mapping_error(). Otherwise DMA-API is not happy: DMA-API: pch_udc 0000:02:02.4: device driver failed to check map error[device address=0x00000000027ee678] [size=64 bytes] [mapped as single] Fixes: abab0c67c061 ("usb: pch_udc: Fixed issue which does not work with g_serial") Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210323153626.54908-3-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit f1e537380153b5c4f36941cd2c078bfd92e0fd2a Author: Andy Shevchenko Date: Tue Mar 23 17:36:21 2021 +0200 usb: gadget: pch_udc: Check if driver is present before calling ->setup() [ Upstream commit fbdbbe6d3ee502b3bdeb4f255196bb45003614be ] Since we have a separate routine for VBUS sense, the interrupt may occur before gadget driver is present. Hence, ->setup() call may oops the kernel: [ 55.245843] BUG: kernel NULL pointer dereference, address: 00000010 ... [ 55.245843] EIP: pch_udc_isr.cold+0x162/0x33f ... [ 55.245843] [ 55.245843] ? pch_udc_svc_data_out+0x160/0x160 Check if driver is present before calling ->setup(). Fixes: f646cf94520e ("USB device driver of Topcliff PCH") Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210323153626.54908-2-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 0933de7be64ef03bf747c7beb92367b14a19a10d Author: Andy Shevchenko Date: Tue Mar 23 17:36:20 2021 +0200 usb: gadget: pch_udc: Replace cpu_to_le32() by lower_32_bits() [ Upstream commit 91356fed6afd1c83bf0d3df1fc336d54e38f0458 ] Either way ~0 will be in the correct byte order, hence replace cpu_to_le32() by lower_32_bits(). Moreover, it makes sparse happy, otherwise it complains: .../pch_udc.c:1813:27: warning: incorrect type in assignment (different base types) .../pch_udc.c:1813:27: expected unsigned int [usertype] dataptr .../pch_udc.c:1813:27: got restricted __le32 [usertype] Fixes: f646cf94520e ("USB device driver of Topcliff PCH") Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210323153626.54908-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 0dadbf7ad2cb736084a3fb194ab40fe531dc7f0d Author: Rasmus Villemoes Date: Fri Mar 12 11:30:26 2021 +0100 devtmpfs: fix placement of complete() call [ Upstream commit 38f087de8947700d3b06d3d1594490e0f611c5d1 ] Calling complete() from within the __init function is wrong - theoretically, the init process could proceed all the way to freeing the init mem before the devtmpfsd thread gets to execute the return instruction in devtmpfs_setup(). In practice, it seems to be harmless as gcc inlines devtmpfs_setup() into devtmpfsd(). So the calls of the __init functions init_chdir() etc. actually happen from devtmpfs_setup(), but the __ref on that one silences modpost (it's all right, because those calls happen before the complete()). But it does make the __init annotation of the setup function moot, which we'll fix in a subsequent patch. Fixes: bcbacc4909f1 ("devtmpfs: refactor devtmpfsd()") Reviewed-by: Christoph Hellwig Signed-off-by: Rasmus Villemoes Link: https://lore.kernel.org/r/20210312103027.2701413-1-linux@rasmusvillemoes.dk Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 49ac0af94139332062747bd08587ecf772e5250b Author: Dmitry Osipenko Date: Sat Mar 20 18:19:15 2021 +0300 usb: host: ehci-tegra: Select USB_GADGET Kconfig option [ Upstream commit 0b9828763aeafa5e527b9d98b8789bdb34937fbc ] Select USB_GADGET Kconfig option in order to fix build failure which happens because ChipIdea driver has a build dependency on both USB_GADGET and USB_EHCI_HCD, while USB_EHCI_TEGRA force-selects the ChipIdea driver without taking into account the tristate USB_GADGET dependency. It's not possible to do anything about the cyclic dependency of the Kconfig options, but USB_EHCI_TEGRA is now a deprecated option that isn't used by defconfigs and USB_GADGET is wanted on Tegra by default, hence it's okay to have a bit clunky workaround for it. Fixes: c3590c7656fb ("usb: host: ehci-tegra: Remove the driver") Reported-by: kernel test robot Acked-by: Alan Stern Signed-off-by: Dmitry Osipenko Link: https://lore.kernel.org/r/20210320151915.7566-2-digetx@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 5a3672a6edcbaf7fc3d79d0f1d518c72868da854 Author: Otavio Pontes Date: Fri Mar 19 09:55:15 2021 -0700 x86/microcode: Check for offline CPUs before requesting new microcode [ Upstream commit 7189b3c11903667808029ec9766a6e96de5012a5 ] Currently, the late microcode loading mechanism checks whether any CPUs are offlined, and, in such a case, aborts the load attempt. However, this must be done before the kernel caches new microcode from the filesystem. Otherwise, when offlined CPUs are onlined later, those cores are going to be updated through the CPU hotplug notifier callback with the new microcode, while CPUs previously onine will continue to run with the older microcode. For example: Turn off one core (2 threads): echo 0 > /sys/devices/system/cpu/cpu3/online echo 0 > /sys/devices/system/cpu/cpu1/online Install the ucode fails because a primary SMT thread is offline: cp intel-ucode/06-8e-09 /lib/firmware/intel-ucode/ echo 1 > /sys/devices/system/cpu/microcode/reload bash: echo: write error: Invalid argument Turn the core back on echo 1 > /sys/devices/system/cpu/cpu3/online echo 1 > /sys/devices/system/cpu/cpu1/online cat /proc/cpuinfo |grep microcode microcode : 0x30 microcode : 0xde microcode : 0x30 microcode : 0xde The rationale for why the update is aborted when at least one primary thread is offline is because even if that thread is soft-offlined and idle, it will still have to participate in broadcasted MCE's synchronization dance or enter SMM, and in both examples it will execute instructions so it better have the same microcode revision as the other cores. [ bp: Heavily edit and extend commit message with the reasoning behind all this. ] Fixes: 30ec26da9967 ("x86/microcode: Do not upload microcode if CPUs are offline") Signed-off-by: Otavio Pontes Signed-off-by: Borislav Petkov Reviewed-by: Tony Luck Acked-by: Ashok Raj Link: https://lkml.kernel.org/r/20210319165515.9240-2-otavio.pontes@intel.com Signed-off-by: Sasha Levin commit 7907a6d2d3653cfcfb38c879591bce82405faca3 Author: Dan Carpenter Date: Mon Mar 22 18:06:49 2021 +0300 staging: qlge: fix an error code in probe() [ Upstream commit f7bff017741d98567265ed6a6449311a51810fb6 ] If alloc_etherdev_mq() fails then return -ENOMEM instead of success. The "err = 0;" triggers an unused assignment now so remove that as well. Fixes: 953b94009377 ("staging: qlge: Initialize devlink health dump framework") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/YFiyicHI189PXrha@mwanda Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9dbd136aff69d3e197e733af56e57b1aa8e917ab Author: Andrea Parri (Microsoft) Date: Mon Mar 1 20:13:48 2021 +0100 Drivers: hv: vmbus: Drop error message when 'No request id available' [ Upstream commit 0c85c54bf7faeb80c6b76901ed77d93acef0207d ] Running out of request IDs on a channel essentially produces the same effect as running out of space in the ring buffer, in that -EAGAIN is returned. The error message in hv_ringbuffer_write() should either be dropped (since we don't output a message when the ring buffer is full) or be made conditional/debug-only. Suggested-by: Michael Kelley Signed-off-by: Andrea Parri (Microsoft) Fixes: e8b7db38449ac ("Drivers: hv: vmbus: Add vmbus_requestor data structure for VMBus hardening") Link: https://lore.kernel.org/r/20210301191348.196485-1-parri.andrea@gmail.com Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit 7bd798abad613855f80f7a205a60ccad17ad9487 Author: Alain Volmat Date: Thu Mar 18 08:24:50 2021 +0100 spi: stm32: Fix use-after-free on unbind [ Upstream commit 79c6246ae8793448c05da86a4c82298eed8549b0 ] stm32_spi_remove() accesses the driver's private data after calling spi_unregister_master() even though that function releases the last reference on the spi_master and thereby frees the private data. Fix by switching over to the new devm_spi_alloc_master() helper which keeps the private data accessible until the driver has unbound. Fixes: 8d559a64f00b ("spi: stm32: drop devres version of spi_register_master") Reported-by: Lukas Wunner Signed-off-by: Alain Volmat Link: https://lore.kernel.org/r/1616052290-10887-1-git-send-email-alain.volmat@foss.st.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0a9c774f003cfc300b97436c64047a6f6d4be207 Author: Eric Biggers Date: Tue Mar 9 23:27:26 2021 -0800 crypto: arm/blake2s - fix for big endian [ Upstream commit d2f2516a3882c0c6463e33c9b112b39bd483f821 ] The new ARM BLAKE2s code doesn't work correctly (fails the self-tests) in big endian kernel builds because it doesn't swap the endianness of the message words when loading them. Fix this. Fixes: 5172d322d34c ("crypto: arm/blake2s - add ARM scalar optimized BLAKE2s") Signed-off-by: Eric Biggers Acked-by: Ard Biesheuvel Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 9cd2bd6874b4c7a01629c971f08f8f2972b04038 Author: Andy Lutomirski Date: Thu Mar 4 09:01:55 2021 -0800 selftests/x86: Add a missing .note.GNU-stack section to thunks_32.S [ Upstream commit f706bb59204ba1c47e896b456c97977fc97b7964 ] test_syscall_vdso_32 ended up with an executable stacks because the asm was missing the annotation that says that it is modern and doesn't need an executable stack. Add the annotation. This was missed in commit aeaaf005da1d ("selftests/x86: Add missing .note.GNU-stack sections"). Fixes: aeaaf005da1d ("selftests/x86: Add missing .note.GNU-stack sections") Signed-off-by: Andy Lutomirski Signed-off-by: Borislav Petkov Link: https://lkml.kernel.org/r/487ed5348a43c031b816fa7e9efedb75dc324299.1614877299.git.luto@kernel.org Signed-off-by: Sasha Levin commit 6c3f0c46ca4876fc985ffe32f26801b5fa91109b Author: Vladimir Barinov Date: Fri Mar 12 18:47:35 2021 +0100 arm64: dts: renesas: r8a77980: Fix vin4-7 endpoint binding [ Upstream commit c8aebc1346522d3569690867ce3996642ad52e01 ] This fixes the bindings in media framework: The CSI40 is endpoint number 2 The CSI41 is endpoint number 3 Signed-off-by: Vladimir Barinov Reviewed-by: Niklas Söderlund Signed-off-by: Niklas Söderlund Link: https://lore.kernel.org/r/20210312174735.2118212-1-niklas.soderlund+renesas@ragnatech.se Fixes: 3182aa4e0bf4d0ee ("arm64: dts: renesas: r8a77980: add CSI2/VIN support") Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 01299660164ac9493efcc3964715957c7a03450c Author: Dan Carpenter Date: Fri Mar 12 10:42:52 2021 +0300 regulator: bd9576: Fix return from bd957x_probe() [ Upstream commit 320fcd6bbd2b500923db518902c2c640242d2b50 ] The probe() function returns an uninitialized variable in the success path. There is no need for the "err" variable at all, just delete it. Fixes: b014e9fae7e7 ("regulator: Support ROHM BD9576MUF and BD9573MUF") Signed-off-by: Dan Carpenter Reviewed-by: Matti Vaittinen Link: https://lore.kernel.org/r/YEsbfLJfEWtnRpoU@mwanda Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 28f00f0213925bc8ee7aa7aeb9f3afa189a8ce11 Author: Rafał Miłecki Date: Fri Mar 12 12:01:20 2021 +0100 arm64: dts: broadcom: bcm4908: set Asus GT-AC5300 port 7 PHY mode [ Upstream commit 5ccb9f9cf05bbd729430c6d6d30d40c96a15c56a ] Port 7 is connected to the external BCM53134S switch using RGMII. Fixes: 527a3ac9bdf8 ("arm64: dts: broadcom: bcm4908: describe internal switch") Signed-off-by: Rafał Miłecki Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin commit 1251ef565c1e31541019248a95eea5ffd5baa616 Author: Antonio Borneo Date: Fri Mar 12 11:34:46 2021 +0100 spi: stm32: drop devres version of spi_register_master [ Upstream commit 8d559a64f00b59af9cc02b803ff52f6e6880a651 ] A call to spi_unregister_master() triggers calling remove() for all the spi devices binded to the spi master. Some spi device driver requires to "talk" with the spi device during the remove(), e.g.: - a LCD panel like drivers/gpu/drm/panel/panel-lg-lg4573.c will turn off the backlighting sending a command over spi. This implies that the spi master must be fully functional when spi_unregister_master() is called, either if it is called explicitly in the master's remove() code or implicitly by the devres framework. Devres calls devres_release_all() to release all the resources "after" the remove() of the spi master driver (check code of __device_release_driver() in drivers/base/dd.c). If the spi master driver has an empty remove() then there would be no issue; the devres_release_all() will release everything in reverse order w.r.t. probe(). But if code in spi master driver remove() disables the spi or makes it not functional (like in this spi-stm32), then devres cannot be used safely for unregistering the spi master and the binded spi devices. Replace devm_spi_register_master() with spi_register_master() and add spi_unregister_master() as first action in remove(). Fixes: dcbe0d84dfa5 ("spi: add driver for STM32 SPI controller") Signed-off-by: Antonio Borneo Signed-off-by: Alain Volmat Link: https://lore.kernel.org/r/1615545286-5395-1-git-send-email-alain.volmat@foss.st.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 6516cb852d704ff8d615de1f93cd443a99736c3d Author: Colin Ian King Date: Tue Mar 2 16:34:46 2021 +0000 crypto: sun8i-ss - Fix memory leak of object d when dma_iv fails to map [ Upstream commit 98b5ef3e97b16eaeeedb936f8bda3594ff84a70e ] In the case where the dma_iv mapping fails, the return error path leaks the memory allocated to object d. Fix this by adding a new error return label and jumping to this to ensure d is free'd before the return. Addresses-Coverity: ("Resource leak") Fixes: ac2614d721de ("crypto: sun8i-ss - Add support for the PRNG") Signed-off-by: Colin Ian King Acked-by: Corentin Labbe Tested-by: Corentin Labbe Acked-by: Corentin Labbe Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 48eb34b16d105370799698aa19b43cfe1d48aed3 Author: Srinivas Kandagatla Date: Tue Mar 9 10:20:25 2021 +0000 arm64: dts: qcom: db845c: fix correct powerdown pin for WSA881x [ Upstream commit c561740e7cfefaf3003a256f3a0cd9f8a069137c ] WSA881x powerdown pin is connected to GPIO1 not gpio2, so correct this. This was working so far due to a shift bug in gpio driver, however once that is fixed this will stop working, so fix this! Fixes: 89a32a4e769cc ("arm64: dts: qcom: db845c: add analog audio support") Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20210309102025.28405-1-srinivas.kandagatla@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit fc474a743e6b7f064cfdadca79e605ce876dcbe1 Author: Shawn Guo Date: Wed Mar 3 11:31:06 2021 +0800 arm64: dts: qcom: sm8350: fix number of pins in 'gpio-ranges' [ Upstream commit 790158579c8e663081e7d708d57e8ac6d69dca4e ] The last cell of 'gpio-ranges' should be number of GPIO pins, and in case of qcom platform it should match msm_pinctrl_soc_data.ngpio rather than msm_pinctrl_soc_data.ngpio - 1. This fixes the problem that when the last GPIO pin in the range is configured with the following call sequence, it always fails with -EPROBE_DEFER. pinctrl_gpio_set_config() pinctrl_get_device_gpio_range() pinctrl_match_gpio_range() Fixes: b7e8f433a673 ("arm64: dts: qcom: Add basic devicetree support for SM8350 SoC") Cc: Vinod Koul Signed-off-by: Shawn Guo Link: https://lore.kernel.org/r/20210303033106.549-5-shawn.guo@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit ebcb732af08447851c3140d42324b754daefbdf0 Author: Shawn Guo Date: Wed Mar 3 11:31:05 2021 +0800 arm64: dts: qcom: sm8250: fix number of pins in 'gpio-ranges' [ Upstream commit e526cb03e2aed42866a0919485a3d8ac130972cf ] The last cell of 'gpio-ranges' should be number of GPIO pins, and in case of qcom platform it should match msm_pinctrl_soc_data.ngpio rather than msm_pinctrl_soc_data.ngpio - 1. This fixes the problem that when the last GPIO pin in the range is configured with the following call sequence, it always fails with -EPROBE_DEFER. pinctrl_gpio_set_config() pinctrl_get_device_gpio_range() pinctrl_match_gpio_range() Fixes: 16951b490b20 ("arm64: dts: qcom: sm8250: Add TLMM pinctrl node") Cc: Bjorn Andersson Signed-off-by: Shawn Guo Link: https://lore.kernel.org/r/20210303033106.549-4-shawn.guo@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 3b7499aafa0c22726b95c1aab23e5fbbc73b19ac Author: Shawn Guo Date: Wed Mar 3 11:31:04 2021 +0800 arm64: dts: qcom: sm8150: fix number of pins in 'gpio-ranges' [ Upstream commit de3abdf3d15c6e7f456e2de3f9da78f3a31414cc ] The last cell of 'gpio-ranges' should be number of GPIO pins, and in case of qcom platform it should match msm_pinctrl_soc_data.ngpio rather than msm_pinctrl_soc_data.ngpio - 1. This fixes the problem that when the last GPIO pin in the range is configured with the following call sequence, it always fails with -EPROBE_DEFER. pinctrl_gpio_set_config() pinctrl_get_device_gpio_range() pinctrl_match_gpio_range() Fixes: e13c6d144fa0 ("arm64: dts: qcom: sm8150: Add base dts file") Cc: Vinod Koul Signed-off-by: Shawn Guo Link: https://lore.kernel.org/r/20210303033106.549-3-shawn.guo@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit dea150cf1d401bc7b4c16dfb665d18130a8ea28c Author: Shawn Guo Date: Wed Mar 3 11:31:03 2021 +0800 arm64: dts: qcom: sdm845: fix number of pins in 'gpio-ranges' [ Upstream commit 02058fc3839df65ff64de2a6b1c5de8c9fd705c1 ] The last cell of 'gpio-ranges' should be number of GPIO pins, and in case of qcom platform it should match msm_pinctrl_soc_data.ngpio rather than msm_pinctrl_soc_data.ngpio - 1. This fixes the problem that when the last GPIO pin in the range is configured with the following call sequence, it always fails with -EPROBE_DEFER. pinctrl_gpio_set_config() pinctrl_get_device_gpio_range() pinctrl_match_gpio_range() Fixes: bc2c806293c6 ("arm64: dts: qcom: sdm845: Add gpio-ranges to TLMM node") Cc: Evan Green Signed-off-by: Shawn Guo Link: https://lore.kernel.org/r/20210303033106.549-2-shawn.guo@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 34833cd1bcd539227896e1e10949c218f1a397da Author: Douglas Anderson Date: Thu Feb 18 14:55:09 2021 -0800 arm64: dts: qcom: sc7180: Avoid glitching SPI CS at bootup on trogdor [ Upstream commit e440e30e26dd6b0424002ad0ddcbbcea783efd85 ] At boot time the following happens: 1. Device core gets ready to probe our SPI driver. 2. Device core applies SPI controller's "default" pinctrl. 3. Device core calls the SPI driver's probe() function which will eventually setup the chip select GPIO as "unasserted". Thinking about the above, we can find: a) For SPI devices that the BIOS inits (Cr50 and EC), the BIOS would have had them configured as "GENI" pins and not as "GPIO" pins. b) It turns out that our BIOS also happens to init these pins as "output" (even though it doesn't need to since they're not muxed as GPIO) but leaves them at the default state of "low". c) As soon as we apply the "default" chip select it'll switch the function to GPIO and stop driving the chip select high (which is how "GENI" was driving it) and start driving it low. d) As of commit 9378f46040be ("UPSTREAM: spi: spi-geni-qcom: Use the new method of gpio CS control"), when the SPI core inits things it inits the GPIO to be "deasserted". Prior to that commit the GPIO was left untouched until first use. e) When the first transaction happens we'll assert the chip select and then deassert it after done. So before the commit to change us to use gpio descriptors we used to have a _really long_ assertion of chip select before our first transaction (because it got pulled down and then the first "assert" was a no-op). That wasn't great but (apparently) didn't cause any real harm. After the commit to change us to use gpio descriptors we end up glitching the chip select line during probe. It would go low and then high with no data transferred. The other side ought to be robust against this, but it certainly could cause some confusion. It's known to at least cause an error message on the EC console and it's believed that, under certain timing conditions, it could be getting the EC into a confused state causing the EC driver to fail to probe. Let's fix things to avoid the glitch. We'll add an extra pinctrl entry that sets the value of the pin to output high (CS deasserted) before doing anything else. We'll do this in its own pinctrl node that comes before the normal pinctrl entries to ensure that the order is correct and that this gets applied before the mux change. This change is in the trogdor board file rather than in the SoC dtsi file because chip select polarity can be different depending on what's hooked up and it doesn't feel worth it to spam the SoC dtsi file with both options. The board file would need to pick the right one anyway. Reviewed-by: Stephen Boyd Fixes: cfbb97fde694 ("arm64: dts: qcom: Switch sc7180-trogdor to control SPI CS via GPIO") Signed-off-by: Douglas Anderson Link: https://lore.kernel.org/r/20210218145456.1.I1da01a075dd86e005152f993b2d5d82dd9686238@changeid Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 66ef17ff0bd987796e14e2cc7ec4318613f03e16 Author: Sai Prakash Ranjan Date: Tue Feb 16 15:17:49 2021 +0530 arm64: dts: qcom: sm8250: Fix timer interrupt to specify EL2 physical timer [ Upstream commit 29a3349543e4ce3fe4e2a761403cc629e3534c67 ] ARM architected timer interrupts DT property specifies EL2/HYP physical interrupt and not EL2/HYP virtual interrupt for the 4th interrupt property. As per interrupt documentation for SM8250 SoC, the EL2/HYP physical timer interrupt is 10 and EL2/HYP virtual timer interrupt is 12, so fix the 4th timer interrupt to be EL2 physical timer interrupt (10 in this case). Fixes: 60378f1a171e ("arm64: dts: qcom: sm8250: Add sm8250 dts file") Signed-off-by: Sai Prakash Ranjan Link: https://lore.kernel.org/r/744e58f725d279eb2b049a7da42b0f09189f4054.1613468366.git.saiprakash.ranjan@codeaurora.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit e688a3953bd1219c46ceffc7a2f289b6461eb305 Author: Sai Prakash Ranjan Date: Tue Feb 16 15:17:48 2021 +0530 arm64: dts: qcom: sm8350: Fix level triggered PMU interrupt polarity [ Upstream commit 794d3e309e44c99158d0166b1717f297341cf3ab ] As per interrupt documentation for SM8350 SoC, the polarity for level triggered PMU interrupt is low, fix this. Fixes: b7e8f433a673 ("arm64: dts: qcom: Add basic devicetree support for SM8350 SoC") Signed-off-by: Sai Prakash Ranjan Link: https://lore.kernel.org/r/ca57409198477f7815e32a6a7467dcdc9b93dc4f.1613468366.git.saiprakash.ranjan@codeaurora.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 3bfdadd3bdf2c78a2582a39325d05d2752a7312e Author: Sai Prakash Ranjan Date: Tue Feb 16 15:17:47 2021 +0530 arm64: dts: qcom: sm8250: Fix level triggered PMU interrupt polarity [ Upstream commit 93138ef5ac923b10f81575d35dbcb83136cbfc40 ] As per interrupt documentation for SM8250 SoC, the polarity for level triggered PMU interrupt is low, fix this. Fixes: 60378f1a171e ("arm64: dts: qcom: sm8250: Add sm8250 dts file") Signed-off-by: Sai Prakash Ranjan Link: https://lore.kernel.org/r/96680a1c6488955c9eef7973c28026462b2a4ec0.1613468366.git.saiprakash.ranjan@codeaurora.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit a3e81f0e31eb3e5999d01db47016bbbf4309b57e Author: Matthias Kaehlcke Date: Thu Feb 25 10:33:36 2021 -0800 arm64: dts: qcom: sc7180: trogdor: Fix trip point config of charger thermal zone [ Upstream commit 38f3267def6511171aef0f056ad172686903603f ] The trip point configuration of the charger thermal zone for trogdor is missing a node for the critical trip point. Add the missing node. Reviewed-by: Stephen Boyd Reviewed-by: Douglas Anderson Fixes: bb06eb3607e9 ("arm64: qcom: sc7180: trogdor: Add ADC nodes and thermal zone for charger thermistor") Signed-off-by: Matthias Kaehlcke Link: https://lore.kernel.org/r/20210225103330.v2.3.Ife7768b6b4765026c9d233ad4982da0e365ddbca@changeid Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 99c85d841529efa3ff958ab847263c1ebfc7328e Author: Nuno Sa Date: Thu Feb 18 12:40:36 2021 +0100 iio: adis16480: fix pps mode sampling frequency math [ Upstream commit 0463e60f087069adf25a815cd88753946aca2565 ] When using PPS mode, the input clock needs to be scaled so that we have an IMU sample rate between (optimally) 4000 and 4250. After this, we can use the decimation filter to lower the sampling rate in order to get what the user wants. Optimally, the user sample rate is a multiple of both the IMU sample rate and the input clock. Hence, calculating the sync_scale dynamically gives us better chances of achieving a perfect/integer value for DEC_RATE. The math here is: 1. lcm of the input clock and the desired output rate. 2. get the highest multiple of the previous result lower than the adis max rate. 3. The last result becomes the IMU sample rate. Use that to calculate SYNC_SCALE and DEC_RATE (to get the user output rate). Fixes: 326e2357553d3 ("iio: imu: adis16480: Add support for external clock") Signed-off-by: Nuno Sa Link: https://lore.kernel.org/r/20210218114039.216091-2-nuno.sa@analog.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 69a2c2e02daaeb1c1377c029124c1fff5b3b6fa0 Author: Aswath Govindraju Date: Fri Mar 5 11:11:04 2021 +0530 arm64: dts: ti: k3-j721e-main: Update the speed modes supported and their itap delay values for MMCSD subsystems [ Upstream commit eb8f6194e8074d7b00642dd75cf04d13e1b218e4 ] According to latest errata of J721e [1], HS400 mode is not supported in MMCSD0 subsystem (i2024) and SDR104 mode is not supported in MMCSD1/2 subsystems (i2090). Therefore, replace mmc-hs400-1_8v with mmc-hs200-1_8v in MMCSD0 subsystem and add a sdhci mask to disable SDR104 speed mode. Also, update the itap delay values for all the MMCSD subsystems according the latest J721e data sheet[2] [1] - https://www.ti.com/lit/er/sprz455/sprz455.pdf [2] - https://www.ti.com/lit/ds/symlink/tda4vm.pdf Fixes: cd48ce86a4d0 ("arm64: dts: ti: k3-j721e-common-proc-board: Add support for SD card UHS modes") Signed-off-by: Aswath Govindraju Signed-off-by: Nishanth Menon Reviewed-by: Kishon Vijay Abraham I Link: https://lore.kernel.org/r/20210305054104.10153-1-a-govindraju@ti.com Signed-off-by: Sasha Levin commit bd264d03a71bd1e32e6595f18506f70cac8eddd5 Author: Valentin CARON - foss Date: Thu Feb 11 12:07:03 2021 +0100 ARM: dts: stm32: fix usart 2 & 3 pinconf to wake up with flow control [ Upstream commit a1429f3d3029b65cd4032f6218d5290911377ce4 ] Modify usart 2 & 3 pins to allow wake up from low power mode while the hardware flow control is activated. UART RTS pin need to stay configure in idle mode to receive characters in order to wake up. Fixes: 842ed898a757 ("ARM: dts: stm32: add usart2, usart3 and uart7 pins in stm32mp15-pinctrl") Signed-off-by: Valentin Caron Signed-off-by: Alexandre Torgue Signed-off-by: Sasha Levin commit c3d322609b49dba50475917c199835992e82e1ab Author: Jia-Ju Bai Date: Sun Mar 7 19:44:46 2021 -0800 mtd: maps: fix error return code of physmap_flash_remove() [ Upstream commit 620b90d30c08684dc6ebee07c72755d997f9d1f6 ] When platform_get_drvdata() returns NULL to info, no error return code of physmap_flash_remove() is assigned. To fix this bug, err is assigned with -EINVAL in this case Fixes: 73566edf9b91 ("[MTD] Convert physmap to platform driver") Reported-by: TOTE Robot Signed-off-by: Jia-Ju Bai Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210308034446.3052-1-baijiaju1990@gmail.com Signed-off-by: Sasha Levin commit 915959ef8becc0970fc0f84eb390791cb8280865 Author: Baruch Siach Date: Wed Mar 3 18:48:16 2021 +0200 mtd: parsers: qcom: incompatible with spi-nor 4k sectors [ Upstream commit 8f62f59f83c3bc902af91c80732cfcd17e0d7069 ] Partition size and offset value are in block size units, which is the same as 'erasesize'. But when 4K sectors are enabled erasesize is set to 4K. Bail out in that case. Fixes: 803eb124e1a64 ("mtd: parsers: Add Qcom SMEM parser") Reviewed-by: Manivannan Sadhasivam Signed-off-by: Baruch Siach Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/0a2611f885b894274436ded3ca78bc0440fca74a.1614790096.git.baruch@tkos.co.il Signed-off-by: Sasha Levin commit 9380ee18b58ddd93bca97bfb6b6d1355dff6d796 Author: Miquel Raynal Date: Wed Mar 3 09:46:34 2021 +0100 mtd: parsers: qcom: Fix error condition [ Upstream commit c95310e1b33eae9767af9698aa976d5301f37203 ] qcom_smem_get() does not return NULL, and even if it did, the NULL condition is usually not an error but a success condition and should not trigger an error trace. Let's replace IS_ERR_OR_NULL() by IS_ERR(). This fixes the following smatch warning: drivers/mtd/parsers/qcomsmempart.c:109 parse_qcomsmem_part() warn: passing zero to 'PTR_ERR' Reported-by: kernel test robot Reported-by: Dan Carpenter Fixes: 803eb124e1a6 ("mtd: parsers: Add Qcom SMEM parser") Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210303084634.12796-1-miquel.raynal@bootlin.com Signed-off-by: Sasha Levin commit 64151b20eba8337365b5ed05788d8d6de0d1f896 Author: David Bauer Date: Wed Feb 17 20:53:20 2021 +0100 mtd: don't lock when recursively deleting partitions [ Upstream commit cb4543054c5c4fd33df960b41d7b483ebca8e786 ] When recursively deleting partitions, don't acquire the masters partition lock twice. Otherwise the process ends up in a deadlocked state. Fixes: 46b5889cc2c5 ("mtd: implement proper partition handling") Signed-off-by: David Bauer Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210217195320.893253-1-mail@david-bauer.net Signed-off-by: Sasha Levin commit a4ef6c56a8af5ee979fa04e8db27d7d33c791639 Author: Manivannan Sadhasivam Date: Tue Mar 2 18:57:57 2021 +0530 mtd: rawnand: qcom: Return actual error code instead of -ENODEV [ Upstream commit 55fbb9ba4f06cb6aff32daca1e1910173c13ec51 ] In qcom_probe_nand_devices() function, the error code returned by qcom_nand_host_init_and_register() is converted to -ENODEV in the case of failure. This poses issue if -EPROBE_DEFER is returned when the dependency is not available for a component like parser. So let's restructure the error handling logic a bit and return the actual error code in case of qcom_nand_host_init_and_register() failure. Fixes: c76b78d8ec05 ("mtd: nand: Qualcomm NAND controller driver") Signed-off-by: Manivannan Sadhasivam Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit 82bcabce34d90f7ff7b1d9b8c8e3ccc5afbcd5eb Author: Manivannan Sadhasivam Date: Tue Mar 2 18:57:56 2021 +0530 mtd: Handle possible -EPROBE_DEFER from parse_mtd_partitions() [ Upstream commit 08608adb520e51403be7592c2214846fa440a23a ] There are chances that the parse_mtd_partitions() function will return -EPROBE_DEFER in mtd_device_parse_register(). This might happen when the dependency is not available for the parser. For instance, on SDX55 the MTD_QCOMSMEM_PARTS parser depends on the QCOM_SMEM driver to parse the partitions defined in the shared memory region. With the current flow, the error returned from parse_mtd_partitions() will be discarded in favor of trying to add the fallback partition. This will prevent the driver to end up in probe deferred pool and the partitions won't be parsed even after the QCOM_SMEM driver is available. Fix this issue by bailing out of mtd_device_parse_register() when -EPROBE_DEFER error is returned from parse_mtd_partitions() function and propagate the error code to the driver core for probing later. Fixes: 5ac67ce36cfe ("mtd: move code adding (registering) partitions to the parse_mtd_partitions()") Signed-off-by: Manivannan Sadhasivam Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit fa897935b7506893f4fb14ec46929777f1facd1e Author: Álvaro Fernández Rojas Date: Wed Feb 24 09:02:10 2021 +0100 mtd: rawnand: brcmnand: fix OOB R/W with Hamming ECC [ Upstream commit f5200c14242fb8fa4a9b93f7fd4064d237e58785 ] Hamming ECC doesn't cover the OOB data, so reading or writing OOB shall always be done without ECC enabled. This is a problem when adding JFFS2 cleanmarkers to erased blocks. If JFFS2 clenmarkers are added to the OOB with ECC enabled, OOB bytes will be changed from ff ff ff to 00 00 00, reporting incorrect ECC errors. Fixes: 27c5b17cd1b1 ("mtd: nand: add NAND driver "library" for Broadcom STB NAND controller") Signed-off-by: Álvaro Fernández Rojas Acked-by: Brian Norris Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210224080210.23686-1-noltari@gmail.com Signed-off-by: Sasha Levin commit 40bad753d1fc02a0c8b988227fb081f106305907 Author: Dan Carpenter Date: Mon Feb 15 18:58:49 2021 +0300 mtd: rawnand: fsmc: Fix error code in fsmc_nand_probe() [ Upstream commit e7a97528e3c787802d8c643d6ab2f428511bb047 ] If dma_request_channel() fails then the probe fails and it should return a negative error code, but currently it returns success. fixes: 4774fb0a48aa ("mtd: nand/fsmc: Add DMA support") Signed-off-by: Dan Carpenter Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/YCqaOZ83OvPOzLwh@mwanda Signed-off-by: Sasha Levin commit 1ad5f8a3f392be238b3d3a97fdbcca7fcad1f1c1 Author: Rafał Miłecki Date: Tue Mar 9 19:44:09 2021 +0100 arm64: dts: broadcom: bcm4908: fix switch parent node name [ Upstream commit a348ff97ffb840b9d74b0e64b3e0e6002187d224 ] Ethernet switch and MDIO are grouped using "simple-bus". It's not allowed to use "ethernet-switch" node name as it isn't a switch. Replace it with "bus". Fixes: 527a3ac9bdf8 ("arm64: dts: broadcom: bcm4908: describe internal switch") Signed-off-by: Rafał Miłecki Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin commit 121a5da334eb1abc2b68ec65ecd5fd9904a16c15 Author: Arnd Bergmann Date: Fri Feb 26 15:00:48 2021 +0100 spi: rockchip: avoid objtool warning [ Upstream commit e50989527faeafb79f45a0f7529ba8e01dff1fff ] Building this file with clang leads to a an unreachable code path causing a warning from objtool: drivers/spi/spi-rockchip.o: warning: objtool: rockchip_spi_transfer_one()+0x2e0: sibling call from callable instruction with modified stack frame Change the unreachable() into an error return that can be handled if it ever happens, rather than silently crashing the kernel. Fixes: 65498c6ae241 ("spi: rockchip: support 4bit words") Signed-off-by: Arnd Bergmann Acked-by: Pratyush Yadav Link: https://lore.kernel.org/r/20210226140109.3477093-1-arnd@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit b9e569ae1da3a113b3acee8703c94777fd20938a Author: Meng Li Date: Fri Feb 26 10:17:37 2021 +0800 regmap: set debugfs_name to NULL after it is freed [ Upstream commit e41a962f82e7afb5b1ee644f48ad0b3aee656268 ] There is a upstream commit cffa4b2122f5("regmap:debugfs: Fix a memory leak when calling regmap_attach_dev") that adds a if condition when create name for debugfs_name. With below function invoking logical, debugfs_name is freed in regmap_debugfs_exit(), but it is not created again because of the if condition introduced by above commit. regmap_reinit_cache() regmap_debugfs_exit() ... regmap_debugfs_init() So, set debugfs_name to NULL after it is freed. Fixes: cffa4b2122f5 ("regmap: debugfs: Fix a memory leak when calling regmap_attach_dev") Signed-off-by: Meng Li Link: https://lore.kernel.org/r/20210226021737.7690-1-Meng.Li@windriver.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 89e2375bafbcf10280d923a4b6ce05a25c02cb8e Author: David E. Box Date: Wed Feb 24 12:10:04 2021 -0800 mfd: intel_pmt: Fix nuisance messages and handling of disabled capabilities [ Upstream commit a1a5c1c3df282dc122508a17500317266ef19e46 ] Some products will be available that have PMT capabilities that are not supported. Remove the warnings in this instance to avoid nuisance messages and confusion. Also return an error code for capabilities that are disabled by quirk to prevent them from keeping the driver loaded if only disabled capabilities are found. Fixes: 4f8217d5b0ca ("mfd: Intel Platform Monitoring Technology support") Signed-off-by: David E. Box Reviewed-by: Hans de Goede Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit a113d3b0ab162272dd89a674f61768d32f0c3abb Author: Wei Yongjun Date: Mon Mar 8 09:48:39 2021 +0000 usb: typec: stusb160x: fix return value check in stusb160x_probe() [ Upstream commit f2d90e07b5df2c7745ae66d2d48cc350d3f1c7d2 ] In case of error, the function device_get_named_child_node() returns NULL pointer not ERR_PTR(). The IS_ERR() test in the return value check should be replaced with NULL test. Fixes: da0cb6310094 ("usb: typec: add support for STUSB160x Type-C controller family") Reported-by: Hulk Robot Reviewed-by: Heikki Krogerus Reviewed-by: Amelie Delaunay Signed-off-by: Wei Yongjun Link: https://lore.kernel.org/r/20210308094839.3586773-1-weiyongjun1@huawei.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 30eca95df3c439bcde0231c05ff789d839980b37 Author: Wei Yongjun Date: Mon Mar 8 09:48:41 2021 +0000 usb: typec: tps6598x: Fix return value check in tps6598x_probe() [ Upstream commit 604c75893a01c8a3b5bd6dac55535963cd44c3f5 ] In case of error, the function device_get_named_child_node() returns NULL pointer not ERR_PTR(). The IS_ERR() test in the return value check should be replaced with NULL test. Fixes: 18a6c866bb19 ("usb: typec: tps6598x: Add USB role switching logic") Reported-by: Hulk Robot Reviewed-by: Heikki Krogerus Signed-off-by: Wei Yongjun Link: https://lore.kernel.org/r/20210308094841.3587751-1-weiyongjun1@huawei.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c7c88f690f155caf94e9c31c8a8794bc975f60ae Author: Badhri Jagan Sridharan Date: Wed Mar 3 23:09:31 2021 -0800 usb: typec: tcpci: Check ROLE_CONTROL while interpreting CC_STATUS [ Upstream commit 19c234a14eafca78e0bc14ffb8be3891096ce147 ] While interpreting CC_STATUS, ROLE_CONTROL has to be read to make sure that CC1/CC2 is not forced presenting Rp/Rd. >From the TCPCI spec: 4.4.5.2 ROLE_CONTROL (Normative): The TCPM shall write B6 (DRP) = 0b and B3..0 (CC1/CC2) if it wishes to control the Rp/Rd directly instead of having the TCPC perform DRP toggling autonomously. When controlling Rp/Rd directly, the TCPM writes to B3..0 (CC1/CC2) each time it wishes to change the CC1/CC2 values. This control is used for TCPM-TCPC implementing Source or Sink only as well as when a connection has been detected via DRP toggling but the TCPM wishes to attempt Try.Src or Try.Snk. Table 4-22. CC_STATUS Register Definition: If (ROLE_CONTROL.CC1 = Rd) or ConnectResult=1) 00b: SNK.Open (Below maximum vRa) 01b: SNK.Default (Above minimum vRd-Connect) 10b: SNK.Power1.5 (Above minimum vRd-Connect) Detects Rp-1.5A 11b: SNK.Power3.0 (Above minimum vRd-Connect) Detects Rp-3.0A If (ROLE_CONTROL.CC2=Rd) or (ConnectResult=1) 00b: SNK.Open (Below maximum vRa) 01b: SNK.Default (Above minimum vRd-Connect) 10b: SNK.Power1.5 (Above minimum vRd-Connect) Detects Rp 1.5A 11b: SNK.Power3.0 (Above minimum vRd-Connect) Detects Rp 3.0A Fixes: 74e656d6b0551 ("staging: typec: Type-C Port Controller Interface driver (tcpci)") Acked-by: Heikki Krogerus Signed-off-by: Badhri Jagan Sridharan Link: https://lore.kernel.org/r/20210304070931.1947316-1-badhri@google.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c03542175f9e3a60fb83cecba19fa9013891553a Author: Badhri Jagan Sridharan Date: Thu Feb 25 02:11:04 2021 -0800 usb: typec: tcpm: Wait for vbus discharge to VSAFE0V before toggling [ Upstream commit 3287f58bcba6c6fa6167624b443a668782fac26d ] When vbus auto discharge is enabled, TCPM can sometimes be faster than the TCPC i.e. TCPM can go ahead and move the port to unattached state (involves disabling vbus auto discharge) before TCPC could effectively discharge vbus to VSAFE0V. This leaves vbus with residual charge and increases the decay time which prevents tsafe0v from being met. This change makes TCPM waits for a maximum of tSafe0V(max) for vbus to discharge to VSAFE0V before transitioning to unattached state and re-enable toggling. If vbus discharges to vsafe0v sooner, then, transition to unattached state happens right away. Also, while in SNK_READY, when auto discharge is enabled, drive disconnect based on vbus turning off instead of Rp disappearing on CC pins. Rp disappearing on CC pins is almost instanteous compared to vbus decay. Sink detach: [ 541.703058] CC1: 3 -> 0, CC2: 0 -> 0 [state SNK_READY, polarity 0, disconnected] [ 541.703331] Setting voltage/current limit 5000 mV 0 mA [ 541.727235] VBUS on [ 541.749650] VBUS off [ 541.749653] pending state change SNK_READY -> SNK_UNATTACHED @ 650 ms [rev3 NONE_AMS] [ 541.749944] VBUS VSAFE0V [ 541.749945] state change SNK_READY -> SNK_UNATTACHED [rev3 NONE_AMS] [ 541.750806] Disable vbus discharge ret:0 [ 541.907345] Start toggling [ 541.922799] CC1: 0 -> 0, CC2: 0 -> 0 [state TOGGLING, polarity 0, disconnected] Source detach: [ 2555.310414] state change SRC_SEND_CAPABILITIES -> SRC_READY [rev3 POWER_NEGOTIATION] [ 2555.310675] AMS POWER_NEGOTIATION finished [ 2555.310679] cc:=3 [ 2593.645886] CC1: 0 -> 0, CC2: 2 -> 0 [state SRC_READY, polarity 1, disconnected] [ 2593.645919] pending state change SRC_READY -> SNK_UNATTACHED @ 650 ms [rev3 NONE_AMS] [ 2593.648419] VBUS off [ 2593.648960] VBUS VSAFE0V [ 2593.648965] state change SRC_READY -> SNK_UNATTACHED [rev3 NONE_AMS] [ 2593.649962] Disable vbus discharge ret:0 [ 2593.890322] Start toggling [ 2593.925663] CC1: 0 -> 0, CC2: 0 -> 0 [state TOGGLING, polarity 0, Fixes: f321a02caebd ("usb: typec: tcpm: Implement enabling Auto Discharge disconnect support") Reviewed-by: Guenter Roeck Reviewed-by: Heikki Krogerus Signed-off-by: Badhri Jagan Sridharan Link: https://lore.kernel.org/r/20210225101104.1680697-1-badhri@google.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9edc7a0660117ccec9aa06cf4b6d0cc518131598 Author: Erwan Le Ray Date: Thu Mar 4 17:23:07 2021 +0100 serial: stm32: fix tx_empty condition [ Upstream commit 3db1d52466dc11dca4e47ef12a6e6e97f846af62 ] In "tx_empty", we should poll TC bit in both DMA and PIO modes (instead of TXE) to check transmission data register has been transmitted independently of the FIFO mode. TC indicates that both transmit register and shift register are empty. When shift register is empty, tx_empty should return TIOCSER_TEMT instead of TC value. Cleans the USART_CR_TC TCCF register define (transmission complete clear flag) as it is duplicate of USART_ICR_TCCF. Fixes: 48a6092fb41f ("serial: stm32-usart: Add STM32 USART Driver") Signed-off-by: Erwan Le Ray Link: https://lore.kernel.org/r/20210304162308.8984-13-erwan.leray@foss.st.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 46c6efeff8e375c64fc46b50487a176b3e17245c Author: Erwan Le Ray Date: Thu Mar 4 17:23:06 2021 +0100 serial: stm32: add FIFO flush when port is closed [ Upstream commit 9f77d19207a0e8ba814c8ceb22e90ce7cb2aef64 ] Transmission complete error is sent when ISR_TC is not set. If port closure is requested despite data in TDR / TX FIFO has not been sent (because of flow control), ISR_TC is not set and error message is sent on port closure but also when a new port is opened. Flush the data when port is closed, so the error isn't printed twice upon next port opening. Fixes: 64c32eab6603 ("serial: stm32: Add support of TC bit status check") Signed-off-by: Erwan Le Ray Link: https://lore.kernel.org/r/20210304162308.8984-12-erwan.leray@foss.st.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 8fa18df352290374fcda27c2817838dce20a1db1 Author: Erwan Le Ray Date: Thu Mar 4 17:23:05 2021 +0100 serial: stm32: fix FIFO flush in startup and set_termios [ Upstream commit 315e2d8a125ad77a1bc28f621162713f3e7aef48 ] Fifo flush set USART_RQR register by calling stm32_usart_set_bits routine (Read/Modify/Write). USART_RQR register is a write only register. So, read before write isn't correct / relevant to flush the FIFOs. Replace stm32_usart_set_bits call by writel_relaxed. Fixes: 84872dc448fe ("serial: stm32: add RX and TX FIFO flush") Signed-off-by: Erwan Le Ray Link: https://lore.kernel.org/r/20210304162308.8984-11-erwan.leray@foss.st.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a5e6b275937663b74ea7c10968557f65b0e28db3 Author: Erwan Le Ray Date: Thu Mar 4 17:23:04 2021 +0100 serial: stm32: call stm32_transmit_chars locked [ Upstream commit f16b90c2d9db3e6ac719d1946b9d335ca4ab33f3 ] stm32_transmit_chars should be called under lock also in tx DMA callback. Fixes: 3489187204eb ("serial: stm32: adding dma support") Signed-off-by: Erwan Le Ray Signed-off-by: Fabrice Gasnier Link: https://lore.kernel.org/r/20210304162308.8984-10-erwan.leray@foss.st.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit b263011153eec8f6445c034591c2219c7313aa82 Author: Erwan Le Ray Date: Thu Mar 4 17:23:03 2021 +0100 serial: stm32: fix tx dma completion, release channel [ Upstream commit fb4f2e04ac13e7c400e6b86afbbd314a5a2a7e8d ] This patch add a proper release of dma channels when completing dma tx. Fixes: 3489187204eb ("serial: stm32: adding dma support") Signed-off-by: Erwan Le Ray Link: https://lore.kernel.org/r/20210304162308.8984-9-erwan.leray@foss.st.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 59ead20a3dece0ee0c1f6163c24f6260e35442be Author: Wei Yongjun Date: Fri Mar 5 03:49:29 2021 +0000 serial: liteuart: fix return value check in liteuart_probe() [ Upstream commit cebeddd6d0d9f839b9df2930b6a768b54913a763 ] In case of error, the function devm_platform_get_and_ioremap_resource() returns ERR_PTR() and never returns NULL. The NULL test in the return value check should be replaced with IS_ERR(). Fixes: 1da81e5562fa ("drivers/tty/serial: add LiteUART driver") Reported-by: Hulk Robot Signed-off-by: Wei Yongjun Link: https://lore.kernel.org/r/20210305034929.3234352-1-weiyongjun1@huawei.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 84a8fdccdd7e88495c50618260c38a419a2ea5ed Author: Erwan Le Ray Date: Thu Mar 4 17:23:02 2021 +0100 serial: stm32: fix a deadlock in set_termios [ Upstream commit 436c97936001776f16153771ee887f125443e974 ] CTS/RTS GPIOs support that has been added recently to STM32 UART driver has introduced scheduled code in a set_termios part protected by a spin lock. This generates a potential deadlock scenario: Chain exists of: &irq_desc_lock_class --> console_owner --> &port_lock_key Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&port_lock_key); lock(console_owner); lock(&port_lock_key); lock(&irq_desc_lock_class); *** DEADLOCK *** 4 locks held by stty/766: Move the scheduled code after the spinlock. Fixes: 6cf61b9bd7cc ("tty: serial: Add modem control gpio support for STM32 UART") Signed-off-by: Erwan Le Ray Link: https://lore.kernel.org/r/20210304162308.8984-8-erwan.leray@foss.st.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 65b53eb11514f3d8f9310adbc7c725bd2d795250 Author: Erwan Le Ray Date: Thu Mar 4 17:23:01 2021 +0100 serial: stm32: fix wake-up flag handling [ Upstream commit 12761869f0efa524348e2ae31827fd52eebf3f0d ] This patch fixes several issue with wake-up handling: - the WUF irq is handled several times at wake-up - the USART is disabled / enabled at suspend to set wake-up flag. It can cause glitches during RX. This patch fix those issues: - clear wake-up flag and disable wake-up irq in WUF irq handling - enable wake-up from low power on start bit detection at port configuration - Unmask the wake-up flag irq at suspend and mask it at resume In addition, pm_wakeup_event handling is moved from receice_chars to WUF irq handling. Fixes: 270e5a74fe4c ("serial: stm32: add wakeup mechanism") Signed-off-by: Erwan Le Ray Link: https://lore.kernel.org/r/20210304162308.8984-7-erwan.leray@foss.st.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit f6fba14ddd5e3d837bfb63a48f7c7f304de5ca26 Author: Erwan Le Ray Date: Thu Mar 4 17:23:00 2021 +0100 serial: stm32: fix a deadlock condition with wakeup event [ Upstream commit ad7676812437a00a4c6be155fc17926069f99084 ] Deadlock issue is seen when enabling CONFIG_PROVE_LOCKING=Y, and uart console as wakeup source. Deadlock occurs when resuming from low power mode if system is waked up via usart console. The deadlock is triggered 100% when also disabling console suspend prior to go to suspend. Simplified call stack, deadlock condition: - stm32_console_write <-- spin_lock already held - print_circular_bug - pm_wakeup_dev_event <-- triggers lockdep as seen above - stm32_receive_chars - stm32_interrupt <-- wakeup via uart console, takes the lock So, revisit spin_lock in stm32-usart driver: - there is no need to hold the lock to access ICR (atomic clear of status flags) - only hold the lock inside stm32_receive_chars() routine (no need to call pm_wakeup_dev_event with lock held) - keep stm32_transmit_chars() routine called with lock held Fixes: 48a6092fb41f ("serial: stm32-usart: Add STM32 USART Driver") Signed-off-by: Erwan Le Ray Signed-off-by: Fabrice Gasnier Link: https://lore.kernel.org/r/20210304162308.8984-6-erwan.leray@foss.st.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9b10b39da6aae5a876caa2558fe445e702de711e Author: Erwan Le Ray Date: Thu Mar 4 17:22:59 2021 +0100 serial: stm32: fix TX and RX FIFO thresholds [ Upstream commit 25a8e7611da5513b388165661b17173c26e12c04 ] TX and RX FIFO thresholds may be cleared after suspend/resume, depending on the low power mode. Those configurations (done in startup) are not effective for UART console, as: - the reference manual indicates that FIFOEN bit can only be written when the USART is disabled (UE=0) - a set_termios (where UE is set) is requested firstly for console enabling, before the startup. Fixes: 84872dc448fe ("serial: stm32: add RX and TX FIFO flush") Signed-off-by: Erwan Le Ray Link: https://lore.kernel.org/r/20210304162308.8984-5-erwan.leray@foss.st.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ace36d5a4249e27cf2452d5c1d35a58d4f6eca89 Author: Erwan Le Ray Date: Thu Mar 4 17:22:58 2021 +0100 serial: stm32: fix incorrect characters on console [ Upstream commit f264c6f6aece81a9f8fbdf912b20bd3feb476a7a ] Incorrect characters are observed on console during boot. This issue occurs when init/main.c is modifying termios settings to open /dev/console on the rootfs. This patch adds a waiting loop in set_termios to wait for TX shift register empty (and TX FIFO if any) before stopping serial port. Fixes: 48a6092fb41f ("serial: stm32-usart: Add STM32 USART Driver") Signed-off-by: Erwan Le Ray Link: https://lore.kernel.org/r/20210304162308.8984-4-erwan.leray@foss.st.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit df5cee6527997dc26dcfb95033115bcabef646ec Author: Erwan Le Ray Date: Thu Mar 4 17:22:57 2021 +0100 serial: stm32: fix startup by enabling usart for reception [ Upstream commit f4518a8a75f5be1a121b0c95ad9c6b1eb27d920e ] RX is configured, but usart is not enabled in startup function. Kernel documentation specifies that startup should enable the port for reception. Fix the startup by enabling usart for reception. Fixes: 84872dc448fe ("serial: stm32: add RX and TX FIFO flush") Signed-off-by: Erwan Le Ray Link: https://lore.kernel.org/r/20210304162308.8984-3-erwan.leray@foss.st.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 3d8b6e3242fb1b01a5c5ce7f8d226ae4e12d0a89 Author: Erwan Le Ray Date: Thu Mar 4 17:22:56 2021 +0100 serial: stm32: fix probe and remove order for dma [ Upstream commit 87fd0741d6dcf63ebdb14050c2b921ae14c7f307 ] The probe and remove orders are wrong as the uart_port is registered before saving device data in the probe, and unregistered after DMA resource deallocation in the remove. uart_port registering should be done at the end of probe and unregistering should be done at the begin of remove to avoid resource allocation issues. Fix probe and remove orders. This enforce resource allocation occur at proper time. Terminate both DMA rx and tx transfers before removing device. Move pm_runtime after uart_remove_one_port() call in remove() to keep the probe error path. Fixes: 3489187204eb ("serial: stm32: adding dma support") Signed-off-by: Erwan Le Ray Link: https://lore.kernel.org/r/20210304162308.8984-2-erwan.leray@foss.st.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit f1a704aa1cd03926685240eefe4467360b31581d Author: Mike Travis Date: Fri Mar 5 10:28:53 2021 -0600 x86/platform/uv: Set section block size for hubless architectures [ Upstream commit 6840a150b9daf35e4d21ab9780d0a03b4ed74a5b ] Commit bbbd2b51a2aa ("x86/platform/UV: Use new set memory block size function") added a call to set the block size value that is needed by the kernel to set the boundaries in the section list. This was done for UV Hubbed systems but missed in the UV Hubless setup. Fix that mistake by adding that same set call for hubless systems, which support the same NVRAMs and Intel BIOS, thus the same problem occurs. [ bp: Massage commit message. ] Fixes: bbbd2b51a2aa ("x86/platform/UV: Use new set memory block size function") Signed-off-by: Mike Travis Signed-off-by: Borislav Petkov Reviewed-by: Steve Wahl Reviewed-by: Russ Anderson Link: https://lkml.kernel.org/r/20210305162853.299892-1-mike.travis@hpe.com Signed-off-by: Sasha Levin commit 023f053c37b2a1ad7434733ecf6869329fdf931b Author: Tony Lindgren Date: Mon Mar 8 11:35:06 2021 +0200 bus: ti-sysc: Fix initializing module_pa for modules without sysc register [ Upstream commit 7bad5af826aba00487fed9a3300d3f43f0cba11b ] We have interconnect target modules with no known registers using only clocks and resets, but we still want to detect them based on the module IO range. So let's call sysc_parse_and_check_child_range() earlier so we have module_pa properly initialized. Fixes: 2928135c93f8 ("bus: ti-sysc: Support modules without control registers") Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit be4720a61d2b313c7e6004772e012151113c16f7 Author: Yoshihiro Shimoda Date: Mon Mar 1 20:06:26 2021 +0900 arm64: dts: renesas: Add mmc aliases into board dts files [ Upstream commit d765a4f302cc046ca23453ba990d21120ceadbbd ] After the commit 7320915c8861 ("mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in v4.14"), the order of /dev/mmcblkN was not fixed in some SoCs which have multiple sdhi controllers. So, we were hard to use an sdhi device as rootfs by using the kernel parameter like "root=/dev/mmcblkNpM". According to the discussion on a mainling list [1], we can add mmc aliases to fix the issue. So, add such aliases into Renesas arm64 board dts files. Notes that mmc0 is an eMMC channel if available. [1] https://lore.kernel.org/linux-arm-kernel/CAPDyKFptyEQNJu8cqzMt2WRFZcwEdjDiytMBp96nkoZyprTgmA@mail.gmail.com/ Fixes: 7320915c8861 ("mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in v4.14") Signed-off-by: Yoshihiro Shimoda Link: https://lore.kernel.org/r/1614596786-22326-1-git-send-email-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit c1cc1df36c52093242877ac86d1d56fef4314534 Author: Yoshihiro Shimoda Date: Fri Feb 12 21:01:56 2021 +0900 ARM: dts: renesas: Add mmc aliases into R-Car Gen2 board dts files [ Upstream commit da926e813fc7f9f0912fa413981a1f5ba63a536d ] After set PROBE_PREFER_ASYNCHRONOUS flag on the mmc host drivers, the order of /dev/mmcblkN was not fixed in some SoCs which have multiple SDHI and/or MMCIF controllers. So, we were hard to use such a device as rootfs by using the kernel parameter like "root=/dev/mmcblkNpM". According to the discussion on a mainling list [1], we can add mmc aliases to fix the issue. So, add such aliases into R-Car Gen2 board dts files. Note that, since R-Car Gen2 is even more complicated about SDHI and/or MMCIF channels variations and they share pins, add the aliases into board dts files instead of SoC dtsi files. [1] https://lore.kernel.org/linux-arm-kernel/CAPDyKFptyEQNJu8cqzMt2WRFZcwEdjDiytMBp96nkoZyprTgmA@mail.gmail.com/ Fixes: 7320915c8861 ("mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in v4.14") Fixes: 21b2cec61c04 ("mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in v4.4") Signed-off-by: Yoshihiro Shimoda Link: https://lore.kernel.org/r/1613131316-30994-1-git-send-email-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit e59274ac3b785c9da77c21b9891952e748c770db Author: Krzysztof Kozlowski Date: Thu Dec 10 22:25:26 2020 +0100 ARM: dts: s5pv210: correct fuel gauge interrupt trigger level on Fascinate family [ Upstream commit 214e6ec8c9f5a3353d3282b3ff475d3ee86cc21a ] The Maxim fuel gauge datasheets describe the interrupt line as active low with a requirement of acknowledge from the CPU. The falling edge interrupt will mostly work but it's not correct. Fixes: 99bb20321f0e ("ARM: dts: s5pv210: Correct fuelgauge definition on Aries") Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20201210212534.216197-10-krzk@kernel.org Signed-off-by: Sasha Levin commit 8ce23c685240e8d477b67633e1da560f45836b15 Author: Krzysztof Kozlowski Date: Thu Dec 10 22:25:25 2020 +0100 ARM: dts: exynos: correct PMIC interrupt trigger level on Snow [ Upstream commit 8987efbb17c2522be8615085df9a14da2ab53d34 ] The Maxim PMIC datasheets describe the interrupt line as active low with a requirement of acknowledge from the CPU. Without specifying the interrupt type in Devicetree, kernel might apply some fixed configuration, not necessarily working for this hardware. Additionally, the interrupt line is shared so using level sensitive interrupt is here especially important to avoid races. Fixes: c61248afa819 ("ARM: dts: Add max77686 RTC interrupt to cros5250-common") Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20201210212534.216197-9-krzk@kernel.org Signed-off-by: Sasha Levin commit 1b05b10ba6768b6ee349858f0b653996a0b07e3a Author: Krzysztof Kozlowski Date: Thu Dec 10 22:25:24 2020 +0100 ARM: dts: exynos: correct PMIC interrupt trigger level on SMDK5250 [ Upstream commit f6368c60561370e4a92fac22982a3bd656172170 ] The Maxim PMIC datasheets describe the interrupt line as active low with a requirement of acknowledge from the CPU. Without specifying the interrupt type in Devicetree, kernel might apply some fixed configuration, not necessarily working for this hardware. Additionally, the interrupt line is shared so using level sensitive interrupt is here especially important to avoid races. Fixes: 47580e8d94c2 ("ARM: dts: Specify MAX77686 pmic interrupt for exynos5250-smdk5250") Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20201210212534.216197-8-krzk@kernel.org Signed-off-by: Sasha Levin commit 7ebd2607296ec1538605ffd49d68b8e45222d2ee Author: Krzysztof Kozlowski Date: Thu Dec 10 22:25:23 2020 +0100 ARM: dts: exynos: correct PMIC interrupt trigger level on P4 Note family [ Upstream commit fbe9c9bb2e929865500a0985735f81c0142accad ] The Maxim PMIC datasheets describe the interrupt line as active low with a requirement of acknowledge from the CPU. Without specifying the interrupt type in Devicetree, kernel might apply some fixed configuration, not necessarily working for this hardware. Additionally, the interrupt line is shared so using level sensitive interrupt is here especially important to avoid races. Fixes: f48b5050c301 ("ARM: dts: exynos: add Samsung's Exynos4412-based P4 Note boards") Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20201210212534.216197-7-krzk@kernel.org Signed-off-by: Sasha Levin commit 642a587880f1b4dbb7c793540633bbd2b48510fc Author: Krzysztof Kozlowski Date: Thu Dec 10 22:25:22 2020 +0100 ARM: dts: exynos: correct PMIC interrupt trigger level on Odroid X/U3 family [ Upstream commit 6503c568e97a52f8b7a3109718db438e52e59485 ] The Maxim PMIC datasheets describe the interrupt line as active low with a requirement of acknowledge from the CPU. Without specifying the interrupt type in Devicetree, kernel might apply some fixed configuration, not necessarily working for this hardware. Additionally, the interrupt line is shared so using level sensitive interrupt is here especially important to avoid races. Fixes: eea6653aae7b ("ARM: dts: Enable PMIC interrupts for exynos4412-odroid-common") Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20201210212534.216197-6-krzk@kernel.org Signed-off-by: Sasha Levin commit c883c93ee1444ba33d817fbb27d48add945df635 Author: Krzysztof Kozlowski Date: Thu Dec 10 22:25:21 2020 +0100 ARM: dts: exynos: correct PMIC interrupt trigger level on Midas family [ Upstream commit e52dcd6e70fab51f53292e53336ecb007bb60889 ] The Maxim PMIC datasheets describe the interrupt line as active low with a requirement of acknowledge from the CPU. Without specifying the interrupt type in Devicetree, kernel might apply some fixed configuration, not necessarily working for this hardware. Additionally, the interrupt line is shared so using level sensitive interrupt is here especially important to avoid races. Fixes: 15dfdfad2d4a ("ARM: dts: Add basic dts for Exynos4412-based Trats 2 board") Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20201210212534.216197-5-krzk@kernel.org Signed-off-by: Sasha Levin commit 9b928651cc3bba3e9aaaff53f0fd1708cb6ce421 Author: Krzysztof Kozlowski Date: Thu Dec 10 22:25:20 2020 +0100 ARM: dts: exynos: correct MUIC interrupt trigger level on Midas family [ Upstream commit 15107e443ab8c6cb35eff10438993e4bc944d9ae ] The Maxim MUIC datasheets describe the interrupt line as active low with a requirement of acknowledge from the CPU. Without specifying the interrupt type in Devicetree, kernel might apply some fixed configuration, not necessarily working for this hardware. Additionally, the interrupt line is shared so using level sensitive interrupt is here especially important to avoid races. Fixes: 7eec1266751b ("ARM: dts: Add Maxim 77693 PMIC to exynos4412-trats2") Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20201210212534.216197-4-krzk@kernel.org Signed-off-by: Sasha Levin commit f73c51927a771077419f75b1c69a97ecaadf01eb Author: Krzysztof Kozlowski Date: Thu Dec 10 22:25:19 2020 +0100 ARM: dts: exynos: correct fuel gauge interrupt trigger level on Midas family [ Upstream commit 8a45f33bd36efbb624198cfa9fdf1f66fd1c3d26 ] The Maxim fuel gauge datasheets describe the interrupt line as active low with a requirement of acknowledge from the CPU. The falling edge interrupt will mostly work but it's not correct. Fixes: e8614292cd41 ("ARM: dts: Add Maxim 77693 fuel gauge node for exynos4412-trats2") Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20201210212534.216197-3-krzk@kernel.org Signed-off-by: Sasha Levin commit 277d9da7d39a4ca514a15cb3da986ab944dffe0c Author: Krzysztof Kozlowski Date: Thu Dec 10 22:25:18 2020 +0100 ARM: dts: exynos: correct fuel gauge interrupt trigger level on P4 Note family [ Upstream commit c731a16e2cf424a462c7d42c33d6acd613576508 ] The Maxim fuel gauge datasheets describe the interrupt line as active low with a requirement of acknowledge from the CPU. The falling edge interrupt will mostly work but it's not correct. Fixes: f48b5050c301 ("ARM: dts: exynos: add Samsung's Exynos4412-based P4 Note boards") Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20201210212534.216197-2-krzk@kernel.org Signed-off-by: Sasha Levin commit 96efb5ea80cd1983a634443cc5c074ba8ca5dc0f Author: Krzysztof Kozlowski Date: Thu Dec 10 22:25:17 2020 +0100 ARM: dts: exynos: correct fuel gauge interrupt trigger level on GT-I9100 [ Upstream commit 46799802136670e00498f19898f1635fbc85f583 ] The Maxim fuel gauge datasheets describe the interrupt line as active low with a requirement of acknowledge from the CPU. The falling edge interrupt will mostly work but it's not correct. Fixes: 8620cc2f99b7 ("ARM: dts: exynos: Add devicetree file for the Galaxy S2") Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20201210212534.216197-1-krzk@kernel.org Signed-off-by: Sasha Levin commit 32feeec631a2d189a2d6a2a3291cae3a68074aa4 Author: Colin Ian King Date: Tue Feb 23 19:38:21 2021 +0000 memory: gpmc: fix out of bounds read and dereference on gpmc_cs[] [ Upstream commit e004c3e67b6459c99285b18366a71af467d869f5 ] Currently the array gpmc_cs is indexed by cs before it cs is range checked and the pointer read from this out-of-index read is dereferenced. Fix this by performing the range check on cs before the read and the following pointer dereference. Addresses-Coverity: ("Negative array index read") Fixes: 9ed7a776eb50 ("ARM: OMAP2+: Fix support for multiple devices on a GPMC chip select") Signed-off-by: Colin Ian King Reviewed-by: Tony Lindgren Link: https://lore.kernel.org/r/20210223193821.17232-1-colin.king@canonical.com Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit 50e7b39b808430ad49a637dc6fb72ca93b451b13 Author: Corentin Labbe Date: Fri Feb 12 09:46:10 2021 +0100 crypto: sun8i-ss - fix result memory leak on error path [ Upstream commit 1dbc6a1e25be8575d6c4114d1d2b841a796507f7 ] This patch fixes a memory leak on an error path. Fixes: d9b45418a917 ("crypto: sun8i-ss - support hash algorithms") Reported-by: kernel test robot Reported-by: Dan Carpenter Signed-off-by: Corentin Labbe Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit ac9675c000054667fe443c57c9ea884e472cd6c0 Author: Wei Yongjun Date: Wed Feb 10 07:45:27 2021 +0000 crypto: keembay-ocs-aes - Fix error return code in kmb_ocs_aes_probe() [ Upstream commit 2eee428d8212265af09d349b74746be03513382e ] Fix to return negative error code -ENOMEM from the error handling case instead of 0, as done elsewhere in this function. Fixes: 885743324513 ("crypto: keembay - Add support for Keem Bay OCS AES/SM4") Reported-by: Hulk Robot Signed-off-by: Wei Yongjun Reviewed-by: Daniele Alessandrelli Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit f2ad9cbc94a09ff164bff20b1f2c10de26c1828e Author: Wei Yongjun Date: Wed Feb 10 07:43:50 2021 +0000 crypto: keembay-ocs-hcu - Fix error return code in kmb_ocs_hcu_probe() [ Upstream commit 662c1c5618aaf71f99ada3105b99668a503605ae ] Fix to return negative error code -ENOMEM from the error handling case instead of 0, as done elsewhere in this function. Fixes: 472b04444cd3 ("crypto: keembay - Add Keem Bay OCS HCU driver") Reported-by: Hulk Robot Signed-off-by: Wei Yongjun Reviewed-by: Daniele Alessandrelli Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 4a153aacc73e07b052b6fe3a8ae4e27fa48f5456 Author: Luca Ceresoli Date: Thu Feb 4 13:13:13 2021 +0100 fpga: fpga-mgr: xilinx-spi: fix error messages on -EPROBE_DEFER [ Upstream commit 484a58607a808c3721917f5ca5fba7eff809e4df ] The current code produces an error message on devm_gpiod_get() errors even when the error is -EPROBE_DEFER, which should be silent. This has been observed producing a significant amount of messages like: xlnx-slave-spi spi1.1: Failed to get PROGRAM_B gpio: -517 Fix and simplify code by using the dev_err_probe() helper function. Signed-off-by: Luca Ceresoli Fixes: dd2784c01d93 ("fpga manager: xilinx-spi: check INIT_B pin during write_init") Fixes: 061c97d13f1a ("fpga manager: Add Xilinx slave serial SPI driver") Signed-off-by: Moritz Fischer Signed-off-by: Sasha Levin commit d28a7779d45b31e91790c6b0d279823bfa8c7fc4 Author: Jiri Slaby Date: Wed Mar 3 07:43:57 2021 +0100 x86/vdso: Use proper modifier for len's format specifier in extract() [ Upstream commit 70c9d959226b7c5c48c119e2c1cfc1424f87b023 ] Commit 8382c668ce4f ("x86/vdso: Add support for exception fixup in vDSO functions") prints length "len" which is size_t. Compilers now complain when building on a 32-bit host: HOSTCC arch/x86/entry/vdso/vdso2c ... In file included from arch/x86/entry/vdso/vdso2c.c:162: arch/x86/entry/vdso/vdso2c.h: In function 'extract64': arch/x86/entry/vdso/vdso2c.h:38:52: warning: format '%lu' expects argument of \ type 'long unsigned int', but argument 4 has type 'size_t' {aka 'unsigned int'} So use proper modifier (%zu) for size_t. [ bp: Massage commit message. ] Fixes: 8382c668ce4f ("x86/vdso: Add support for exception fixup in vDSO functions") Signed-off-by: Jiri Slaby Signed-off-by: Borislav Petkov Acked-by: Jarkko Sakkinen Link: https://lkml.kernel.org/r/20210303064357.17056-1-jslaby@suse.cz Signed-off-by: Sasha Levin commit 17d45b88c1aff01862741bf45b3797a6760d5dd7 Author: Nobuhiro Iwamatsu Date: Tue Feb 16 00:58:49 2021 +0900 firmware: xilinx: Remove zynqmp_pm_get_eemi_ops() in IS_REACHABLE(CONFIG_ZYNQMP_FIRMWARE) [ Upstream commit 79bfe480a0a0b259ab9fddcd2fe52c03542b1196 ] zynqmp_pm_get_eemi_ops() was removed in commit 4db8180ffe7c: "Firmware: xilinx: Remove eemi ops for fpga related APIs", but not in IS_REACHABLE(CONFIG_ZYNQMP_FIRMWARE). Any driver who want to communicate with PMC using EEMI APIs use the functions provided for each function This removed zynqmp_pm_get_eemi_ops() in IS_REACHABLE(CONFIG_ZYNQMP_FIRMWARE), and also modify the documentation for this driver. Fixes: 4db8180ffe7c ("firmware: xilinx: Remove eemi ops for fpga related APIs") Signed-off-by: Nobuhiro Iwamatsu Link: https://lore.kernel.org/r/20210215155849.2425846-1-iwamatsu@nigauri.org Signed-off-by: Michal Simek Signed-off-by: Sasha Levin commit f7476bf64f40dbd0dc87c7999675aa97ccf901ec Author: Tejas Patel Date: Sun Feb 7 22:31:23 2021 -0800 firmware: xilinx: Fix dereferencing freed memory [ Upstream commit f1f21bece82c76a56a96988ec7d51ccc033d8949 ] Fix smatch warning: drivers/firmware/xilinx/zynqmp.c:1288 zynqmp_firmware_remove() error: dereferencing freed memory 'feature_data' Use hash_for_each_safe for safe removal of hash entry. Fixes: acfdd18591ea ("firmware: xilinx: Use hash-table for api feature check") Reported-by: kernel test robot Reported-by: Dan Carpenter Signed-off-by: Tejas Patel Signed-off-by: Rajan Vaja Link: https://lore.kernel.org/r/1612765883-22018-1-git-send-email-rajan.vaja@xilinx.com Signed-off-by: Michal Simek Signed-off-by: Sasha Levin commit 07871a25dfb3beb54511dd906993a6ce5a907705 Author: Len Brown Date: Thu Mar 11 18:36:35 2021 -0500 Revert "tools/power turbostat: adjust for temperature offset" commit b2b94be787bf47eedd5890a249f3318bf9f1f1d5 upstream. This reverts commit 6ff7cb371c4bea3dba03a56d774da925e78a5087. Apparently the TCC offset should not be used to adjust what temperature we show the user after all. (on most systems, TCC offset is 0, FWIW) Fixes: 6ff7cb371c4b Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman commit e879c36a851270dafc30500bd3ba30d2b3655b53 Author: Andy Shevchenko Date: Tue Mar 23 17:36:24 2021 +0200 usb: gadget: pch_udc: Revert d3cb25a12138 completely commit 50a318cc9b54a36f00beadf77e578a50f3620477 upstream. The commit d3cb25a12138 ("usb: gadget: udc: fix spin_lock in pch_udc") obviously was not thought through and had made the situation even worse than it was before. Two changes after almost reverted it. but a few leftovers have been left as it. With this revert d3cb25a12138 completely. While at it, narrow down the scope of unlocked section to prevent potential race when prot_stall is assigned. Fixes: d3cb25a12138 ("usb: gadget: udc: fix spin_lock in pch_udc") Fixes: 9903b6bedd38 ("usb: gadget: pch-udc: fix lock") Fixes: 1d23d16a88e6 ("usb: gadget: pch_udc: reorder spin_[un]lock to avoid deadlock") Cc: Iago Abal Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210323153626.54908-5-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 3228a02f91d5a2d0abfe7d0ccb16c3cf7fffd2e3 Author: Gerd Hoffmann Date: Thu Feb 4 15:57:03 2021 +0100 Revert "drm/qxl: do not run release if qxl failed to init" commit 93d8da8d7efbf690c0a9eaca798acc0c625245e6 upstream. This reverts commit b91907a6241193465ca92e357adf16822242296d. Patch is broken, it effectively makes qxl_drm_release() a nop because on normal driver shutdown qxl_drm_release() is called *after* drm_dev_unregister(). Fixes: b91907a62411 ("drm/qxl: do not run release if qxl failed to init") Cc: Tong Zhang Signed-off-by: Gerd Hoffmann Acked-by: Thomas Zimmermann Link: http://patchwork.freedesktop.org/patch/msgid/20210204145712.1531203-3-kraxel@redhat.com Signed-off-by: Greg Kroah-Hartman commit 93a3589b710ee3ebd653a378fb0cbfe97877d20d Author: Dan Carpenter Date: Tue Mar 23 16:19:35 2021 +0300 ovl: fix missing revert_creds() on error path commit 7b279bbfd2b230c7a210ff8f405799c7e46bbf48 upstream. Smatch complains about missing that the ovl_override_creds() doesn't have a matching revert_creds() if the dentry is disconnected. Fix this by moving the ovl_override_creds() until after the disconnected check. Fixes: aa3ff3c152ff ("ovl: copy up of disconnected dentries") Signed-off-by: Dan Carpenter Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit af582bd4a21af114ea58e1c9c216088f4860bf47 Author: Rikard Falkeborn Date: Fri Mar 5 00:07:09 2021 +0100 mfd: stmpe: Revert "Constify static struct resource" commit cb9e880a797a77c21c0f0e7ccd553da8eb4870af upstream. In stmpe_devices_init(), the start and end field of these structs are modified, so they can not be const. Add a comment to those structs that lacked it to reduce the risk that this happens again. This reverts commit 8d7b3a6dac4eae22c58b0853696cbd256966741b. Fixes: 8d7b3a6dac4e ("mfd: stmpe: Constify static struct resource") Reported-by: Andy Shevchenko Signed-off-by: Rikard Falkeborn Reviewed-by: Andy Shevchenko Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit 13b824cf038ef67adf94e6c94cfdb777a88a8de1 Author: Jae Hyun Yoo Date: Thu Apr 8 10:28:03 2021 -0700 Revert "i3c master: fix missing destroy_workqueue() on error in i3c_master_register" commit 0d95f41ebde40d552bb4fea64b1d618607915fd6 upstream. Adding the destroy_workqueue call in i3c_master_register introduced below kernel warning because it makes duplicate destroy_workqueue calls when i3c_master_register fails after allocating the workqueue. The workqueue will be destroyed by i3c_masterdev_release which is called by put_device at the end of the i3c_master_register function eventually in failure cases so the workqueue doesn't need to be destroyed in i3c_master_register. [ 6.972952] WARNING: CPU: 1 PID: 1 at lib/list_debug.c:48 __list_del_entry_valid+0x9c/0xf4 [ 6.982205] list_del corruption, 8fe03c08->prev is LIST_POISON2 (00000122) [ 6.989910] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W 5.10.23-c12838a-dirty-31dc772 #1 [ 7.000295] Hardware name: Generic DT based system [ 7.005638] Backtrace: [ 7.008369] [<809133f0>] (dump_backtrace) from [<80913644>] (show_stack+0x20/0x24) [ 7.016819] r7:00000030 r6:60000013 r5:00000000 r4:813b5d40 [ 7.023137] [<80913624>] (show_stack) from [<8091e1a0>] (dump_stack+0x9c/0xb0) [ 7.031201] [<8091e104>] (dump_stack) from [<8011fa30>] (__warn+0xf8/0x154) [ 7.038972] r7:00000030 r6:00000009 r5:804fa1c8 r4:80b6eca4 [ 7.045289] [<8011f938>] (__warn) from [<80913d14>] (warn_slowpath_fmt+0x8c/0xc0) [ 7.053641] r7:00000030 r6:80b6eca4 r5:80b6ed74 r4:818cc000 [ 7.059960] [<80913c8c>] (warn_slowpath_fmt) from [<804fa1c8>] (__list_del_entry_valid+0x9c/0xf4) [ 7.069866] r9:96becf8c r8:818cc000 r7:8fe03c10 r6:8fe03c00 r5:8fe03ba0 r4:ff7ead4c [ 7.078513] [<804fa12c>] (__list_del_entry_valid) from [<8013f0b4>] (destroy_workqueue+0x1c4/0x23c) [ 7.088615] [<8013eef0>] (destroy_workqueue) from [<806aa124>] (i3c_masterdev_release+0x40/0xb0) [ 7.098421] r7:00000000 r6:81a43b80 r5:8fe65360 r4:8fe65048 [ 7.104740] [<806aa0e4>] (i3c_masterdev_release) from [<805f3f04>] (device_release+0x40/0xb0) [ 7.114254] r5:00000000 r4:8fe65048 [ 7.118245] [<805f3ec4>] (device_release) from [<808fe754>] (kobject_put+0xc8/0x204) [ 7.126885] r5:813978dc r4:8fe65048 [ 7.130877] [<808fe68c>] (kobject_put) from [<805f5fbc>] (put_device+0x20/0x24) [ 7.139037] r7:8fe65358 r6:8fe65368 r5:8fe65358 r4:8fe65048 [ 7.145355] [<805f5f9c>] (put_device) from [<806abac4>] (i3c_master_register+0x338/0xb00) [ 7.154487] [<806ab78c>] (i3c_master_register) from [<806ae084>] (dw_i3c_probe+0x224/0x24c) [ 7.163811] r10:00000000 r9:8fe7a100 r8:00000032 r7:819fa810 r6:819fa800 r5:8fe65040 [ 7.172547] r4:00000000 [ 7.175376] [<806ade60>] (dw_i3c_probe) from [<805fdc14>] (platform_drv_probe+0x44/0x80) [ 7.184409] r9:813a25c0 r8:00000000 r7:815ec114 r6:00000000 r5:813a25c0 r4:819fa810 [ 7.193053] [<805fdbd0>] (platform_drv_probe) from [<805fb83c>] (really_probe+0x108/0x50c) [ 7.202275] r5:815ec004 r4:819fa810 [ 7.206265] [<805fb734>] (really_probe) from [<805fc180>] (driver_probe_device+0xb4/0x190) [ 7.215492] r10:813dc000 r9:80c4385c r8:000000d9 r7:813a25c0 r6:819fa810 r5:00000000 [ 7.224228] r4:813a25c0 [ 7.227055] [<805fc0cc>] (driver_probe_device) from [<805fc5cc>] (device_driver_attach+0xb8/0xc0) [ 7.236959] r9:80c4385c r8:000000d9 r7:813a25c0 r6:819fa854 r4:819fa810 [ 7.244439] [<805fc514>] (device_driver_attach) from [<805fc65c>] (__driver_attach+0x88/0x16c) [ 7.254051] r7:00000000 r6:819fa810 r5:00000000 r4:813a25c0 [ 7.260369] [<805fc5d4>] (__driver_attach) from [<805f954c>] (bus_for_each_dev+0x88/0xc8) [ 7.269489] r7:00000000 r6:818cc000 r5:805fc5d4 r4:813a25c0 [ 7.275806] [<805f94c4>] (bus_for_each_dev) from [<805fc76c>] (driver_attach+0x2c/0x30) [ 7.284739] r7:81397c98 r6:00000000 r5:8fe7db80 r4:813a25c0 [ 7.291057] [<805fc740>] (driver_attach) from [<805f9eec>] (bus_add_driver+0x120/0x200) [ 7.299984] [<805f9dcc>] (bus_add_driver) from [<805fce44>] (driver_register+0x98/0x128) [ 7.309005] r7:80c4383c r6:00000000 r5:00000000 r4:813a25c0 [ 7.315323] [<805fcdac>] (driver_register) from [<805fedb4>] (__platform_driver_register+0x50/0x58) [ 7.325410] r5:818cc000 r4:81397c98 [ 7.329404] [<805fed64>] (__platform_driver_register) from [<80c23398>] (dw_i3c_driver_init+0x24/0x28) [ 7.339790] r5:818cc000 r4:80c23374 [ 7.343784] [<80c23374>] (dw_i3c_driver_init) from [<80c01300>] (do_one_initcall+0xac/0x1d0) [ 7.353206] [<80c01254>] (do_one_initcall) from [<80c01630>] (kernel_init_freeable+0x1a8/0x204) [ 7.362916] r8:000000d9 r7:80c4383c r6:00000007 r5:819ca2c0 r4:80c67680 [ 7.370398] [<80c01488>] (kernel_init_freeable) from [<8091eb18>] (kernel_init+0x18/0x12c) [ 7.379616] r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:8091eb00 [ 7.388343] r4:00000000 [ 7.391170] [<8091eb00>] (kernel_init) from [<80100148>] (ret_from_fork+0x14/0x2c) [ 7.399607] Exception stack(0x818cdfb0 to 0x818cdff8) [ 7.405243] dfa0: 00000000 00000000 00000000 00000000 [ 7.414371] dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 7.423499] dfe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 7.430879] r5:8091eb00 r4:00000000 This reverts commit 59165d16c699182b86b5c65181013f1fd88feb62. Fixes: 59165d16c699 ("i3c master: fix missing destroy_workqueue() on error in i3c_master_register") Signed-off-by: Jae Hyun Yoo Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20210408172803.24599-1-jae.hyun.yoo@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 401e15486bc06d1d3b6112088cf899214d164b87 Author: Xie He Date: Sun May 2 20:51:36 2021 -0700 Revert "drivers/net/wan/hdlc_fr: Fix a double free in pvc_xmit" commit d362fd0be456dba2d3d58a90b7a193962776562b upstream. This reverts commit 1b479fb80160 ("drivers/net/wan/hdlc_fr: Fix a double free in pvc_xmit"). 1. This commit is incorrect. "__skb_pad" will NOT free the skb on failure when its "free_on_error" parameter is "false". 2. This commit claims to fix my commit. But it didn't CC me?? Fixes: 1b479fb80160 ("drivers/net/wan/hdlc_fr: Fix a double free in pvc_xmit") Cc: Lv Yunlong Signed-off-by: Xie He Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 9e4f06d5d55eab7cc9cda4de8459028ed54d7d31 Author: Paolo Bonzini Date: Tue Apr 20 04:13:03 2021 -0400 KVM: selftests: Always run vCPU thread with blocked SIG_IPI commit bf1e15a82e3b74ee86bb119d6038b41e1ed2b319 upstream. The main thread could start to send SIG_IPI at any time, even before signal blocked on vcpu thread. Therefore, start the vcpu thread with the signal blocked. Without this patch, on very busy cores the dirty_log_test could fail directly on receiving a SIGUSR1 without a handler (when vcpu runs far slower than main). Reported-by: Peter Xu Cc: stable@vger.kernel.org Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit b821282e38a72f04a585338bbe31c9ce6317f806 Author: Peter Xu Date: Sat Apr 17 10:36:01 2021 -0400 KVM: selftests: Sync data verify of dirty logging with guest sync commit 016ff1a442d9a8f36dcb3beca0bcdfc35e281e18 upstream. This fixes a bug that can trigger with e.g. "taskset -c 0 ./dirty_log_test" or when the testing host is very busy. A similar previous attempt is done [1] but that is not enough, the reason is stated in the reply [2]. As a summary (partly quotting from [2]): The problem is I think one guest memory write operation (of this specific test) contains a few micro-steps when page is during kvm dirty tracking (here I'm only considering write-protect rather than pml but pml should be similar at least when the log buffer is full): (1) Guest read 'iteration' number into register, prepare to write, page fault (2) Set dirty bit in either dirty bitmap or dirty ring (3) Return to guest, data written When we verify the data, we assumed that all these steps are "atomic", say, when (1) happened for this page, we assume (2) & (3) must have happened. We had some trick to workaround "un-atomicity" of above three steps, as previous version of this patch wanted to fix atomicity of step (2)+(3) by explicitly letting the main thread wait for at least one vmenter of vcpu thread, which should work. However what I overlooked is probably that we still have race when (1) and (2) can be interrupted. One example calltrace when it could happen that we read an old interation, got interrupted before even setting the dirty bit and flushing data: __schedule+1742 __cond_resched+52 __get_user_pages+530 get_user_pages_unlocked+197 hva_to_pfn+206 try_async_pf+132 direct_page_fault+320 kvm_mmu_page_fault+103 vmx_handle_exit+288 vcpu_enter_guest+2460 kvm_arch_vcpu_ioctl_run+325 kvm_vcpu_ioctl+526 __x64_sys_ioctl+131 do_syscall_64+51 entry_SYSCALL_64_after_hwframe+68 It means iteration number cached in vcpu register can be very old when dirty bit set and data flushed. So far I don't see an easy way to guarantee all steps 1-3 atomicity but to sync at the GUEST_SYNC() point of guest code when we do verification of the dirty bits as what this patch does. [1] https://lore.kernel.org/lkml/20210413213641.23742-1-peterx@redhat.com/ [2] https://lore.kernel.org/lkml/20210417140956.GV4440@xz-x1/ Cc: Paolo Bonzini Cc: Sean Christopherson Cc: Andrew Jones Cc: stable@vger.kernel.org Signed-off-by: Peter Xu Message-Id: <20210417143602.215059-2-peterx@redhat.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 4dd4e8d2cc88965a2739e2e83847946e4695ee00 Author: Eric Auger Date: Mon Apr 5 18:39:34 2021 +0200 KVM: arm64: Fix KVM_VGIC_V3_ADDR_TYPE_REDIST_REGION read commit 53b16dd6ba5cf64ed147ac3523ec34651d553cb0 upstream. The doc says: "The characteristics of a specific redistributor region can be read by presetting the index field in the attr data. Only valid for KVM_DEV_TYPE_ARM_VGIC_V3" Unfortunately the existing code fails to read the input attr data. Fixes: 04c110932225 ("KVM: arm/arm64: Implement KVM_VGIC_V3_ADDR_TYPE_REDIST_REGION") Cc: stable@vger.kernel.org#v4.17+ Signed-off-by: Eric Auger Reviewed-by: Alexandru Elisei Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20210405163941.510258-3-eric.auger@redhat.com Signed-off-by: Greg Kroah-Hartman commit 8c6fc4ecc1d057a8986c759304b5a3292da40b7e Author: Marc Zyngier Date: Wed Apr 7 18:54:16 2021 +0100 KVM: arm64: Fully zero the vcpu state on reset commit 85d703746154cdc6794b6654b587b0b0354c97e9 upstream. On vcpu reset, we expect all the registers to be brought back to their initial state, which happens to be a bunch of zeroes. However, some recent commit broke this, and is now leaving a bunch of registers (such as the FP state) with whatever was left by the guest. My bad. Zero the reset of the state (32bit SPSRs and FPSIMD state). Cc: stable@vger.kernel.org Fixes: e47c2055c68e ("KVM: arm64: Make struct kvm_regs userspace-only") Signed-off-by: Marc Zyngier Signed-off-by: Greg Kroah-Hartman commit 5b1fec560e7085e03e04b0f2893fe829e5685bee Author: David Brazdil Date: Wed Mar 31 13:30:48 2021 +0000 KVM: arm64: Support PREL/PLT relocs in EL2 code commit 77e06b300161d41d65950be9c77a785c142b381d upstream. gen-hyprel tool parses object files of the EL2 portion of KVM and generates runtime relocation data. While only filtering for R_AARCH64_ABS64 relocations in the input object files, it has an allow-list of relocation types that are used for relative addressing. Other, unexpected, relocation types are rejected and cause the build to fail. This allow-list did not include the position-relative relocation types R_AARCH64_PREL64/32/16 and the recently introduced _PLT32. While not seen used by toolchains in the wild, add them to the allow-list for completeness. Fixes: 8c49b5d43d4c ("KVM: arm64: Generate hyp relocation data") Cc: Reported-by: Will Deacon Signed-off-by: David Brazdil Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20210331133048.63311-1-dbrazdil@google.com Signed-off-by: Greg Kroah-Hartman commit 50cbad42bfea8c052b7ca590bd4126cdc898713c Author: Sean Christopherson Date: Mon Apr 12 15:20:49 2021 -0700 KVM: Stop looking for coalesced MMIO zones if the bus is destroyed commit 5d3c4c79384af06e3c8e25b7770b6247496b4417 upstream. Abort the walk of coalesced MMIO zones if kvm_io_bus_unregister_dev() fails to allocate memory for the new instance of the bus. If it can't instantiate a new bus, unregister_dev() destroys all devices _except_ the target device. But, it doesn't tell the caller that it obliterated the bus and invoked the destructor for all devices that were on the bus. In the coalesced MMIO case, this can result in a deleted list entry dereference due to attempting to continue iterating on coalesced_zones after future entries (in the walk) have been deleted. Opportunistically add curly braces to the for-loop, which encompasses many lines but sneaks by without braces due to the guts being a single if statement. Fixes: f65886606c2d ("KVM: fix memory leak in kvm_io_bus_unregister_dev()") Cc: stable@vger.kernel.org Reported-by: Hao Sun Signed-off-by: Sean Christopherson Message-Id: <20210412222050.876100-3-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 30f46c6993731efb2a690c9197c0fd9ed425da2d Author: Sean Christopherson Date: Mon Apr 12 15:20:48 2021 -0700 KVM: Destroy I/O bus devices on unregister failure _after_ sync'ing SRCU commit 2ee3757424be7c1cd1d0bbfa6db29a7edd82a250 upstream. If allocating a new instance of an I/O bus fails when unregistering a device, wait to destroy the device until after all readers are guaranteed to see the new null bus. Destroying devices before the bus is nullified could lead to use-after-free since readers expect the devices on their reference of the bus to remain valid. Fixes: f65886606c2d ("KVM: fix memory leak in kvm_io_bus_unregister_dev()") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-Id: <20210412222050.876100-2-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit a2bc4ca001313a8304ccb6aa56d0301acb55ad13 Author: Eric Auger Date: Mon Apr 12 17:00:34 2021 +0200 KVM: arm/arm64: Fix KVM_VGIC_V3_ADDR_TYPE_REDIST read commit 94ac0835391efc1a30feda6fc908913ec012951e upstream. When reading the base address of the a REDIST region through KVM_VGIC_V3_ADDR_TYPE_REDIST we expect the redistributor region list to be populated with a single element. However list_first_entry() expects the list to be non empty. Instead we should use list_first_entry_or_null which effectively returns NULL if the list is empty. Fixes: dbd9733ab674 ("KVM: arm/arm64: Replace the single rdist region by a list") Cc: # v4.18+ Signed-off-by: Eric Auger Reported-by: Gavin Shan Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20210412150034.29185-1-eric.auger@redhat.com Signed-off-by: Greg Kroah-Hartman commit f0a0625e459cd19a5dd9ee9e4937216ceaa8ffaa Author: Sean Christopherson Date: Wed Apr 21 19:21:25 2021 -0700 KVM: nVMX: Truncate base/index GPR value on address calc in !64-bit commit 82277eeed65eed6c6ee5b8f97bd978763eab148f upstream. Drop bits 63:32 of the base and/or index GPRs when calculating the effective address of a VMX instruction memory operand. Outside of 64-bit mode, memory encodings are strictly limited to E*X and below. Fixes: 064aea774768 ("KVM: nVMX: Decoding memory operands of VMX instructions") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-Id: <20210422022128.3464144-7-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 1194e31eaea54f29f7cd55de4d130aa85d8d5396 Author: Sean Christopherson Date: Wed Apr 21 19:21:24 2021 -0700 KVM: nVMX: Truncate bits 63:32 of VMCS field on nested check in !64-bit commit ee050a577523dfd5fac95e6cc182ebe0293ead59 upstream. Drop bits 63:32 of the VMCS field encoding when checking for a nested VM-Exit on VMREAD/VMWRITE in !64-bit mode. VMREAD and VMWRITE always use 32-bit operands outside of 64-bit mode. The actual emulation of VMREAD/VMWRITE does the right thing, this bug is purely limited to incorrectly causing a nested VM-Exit if a GPR happens to have bits 63:32 set outside of 64-bit mode. Fixes: a7cde481b6e8 ("KVM: nVMX: Do not forward VMREAD/VMWRITE VMExits to L1 if required so by vmcs12 vmread/vmwrite bitmaps") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-Id: <20210422022128.3464144-6-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 3d386331268cfb4bd3239870ae4bb97ba38e2fbb Author: Sean Christopherson Date: Wed Apr 21 19:21:23 2021 -0700 KVM: VMX: Truncate GPR value for DR and CR reads in !64-bit mode commit d8971344f5739a9cc53f91f1f593ddd82265b93b upstream. Drop bits 63:32 when storing a DR/CR to a GPR when the vCPU is not in 64-bit mode. Per the SDM: The operand size for these instructions is always 32 bits in non-64-bit modes, regardless of the operand-size attribute. CR8 technically isn't affected as CR8 isn't accessible outside of 64-bit mode, but fix it up for consistency and to allow for future cleanup. Fixes: 6aa8b732ca01 ("[PATCH] kvm: userspace interface") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-Id: <20210422022128.3464144-5-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 5746acdd0af84a48e82448423e2757a50d0d7133 Author: Sean Christopherson Date: Thu Mar 4 17:10:57 2021 -0800 KVM: nVMX: Defer the MMU reload to the normal path on an EPTP switch commit c805f5d5585ab5e0cdac6b1ccf7086eb120fb7db upstream. Defer reloading the MMU after a EPTP successful EPTP switch. The VMFUNC instruction itself is executed in the previous EPTP context, any side effects, e.g. updating RIP, should occur in the old context. Practically speaking, this bug is benign as VMX doesn't touch the MMU when skipping an emulated instruction, nor does queuing a single-step #DB. No other post-switch side effects exist. Fixes: 41ab93727467 ("KVM: nVMX: Emulate EPTP switching for the L1 hypervisor") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-Id: <20210305011101.3597423-14-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 00ba45aaf834f7944e89c77c1ba69c2d88e203d6 Author: Sean Christopherson Date: Fri Apr 23 15:34:01 2021 -0700 KVM: SVM: Inject #GP on guest MSR_TSC_AUX accesses if RDTSCP unsupported commit 6f2b296aa6432d8274e258cc3220047ca04f5de0 upstream. Inject #GP on guest accesses to MSR_TSC_AUX if RDTSCP is unsupported in the guest's CPUID model. Fixes: 46896c73c1a4 ("KVM: svm: add support for RDTSCP") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-Id: <20210423223404.3860547-2-seanjc@google.com> Reviewed-by: Vitaly Kuznetsov Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 6dbfe62155822e530c0d6ecb95582d18c1e63a30 Author: Sean Christopherson Date: Tue Mar 30 20:19:36 2021 -0700 KVM: SVM: Do not allow SEV/SEV-ES initialization after vCPUs are created commit 8727906fde6ea665b52e68ddc58833772537f40a upstream. Reject KVM_SEV_INIT and KVM_SEV_ES_INIT if they are attempted after one or more vCPUs have been created. KVM assumes a VM is tagged SEV/SEV-ES prior to vCPU creation, e.g. init_vmcb() needs to mark the VMCB as SEV enabled, and svm_create_vcpu() needs to allocate the VMSA. At best, creating vCPUs before SEV/SEV-ES init will lead to unexpected errors and/or behavior, and at worst it will crash the host, e.g. sev_launch_update_vmsa() will dereference a null svm->vmsa pointer. Fixes: 1654efcbc431 ("KVM: SVM: Add KVM_SEV_INIT command") Fixes: ad73109ae7ec ("KVM: SVM: Provide support to launch and run an SEV-ES guest") Cc: stable@vger.kernel.org Cc: Brijesh Singh Cc: Tom Lendacky Signed-off-by: Sean Christopherson Message-Id: <20210331031936.2495277-4-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit fd88ede84e43bb6be419d626152a82f7dcc41b9a Author: Sean Christopherson Date: Tue Mar 30 20:19:35 2021 -0700 KVM: SVM: Do not set sev->es_active until KVM_SEV_ES_INIT completes commit 9fa1521daafb58d878d03d75f6863a11312fae22 upstream. Set sev->es_active only after the guts of KVM_SEV_ES_INIT succeeds. If the command fails, e.g. because SEV is already active or there are no available ASIDs, then es_active will be left set even though the VM is not fully SEV-ES capable. Refactor the code so that "es_active" is passed on the stack instead of being prematurely shoved into sev_info, both to avoid having to unwind sev_info and so that it's more obvious what actually consumes es_active in sev_guest_init() and its helpers. Fixes: ad73109ae7ec ("KVM: SVM: Provide support to launch and run an SEV-ES guest") Cc: stable@vger.kernel.org Cc: Brijesh Singh Cc: Tom Lendacky Signed-off-by: Sean Christopherson Message-Id: <20210331031936.2495277-3-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit ba7bf5d6336aa9c0d977b161bfa420c56d46ee40 Author: Sean Christopherson Date: Tue Mar 30 20:19:34 2021 -0700 KVM: SVM: Use online_vcpus, not created_vcpus, to iterate over vCPUs commit c36b16d29f3af5f32fc1b2a3401bf48f71cabee1 upstream. Use the kvm_for_each_vcpu() helper to iterate over vCPUs when encrypting VMSAs for SEV, which effectively switches to use online_vcpus instead of created_vcpus. This fixes a possible null-pointer dereference as created_vcpus does not guarantee a vCPU exists, since it is updated at the very beginning of KVM_CREATE_VCPU. created_vcpus exists to allow the bulk of vCPU creation to run in parallel, while still correctly restricting the max number of max vCPUs. Fixes: ad73109ae7ec ("KVM: SVM: Provide support to launch and run an SEV-ES guest") Cc: stable@vger.kernel.org Cc: Brijesh Singh Cc: Tom Lendacky Signed-off-by: Sean Christopherson Message-Id: <20210331031936.2495277-2-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 62ae40d4281a1cb3d0b3e87f4d9deb466efde156 Author: Sean Christopherson Date: Thu Mar 4 17:10:56 2021 -0800 KVM: SVM: Don't strip the C-bit from CR2 on #PF interception commit 6d1b867d045699d6ce0dfa0ef35d1b87dd36db56 upstream. Don't strip the C-bit from the faulting address on an intercepted #PF, the address is a virtual address, not a physical address. Fixes: 0ede79e13224 ("KVM: SVM: Clear C-bit from the page fault address") Cc: stable@vger.kernel.org Cc: Brijesh Singh Cc: Tom Lendacky Signed-off-by: Sean Christopherson Message-Id: <20210305011101.3597423-13-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit dd9c924a487a6bb5b0e9209ad5b76ec7cce81378 Author: Sean Christopherson Date: Thu Mar 4 17:10:45 2021 -0800 KVM: nSVM: Set the shadow root level to the TDP level for nested NPT commit a3322d5cd87fef5ec0037fd1b14068a533f9a60f upstream. Override the shadow root level in the MMU context when configuring NPT for shadowing nested NPT. The level is always tied to the TDP level of the host, not whatever level the guest happens to be using. Fixes: 096586fda522 ("KVM: nSVM: Correctly set the shadow NPT root level in its MMU role") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-Id: <20210305011101.3597423-2-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 00f892e28e1ad4dfe15e212f22ed07749ce06c68 Author: Sean Christopherson Date: Wed Apr 21 19:21:20 2021 -0700 KVM: x86: Remove emulator's broken checks on CR0/CR3/CR4 loads commit d0fe7b6404408835ed60232cb3bf28324b2f95db upstream. Remove the emulator's checks for illegal CR0, CR3, and CR4 values, as the checks are redundant, outdated, and in the case of SEV's C-bit, broken. The emulator manually calculates MAXPHYADDR from CPUID and neglects to mask off the C-bit. For all other checks, kvm_set_cr*() are a superset of the emulator checks, e.g. see CR4.LA57. Fixes: a780a3ea6282 ("KVM: X86: Fix reserved bits check for MOV to CR3") Cc: Babu Moger Signed-off-by: Sean Christopherson Message-Id: <20210422022128.3464144-2-seanjc@google.com> Cc: stable@vger.kernel.org [Unify check_cr_read and check_cr_write. - Paolo] Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 2c466d1bd7d643fcf0d84e6a2a02f358f7daa858 Author: Sean Christopherson Date: Wed Apr 21 19:21:21 2021 -0700 KVM: x86: Check CR3 GPA for validity regardless of vCPU mode commit 886bbcc7a523b8d4fac60f1015d2e0fcad50db82 upstream. Check CR3 for an invalid GPA even if the vCPU isn't in long mode. For bigger emulation flows, notably RSM, the vCPU mode may not be accurate if CR0/CR4 are loaded after CR3. For MOV CR3 and similar flows, the caller is responsible for truncating the value. Fixes: 660a5d517aaa ("KVM: x86: save/load state on SMM switch") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-Id: <20210422022128.3464144-3-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 36825931c6076dbc3ceff61b2a1fed779d9c8177 Author: Vitaly Kuznetsov Date: Thu Apr 22 11:29:48 2021 +0200 KVM: x86: Properly handle APF vs disabled LAPIC situation commit 2f15d027c05fac406decdb5eceb9ec0902b68f53 upstream. Async PF 'page ready' event may happen when LAPIC is (temporary) disabled. In particular, Sebastien reports that when Linux kernel is directly booted by Cloud Hypervisor, LAPIC is 'software disabled' when APF mechanism is initialized. On initialization KVM tries to inject 'wakeup all' event and puts the corresponding token to the slot. It is, however, failing to inject an interrupt (kvm_apic_set_irq() -> __apic_accept_irq() -> !apic_enabled()) so the guest never gets notified and the whole APF mechanism gets stuck. The same issue is likely to happen if the guest temporary disables LAPIC and a previously unavailable page becomes available. Do two things to resolve the issue: - Avoid dequeuing 'page ready' events from APF queue when LAPIC is disabled. - Trigger an attempt to deliver pending 'page ready' events when LAPIC becomes enabled (SPIV or MSR_IA32_APICBASE). Reported-by: Sebastien Boeuf Signed-off-by: Vitaly Kuznetsov Message-Id: <20210422092948.568327-1-vkuznets@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit f62bc34d2890b9363d34813f75b1eea8ab523bd0 Author: Wanpeng Li Date: Thu Apr 22 16:34:19 2021 +0800 KVM: X86: Fix failure to boost kernel lock holder candidate in SEV-ES guests commit b86bb11e3a79ac0db9a6786b1fe80f74321cb076 upstream. Commit f1c6366e3043 ("KVM: SVM: Add required changes to support intercepts under SEV-ES") prevents hypervisor accesses guest register state when the guest is running under SEV-ES. The initial value of vcpu->arch.guest_state_protected is false, it will not be updated in preemption notifiers after this commit which means that the kernel spinlock lock holder will always be skipped to boost. Let's fix it by always treating preempted is in the guest kernel mode, false positive is better than skip completely. Fixes: f1c6366e3043 (KVM: SVM: Add required changes to support intercepts under SEV-ES) Signed-off-by: Wanpeng Li Message-Id: <1619080459-30032-1-git-send-email-wanpengli@tencent.com> Cc: stable@vger.kernel.org Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit dd42721d3a0e5f4e00c83d1f2da68c4d7468949f Author: Sean Christopherson Date: Wed Apr 21 19:21:26 2021 -0700 KVM: x86/xen: Drop RAX[63:32] when processing hypercall commit 6b48fd4cb206485c357420d91ea766ef81b20dc3 upstream. Truncate RAX to 32 bits, i.e. consume EAX, when retrieving the hypecall index for a Xen hypercall. Per Xen documentation[*], the index is EAX when the vCPU is not in 64-bit mode. [*] http://xenbits.xenproject.org/docs/sphinx-unstable/guest-guide/x86/hypercall-abi.html Fixes: 23200b7a30de ("KVM: x86/xen: intercept xen hypercalls if enabled") Cc: Joao Martins Cc: David Woodhouse Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-Id: <20210422022128.3464144-8-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit a974aed548b20bf6483b6098d830cdd22fd5bcb8 Author: Sean Christopherson Date: Thu Mar 4 17:10:46 2021 -0800 KVM: x86/mmu: Alloc page for PDPTEs when shadowing 32-bit NPT with 64-bit commit 04d45551a1eefbea42655da52f56e846c0af721a upstream. Allocate the so called pae_root page on-demand, along with the lm_root page, when shadowing 32-bit NPT with 64-bit NPT, i.e. when running a 32-bit L1. KVM currently only allocates the page when NPT is disabled, or when L0 is 32-bit (using PAE paging). Note, there is an existing memory leak involving the MMU roots, as KVM fails to free the PAE roots on failure. This will be addressed in a future commit. Fixes: ee6268ba3a68 ("KVM: x86: Skip pae_root shadow allocation if tdp enabled") Fixes: b6b80c78af83 ("KVM: x86/mmu: Allocate PAE root array when using SVM's 32-bit NPT") Cc: stable@vger.kernel.org Reviewed-by: Ben Gardon Signed-off-by: Sean Christopherson Message-Id: <20210305011101.3597423-3-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit d8032e13979d944aa8bbafaac66e22deeb4365b4 Author: Claudio Imbrenda Date: Mon Feb 1 17:26:54 2021 +0100 KVM: s390: extend kvm_s390_shadow_fault to return entry pointer commit 5ac14bac08ae827b619f21bcceaaac3b8c497e31 upstream. Extend kvm_s390_shadow_fault to return the pointer to the valid leaf DAT table entry, or to the invalid entry. Also return some flags in the lower bits of the address: PEI_DAT_PROT: indicates that DAT protection applies because of the protection bit in the segment (or, if EDAT, region) tables. PEI_NOT_PTE: indicates that the address of the DAT table entry returned does not refer to a PTE, but to a segment or region table. Signed-off-by: Claudio Imbrenda Cc: stable@vger.kernel.org Reviewed-by: Janosch Frank Reviewed-by: David Hildenbrand Reviewed-by: Christian Borntraeger Link: https://lore.kernel.org/r/20210302174443.514363-3-imbrenda@linux.ibm.com [borntraeger@de.ibm.com: fold in a fix from Claudio] Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit f09435247c5fb891b12feec5d3cf4c91898570ae Author: Claudio Imbrenda Date: Mon Mar 22 15:05:58 2021 +0100 KVM: s390: split kvm_s390_real_to_abs commit c5d1f6b531e68888cbe6718b3f77a60115d58b9c upstream. A new function _kvm_s390_real_to_abs will apply prefixing to a real address with a given prefix value. The old kvm_s390_real_to_abs becomes now a wrapper around the new function. This is needed to avoid code duplication in vSIE. Signed-off-by: Claudio Imbrenda Reviewed-by: David Hildenbrand Reviewed-by: Thomas Huth Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210322140559.500716-2-imbrenda@linux.ibm.com Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit 8baf398f50f155e15495d16e300cd73027211d86 Author: Claudio Imbrenda Date: Mon Mar 22 15:05:59 2021 +0100 KVM: s390: VSIE: fix MVPG handling for prefixing and MSO commit c3171e94cc1cdcc3229565244112e869f052b8d9 upstream. Prefixing needs to be applied to the guest real address to translate it into a guest absolute address. The value of MSO needs to be added to a guest-absolute address in order to obtain the host-virtual. Fixes: bdf7509bbefa ("s390/kvm: VSIE: correctly handle MVPG when in VSIE") Reported-by: Janosch Frank Signed-off-by: Claudio Imbrenda Reviewed-by: David Hildenbrand Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210322140559.500716-3-imbrenda@linux.ibm.com [borntraeger@de.ibm.com simplify mso] Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit f5a0098b46b21fc2e6c5d82246d6b6af0f8887fd Author: David Hildenbrand Date: Mon May 3 14:12:44 2021 +0200 s390: fix detection of vector enhancements facility 1 vs. vector packed decimal facility commit b208108638c4bd3215792415944467c36f5dfd97 upstream. The PoP documents: 134: The vector packed decimal facility is installed in the z/Architecture architectural mode. When bit 134 is one, bit 129 is also one. 135: The vector enhancements facility 1 is installed in the z/Architecture architectural mode. When bit 135 is one, bit 129 is also one. Looks like we confuse the vector enhancements facility 1 ("EXT") with the Vector packed decimal facility ("BCD"). Let's fix the facility checks. Detected while working on QEMU/tcg z14 support and only unlocking the vector enhancements facility 1, but not the vector packed decimal facility. Fixes: 2583b848cad0 ("s390: report new vector facilities") Cc: Vasily Gorbik Signed-off-by: David Hildenbrand Reviewed-by: Christian Borntraeger Reviewed-by: Cornelia Huck Reviewed-by: Janosch Frank Link: https://lore.kernel.org/r/20210503121244.25232-1-david@redhat.com Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit 4f5a74461656b3d3e44abee987cb33cbdf46b8a2 Author: Heiko Carstens Date: Thu Apr 15 10:01:27 2021 +0200 KVM: s390: fix guarded storage control register handling commit 44bada28219031f9e8e86b84460606efa57b871e upstream. store_regs_fmt2() has an ordering problem: first the guarded storage facility is enabled on the local cpu, then preemption disabled, and then the STGSC (store guarded storage controls) instruction is executed. If the process gets scheduled away between enabling the guarded storage facility and before preemption is disabled, this might lead to a special operation exception and therefore kernel crash as soon as the process is scheduled back and the STGSC instruction is executed. Fixes: 4e0b1ab72b8a ("KVM: s390: gs support for kvm guests") Signed-off-by: Heiko Carstens Reviewed-by: Christian Borntraeger Reviewed-by: David Hildenbrand Reviewed-by: Janosch Frank Reviewed-by: Cornelia Huck Cc: # 4.12 Link: https://lore.kernel.org/r/20210415080127.1061275-1-hca@linux.ibm.com Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit 02a9126f51a50bceb3c3b4a15ca8cd9a40485ccc Author: Claudio Imbrenda Date: Tue Mar 2 13:36:44 2021 +0100 KVM: s390: split kvm_s390_logical_to_effective commit f85f1baaa18932a041fd2b1c2ca6cfd9898c7d2b upstream. Split kvm_s390_logical_to_effective to a generic function called _kvm_s390_logical_to_effective. The new function takes a PSW and an address and returns the address with the appropriate bits masked off. The old function now calls the new function with the appropriate PSW from the vCPU. This is needed to avoid code duplication for vSIE. Signed-off-by: Claudio Imbrenda Reviewed-by: Christian Borntraeger Cc: stable@vger.kernel.org # for VSIE: correctly handle MVPG when in VSIE Link: https://lore.kernel.org/r/20210302174443.514363-2-imbrenda@linux.ibm.com Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit aac02c6bfdd65ecf38bdeac842e7fe6a8b3acef3 Author: Claudio Imbrenda Date: Mon Feb 1 21:54:13 2021 +0100 KVM: s390: VSIE: correctly handle MVPG when in VSIE commit bdf7509bbefa20855d5f6bacdc5b62a8489477c9 upstream. Correctly handle the MVPG instruction when issued by a VSIE guest. Fixes: a3508fbe9dc6d ("KVM: s390: vsie: initial support for nested virtualization") Cc: stable@vger.kernel.org # f85f1baaa189: KVM: s390: split kvm_s390_logical_to_effective Signed-off-by: Claudio Imbrenda Acked-by: Janosch Frank Reviewed-by: David Hildenbrand Acked-by: Christian Borntraeger Link: https://lore.kernel.org/r/20210302174443.514363-4-imbrenda@linux.ibm.com [borntraeger@de.ibm.com: apply fixup from Claudio] Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit f13e4287be654cf7558218e68f56e929e356d7e0 Author: Takashi Iwai Date: Tue May 4 11:18:02 2021 +0200 ALSA: hda/realtek: Fix speaker amp on HP Envy AiO 32 commit 622464c893142f7beac89f5ba8c9773bca5e5004 upstream. HP Envy AiO 32-a12xxx has an external amp that is controlled via GPIO bit 0x04. However, unlike other devices, this amp seems to shut down itself after the certain period, hence the OS needs to up/down the bit dynamically only during the actual playback. This patch adds the control of the GPIO bit via the existing pcm_hook mechanism. Ideally it should be triggered at the actual stream start, but we have only the state change at prepare/cleanup, so use those for switching the GPIO bit on/off. This should be good enough for the purpose, and was actually confirmed to work fine. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=212873 Cc: Link: https://lore.kernel.org/r/20210504091802.13200-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit e73bf2eb82d68d9a2cf124016d04d4025a678ea8 Author: Sami Loone Date: Sat May 1 12:07:53 2021 +0200 ALSA: hda/realtek: ALC285 Thinkpad jack pin quirk is unreachable commit 266fd994b2b0ab7ba3e5541868838ce30775964b upstream. In 9bbb94e57df1 ("ALSA: hda/realtek: fix static noise on ALC285 Lenovo laptops") an existing Lenovo quirk was made more generic by removing a 0x12 pin requirement from the entry. This made the second chance table Thinkpad jack entry unreachable as the pin configurations became identical. Revert the 0x12 pin requirement removal and move Thinkpad jack pin quirk back to the primary pin table as they can co-exist when more specific configurations come first. Add a more targeted pin quirk for Lenovo devices that have 0x12 as 0x40000000. Tested on Yoga 6 (AMD) laptop. [ Corrected the commit ID -- tiwai ] Fixes: 9bbb94e57df1 ("ALSA: hda/realtek: fix static noise on ALC285 Lenovo laptops") Signed-off-by: Sami Loone Cc: Link: https://lore.kernel.org/r/YI0oefvTYn8URYDb@yoga Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 5e9a107d241020da5627f99f120deab3ef277e97 Author: Takashi Iwai Date: Wed Apr 28 13:27:03 2021 +0200 ALSA: hda/realtek: Remove redundant entry for ALC861 Haier/Uniwill devices commit defce244b01ee12534910a4544e11be5eb927d25 upstream. The quirk entry for Uniwill ECS M31EI is with the PCI SSID device 0, which means matching with all. That is, it's essentially equivalent with SND_PCI_QUIRK_VENDOR(0x1584), which also matches with the previous entry for Haier W18 applying the very same quirk. Let's unify them with the single vendor-quirk entry. Cc: Link: https://lore.kernel.org/r/20210428112704.23967-13-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit b769a6285896b51f6d7fdcde863bda29d1a2d161 Author: Takashi Iwai Date: Wed Apr 28 13:27:02 2021 +0200 ALSA: hda/realtek: Re-order ALC662 quirk table entries commit 9edeb1109d05953b2f0e24e5b2341a98c3fa78d5 upstream. Just re-order the alc662_fixup_tbl[] entries for Acer and ASUS devices for avoiding the oversight of the duplicated or unapplied item in future. No functional changes. Also Cc-to-stable for the further patch applications. Cc: Link: https://lore.kernel.org/r/20210428112704.23967-12-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit a3cef89e9101d422c8fdc04682565581fa88a88c Author: Takashi Iwai Date: Wed Apr 28 13:27:01 2021 +0200 ALSA: hda/realtek: Re-order remaining ALC269 quirk table entries commit c656f747df151a0a89756a5312f4ca2116758ba4 upstream. Just re-order the alc269_fixup_tbl[] entries for FSC, Medion, Samsung and Lemote devices for avoiding the oversight of the duplicated or unapplied item in future. No functional changes. Also Cc-to-stable for the further patch applications. Cc: Link: https://lore.kernel.org/r/20210428112704.23967-11-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit d115e658d594f0c4f1df959e676fdd2be3070a89 Author: Takashi Iwai Date: Wed Apr 28 13:27:00 2021 +0200 ALSA: hda/realtek: Re-order ALC269 Lenovo quirk table entries commit f552ff54c2a700616a02b038e4bf3cbf859f65b7 upstream. Just re-order the alc269_fixup_tbl[] entries for Lenovo devices for avoiding the oversight of the duplicated or unapplied item in future. No functional changes. Also Cc-to-stable for the further patch applications. Cc: Link: https://lore.kernel.org/r/20210428112704.23967-10-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 1698d55bf8c619c777a830d34c9ab00819eb3e9c Author: Takashi Iwai Date: Wed Apr 28 13:26:59 2021 +0200 ALSA: hda/realtek: Re-order ALC269 Sony quirk table entries commit cab561f8d4bc9b196ae20c960aa5da89fd786ab5 upstream. Just re-order the alc269_fixup_tbl[] entries for Sony devices for avoiding the oversight of the duplicated or unapplied item in future. No functional changes. Also Cc-to-stable for the further patch applications. Cc: Link: https://lore.kernel.org/r/20210428112704.23967-9-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 9c3465fc2df8d7501790d964abd0a33e46a7cdf8 Author: Takashi Iwai Date: Wed Apr 28 13:26:58 2021 +0200 ALSA: hda/realtek: Re-order ALC269 ASUS quirk table entries commit 3cd0ed636dd19e7fbe3ebe8de8476e1718d5a8f1 upstream. Just re-order the alc269_fixup_tbl[] entries for ASUS devices for avoiding the oversight of the duplicated or unapplied item in future. No functional changes. Also Cc-to-stable for the further patch applications. Cc: Link: https://lore.kernel.org/r/20210428112704.23967-8-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 13abe4452472591e703ea55b11a2a6c15a818501 Author: Takashi Iwai Date: Wed Apr 28 13:26:57 2021 +0200 ALSA: hda/realtek: Re-order ALC269 Dell quirk table entries commit aa143ad39a52d968ac69e426d329bb74f270e6ca upstream. Just re-order the alc269_fixup_tbl[] entries for Dell devices for avoiding the oversight of the duplicated or unapplied item in future. No functional changes. Also Cc-to-stable for the further patch applications. Cc: Link: https://lore.kernel.org/r/20210428112704.23967-7-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 8ff6fb1076ac18384a0d5cafc1e4b485e4fcafd0 Author: Takashi Iwai Date: Wed Apr 28 13:26:56 2021 +0200 ALSA: hda/realtek: Re-order ALC269 Acer quirk table entries commit 433f894ec7fbd3b4bf1f3187b2ddd566078c4aef upstream. Just re-order the alc269_fixup_tbl[] entries for Acer devices for avoiding the oversight of the duplicated or unapplied item in future. No functional changes. Also Cc-to-stable for the further patch applications. Cc: Link: https://lore.kernel.org/r/20210428112704.23967-6-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit a0848b321992003372190dc4cb7a21e57a2e81f4 Author: Takashi Iwai Date: Wed Apr 28 13:26:55 2021 +0200 ALSA: hda/realtek: Re-order ALC269 HP quirk table entries commit 45461e3b554c75ddff9703539f3711cc3dfb0422 upstream. Just re-order the alc269_fixup_tbl[] entries for HP devices for avoiding the oversight of the duplicated or unapplied item in future. No functional changes. Formerly, some entries were grouped for the actual codec, but this doesn't seem reasonable to keep in that way. So now we simply keep the PCI SSID order for the whole. Also Cc-to-stable for the further patch applications. Cc: Link: https://lore.kernel.org/r/20210428112704.23967-5-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 8335fdd8783f7c44547e0419f5276085d1e800a4 Author: Takashi Iwai Date: Wed Apr 28 13:26:54 2021 +0200 ALSA: hda/realtek: Re-order ALC882 Clevo quirk table entries commit 13e1a4cd490b959a4c72c9f4fb502ef56b190062 upstream. Just re-order the alc882_fixup_tbl[] entries for Clevo devices for avoiding the oversight of the duplicated or unapplied item in future. No functional changes. Also, user lower hex letters in the entry. Also Cc-to-stable for the further patch applications. Cc: Link: https://lore.kernel.org/r/20210428112704.23967-4-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 4d5fa5c3d3ee94f20c2d8b3dd23db8ffad1d97a3 Author: Takashi Iwai Date: Wed Apr 28 13:26:53 2021 +0200 ALSA: hda/realtek: Re-order ALC882 Sony quirk table entries commit b7529c18feecb1af92f9db08c8e7fe446a82d96d upstream. Just re-order the alc882_fixup_tbl[] entries for Sony devices for avoiding the oversight of the duplicated or unapplied item in future. No functional changes. Also Cc-to-stable for the further patch applications. Cc: Link: https://lore.kernel.org/r/20210428112704.23967-3-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit c9e224a129dd8cabf98081aaeedc29b593dc9594 Author: Takashi Iwai Date: Wed Apr 28 13:26:52 2021 +0200 ALSA: hda/realtek: Re-order ALC882 Acer quirk table entries commit b265047ac56bad8c4f3d0c8bf9cb4e828ee0d28e upstream. Just re-order the alc882_fixup_tbl[] entries for Acer devices for avoiding the oversight of the duplicated or unapplied item in future. No functional changes. Also Cc-to-stable for the further patch applications. Cc: Link: https://lore.kernel.org/r/20210428112704.23967-2-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit c9864a6b0ab3860e9f462b5f23b653762c1657a9 Author: Bas Nieuwenhuizen Date: Wed May 5 03:27:49 2021 +0200 drm/amdgpu: Init GFX10_ADDR_CONFIG for VCN v3 in DPG mode. commit 8bf073ca9235fe38d7b74a0b4e779cfa7cc70fc9 upstream. Otherwise tiling modes that require the values form this field (In particular _*_X) would be corrupted upon video decode. Copied from the VCN v2 code. Fixes: 99541f392b4d ("drm/amdgpu: add mc resume DPG mode for VCN3.0") Reviewed-and-Tested by: Leo Liu Signed-off-by: Bas Nieuwenhuizen Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit cf7889354f24622d6007ad303ac5248d15f11bae Author: Victor Zhao Date: Tue Apr 27 17:52:56 2021 +0800 drm/amdgpu: fix r initial values commit 4b12ee6f426e5e36396501a58f3a1af5b92a7e06 upstream. Sriov gets suspend of IP block failed as return value was not initialized. v2: return 0 directly to align original code semantic before this was broken out into a separate helper function instead of setting initial values Signed-off-by: Victor Zhao Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 1c3697e3f91939fcb6d09329c72979637bfcd2c6 Author: Evan Quan Date: Wed Apr 28 12:00:20 2021 +0800 drm/amdgpu: add new MC firmware for Polaris12 32bit ASIC commit c83c4e1912446db697a120eb30126cd80cbf6349 upstream. Polaris12 32bit ASIC needs a special MC firmware. Signed-off-by: Evan Quan Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 6d8568b72485a9df0a3b0ed3442bb588d4de1277 Author: Christian König Date: Thu Apr 22 13:11:39 2021 +0200 drm/amdgpu: fix concurrent VM flushes on Vega/Navi v2 commit 20a5f5a98e1bb3d40acd97e89299e8c2d22784be upstream. Starting with Vega the hardware supports concurrent flushes of VMID which can be used to implement per process VMID allocation. But concurrent flushes are mutual exclusive with back to back VMID allocations, fix this to avoid a VMID used in two ways at the same time. v2: don't set ring to NULL Signed-off-by: Christian König Reviewed-by: James Zhu Tested-by: James Zhu Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit e304cfd8cc67495b41eff16cf690f2a256bfd7c9 Author: Harry Wentland Date: Thu Apr 22 19:10:52 2021 -0400 drm/amd/display: Reject non-zero src_y and src_x for video planes commit d89f6048bdcb6a56abb396c584747d5eeae650db upstream. [Why] This hasn't been well tested and leads to complete system hangs on DCN1 based systems, possibly others. The system hang can be reproduced by gesturing the video on the YouTube Android app on ChromeOS into full screen. [How] Reject atomic commits with non-zero drm_plane_state.src_x or src_y values. v2: - Add code comment describing the reason we're rejecting non-zero src_x and src_y - Drop gerrit Change-Id - Add stable CC - Based on amd-staging-drm-next v3: removed trailing whitespace Signed-off-by: Harry Wentland Cc: stable@vger.kernel.org Cc: nicholas.kazlauskas@amd.com Cc: amd-gfx@lists.freedesktop.org Cc: alexander.deucher@amd.com Cc: Roman.Li@amd.com Cc: hersenxs.wu@amd.com Cc: danny.wang@amd.com Reviewed-by: Nicholas Kazlauskas Acked-by: Christian König Reviewed-by: Hersen Wu Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 98d7d76a74e48ec3ddf2e23950adff7edcab9327 Author: Paul Cercueil Date: Sat Mar 27 11:57:40 2021 +0000 drm: bridge/panel: Cleanup connector on bridge detach commit 4d906839d321c2efbf3fed4bc31ffd9ff55b75c0 upstream. If we don't call drm_connector_cleanup() manually in panel_bridge_detach(), the connector will be cleaned up with the other DRM objects in the call to drm_mode_config_cleanup(). However, since our drm_connector is devm-allocated, by the time drm_mode_config_cleanup() will be called, our connector will be long gone. Therefore, the connector must be cleaned up when the bridge is detached to avoid use-after-free conditions. v2: Cleanup connector only if it was created v3: Add FIXME v4: (Use connector->dev) directly in if() block Fixes: 13dfc0540a57 ("drm/bridge: Refactor out the panel wrapper from the lvds-encoder bridge.") Cc: # 4.12+ Cc: Andrzej Hajda Cc: Neil Armstrong Cc: Laurent Pinchart Cc: Jonas Karlman Cc: Jernej Skrabec Signed-off-by: Paul Cercueil Reviewed-by: Laurent Pinchart Link: https://patchwork.freedesktop.org/patch/msgid/20210327115742.18986-2-paul@crapouillou.net Signed-off-by: Greg Kroah-Hartman commit 4ab5778889e580f3c980d3c01514dccce63cfc61 Author: Randy Dunlap Date: Thu Apr 15 11:36:19 2021 -0700 drm: bridge: fix ANX7625 use of mipi_dsi_() functions commit ed01fca38717169fcb61bd45ad1c3750d9c40d59 upstream. The Analogix DRM ANX7625 bridge driver uses mips_dsi_() function interfaces so it should select DRM_MIPI_DSI to prevent build errors. ERROR: modpost: "mipi_dsi_attach" [drivers/gpu/drm/bridge/analogix/anx7625.ko] undefined! ERROR: modpost: "mipi_dsi_device_register_full" [drivers/gpu/drm/bridge/analogix/anx7625.ko] undefined! ERROR: modpost: "of_find_mipi_dsi_host_by_node" [drivers/gpu/drm/bridge/analogix/anx7625.ko] undefined! ERROR: modpost: "mipi_dsi_device_unregister" [drivers/gpu/drm/bridge/analogix/anx7625.ko] undefined! ERROR: modpost: "mipi_dsi_detach" [drivers/gpu/drm/bridge/analogix/anx7625.ko] undefined! Fixes: 8bdfc5dae4e3 ("drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP") Reported-by: kernel test robot Signed-off-by: Randy Dunlap Reviewed-by: Robert Foss Cc: Xin Ji Cc: Sam Ravnborg Cc: dri-devel@lists.freedesktop.org Cc: Andrzej Hajda Cc: Neil Armstrong Cc: Robert Foss Cc: stable@vger.kernel.org Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20210415183619.1431-1-rdunlap@infradead.org Signed-off-by: Greg Kroah-Hartman commit 5636981fa8d85ad7d5268cdaa9722900a9d71e65 Author: Wayne Lin Date: Wed Feb 24 18:15:21 2021 +0800 drm/dp_mst: Set CLEAR_PAYLOAD_ID_TABLE as broadcast commit d919d3d6cdb31d0f9fe06c880f683a24f2838813 upstream. [Why & How] According to DP spec, CLEAR_PAYLOAD_ID_TABLE is a path broadcast request message and current implementation is incorrect. Fix it. Signed-off-by: Wayne Lin Cc: stable@vger.kernel.org Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patchwork.freedesktop.org/patch/msgid/20210224101521.6713-3-Wayne.Lin@amd.com Signed-off-by: Greg Kroah-Hartman commit dc37d27f16ddc7a00bd12dea5bc93d6c4cf0e0e2 Author: Wayne Lin Date: Wed Feb 24 18:15:20 2021 +0800 drm/dp_mst: Revise broadcast msg lct & lcr commit 419e91ea3143bf26991442465ac64d9461e98d96 upstream. [Why & How] According to DP spec, broadcast message LCT equals to 1 and LCR equals to 6. Current implementation is incorrect. Fix it. In addition, revise a bit the hdr->rad handling to include broadcast case. Signed-off-by: Wayne Lin Cc: stable@vger.kernel.org Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patchwork.freedesktop.org/patch/msgid/20210224101521.6713-2-Wayne.Lin@amd.com Signed-off-by: Greg Kroah-Hartman commit d083f0de9d0628d7b124d7cb8066f393a3776982 Author: Colin Ian King Date: Wed Mar 3 00:27:59 2021 +0000 drm/radeon: fix copy of uninitialized variable back to userspace commit 8dbc2ccac5a65c5b57e3070e36a3dc97c7970d96 upstream. Currently the ioctl command RADEON_INFO_SI_BACKEND_ENABLED_MASK can copy back uninitialised data in value_tmp that pointer *value points to. This can occur when rdev->family is less than CHIP_BONAIRE and less than CHIP_TAHITI. Fix this by adding in a missing -EINVAL so that no invalid value is copied back to userspace. Addresses-Coverity: ("Uninitialized scalar variable) Cc: stable@vger.kernel.org # 3.13+ Fixes: 439a1cfffe2c ("drm/radeon: expose render backend mask to the userspace") Reviewed-by: Christian König Signed-off-by: Colin Ian King Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 1ae37c62b3232ba0b77028fdc96ee67a0ce23e08 Author: Boris Brezillon Date: Fri Feb 5 12:17:56 2021 +0100 drm/panfrost: Don't try to map pages that are already mapped commit f45da8204ff1707c529a8769f5467ff16f504b26 upstream. We allocate 2MB chunks at a time, so it might appear that a page fault has already been handled by a previous page fault when we reach panfrost_mmu_map_fault_addr(). Bail out in that case to avoid mapping the same area twice. Cc: Fixes: 187d2929206e ("drm/panfrost: Add support for GPU heap allocations") Signed-off-by: Boris Brezillon Reviewed-by: Steven Price Link: https://patchwork.freedesktop.org/patch/msgid/20210205111757.585248-3-boris.brezillon@collabora.com Signed-off-by: Greg Kroah-Hartman commit be586482bd40af0debcac2940c54d01954d30704 Author: Boris Brezillon Date: Fri Feb 5 12:17:55 2021 +0100 drm/panfrost: Clear MMU irqs before handling the fault commit 3aa0a80fc692c9959c261f4c5bfe9c23ddd90562 upstream. When a fault is handled it will unblock the GPU which will continue executing its shader and might fault almost immediately on a different page. If we clear interrupts after handling the fault we might miss new faults, so clear them before. Cc: Fixes: 187d2929206e ("drm/panfrost: Add support for GPU heap allocations") Signed-off-by: Boris Brezillon Reviewed-by: Steven Price Link: https://patchwork.freedesktop.org/patch/msgid/20210205111757.585248-2-boris.brezillon@collabora.com Signed-off-by: Greg Kroah-Hartman commit e5550e2f3e70002d333a63d7234f5d2ed198780b Author: Paul Cercueil Date: Sun Jan 24 08:55:52 2021 +0000 drm/ingenic: Fix non-OSD mode commit 7b4957684e5d813fcbdc98144e3cc5c4467b3e2e upstream. Even though the JZ4740 did not have the OSD mode, it had (according to the documentation) two DMA channels, but there is absolutely no information about how to select the second DMA channel. Make the ingenic-drm driver work in non-OSD mode by using the foreground0 plane (which is bound to the DMA0 channel) as the primary plane, instead of the foreground1 plane, which is the primary plane when in OSD mode. Fixes: 3c9bea4ef32b ("drm/ingenic: Add support for OSD mode") Cc: # v5.8+ Signed-off-by: Paul Cercueil Acked-by: Daniel Vetter Tested-by: H. Nikolaus Schaller Link: https://patchwork.freedesktop.org/patch/msgid/20210124085552.29146-5-paul@crapouillou.net Signed-off-by: Greg Kroah-Hartman commit d1f5199445caa9170f8efa39664338c28a7c5f40 Author: Gerd Hoffmann Date: Wed Feb 17 13:32:05 2021 +0100 drm/qxl: use ttm bo priorities commit 4fff19ae427548d8c37260c975a4b20d3c040ec6 upstream. Allow to set priorities for buffer objects. Use priority 1 for surface and cursor command releases. Use priority 0 for drawing command releases. That way the short-living drawing commands are first in line when it comes to eviction, making it *much* less likely that ttm_bo_mem_force_space() picks something which can't be evicted and throws an error after waiting a while without success. Signed-off-by: Gerd Hoffmann Acked-by: Thomas Zimmermann Link: http://patchwork.freedesktop.org/patch/msgid/20210217123213.2199186-4-kraxel@redhat.com Signed-off-by: Greg Kroah-Hartman commit fba8cea75895898420eaeccd7e99915b3e660180 Author: Maciej W. Rozycki Date: Wed Mar 10 13:03:14 2021 +0100 FDDI: defxx: Make MMIO the configuration default except for EISA commit 193ced4a79599352d63cb8c9e2f0c6043106eb6a upstream. Recent versions of the PCI Express specification have deprecated support for I/O transactions and actually some PCIe host bridges, such as Power Systems Host Bridge 4 (PHB4), do not implement them. The default kernel configuration choice for the defxx driver is the use of I/O ports rather than MMIO for PCI and EISA systems. It may have made sense as a conservative backwards compatible choice back when MMIO operation support was added to the driver as a part of TURBOchannel bus support. However nowadays this configuration choice makes the driver unusable with systems that do not implement I/O transactions for PCIe. Make DEFXX_MMIO the configuration default then, except where configured for EISA. This exception is because an EISA adapter can have its MMIO decoding disabled with ECU (EISA Configuration Utility) and therefore not available with the resource allocation infrastructure we implement, while port I/O is always readily available as it uses slot-specific addressing, directly mapped to the slot an option card has been placed in and handled with our EISA bus support core. Conversely a kernel that supports modern systems which may not have I/O transactions implemented for PCIe will usually not be expected to handle legacy EISA systems. The change of the default will make it easier for people, including but not limited to distribution packagers, to make a working choice for the driver. Update the option description accordingly and while at it replace the potentially ambiguous PIO acronym with IOP for "port I/O" vs "I/O ports" according to our nomenclature used elsewhere. Signed-off-by: Maciej W. Rozycki Fixes: e89a2cfb7d7b ("[TC] defxx: TURBOchannel support") Cc: stable@vger.kernel.org # v2.6.21+ Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 91b9548d413fda488ea853cd1b9f59b572db3a0c Author: Felix Fietkau Date: Tue Mar 23 22:47:37 2021 +0100 mt76: fix potential DMA mapping leak commit b4403cee6400c5f679e9c4a82b91d61aa961eccf upstream. With buf uninitialized in mt76_dma_tx_queue_skb_raw, its field skip_unmap could potentially inherit a non-zero value from stack garbage. If this happens, it will cause DMA mappings for MCU command frames to not be unmapped after completion Fixes: 27d5c528a7ca ("mt76: fix double DMA unmap of the first buffer on 7615/7915") Cc: stable@vger.kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Greg Kroah-Hartman commit 9cd09722e18a08b6a3d68b8bccfac39ddc22434c Author: Ping-Ke Shih Date: Thu Apr 1 14:27:17 2021 -0500 rtw88: Fix array overrun in rtw_get_tx_power_params() commit 2ff25985ea9ccc6c9af2c77b0b49045adcc62e0e upstream. Using a kernel with the Undefined Behaviour Sanity Checker (UBSAN) enabled, the following array overrun is logged: ================================================================================ UBSAN: array-index-out-of-bounds in /home/finger/wireless-drivers-next/drivers/net/wireless/realtek/rtw88/phy.c:1789:34 index 5 is out of range for type 'u8 [5]' CPU: 2 PID: 84 Comm: kworker/u16:3 Tainted: G O 5.12.0-rc5-00086-gd88bba47038e-dirty #651 Hardware name: TOSHIBA TECRA A50-A/TECRA A50-A, BIOS Version 4.50 09/29/2014 Workqueue: phy0 ieee80211_scan_work [mac80211] Call Trace: dump_stack+0x64/0x7c ubsan_epilogue+0x5/0x40 __ubsan_handle_out_of_bounds.cold+0x43/0x48 rtw_get_tx_power_params+0x83a/drivers/net/wireless/realtek/rtw88/0xad0 [rtw_core] ? rtw_pci_read16+0x20/0x20 [rtw_pci] ? check_hw_ready+0x50/0x90 [rtw_core] rtw_phy_get_tx_power_index+0x4d/0xd0 [rtw_core] rtw_phy_set_tx_power_level+0xee/0x1b0 [rtw_core] rtw_set_channel+0xab/0x110 [rtw_core] rtw_ops_config+0x87/0xc0 [rtw_core] ieee80211_hw_config+0x9d/0x130 [mac80211] ieee80211_scan_state_set_channel+0x81/0x170 [mac80211] ieee80211_scan_work+0x19f/0x2a0 [mac80211] process_one_work+0x1dd/0x3a0 worker_thread+0x49/0x330 ? rescuer_thread+0x3a0/0x3a0 kthread+0x134/0x150 ? kthread_create_worker_on_cpu+0x70/0x70 ret_from_fork+0x22/0x30 ================================================================================ The statement where an array is being overrun is shown in the following snippet: if (rate <= DESC_RATE11M) tx_power = pwr_idx_2g->cck_base[group]; else ====> tx_power = pwr_idx_2g->bw40_base[group]; The associated arrays are defined in main.h as follows: struct rtw_2g_txpwr_idx { u8 cck_base[6]; u8 bw40_base[5]; struct rtw_2g_1s_pwr_idx_diff ht_1s_diff; struct rtw_2g_ns_pwr_idx_diff ht_2s_diff; struct rtw_2g_ns_pwr_idx_diff ht_3s_diff; struct rtw_2g_ns_pwr_idx_diff ht_4s_diff; }; The problem arises because the value of group is 5 for channel 14. The trivial increase in the dimension of bw40_base fails as this struct must match the layout of efuse. The fix is to add the rate as an argument to rtw_get_channel_group() and set the group for channel 14 to 4 if rate <= DESC_RATE11M. This patch fixes commit fa6dfe6bff24 ("rtw88: resolve order of tx power setting routines") Fixes: fa6dfe6bff24 ("rtw88: resolve order of tx power setting routines") Reported-by: Богдан Пилипенко Signed-off-by: Larry Finger Signed-off-by: Ping-Ke Shih Cc: Stable Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210401192717.28927-1-Larry.Finger@lwfinger.net Signed-off-by: Greg Kroah-Hartman commit f94f09e695684b2d619301aa143fed874a85e8fa Author: Johannes Berg Date: Fri Apr 16 09:42:14 2021 +0200 cfg80211: scan: drop entry from hidden_list on overflow commit 010bfbe768f7ecc876ffba92db30432de4997e2a upstream. If we overflow the maximum number of BSS entries and free the new entry, drop it from any hidden_list that it may have been added to in the code above or in cfg80211_combine_bsses(). Reported-by: Dan Carpenter Link: https://lore.kernel.org/r/20210416094212.5de7d1676ad7.Ied283b0bc5f504845e7d6ab90626bdfa68bb3dc0@changeid Cc: stable@vger.kernel.org Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit aff4d8cb5ef5dfe3cec5661ea95686d2a5740f0c Author: Randy Dunlap Date: Fri Apr 16 23:55:54 2021 -0700 net: xilinx: drivers need/depend on HAS_IOMEM commit 46fd4471615c1bff9d87c411140807762c25667a upstream. kernel test robot reports build errors in 3 Xilinx ethernet drivers. They all use ioremap functions that are only available when HAS_IOMEM is set/enabled. If it is not enabled, they all have build errors, so make these 3 drivers depend on HAS_IOMEM. ld: drivers/net/ethernet/xilinx/xilinx_emaclite.o: in function `xemaclite_of_probe': xilinx_emaclite.c:(.text+0x9fc): undefined reference to `devm_ioremap_resource' ld: drivers/net/ethernet/xilinx/xilinx_axienet_main.o: in function `axienet_probe': xilinx_axienet_main.c:(.text+0x942): undefined reference to `devm_ioremap_resource' ld: drivers/net/ethernet/xilinx/ll_temac_main.o: in function `temac_probe': ll_temac_main.c:(.text+0x1283): undefined reference to `devm_platform_ioremap_resource_byname' ld: ll_temac_main.c:(.text+0x13ad): undefined reference to `devm_of_iomap' ld: ll_temac_main.c:(.text+0x162e): undefined reference to `devm_platform_ioremap_resource' Fixes: 8a3b7a252dca ("drivers/net/ethernet/xilinx: added Xilinx AXI Ethernet driver") Signed-off-by: Randy Dunlap Reported-by: kernel test robot Cc: Radhey Shyam Pandey Cc: Gary Guo Cc: Zhang Changzhong Cc: Andre Przywara Cc: stable@vger.kernel.org Cc: Daniel Borkmann Cc: "David S. Miller" Cc: Jakub Kicinski Cc: netdev@vger.kernel.org Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 352f856408a9c15484ff23dcfacbb86128d2177c Author: Dan Carpenter Date: Wed Apr 14 11:29:55 2021 +0300 ipw2x00: potential buffer overflow in libipw_wx_set_encodeext() commit 260a9ad9446723d4063ed802989758852809714d upstream. The "ext->key_len" is a u16 that comes from the user. If it's over SCM_KEY_LEN (32) that could lead to memory corruption. Fixes: e0d369d1d969 ("[PATCH] ieee82011: Added WE-18 support to default wireless extension handler") Cc: stable@vger.kernel.org Signed-off-by: Dan Carpenter Acked-by: Stanislav Yakovlev Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/YHaoA1i+8uT4ir4h@mwanda Signed-off-by: Greg Kroah-Hartman commit 790da494c18345e83b6ce986c3c251b7294993bb Author: Ryder Lee Date: Tue Apr 13 16:00:07 2021 +0800 mt76: mt7615: use ieee80211_free_txskb() in mt7615_tx_token_put() commit 06991d1f73a9bdbc5f234ee96737b9102705b89c upstream. We should use ieee80211_free_txskb() to report skb status avoid wrong aql accounting after reset. Cc: stable@vger.kernel.org Signed-off-by: Ryder Lee Signed-off-by: Felix Fietkau Signed-off-by: Greg Kroah-Hartman commit 17bf84d857d0bc138d33fbb07d3894fabcf79cb0 Author: Nathan Chancellor Date: Fri Apr 9 12:21:28 2021 -0700 MIPS: generic: Update node names to avoid unit addresses commit e607ff630c6053ecc67502677c0e50053d7892d4 upstream. With the latest mkimage from U-Boot 2021.04, the generic defconfigs no longer build, failing with: /usr/bin/mkimage: verify_header failed for FIT Image support with exit code 1 This is expected after the linked U-Boot commits because '@' is forbidden in the node names due to the way that libfdt treats nodes with the same prefix but different unit addresses. Switch the '@' in the node name to '-'. Drop the unit addresses from the hash and kernel child nodes because there is only one node so they do not need to have a number to differentiate them. Cc: stable@vger.kernel.org Link: https://source.denx.de/u-boot/u-boot/-/commit/79af75f7776fc20b0d7eb6afe1e27c00fdb4b9b4 Link: https://source.denx.de/u-boot/u-boot/-/commit/3f04db891a353f4b127ed57279279f851c6b4917 Suggested-by: Simon Glass Signed-off-by: Nathan Chancellor Reviewed-by: Tom Rini Signed-off-by: Thomas Bogendoerfer Signed-off-by: Greg Kroah-Hartman commit 001f553ca5beb7951b6a4edbedb9f148c70718a3 Author: Jan Glauber Date: Wed Mar 17 15:04:39 2021 +0100 md: Fix missing unused status line of /proc/mdstat commit 7abfabaf5f805f5171d133ce6af9b65ab766e76a upstream. Reading /proc/mdstat with a read buffer size that would not fit the unused status line in the first read will skip this line from the output. So 'dd if=/proc/mdstat bs=64 2>/dev/null' will not print something like: unused devices: Don't return NULL immediately in start() for v=2 but call show() once to print the status line also for multiple reads. Cc: stable@vger.kernel.org Fixes: 1f4aace60b0e ("fs/seq_file.c: simplify seq_file iteration code and interface") Signed-off-by: Jan Glauber Signed-off-by: Song Liu Signed-off-by: Greg Kroah-Hartman commit 5ad71f445a6c89d9e166a79617ce20c18600f3af Author: Zhao Heming Date: Sat Apr 3 11:01:25 2021 +0800 md: md_open returns -EBUSY when entering racing area commit 6a4db2a60306eb65bfb14ccc9fde035b74a4b4e7 upstream. commit d3374825ce57 ("md: make devices disappear when they are no longer needed.") introduced protection between mddev creating & removing. The md_open shouldn't create mddev when all_mddevs list doesn't contain mddev. With currently code logic, there will be very easy to trigger soft lockup in non-preempt env. This patch changes md_open returning from -ERESTARTSYS to -EBUSY, which will break the infinitely retry when md_open enter racing area. This patch is partly fix soft lockup issue, full fix needs mddev_find is split into two functions: mddev_find & mddev_find_or_alloc. And md_open should call new mddev_find (it only does searching job). For more detail, please refer with Christoph's "split mddev_find" patch in later commits. *** env *** kvm-qemu VM 2C1G with 2 iscsi luns kernel should be non-preempt *** script *** about trigger every time with below script ``` 1 node1="mdcluster1" 2 node2="mdcluster2" 3 4 mdadm -Ss 5 ssh ${node2} "mdadm -Ss" 6 wipefs -a /dev/sda /dev/sdb 7 mdadm -CR /dev/md0 -b clustered -e 1.2 -n 2 -l mirror /dev/sda \ /dev/sdb --assume-clean 8 9 for i in {1..10}; do 10 echo ==== $i ====; 11 12 echo "test ...." 13 ssh ${node2} "mdadm -A /dev/md0 /dev/sda /dev/sdb" 14 sleep 1 15 16 echo "clean ....." 17 ssh ${node2} "mdadm -Ss" 18 done ``` I use mdcluster env to trigger soft lockup, but it isn't mdcluster speical bug. To stop md array in mdcluster env will do more jobs than non-cluster array, which will leave enough time/gap to allow kernel to run md_open. *** stack *** ``` [ 884.226509] mddev_put+0x1c/0xe0 [md_mod] [ 884.226515] md_open+0x3c/0xe0 [md_mod] [ 884.226518] __blkdev_get+0x30d/0x710 [ 884.226520] ? bd_acquire+0xd0/0xd0 [ 884.226522] blkdev_get+0x14/0x30 [ 884.226524] do_dentry_open+0x204/0x3a0 [ 884.226531] path_openat+0x2fc/0x1520 [ 884.226534] ? seq_printf+0x4e/0x70 [ 884.226536] do_filp_open+0x9b/0x110 [ 884.226542] ? md_release+0x20/0x20 [md_mod] [ 884.226543] ? seq_read+0x1d8/0x3e0 [ 884.226545] ? kmem_cache_alloc+0x18a/0x270 [ 884.226547] ? do_sys_open+0x1bd/0x260 [ 884.226548] do_sys_open+0x1bd/0x260 [ 884.226551] do_syscall_64+0x5b/0x1e0 [ 884.226554] entry_SYSCALL_64_after_hwframe+0x44/0xa9 ``` *** rootcause *** "mdadm -A" (or other array assemble commands) will start a daemon "mdadm --monitor" by default. When "mdadm -Ss" is running, the stop action will wakeup "mdadm --monitor". The "--monitor" daemon will immediately get info from /proc/mdstat. This time mddev in kernel still exist, so /proc/mdstat still show md device, which makes "mdadm --monitor" to open /dev/md0. The previously "mdadm -Ss" is removing action, the "mdadm --monitor" open action will trigger md_open which is creating action. Racing is happening. ``` : "mdadm -Ss" md_release mddev_put deletes mddev from all_mddevs queue_work for mddev_delayed_delete at this time, "/dev/md0" is still available for opening : "mdadm --monitor ..." md_open + mddev_find can't find mddev of /dev/md0, and create a new mddev and | return. + trigger "if (mddev->gendisk != bdev->bd_disk)" and return -ERESTARTSYS. ``` In non-preempt kernel, is occupying on current CPU. and mddev_delayed_delete which was created in also can't be schedule. In preempt kernel, it can also trigger above racing. But kernel doesn't allow one thread running on a CPU all the time. after running some time, the later "mdadm -A" (refer above script line 13) will call md_alloc to alloc a new gendisk for mddev. it will break md_open statement "if (mddev->gendisk != bdev->bd_disk)" and return 0 to caller, the soft lockup is broken. Cc: stable@vger.kernel.org Reviewed-by: Christoph Hellwig Signed-off-by: Zhao Heming Signed-off-by: Song Liu Signed-off-by: Greg Kroah-Hartman commit 2271da3216842983d7acd3b506985aea936e36eb Author: Christoph Hellwig Date: Sat Apr 3 18:15:28 2021 +0200 md: factor out a mddev_find_locked helper from mddev_find commit 8b57251f9a91f5e5a599de7549915d2d226cc3af upstream. Factor out a self-contained helper to just lookup a mddev by the dev_t "unit". Cc: stable@vger.kernel.org Reviewed-by: Heming Zhao Signed-off-by: Christoph Hellwig Signed-off-by: Song Liu Signed-off-by: Greg Kroah-Hartman commit cfac69f5cde91553de284c4e3221353c9e2c6b07 Author: Christoph Hellwig Date: Sat Apr 3 18:15:29 2021 +0200 md: split mddev_find commit 65aa97c4d2bfd76677c211b9d03ef05a98c6d68e upstream. Split mddev_find into a simple mddev_find that just finds an existing mddev by the unit number, and a more complicated mddev_find that deals with find or allocating a mddev. This turns out to fix this bug reported by Zhao Heming. ----------------------------- snip ------------------------------ commit d3374825ce57 ("md: make devices disappear when they are no longer needed.") introduced protection between mddev creating & removing. The md_open shouldn't create mddev when all_mddevs list doesn't contain mddev. With currently code logic, there will be very easy to trigger soft lockup in non-preempt env. commit fe5dbe71fcdeced685f3355d4ea9de8473221161 Author: Heming Zhao Date: Thu Apr 8 15:44:15 2021 +0800 md-cluster: fix use-after-free issue when removing rdev commit f7c7a2f9a23e5b6e0f5251f29648d0238bb7757e upstream. md_kick_rdev_from_array will remove rdev, so we should use rdev_for_each_safe to search list. How to trigger: env: Two nodes on kvm-qemu x86_64 VMs (2C2G with 2 iscsi luns). ``` node2=192.168.0.3 for i in {1..20}; do echo ==== $i `date` ====; mdadm -Ss && ssh ${node2} "mdadm -Ss" wipefs -a /dev/sda /dev/sdb mdadm -CR /dev/md0 -b clustered -e 1.2 -n 2 -l 1 /dev/sda \ /dev/sdb --assume-clean ssh ${node2} "mdadm -A /dev/md0 /dev/sda /dev/sdb" mdadm --wait /dev/md0 ssh ${node2} "mdadm --wait /dev/md0" mdadm --manage /dev/md0 --fail /dev/sda --remove /dev/sda sleep 1 done ``` Crash stack: ``` stack segment: 0000 [#1] SMP ... ... RIP: 0010:md_check_recovery+0x1e8/0x570 [md_mod] ... ... RSP: 0018:ffffb149807a7d68 EFLAGS: 00010207 RAX: 0000000000000000 RBX: ffff9d494c180800 RCX: ffff9d490fc01e50 RDX: fffff047c0ed8308 RSI: 0000000000000246 RDI: 0000000000000246 RBP: 6b6b6b6b6b6b6b6b R08: ffff9d490fc01e40 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000000 R13: ffff9d494c180818 R14: ffff9d493399ef38 R15: ffff9d4933a1d800 FS: 0000000000000000(0000) GS:ffff9d494f700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe68cab9010 CR3: 000000004c6be001 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: raid1d+0x5c/0xd40 [raid1] ? finish_task_switch+0x75/0x2a0 ? lock_timer_base+0x67/0x80 ? try_to_del_timer_sync+0x4d/0x80 ? del_timer_sync+0x41/0x50 ? schedule_timeout+0x254/0x2d0 ? md_start_sync+0xe0/0xe0 [md_mod] ? md_thread+0x127/0x160 [md_mod] md_thread+0x127/0x160 [md_mod] ? wait_woken+0x80/0x80 kthread+0x10d/0x130 ? kthread_park+0xa0/0xa0 ret_from_fork+0x1f/0x40 ``` Fixes: dbb64f8635f5d ("md-cluster: Fix adding of new disk with new reload code") Fixes: 659b254fa7392 ("md-cluster: remove a disk asynchronously from cluster environment") Cc: stable@vger.kernel.org Reviewed-by: Gang He Signed-off-by: Heming Zhao Signed-off-by: Song Liu Signed-off-by: Greg Kroah-Hartman commit 91d74f0a71e02f620adc3b2b0c00859a47bc1b96 Author: Sudhakar Panneerselvam Date: Tue Apr 13 04:08:29 2021 +0000 md/bitmap: wait for external bitmap writes to complete during tear down commit 404a8ef512587b2460107d3272c17a89aef75edf upstream. NULL pointer dereference was observed in super_written() when it tries to access the mddev structure. [The below stack trace is from an older kernel, but the problem described in this patch applies to the mainline kernel.] [ 1194.474861] task: ffff8fdd20858000 task.stack: ffffb99d40790000 [ 1194.488000] RIP: 0010:super_written+0x29/0xe1 [ 1194.499688] RSP: 0018:ffff8ffb7fcc3c78 EFLAGS: 00010046 [ 1194.512477] RAX: 0000000000000000 RBX: ffff8ffb7bf4a000 RCX: ffff8ffb78991048 [ 1194.527325] RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff8ffb56b8a200 [ 1194.542576] RBP: ffff8ffb7fcc3c90 R08: 000000000000000b R09: 0000000000000000 [ 1194.558001] R10: ffff8ffb56b8a298 R11: 0000000000000000 R12: ffff8ffb56b8a200 [ 1194.573070] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 1194.588117] FS: 0000000000000000(0000) GS:ffff8ffb7fcc0000(0000) knlGS:0000000000000000 [ 1194.604264] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1194.617375] CR2: 00000000000002b8 CR3: 00000021e040a002 CR4: 00000000007606e0 [ 1194.632327] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1194.647865] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 1194.663316] PKRU: 55555554 [ 1194.674090] Call Trace: [ 1194.683735] [ 1194.692948] bio_endio+0xae/0x135 [ 1194.703580] blk_update_request+0xad/0x2fa [ 1194.714990] blk_update_bidi_request+0x20/0x72 [ 1194.726578] __blk_end_bidi_request+0x2c/0x4d [ 1194.738373] __blk_end_request_all+0x31/0x49 [ 1194.749344] blk_flush_complete_seq+0x377/0x383 [ 1194.761550] flush_end_io+0x1dd/0x2a7 [ 1194.772910] blk_finish_request+0x9f/0x13c [ 1194.784544] scsi_end_request+0x180/0x25c [ 1194.796149] scsi_io_completion+0xc8/0x610 [ 1194.807503] scsi_finish_command+0xdc/0x125 [ 1194.818897] scsi_softirq_done+0x81/0xde [ 1194.830062] blk_done_softirq+0xa4/0xcc [ 1194.841008] __do_softirq+0xd9/0x29f [ 1194.851257] irq_exit+0xe6/0xeb [ 1194.861290] do_IRQ+0x59/0xe3 [ 1194.871060] common_interrupt+0x1c6/0x382 [ 1194.881988] [ 1194.890646] RIP: 0010:cpuidle_enter_state+0xdd/0x2a5 [ 1194.902532] RSP: 0018:ffffb99d40793e68 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff43 [ 1194.917317] RAX: ffff8ffb7fce27c0 RBX: ffff8ffb7fced800 RCX: 000000000000001f [ 1194.932056] RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000000 [ 1194.946428] RBP: ffffb99d40793ea0 R08: 0000000000000004 R09: 0000000000002ed2 [ 1194.960508] R10: 0000000000002664 R11: 0000000000000018 R12: 0000000000000003 [ 1194.974454] R13: 000000000000000b R14: ffffffff925715a0 R15: 0000011610120d5a [ 1194.988607] ? cpuidle_enter_state+0xcc/0x2a5 [ 1194.999077] cpuidle_enter+0x17/0x19 [ 1195.008395] call_cpuidle+0x23/0x3a [ 1195.017718] do_idle+0x172/0x1d5 [ 1195.026358] cpu_startup_entry+0x73/0x75 [ 1195.035769] start_secondary+0x1b9/0x20b [ 1195.044894] secondary_startup_64+0xa5/0xa5 [ 1195.084921] RIP: super_written+0x29/0xe1 RSP: ffff8ffb7fcc3c78 [ 1195.096354] CR2: 00000000000002b8 bio in the above stack is a bitmap write whose completion is invoked after the tear down sequence sets the mddev structure to NULL in rdev. During tear down, there is an attempt to flush the bitmap writes, but for external bitmaps, there is no explicit wait for all the bitmap writes to complete. For instance, md_bitmap_flush() is called to flush the bitmap writes, but the last call to md_bitmap_daemon_work() in md_bitmap_flush() could generate new bitmap writes for which there is no explicit wait to complete those writes. The call to md_bitmap_update_sb() will return simply for external bitmaps and the follow-up call to md_update_sb() is conditional and may not get called for external bitmaps. This results in a kernel panic when the completion routine, super_written() is called which tries to reference mddev in the rdev that has been set to NULL(in unbind_rdev_from_array() by tear down sequence). The solution is to call md_super_wait() for external bitmaps after the last call to md_bitmap_daemon_work() in md_bitmap_flush() to ensure there are no pending bitmap writes before proceeding with the tear down. Cc: stable@vger.kernel.org Signed-off-by: Sudhakar Panneerselvam Reviewed-by: Zhao Heming Signed-off-by: Song Liu Signed-off-by: Greg Kroah-Hartman commit 53f8208e11abd6dde9480dfcb97fecdb1bc2ac18 Author: Xiao Ni Date: Sun Apr 25 17:22:57 2021 +0800 async_xor: increase src_offs when dropping destination page commit ceaf2966ab082bbc4d26516f97b3ca8a676e2af8 upstream. Now we support sharing one page if PAGE_SIZE is not equal stripe size. To support this, it needs to support calculating xor value with different offsets for each r5dev. One offset array is used to record those offsets. In RMW mode, parity page is used as a source page. It sets ASYNC_TX_XOR_DROP_DST before calculating xor value in ops_run_prexor5. So it needs to add src_list and src_offs at the same time. Now it only needs src_list. So the xor value which is calculated is wrong. It can cause data corruption problem. I can reproduce this problem 100% on a POWER8 machine. The steps are: mdadm -CR /dev/md0 -l5 -n3 /dev/sdb1 /dev/sdc1 /dev/sdd1 --size=3G mkfs.xfs /dev/md0 mount /dev/md0 /mnt/test mount: /mnt/test: mount(2) system call failed: Structure needs cleaning. Fixes: 29bcff787a25 ("md/raid5: add new xor function to support different page offset") Cc: stable@vger.kernel.org # v5.10+ Signed-off-by: Xiao Ni Signed-off-by: Song Liu Signed-off-by: Greg Kroah-Hartman commit 0a78ba078a371ef235c6829b8033fa82a31ddac8 Author: Alison Schofield Date: Wed Mar 10 11:02:33 2021 -0800 x86, sched: Treat Intel SNC topology as default, COD as exception commit 2c88d45edbb89029c1190bb3b136d2602f057c98 upstream. Commit 1340ccfa9a9a ("x86,sched: Allow topologies where NUMA nodes share an LLC") added a vendor and model specific check to never call topology_sane() for Intel Skylake Server systems where NUMA nodes share an LLC. Intel Ice Lake and Sapphire Rapids CPUs also enumerate an LLC that is shared by multiple NUMA nodes. The LLC on these CPUs is shared for off-package data access but private to the NUMA node for on-package access. Rather than managing a list of allowable SNC topologies, make this SNC topology the default, and treat Intel's Cluster-On-Die (COD) topology as the exception. In SNC mode, Sky Lake, Ice Lake, and Sapphire Rapids servers do not emit this warning: sched: CPU #3's llc-sibling CPU #0 is not on the same node! [node: 1 != 0]. Ignoring dependency. Suggested-by: Peter Zijlstra (Intel) Signed-off-by: Alison Schofield Signed-off-by: Peter Zijlstra (Intel) Acked-by: Dave Hansen Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20210310190233.31752-1-alison.schofield@intel.com Signed-off-by: Greg Kroah-Hartman commit 336dc1d637f3c889785a718fe791580e01bc2a93 Author: Paul Moore Date: Wed Apr 21 21:15:36 2021 -0400 selinux: add proper NULL termination to the secclass_map permissions commit e4c82eafb609c2badc56f4e11bc50fcf44b8e9eb upstream. This patch adds the missing NULL termination to the "bpf" and "perf_event" object class permission lists. This missing NULL termination should really only affect the tools under scripts/selinux, with the most important being genheaders.c, although in practice this has not been an issue on any of my dev/test systems. If the problem were to manifest itself it would likely result in bogus permissions added to the end of the object class; thankfully with no access control checks using these bogus permissions and no policies defining these permissions the impact would likely be limited to some noise about undefined permissions during policy load. Cc: stable@vger.kernel.org Fixes: ec27c3568a34 ("selinux: bpf: Add selinux check for eBPF syscall operations") Fixes: da97e18458fb ("perf_event: Add support for LSM and SELinux checks") Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit aa38b4eebb53791938754ec79e04ac53696b1375 Author: Tetsuo Handa Date: Fri Apr 2 21:17:42 2021 +0900 misc: vmw_vmci: explicitly initialize vmci_datagram payload commit b2192cfeba8481224da0a4ec3b4a7ccd80b1623b upstream. KMSAN complains that vmci_check_host_caps() left the payload part of check_msg uninitialized. ===================================================== BUG: KMSAN: uninit-value in kmsan_check_memory+0xd/0x10 CPU: 1 PID: 1 Comm: swapper/0 Tainted: G B 5.11.0-rc7+ #4 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 02/27/2020 Call Trace: dump_stack+0x21c/0x280 kmsan_report+0xfb/0x1e0 kmsan_internal_check_memory+0x202/0x520 kmsan_check_memory+0xd/0x10 iowrite8_rep+0x86/0x380 vmci_guest_probe_device+0xf0b/0x1e70 pci_device_probe+0xab3/0xe70 really_probe+0xd16/0x24d0 driver_probe_device+0x29d/0x3a0 device_driver_attach+0x25a/0x490 __driver_attach+0x78c/0x840 bus_for_each_dev+0x210/0x340 driver_attach+0x89/0xb0 bus_add_driver+0x677/0xc40 driver_register+0x485/0x8e0 __pci_register_driver+0x1ff/0x350 vmci_guest_init+0x3e/0x41 vmci_drv_init+0x1d6/0x43f do_one_initcall+0x39c/0x9a0 do_initcall_level+0x1d7/0x259 do_initcalls+0x127/0x1cb do_basic_setup+0x33/0x36 kernel_init_freeable+0x29a/0x3ed kernel_init+0x1f/0x840 ret_from_fork+0x1f/0x30 Uninit was created at: kmsan_internal_poison_shadow+0x5c/0xf0 kmsan_slab_alloc+0x8d/0xe0 kmem_cache_alloc+0x84f/0xe30 vmci_guest_probe_device+0xd11/0x1e70 pci_device_probe+0xab3/0xe70 really_probe+0xd16/0x24d0 driver_probe_device+0x29d/0x3a0 device_driver_attach+0x25a/0x490 __driver_attach+0x78c/0x840 bus_for_each_dev+0x210/0x340 driver_attach+0x89/0xb0 bus_add_driver+0x677/0xc40 driver_register+0x485/0x8e0 __pci_register_driver+0x1ff/0x350 vmci_guest_init+0x3e/0x41 vmci_drv_init+0x1d6/0x43f do_one_initcall+0x39c/0x9a0 do_initcall_level+0x1d7/0x259 do_initcalls+0x127/0x1cb do_basic_setup+0x33/0x36 kernel_init_freeable+0x29a/0x3ed kernel_init+0x1f/0x840 ret_from_fork+0x1f/0x30 Bytes 28-31 of 36 are uninitialized Memory access of size 36 starts at ffff8881675e5f00 ===================================================== Fixes: 1f166439917b69d3 ("VMCI: guest side driver implementation.") Cc: Signed-off-by: Tetsuo Handa Link: https://lore.kernel.org/r/20210402121742.3917-2-penguin-kernel@I-love.SAKURA.ne.jp Signed-off-by: Greg Kroah-Hartman commit bc4087770460baaf9e72c09f031d45a6650a6d70 Author: Tetsuo Handa Date: Fri Apr 2 21:17:41 2021 +0900 misc: vmw_vmci: explicitly initialize vmci_notify_bm_set_msg struct commit 376565b9717c30cd58ad33860fa42697615fa2e4 upstream. KMSAN complains that the vmci_use_ppn64() == false path in vmci_dbell_register_notification_bitmap() left upper 32bits of bitmap_set_msg.bitmap_ppn64 member uninitialized. ===================================================== BUG: KMSAN: uninit-value in kmsan_check_memory+0xd/0x10 CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.11.0-rc7+ #4 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 02/27/2020 Call Trace: dump_stack+0x21c/0x280 kmsan_report+0xfb/0x1e0 kmsan_internal_check_memory+0x484/0x520 kmsan_check_memory+0xd/0x10 iowrite8_rep+0x86/0x380 vmci_send_datagram+0x150/0x280 vmci_dbell_register_notification_bitmap+0x133/0x1e0 vmci_guest_probe_device+0xcab/0x1e70 pci_device_probe+0xab3/0xe70 really_probe+0xd16/0x24d0 driver_probe_device+0x29d/0x3a0 device_driver_attach+0x25a/0x490 __driver_attach+0x78c/0x840 bus_for_each_dev+0x210/0x340 driver_attach+0x89/0xb0 bus_add_driver+0x677/0xc40 driver_register+0x485/0x8e0 __pci_register_driver+0x1ff/0x350 vmci_guest_init+0x3e/0x41 vmci_drv_init+0x1d6/0x43f do_one_initcall+0x39c/0x9a0 do_initcall_level+0x1d7/0x259 do_initcalls+0x127/0x1cb do_basic_setup+0x33/0x36 kernel_init_freeable+0x29a/0x3ed kernel_init+0x1f/0x840 ret_from_fork+0x1f/0x30 Local variable ----bitmap_set_msg@vmci_dbell_register_notification_bitmap created at: vmci_dbell_register_notification_bitmap+0x50/0x1e0 vmci_dbell_register_notification_bitmap+0x50/0x1e0 Bytes 28-31 of 32 are uninitialized Memory access of size 32 starts at ffff88810098f570 ===================================================== Fixes: 83e2ec765be03e8a ("VMCI: doorbell implementation.") Cc: Signed-off-by: Tetsuo Handa Link: https://lore.kernel.org/r/20210402121742.3917-1-penguin-kernel@I-love.SAKURA.ne.jp Signed-off-by: Greg Kroah-Hartman commit 3b22a73354ffc9af1af1aa5d8b566898ce36442d Author: Kishon Vijay Abraham I Date: Fri Mar 19 18:11:17 2021 +0530 phy: ti: j721e-wiz: Invoke wiz_init() before of_platform_device_create() commit f7eb147d306ad2efae6837e20d2944f03be42eb4 upstream. Invoke wiz_init() before configuring anything else in Sierra/Torrent (invoked as part of of_platform_device_create()). wiz_init() resets the SERDES device and any configuration done in the probe() of Sierra/Torrent will be lost. In order to prevent SERDES configuration from getting reset, invoke wiz_init() immediately before invoking of_platform_device_create(). Fixes: 091876cc355d ("phy: ti: j721e-wiz: Add support for WIZ module present in TI J721E SoC") Signed-off-by: Kishon Vijay Abraham I Reviewed-by: Swapnil Jakhade Cc: # v5.10 Link: https://lore.kernel.org/r/20210319124128.13308-3-kishon@ti.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 709e69247a1f2e5c29327fc91a6fce3276c77f43 Author: Hans de Goede Date: Wed Feb 17 11:24:59 2021 +0100 misc: lis3lv02d: Fix false-positive WARN on various HP models commit 3641762c1c9c7cfd84a7061a0a73054f09b412e3 upstream. Before this commit lis3lv02d_get_pwron_wait() had a WARN_ONCE() to catch a potential divide by 0. WARN macros should only be used to catch internal kernel bugs and that is not the case here. We have been receiving a lot of bug reports about kernel backtraces caused by this WARN. The div value being checked comes from the lis3->odrs[] array. Which is sized to be a power-of-2 matching the number of bits in lis3->odr_mask. The only lis3 model where this array is not entirely filled with non zero values. IOW the only model where we can hit the div == 0 check is the 3dc ("8 bits 3DC sensor") model: int lis3_3dc_rates[16] = {0, 1, 10, 25, 50, 100, 200, 400, 1600, 5000}; Note the 0 value at index 0, according to the datasheet an odr index of 0 means "Power-down mode". HP typically uses a lis3 accelerometer for HDD fall protection. What I believe is happening here is that on newer HP devices, which only contain a SDD, the BIOS is leaving the lis3 device powered-down since it is not used for HDD fall protection. Note that the lis3_3dc_rates array initializer only specifies 10 values, which matches the datasheet. So it also contains 6 zero values at the end. Replace the WARN with a normal check, which treats an odr index of 0 as power-down and uses a normal dev_err() to report the error in case odr index point past the initialized part of the array. Fixes: 1510dd5954be ("lis3lv02d: avoid divide by zero due to unchecked") Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=785814 BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1817027 BugLink: https://bugs.centos.org/view.php?id=10720 Link: https://lore.kernel.org/r/20210217102501.31758-1-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit cb506a1b7fefced5b2042a3c41e9d60085a34319 Author: Kishon Vijay Abraham I Date: Fri Mar 19 18:11:16 2021 +0530 phy: cadence: Sierra: Fix PHY power_on sequence commit 5b4f5757f83be34d1428a1ffbb68d4a1966e9aae upstream. Commit 44d30d622821d ("phy: cadence: Add driver for Sierra PHY") de-asserts PHY_RESET even before the configurations are loaded in phy_init(). However PHY_RESET should be de-asserted only after all the configurations has been initialized, instead of de-asserting in probe. Fix it here. Fixes: 44d30d622821d ("phy: cadence: Add driver for Sierra PHY") Signed-off-by: Kishon Vijay Abraham I Cc: # v5.4+ Reviewed-by: Philipp Zabel Link: https://lore.kernel.org/r/20210319124128.13308-2-kishon@ti.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 07b929c857f04405fe6d172b7d1a2689b76f49fd Author: Annaliese McDermond Date: Mon Mar 29 20:10:49 2021 +0000 sc16is7xx: Defer probe if device read fails commit 158e800e0fde91014812f5cdfb92ce812e3a33b4 upstream. A test was added to the probe function to ensure the device was actually connected and working before successfully completing a probe. If the device was actually there, but the I2C bus was not ready yet for whatever reason, the probe fails permanently. Change the probe so that we defer the probe on a regmap read failure so that we try the probe again when the dependent drivers are potentially loaded. This should not affect the case where the device truly isn't present because the probe will never successfully complete. Fixes: 2aa916e67db3 ("sc16is7xx: Read the LSR register for basic device presence check") Cc: stable@vger.kernel.org Signed-off-by: Annaliese McDermond Link: https://lore.kernel.org/r/010101787f9c3fd8-c1815c00-2d6b-4c85-a96a-a13e68597fda-000000@us-west-2.amazonses.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 091d32c54550ae1a0b464cd08a1db999563e6cb6 Author: Ye Xiang Date: Sat Jan 30 18:25:46 2021 +0800 iio: hid-sensor-rotation: Fix quaternion data not correct commit 6c3b615379d7cd90d2f70b3cf9860c5a4910546a upstream. Because the data of HID_USAGE_SENSOR_ORIENT_QUATERNION defined by ISH FW is s16, but quaternion data type is in_rot_quaternion_type(le:s16/32X4>>0), need to transform data type from s16 to s32 May require manual backporting. Fixes: fc18dddc0625 ("iio: hid-sensors: Added device rotation support") Signed-off-by: Ye Xiang Link: https://lore.kernel.org/r/20210130102546.31397-1-xiang.ye@intel.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 99f8854ad3dadda15fd46deca57fc9205f888980 Author: Gwendal Grignou Date: Fri Mar 26 11:46:02 2021 -0700 iio: sx9310: Fix access to variable DT array commit 6f0078ae704d94b1a93e5f3d0a44cf3d8090fa91 upstream. With the current code, we want to read 4 entries from DT array "semtech,combined-sensors". If there are less, we silently fail as of_property_read_u32_array() returns -EOVERFLOW. First count the number of entries and if between 1 and 4, collect the content of the array. Fixes: 5b19ca2c78a0 ("iio: sx9310: Set various settings from DT") Signed-off-by: Gwendal Grignou Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210326184603.251683-2-gwendal@chromium.org Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 0a5cc717d5ae98fa61ec26c1445c495f79073e45 Author: Linus Walleij Date: Mon Feb 15 16:30:23 2021 +0100 iio: magnetometer: yas530: Fix return value on error path commit e64837bf9e2c063d6b5bab51c0554a60270f636d upstream. There was a missed return variable assignment in the default errorpath of the switch statement in yas5xx_probe(). Fix it. Reported-by: kernel test robot Reported-by: Dan Carpenter Suggested-by: Andy Shevchenko Signed-off-by: Linus Walleij Link: https://lore.kernel.org/r/20210215153023.47899-1-linus.walleij@linaro.org Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 0ed8a4d4606b0936ae94f9c949249f0eb27d9fef Author: Jonathan Cameron Date: Thu Apr 1 18:17:57 2021 +0100 iio:adc:ad7476: Fix remove handling commit 6baee4bd63f5fdf1716f88e95c21a683e94fe30d upstream. This driver was in an odd half way state between devm based cleanup and manual cleanup (most of which was missing). I would guess something went wrong with a rebase or similar. Anyhow, this basically finishes the job as a precursor to improving the regulator handling. Signed-off-by: Jonathan Cameron Fixes: 4bb2b8f94ace3 ("iio: adc: ad7476: implement devm_add_action_or_reset") Cc: Michael Hennerich Reviewed-by: Alexandru Ardelean Cc: Link: https://lore.kernel.org/r/20210401171759.318140-2-jic23@kernel.org Signed-off-by: Greg Kroah-Hartman commit 8260a84e54d4e800095ff7a4553a0b8fde9818ed Author: Jonathan Cameron Date: Sun Mar 21 18:29:56 2021 +0000 iio:accel:adis16201: Fix wrong axis assignment that prevents loading commit 4e102429f3dc62dce546f6107e34a4284634196d upstream. Whilst running some basic tests as part of writing up the dt-bindings for this driver (to follow), it became clear it doesn't actually load currently. iio iio:device1: tried to double register : in_incli_x_index adis16201 spi0.0: Failed to create buffer sysfs interfaces adis16201: probe of spi0.0 failed with error -16 Looks like a cut and paste / update bug. Fixes tag obviously not accurate but we don't want to bother carry thing back to before the driver moved out of staging. Fixes: 591298e54cea ("Staging: iio: accel: adis16201: Move adis16201 driver out of staging") Signed-off-by: Jonathan Cameron Cc: Cc: Himanshu Jha Cc: Nuno Sá Reviewed-by: Alexandru Ardelean Link: https://lore.kernel.org/r/20210321182956.844652-1-jic23@kernel.org Signed-off-by: Greg Kroah-Hartman commit 47007b0dd0f7251e277d205ca055e3f74d490405 Author: Gwendal Grignou Date: Wed Mar 31 11:22:22 2021 -0700 iio: sx9310: Fix write_.._debounce() commit fc948409ccc1e8afe8655cee77c686eedbfbee60 upstream. Check input to be sure it matches Semtech sx9310 specification and can fit into debounce register. Compare argument writen to thresh_.._period with read from same sysfs attribute: Before: Afer: write | read write | read -1 | 8 -1 fails: -EINVAL 0 | 8 0 | 0 1 | 0 1 | 0 2..15 | 2^log2(N) 2..15 | 2^log2(N) 16 | 0 >= 16 fails: -EINVAL Fixes: 1b6872015f0b ("iio: sx9310: Support setting debounce values") Signed-off-by: Gwendal Grignou Cc: stable@vger.kernel.org Reviewed-by: Stephen Boyd Link: https://lore.kernel.org/r/20210331182222.219533-1-gwendal@chromium.org Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 71ec5597189caadedf1e08c0e947acc7737d0e1e Author: Linus Walleij Date: Mon Feb 15 16:30:32 2021 +0100 iio: magnetometer: yas530: Include right header commit bb354aeb364f9dee51e16edfdf6194ce4ba9237e upstream. To get access to the big endian byte order parsing helpers drivers need to include and nothing else. Reported-by: kernel test robot Suggested-by: Harvey Harrison Signed-off-by: Linus Walleij Cc: Link: https://lore.kernel.org/r/20210215153032.47962-1-linus.walleij@linaro.org Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 25a233aba5d00b1478824bb50c8474c452b9c4f6 Author: Lars-Peter Clausen Date: Mon Apr 5 13:44:41 2021 +0200 iio: inv_mpu6050: Fully validate gyro and accel scale writes commit e09fe9135399807b8397798a53160e055dc6c29f upstream. When setting the gyro or accelerometer scale the inv_mpu6050 driver ignores the integer part of the value. As a result e.g. all of 0.13309, 1.13309, 12345.13309, ... are accepted as a valid gyro scale and 0.13309 is the scale that gets set in all those cases. Make sure to check that the integer part of the scale value is 0 and reject it otherwise. Fixes: 09a642b78523 ("Invensense MPU6050 Device Driver.") Signed-off-by: Lars-Peter Clausen Acked-by: Jean-Baptiste Maneyrol Link: https://lore.kernel.org/r/20210405114441.24167-1-lars@metafoo.de Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit ff39adf5d31c72025bba799aec69c5c86d81d549 Author: Dmitry Osipenko Date: Tue Mar 2 16:18:00 2021 +0300 soc/tegra: regulators: Fix locking up when voltage-spread is out of range commit ef85bb582c41524e9e68dfdbde48e519dac4ab3d upstream. Fix voltage coupler lockup which happens when voltage-spread is out of range due to a bug in the code. The max-spread requirement shall be accounted when CPU regulator doesn't have consumers. This problem is observed on Tegra30 Ouya game console once system-wide DVFS is enabled in a device-tree. Fixes: 783807436f36 ("soc/tegra: regulators: Add regulators coupler for Tegra30") Cc: stable@vger.kernel.org Reported-by: Peter Geis Tested-by: Peter Geis # Ouya T30 Tested-by: Matt Merhar # Ouya T30 Signed-off-by: Dmitry Osipenko Signed-off-by: Thierry Reding Signed-off-by: Greg Kroah-Hartman commit ce835bc103eae094ac07ea1cd7575312d39a22cf Author: Lukasz Luba Date: Mon Mar 15 09:31:23 2021 +0000 PM / devfreq: Unlock mutex and free devfreq struct in error path commit 8b50a7995770d41a2e8d9c422cd2882aca0dedd2 upstream. The devfreq->lock is held for time of setup. Release the lock in the error path, before jumping to the end of the function. Change the goto destination which frees the allocated memory. Cc: v5.9+ # v5.9+ Fixes: 4dc3bab8687f ("PM / devfreq: Add support delayed timer for polling mode") Signed-off-by: Lukasz Luba Signed-off-by: Chanwoo Choi Signed-off-by: Greg Kroah-Hartman commit 901b6b29fde93d57b4d02d1554f7ce4670568c8f Author: Kishon Vijay Abraham I Date: Wed Mar 17 18:45:18 2021 +0530 PCI: keystone: Let AM65 use the pci_ops defined in pcie-designware-host.c commit 3d0b2a3a87ce5ae85de46c4241afd52ab8b566fe upstream. Both TI's AM65x (K3) and TI's K2 PCIe driver are implemented in pci-keystone. However Only K2 PCIe driver should use it's own pci_ops for configuration space accesses. But commit 10a797c6e54a ("PCI: dwc: keystone: Use pci_ops for config space accessors") used custom pci_ops for both AM65x and K2. This breaks configuration space access for AM65x platform. Fix it here. Link: https://lore.kernel.org/r/20210317131518.11040-1-kishon@ti.com Fixes: 10a797c6e54a ("PCI: dwc: keystone: Use pci_ops for config space accessors") Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Lorenzo Pieralisi Reviewed-by: Krzysztof Wilczyński Cc: # v5.10 Signed-off-by: Greg Kroah-Hartman commit 6df842bbbaabccb0fc6e3b067d5c60c4e4e9ee97 Author: Dejin Zheng Date: Sun Mar 28 22:41:18 2021 +0800 PCI: xgene: Fix cfg resource mapping commit d4707d79fae08c8996a1ba45965a491045a22dda upstream. In commit e2dcd20b1645 a change was made to use devm_platform_ioremap_resource_byname() to simplify code and remove the res variable; this was wrong since the res variable is still needed and as an outcome the port->cfg_addr gets an erroneous address. Revert the change going back to original behaviour. Link: https://lore.kernel.org/r/20210328144118.305074-1-zhengdejin5@gmail.com Fixes: e2dcd20b1645a ("PCI: controller: Convert to devm_platform_ioremap_resource_byname()") Reported-by: dann.frazier@canonical.com Tested-by: dann frazier Signed-off-by: Dejin Zheng Signed-off-by: Lorenzo Pieralisi Cc: stable@vger.kernel.org # v5.9+ Signed-off-by: Greg Kroah-Hartman commit bb2679a3a1c030d2f43200b575bb825f4ad3da99 Author: Sean Christopherson Date: Thu Mar 4 17:10:58 2021 -0800 KVM: x86: Defer the MMU unload to the normal path on an global INVPCID commit f66c53b3b94f658590e1012bf6d922f8b7e01bda upstream. Defer unloading the MMU after a INVPCID until the instruction emulation has completed, i.e. until after RIP has been updated. On VMX, this is a benign bug as VMX doesn't touch the MMU when skipping an emulated instruction. However, on SVM, if nrip is disabled, the emulator is used to skip an instruction, which would lead to fireworks if the emulator were invoked without a valid MMU. Fixes: eb4b248e152d ("kvm: vmx: Support INVPCID in shadow paging mode") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-Id: <20210305011101.3597423-15-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 60870cc69ec806900509f991daff48f40ef1d518 Author: Arun Easi Date: Fri Apr 9 14:51:53 2021 -0700 PCI: Allow VPD access for QLogic ISP2722 commit e00dc69b5f17c444a38cd9745a0f76bc989b3af4 upstream. 0d5370d1d852 ("PCI: Prevent VPD access for QLogic ISP2722") disabled access to VPD of the ISP2722-based 16/32Gb Fibre Channel to PCIe Adapter because reading past the end of the VPD caused NMIs. 104daa71b396 ("PCI: Determine actual VPD size on first access") limits reads to the actual size of VPD, which should prevent these NMIs. 104daa71b396 was merged *before* 0d5370d1d852, but we think the testing that prompted 0d5370d1d852 ("PCI: Prevent VPD access for QLogic ISP2722") was done with a kernel that lacked 104daa71b396. See [1, 2]. Remove the quirk added by 0d5370d1d852 ("PCI: Prevent VPD access for QLogic ISP2722") so customers can read the HBA VPD. [1] https://lore.kernel.org/linux-pci/alpine.LRH.2.21.9999.2012161641230.28924@irv1user01.caveonetworks.com/ [2] https://lore.kernel.org/linux-pci/alpine.LRH.2.21.9999.2104071535110.13940@irv1user01.caveonetworks.com/ [bhelgaas: commit log] Link: https://lore.kernel.org/r/20210409215153.16569-2-aeasi@marvell.com Signed-off-by: Arun Easi Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org # v4.6+ Signed-off-by: Greg Kroah-Hartman commit 9b3dfb74303706597a2e86a36ea4faeae205d1dd Author: Maciej W. Rozycki Date: Wed Mar 10 13:03:09 2021 +0100 FDDI: defxx: Bail out gracefully with unassigned PCI resource for CSR commit f626ca682912fab55dff15469ce893ae16b65c7e upstream. Recent versions of the PCI Express specification have deprecated support for I/O transactions and actually some PCIe host bridges, such as Power Systems Host Bridge 4 (PHB4), do not implement them. For those systems the PCI BARs that request a mapping in the I/O space have the length recorded in the corresponding PCI resource set to zero, which makes it unassigned: # lspci -s 0031:02:04.0 -v 0031:02:04.0 FDDI network controller: Digital Equipment Corporation PCI-to-PDQ Interface Chip [PFI] FDDI (DEFPA) (rev 02) Subsystem: Digital Equipment Corporation FDDIcontroller/PCI (DEFPA) Flags: bus master, medium devsel, latency 136, IRQ 57, NUMA node 8 Memory at 620c080020000 (32-bit, non-prefetchable) [size=128] I/O ports at [disabled] Memory at 620c080030000 (32-bit, non-prefetchable) [size=64K] Capabilities: [50] Power Management version 2 Kernel driver in use: defxx Kernel modules: defxx # Regardless the driver goes ahead and requests it (here observed with a Raptor Talos II POWER9 system), resulting in an odd /proc/ioport entry: # cat /proc/ioports 00000000-ffffffffffffffff : 0031:02:04.0 # Furthermore, the system gets confused as the driver actually continues and pokes at those locations, causing a flood of messages being output to the system console by the underlying system firmware, like: defxx: v1.11 2014/07/01 Lawrence V. Stefani and others defxx 0031:02:04.0: enabling device (0140 -> 0142) LPC[000]: Got SYNC no-response error. Error address reg: 0xd0010000 IPMI: dropping non severe PEL event LPC[000]: Got SYNC no-response error. Error address reg: 0xd0010014 IPMI: dropping non severe PEL event LPC[000]: Got SYNC no-response error. Error address reg: 0xd0010014 IPMI: dropping non severe PEL event and so on and so on (possibly intermixed actually, as there's no locking between the kernel and the firmware in console port access with this particular system, but cleaned up above for clarity), and once some 10k of such pairs of the latter two messages have been produced an interace eventually shows up in a useless state: 0031:02:04.0: DEFPA at I/O addr = 0x0, IRQ = 57, Hardware addr = 00-00-00-00-00-00 This was not expected to happen as resource handling was added to the driver a while ago, because it was not known at that time that a PCI system would be possible that cannot assign port I/O resources, and oddly enough `request_region' does not fail, which would have caught it. Correct the problem then by checking for the length of zero for the CSR resource and bail out gracefully refusing to register an interface if that turns out to be the case, producing messages like: defxx: v1.11 2014/07/01 Lawrence V. Stefani and others 0031:02:04.0: Cannot use I/O, no address set, aborting 0031:02:04.0: Recompile driver with "CONFIG_DEFXX_MMIO=y" Keep the original check for the EISA MMIO resource as implemented, because in that case the length is hardwired to 0x400 as a consequence of how the compare/mask address decoding works in the ESIC chip and it is only the base address that is set to zero if MMIO has been disabled for the adapter in EISA configuration, which in turn could be a valid bus address in a legacy-free system implementing PCI, especially for port I/O. Where the EISA MMIO resource has been disabled for the adapter in EISA configuration this arrangement keeps producing messages like: eisa 00:05: EISA: slot 5: DEC3002 detected defxx: v1.11 2014/07/01 Lawrence V. Stefani and others 00:05: Cannot use MMIO, no address set, aborting 00:05: Recompile driver with "CONFIG_DEFXX_MMIO=n" 00:05: Or run ECU and set adapter's MMIO location with the last two lines now swapped for easier handling in the driver. There is no need to check for and catch the case of a port I/O resource not having been assigned for EISA as the adapter uses the slot-specific I/O space, which gets assigned by how EISA has been specified and maps directly to the particular slot an option card has been placed in. And the EISA variant of the adapter has additional registers that are only accessible via the port I/O space anyway. While at it factor out the error message calls into helpers and fix an argument order bug with the `pr_err' call now in `dfx_register_res_err'. Signed-off-by: Maciej W. Rozycki Fixes: 4d0438e56a8f ("defxx: Clean up DEFEA resource management") Cc: stable@vger.kernel.org # v3.19+ Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit da61e572de95466f1b54391cb2eccaa638677eeb Author: Ilya Lipnitskiy Date: Tue Apr 13 20:12:33 2021 -0700 MIPS: pci-rt2880: fix slot 0 configuration commit 8e98b697006d749d745d3b174168a877bb96c500 upstream. pci_fixup_irqs() used to call pcibios_map_irq on every PCI device, which for RT2880 included bus 0 slot 0. After pci_fixup_irqs() got removed, only slots/funcs with devices attached would be called. While arguably the right thing, that left no chance for this driver to ever initialize slot 0, effectively bricking PCI and USB on RT2880 devices such as the Belkin F5D8235-4 v1. Slot 0 configuration needs to happen after PCI bus enumeration, but before any device at slot 0x11 (func 0 or 1) is talked to. That was determined empirically by testing on a Belkin F5D8235-4 v1 device. A minimal BAR 0 config write followed by read, then setting slot 0 PCI_COMMAND to MASTER | IO | MEMORY is all that seems to be required for proper functionality. Tested by ensuring that full- and high-speed USB devices get enumerated on the Belkin F5D8235-4 v1 (with an out of tree DTS file from OpenWrt). Fixes: 04c81c7293df ("MIPS: PCI: Replace pci_fixup_irqs() call with host bridge IRQ mapping hooks") Signed-off-by: Ilya Lipnitskiy Cc: Lorenzo Pieralisi Cc: Tobias Wolf Cc: # v4.14+ Signed-off-by: Thomas Bogendoerfer Signed-off-by: Greg Kroah-Hartman commit 97f12e7b3249f9a202ae2aa08f298b539f4ee3bc Author: Ilya Lipnitskiy Date: Sat Mar 6 20:17:24 2021 -0800 MIPS: pci-mt7620: fix PLL lock check commit c15b99ae2ba9ea30da3c7cd4765b8a4707e530a6 upstream. Upstream a long-standing OpenWrt patch [0] that fixes MT7620 PCIe PLL lock check. The existing code checks the wrong register bit: PPLL_SW_SET is not defined in PPLL_CFG1 and bit 31 of PPLL_CFG1 is marked as reserved in the MT7620 Programming Guide. The correct bit to check for PLL lock is PPLL_LD (bit 23). Also reword the error message for clarity. Without this change it is unlikely that this driver ever worked with mainline kernel. [0]: https://lists.infradead.org/pipermail/lede-commits/2017-July/004441.html Signed-off-by: Ilya Lipnitskiy Cc: John Crispin Cc: linux-mips@vger.kernel.org Cc: linux-mediatek@lists.infradead.org Cc: linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org Signed-off-by: Thomas Bogendoerfer Signed-off-by: Greg Kroah-Hartman commit 4aad12fcb5132e3209dc0b24f6c9a650d28bd460 Author: Annaliese McDermond Date: Wed Mar 31 18:21:45 2021 +0000 ASoC: tlv320aic32x4: Increase maximum register in regmap commit 29654ed8384e9dbaf4cfba689dbcb664a6ab4bb7 upstream. AIC32X4_REFPOWERUP was added as a register, but the maximum register value in the regmap and regmap range was not correspondingly increased. This caused an error when this register was attempted to be written. Fixes: ec96690de82c ("ASoC: tlv320aic32x4: Enable fast charge") Cc: stable@vger.kernel.org Signed-off-by: Annaliese McDermond Link: https://lore.kernel.org/r/0101017889851cab-ce60cfdb-d88c-43d8-bbd2-7fbf34a0c912-000000@us-west-2.amazonses.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 4eff0aece2bf6e490cc91be3c5681188012ed31f Author: Annaliese McDermond Date: Wed Mar 31 18:21:38 2021 +0000 ASoC: tlv320aic32x4: Register clocks before registering component commit 1ca1156cfd69530e6b7cb99943baf90c8bd871a5 upstream. Clock registration must be performed before the component is registered. aic32x4_component_probe attempts to get all the clocks right off the bat. If the component is registered before the clocks there is a race condition where the clocks may not be registered by the time aic32x4_componet_probe actually runs. Fixes: d1c859d314d8 ("ASoC: codec: tlv3204: Increased maximum supported channels") Cc: stable@vger.kernel.org Signed-off-by: Annaliese McDermond Link: https://lore.kernel.org/r/0101017889850206-dcac4cce-8cc8-4a21-80e9-4e4bef44b981-000000@us-west-2.amazonses.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit bbe08fe17ca94e955eb506724435d707115c93a7 Author: Lukasz Majczak Date: Thu Apr 15 14:43:47 2021 +0200 ASoC: Intel: kbl_da7219_max98927: Fix kabylake_ssp_fixup function commit a523ef731ac6674dc07574f31bf44cc5bfa14e4d upstream. kabylake_ssp_fixup function uses snd_soc_dpcm to identify the codecs DAIs. The HW parameters are changed based on the codec DAI of the stream. The earlier approach to get snd_soc_dpcm was using container_of() macro on snd_pcm_hw_params. The structures have been modified over time and snd_soc_dpcm does not have snd_pcm_hw_params as a reference but as a copy. This causes the current driver to crash when used. This patch changes the way snd_soc_dpcm is extracted. snd_soc_pcm_runtime holds 2 dpcm instances (one for playback and one for capture). 2 codecs on the SSP are dmic (capture) and speakers (playback). Based on the stream direction, snd_soc_dpcm is extracted from snd_soc_pcm_runtime. Tested for all use cases of the driver. Based on similar fix in kbl_rt5663_rt5514_max98927.c from Harsha Priya and Vamshi Krishna Gopal Cc: # 5.4+ Signed-off-by: Lukasz Majczak Acked-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20210415124347.475432-1-lma@semihalf.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit e0efbd1233794a2811fa9e9cf9d19f9f23f8f41e Author: Pierre-Louis Bossart Date: Fri Mar 12 12:02:30 2021 -0600 ASoC: samsung: tm2_wm5110: check of of_parse return value commit d58970da324732686529655c21791cef0ee547c4 upstream. cppcheck warning: sound/soc/samsung/tm2_wm5110.c:605:6: style: Variable 'ret' is reassigned a value before the old one has been used. [redundantAssignment] ret = devm_snd_soc_register_component(dev, &tm2_component, ^ sound/soc/samsung/tm2_wm5110.c:554:7: note: ret is assigned ret = of_parse_phandle_with_args(dev->of_node, "i2s-controller", ^ sound/soc/samsung/tm2_wm5110.c:605:6: note: ret is overwritten ret = devm_snd_soc_register_component(dev, &tm2_component, ^ The args is a stack variable, so it could have junk (uninitialized) therefore args.np could have a non-NULL and random value even though property was missing. Later could trigger invalid pointer dereference. There's no need to check for args.np because args.np won't be initialized on errors. Fixes: 8d1513cef51a ("ASoC: samsung: Add support for HDMI audio on TM2 board") Cc: Suggested-by: Krzysztof Kozlowski Reviewed-by: Krzysztof Kozlowski Reviewed-by: Sylwester Nawrocki Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20210312180231.2741-2-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit bda903c4077575c8ee4625c8c8abd9826152d5fd Author: Chunfeng Yun Date: Mon Mar 8 10:51:51 2021 +0800 usb: xhci-mtk: improve bandwidth scheduling with TT commit e19ee44a3d07c232f9241024dab1ebd0748cdf5f upstream. When the USB headset is plug into an external hub, sometimes can't set config due to not enough bandwidth, so need improve LS/FS INT/ISOC bandwidth scheduling with TT. Fixes: 54f6a8af3722 ("usb: xhci-mtk: skip dropping bandwidth of unchecked endpoints") Cc: stable Signed-off-by: Yaqii Wu Signed-off-by: Chunfeng Yun Link: https://lore.kernel.org/r/2f30e81400a59afef5f8231c98149169c7520519.1615170625.git.chunfeng.yun@mediatek.com Signed-off-by: Greg Kroah-Hartman commit 9cc300e48da1a6b95d1e0a0682ddba47ab927d80 Author: Chunfeng Yun Date: Mon Mar 8 10:51:50 2021 +0800 usb: xhci-mtk: remove or operator for setting schedule parameters commit 5fa5827566e3affa1657ccf9b22706c06a5d021a upstream. Side effect may happen if use or operator to set schedule parameters when the parameters are already set before. Set them directly due to other bits are reserved. Fixes: 54f6a8af3722 ("usb: xhci-mtk: skip dropping bandwidth of unchecked endpoints") Cc: stable Signed-off-by: Chunfeng Yun Link: https://lore.kernel.org/r/d287899e6beb2fc1bfb8900c75a872f628ecde55.1615170625.git.chunfeng.yun@mediatek.com Signed-off-by: Greg Kroah-Hartman commit a6727853725fb92734019361677327e002c3699e Author: Johan Hovold Date: Tue Mar 30 16:37:16 2021 +0200 USB: serial: xr: fix CSIZE handling commit ea7ada4de2f7406150dd35ecd0302842587a464e upstream. The XR21V141X does not have a 5- or 6-bit mode, but the current implementation failed to properly restore the old setting when CS5 or CS6 was requested. Instead an invalid request would be sent to the device. Fixes: c2d405aa86b4 ("USB: serial: add MaxLinear/Exar USB to Serial driver") Reviewed-by: Manivannan Sadhasivam Cc: stable@vger.kernel.org # 5.12 Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 0707201cd3e5c7ccc26c7487f1737d98e8af7ccf Author: Badhri Jagan Sridharan Date: Wed Apr 7 13:07:20 2021 -0700 usb: typec: tcpm: update power supply once partner accepts commit 4050f2683f2c3151dc3dd1501ac88c57caf810ff upstream. power_supply_changed needs to be called to notify clients after the partner accepts the requested values for the pps case. Also, remove the redundant power_supply_changed at the end of the tcpm_reset_port as power_supply_changed is already called right after usb_type is changed. Fixes: f2a8aa053c176 ("typec: tcpm: Represent source supply through power_supply") Signed-off-by: Badhri Jagan Sridharan Cc: stable Reviewed-by: Adam Thomson Reviewed-by: Heikki Krogerus Link: https://lore.kernel.org/r/20210407200723.1914388-3-badhri@google.com Signed-off-by: Greg Kroah-Hartman commit 999237e2fe4afcb04755aa4c1ac5863f4d39105f Author: Badhri Jagan Sridharan Date: Wed Apr 7 13:07:19 2021 -0700 usb: typec: tcpm: Address incorrect values of tcpm psy for pps supply commit e3a0720224873587954b55d193d5b4abb14f0443 upstream. tcpm_pd_select_pps_apdo overwrites port->pps_data.min_volt, port->pps_data.max_volt, port->pps_data.max_curr even before port partner accepts the requests. This leaves incorrect values in current_limit and supply_voltage that get exported by "tcpm-source-psy-". Solving this problem by caching the request values in req_min_volt, req_max_volt, req_max_curr, req_out_volt, req_op_curr. min_volt, max_volt, max_curr gets updated once the partner accepts the request. current_limit, supply_voltage gets updated once local port's tcpm enters SNK_TRANSITION_SINK when the accepted current_limit and supply_voltage is enforced. Fixes: f2a8aa053c176 ("typec: tcpm: Represent source supply through power_supply") Signed-off-by: Badhri Jagan Sridharan Cc: stable Reviewed-by: Adam Thomson Reviewed-by: Heikki Krogerus Link: https://lore.kernel.org/r/20210407200723.1914388-2-badhri@google.com Signed-off-by: Greg Kroah-Hartman commit 3645a7d04f2f215c09ee80d38bf93578a74ed767 Author: Badhri Jagan Sridharan Date: Wed Apr 7 13:07:18 2021 -0700 usb: typec: tcpm: Address incorrect values of tcpm psy for fixed supply commit f3dedafb8263ca4791a92a23f5230068f5bde008 upstream. tcpm_pd_build_request overwrites current_limit and supply_voltage even before port partner accepts the requests. This leaves stale values in current_limit and supply_voltage that get exported by "tcpm-source-psy-". Solving this problem by caching the request values of current limit/supply voltage in req_current_limit and req_supply_voltage. current_limit/supply_voltage gets updated once the port partner accepts the request. Fixes: f2a8aa053c176 ("typec: tcpm: Represent source supply through power_supply") Signed-off-by: Badhri Jagan Sridharan Cc: stable Reviewed-by: Guenter Roeck Reviewed-by: Adam Thomson Reviewed-by: Heikki Krogerus Link: https://lore.kernel.org/r/20210407200723.1914388-1-badhri@google.com Signed-off-by: Greg Kroah-Hartman commit ff3486804847c492487041d6e52123657c4bc8ba Author: Randy Dunlap Date: Thu Apr 15 11:36:39 2021 -0700 drm: bridge: fix LONTIUM use of mipi_dsi_() functions commit ad085b3a712a89e4a48472121b231add7a8362e4 upstream. The Lontium DRM bridge drivers use mipi_dsi_() function interfaces so they need to select DRM_MIPI_DSI to prevent build errors. ERROR: modpost: "mipi_dsi_attach" [drivers/gpu/drm/bridge/lontium-lt9611uxc.ko] undefined! ERROR: modpost: "mipi_dsi_device_register_full" [drivers/gpu/drm/bridge/lontium-lt9611uxc.ko] undefined! ERROR: modpost: "of_find_mipi_dsi_host_by_node" [drivers/gpu/drm/bridge/lontium-lt9611uxc.ko] undefined! ERROR: modpost: "mipi_dsi_device_unregister" [drivers/gpu/drm/bridge/lontium-lt9611uxc.ko] undefined! ERROR: modpost: "mipi_dsi_detach" [drivers/gpu/drm/bridge/lontium-lt9611uxc.ko] undefined! ERROR: modpost: "mipi_dsi_attach" [drivers/gpu/drm/bridge/lontium-lt9611.ko] undefined! ERROR: modpost: "mipi_dsi_device_register_full" [drivers/gpu/drm/bridge/lontium-lt9611.ko] undefined! ERROR: modpost: "of_find_mipi_dsi_host_by_node" [drivers/gpu/drm/bridge/lontium-lt9611.ko] undefined! ERROR: modpost: "mipi_dsi_device_unregister" [drivers/gpu/drm/bridge/lontium-lt9611.ko] undefined! ERROR: modpost: "mipi_dsi_detach" [drivers/gpu/drm/bridge/lontium-lt9611.ko] undefined! WARNING: modpost: suppressed 5 unresolved symbol warnings because there were too many) Fixes: 23278bf54afe ("drm/bridge: Introduce LT9611 DSI to HDMI bridge") Fixes: 0cbbd5b1a012 ("drm: bridge: add support for lontium LT9611UXC bridge") Fixes: 30e2ae943c26 ("drm/bridge: Introduce LT8912B DSI to HDMI bridge") Reported-by: kernel test robot Signed-off-by: Randy Dunlap Reviewed-by: Adren Grassein Cc: Dmitry Baryshkov Cc: Sam Ravnborg Cc: Vinod Koul Cc: Bjorn Andersson Cc: Srinivas Kandagatla Cc: Adrien Grassein Cc: Andrzej Hajda Cc: Neil Armstrong Cc: Robert Foss Cc: dri-devel@lists.freedesktop.org Cc: stable@vger.kernel.org Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20210415183639.1487-1-rdunlap@infradead.org Signed-off-by: Greg Kroah-Hartman commit f162f1edfcd7343ba52aa31ced832247d1e668e3 Author: Johan Hovold Date: Wed Apr 7 12:23:32 2021 +0200 tty: mxser: fix TIOCSSERIAL permission check commit b91cfb2573aeb5ab426fc3c35bcfe9e0d2a7ecbc upstream. Changing the port type and closing_wait parameter are privileged operations so make sure to return -EPERM if a regular user tries to change them. Note that the closing_wait parameter would not actually have been changed but the return value did not indicate that. Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20210407102334.32361-15-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit b4a73d0398cdf06025c9ae9282b97c7ff44681ed Author: Johan Hovold Date: Wed Apr 7 12:23:20 2021 +0200 staging: fwserial: fix TIOCSSERIAL permission check commit 2104eb283df66a482b60254299acbe3c68c03412 upstream. Changing the port close-delay parameter is a privileged operation so make sure to return -EPERM if a regular user tries to change it. Fixes: 7355ba3445f2 ("staging: fwserial: Add TTY-over-Firewire serial driver") Cc: stable@vger.kernel.org # 3.8 Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20210407102334.32361-3-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit abeecdf9b9f3b01cb6113ddaca2e46b6d157deda Author: Johan Hovold Date: Wed Apr 7 12:23:31 2021 +0200 tty: mxser: fix TIOCSSERIAL jiffies conversions commit be6cf583d24dfe87324dd2830d90fc056e0a6648 upstream. The port close_delay and closing wait parameters set by TIOCSSERIAL are specified in jiffies, while the values returned by TIOCGSERIAL are specified in centiseconds. Add the missing conversions so that TIOCSSERIAL works as expected also when HZ is not 100. Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20210407102334.32361-14-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 13b2afa47b651f7944f9e847e384dd06b13b726f Author: Johan Hovold Date: Wed Apr 7 12:23:29 2021 +0200 tty: moxa: fix TIOCSSERIAL permission check commit dc8c8437658667be9b11ec25c4b5482ed2becdaa upstream. Changing the port close delay or type are privileged operations so make sure to return -EPERM if a regular user tries to change them. Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20210407102334.32361-12-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 63cf4009837d21741f8f86664dd75f3e925504c8 Author: Johan Hovold Date: Wed Apr 7 12:23:19 2021 +0200 staging: fwserial: fix TIOCSSERIAL jiffies conversions commit 7a3791afdbd5a951b09a7689bba856bd9f6c6a9f upstream. The port close_delay parameter set by TIOCSSERIAL is specified in jiffies, while the value returned by TIOCGSERIAL is specified in centiseconds. Add the missing conversions so that TIOCGSERIAL works as expected also when HZ is not 100. Fixes: 7355ba3445f2 ("staging: fwserial: Add TTY-over-Firewire serial driver") Cc: stable@vger.kernel.org # 3.8 Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20210407102334.32361-2-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit be43d200fff916dbf30caaf6c2c7fd8dc689319c Author: Johan Hovold Date: Wed Apr 7 12:39:15 2021 +0200 USB: serial: ti_usb_3410_5052: fix TIOCSSERIAL permission check commit d370c90dcd64e427a79a093a070117a1571d4cd8 upstream. Changing the port closing-wait parameter is a privileged operation so make sure to return -EPERM if a regular user tries to change it. Cc: stable@vger.kernel.org Reviewed-by: Greg Kroah-Hartman Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 2ab75256154082884cfb55796f86346bab15d035 Author: Johan Hovold Date: Wed Apr 7 12:23:23 2021 +0200 staging: greybus: uart: fix TIOCSSERIAL jiffies conversions commit b71e571adaa58be4fd289abebc8997e05b4c6b40 upstream. The port close_delay and closing_wait parameters set by TIOCSSERIAL are specified in jiffies and not milliseconds. Add the missing conversions so that TIOCSSERIAL works as expected also when HZ is not 1000. Fixes: e68453ed28c5 ("greybus: uart-gb: now builds, more framework added") Cc: stable@vger.kernel.org # 4.9 Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20210407102334.32361-6-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 0f8dc63a47721575cc4e6fee532f5a9dccd79c14 Author: Johan Hovold Date: Wed Apr 7 12:39:16 2021 +0200 USB: serial: usb_wwan: fix TIOCSSERIAL jiffies conversions commit 3d732690d2267f4d0e19077b178dffbedafdf0c9 upstream. The port close_delay and closing_wait parameters set by TIOCSSERIAL are specified in jiffies and not milliseconds. Add the missing conversions so that the TIOCSSERIAL works as expected also when HZ is not 1000. Fixes: 02303f73373a ("usb-wwan: implement TIOCGSERIAL and TIOCSSERIAL to avoid blocking close(2)") Cc: stable@vger.kernel.org # 2.6.38 Reviewed-by: Greg Kroah-Hartman Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 6a855bd0251613f4fa03b4471b1d6f04a0183ac0 Author: Johan Hovold Date: Wed Apr 7 12:23:26 2021 +0200 tty: amiserial: fix TIOCSSERIAL permission check commit 1d31a831cc04f5f942de3e7d91edaa52310d3c99 upstream. Changing the port closing_wait parameter is a privileged operation. Add the missing check to TIOCSSERIAL so that -EPERM is returned in case an unprivileged user tries to change the closing-wait setting. Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20210407102334.32361-9-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 9ee8e4799334932804b8991ea6cb65f35947771b Author: Johan Hovold Date: Wed Apr 7 12:23:28 2021 +0200 tty: moxa: fix TIOCSSERIAL jiffies conversions commit 6e70b73ca5240c0059a1fbf8ccd4276d6cf71956 upstream. The port close_delay parameter set by TIOCSSERIAL is specified in jiffies, while the value returned by TIOCGSERIAL is specified in centiseconds. Add the missing conversions so that TIOCGSERIAL works as expected also when HZ is not 100. Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20210407102334.32361-11-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 0eff3fa802e58ea04cce53b4ac545dc76fffa746 Author: Hans de Goede Date: Fri Apr 9 14:41:36 2021 +0200 usb: roles: Call try_module_get() from usb_role_switch_find_by_fwnode() commit 3a2a91a2d51761557843996a66098eb7182b48b4 upstream. usb_role_switch_find_by_fwnode() returns a reference to the role-switch which must be put by calling usb_role_switch_put(). usb_role_switch_put() calls module_put(sw->dev.parent->driver->owner), add a matching try_module_get() to usb_role_switch_find_by_fwnode(), making it behave the same as the other usb_role_switch functions which return a reference. This avoids a WARN_ON being hit at kernel/module.c:1158 due to the module-refcount going below 0. Fixes: c6919d5e0cd1 ("usb: roles: Add usb_role_switch_find_by_fwnode()") Cc: stable Reviewed-by: Guenter Roeck Reviewed-by: Heikki Krogerus Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20210409124136.65591-1-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman commit 8f0591e79cdeb9b977285b38e4093286328f3a1c Author: Johan Hovold Date: Thu Apr 8 15:16:00 2021 +0200 Revert "USB: cdc-acm: fix rounding error in TIOCSSERIAL" commit 729f7955cb987c5b7d7e54c87c5ad71c789934f7 upstream. This reverts commit b401f8c4f492cbf74f3f59c9141e5be3071071bb. The offending commit claimed that trying to set the values reported back by TIOCGSERIAL as a regular user could result in an -EPERM error when HZ is 250, but that was never the case. With HZ=250, the default 0.5 second value of close_delay is converted to 125 jiffies when set and is converted back to 50 centiseconds by TIOCGSERIAL as expected (not 12 cs as was claimed, even if that was the case before an earlier fix). Comparing the internal current and new jiffies values is just fine to determine if the value is about to change so drop the bogus workaround (which was also backported to stable). For completeness: With different default values for these parameters or with a HZ value not divisible by two, the lack of rounding when setting the default values in tty_port_init() could result in an -EPERM being returned, but this is hardly something we need to worry about. Cc: Anthony Mallet Cc: stable@vger.kernel.org Acked-by: Oliver Neukum Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20210408131602.27956-2-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 226c0978a22661f6382b7063f6db128179c4ac8f Author: Heikki Krogerus Date: Wed Apr 14 10:54:38 2021 +0300 software node: Allow node addition to already existing device commit b622b24519f5b008f6d4e20e5675eaffa8fbd87b upstream. If the node is added to an already exiting device, the node needs to be also linked to the device separately. This will make sure the reference count is kept in balance also when the node is injected to a device afterwards. Fixes: e68d0119e328 ("software node: Introduce device_add_software_node()") Reported-by: Pierre-Louis Bossart Signed-off-by: Heikki Krogerus Cc: stable Link: https://lore.kernel.org/r/20210414075438.64547-1-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit b1faea82c829cccb935691424250b30a8e9937cf Author: Mike Leach Date: Thu Apr 15 14:24:04 2021 -0600 coresight: etm-perf: Fix define build issue when built as module commit 9204ff94868496f2d9b8b173af52ec455160c364 upstream. CONFIG_CORESIGHT_SOURCE_ETM4X is undefined when built as module, CONFIG_CORESIGHT_SOURCE_ETM4X_MODULE is defined instead. Therefore code in format_attr_contextid_show() not correctly complied when coresight built as module. Use IS_ENABLED(CONFIG_CORESIGHT_SOURCE_ETM4X) to correct this. Link: https://lore.kernel.org/r/20210414194808.22872-1-mike.leach@linaro.org Fixes: 88f11864cf1d ("coresight: etm-perf: Support PID tracing for kernel at EL2") Reviewed-by: Leo Yan Signed-off-by: Mike Leach Signed-off-by: Mathieu Poirier Cc: stable Link: https://lore.kernel.org/r/20210415202404.945368-2-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman commit ca2960d35c36f2e601563c49f6673efd111b94c0 Author: Thadeu Lima de Souza Cascardo Date: Wed May 5 09:47:06 2021 -0300 io_uring: truncate lengths larger than MAX_RW_COUNT on provide buffers commit d1f82808877bb10d3deee7cf3374a4eb3fb582db upstream. Read and write operations are capped to MAX_RW_COUNT. Some read ops rely on that limit, and that is not guaranteed by the IORING_OP_PROVIDE_BUFFERS. Truncate those lengths when doing io_add_buffers, so buffer addresses still use the uncapped length. Also, take the chance and change struct io_buffer len member to __u32, so it matches struct io_provide_buffer len member. This fixes CVE-2021-3491, also reported as ZDI-CAN-13546. Fixes: ddf0322db79c ("io_uring: add IORING_OP_PROVIDE_BUFFERS") Reported-by: Billy Jheng Bing-Jhong (@st424204) Signed-off-by: Thadeu Lima de Souza Cascardo Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 18175fe17ae043a0b81e5d511f8817825784c299 Author: Or Cohen Date: Tue May 4 10:16:46 2021 +0300 net/nfc: fix use-after-free llcp_sock_bind/connect commit c61760e6940dd4039a7f5e84a6afc9cdbf4d82b6 upstream. Commits 8a4cd82d ("nfc: fix refcount leak in llcp_sock_connect()") and c33b1cc62 ("nfc: fix refcount leak in llcp_sock_bind()") fixed a refcount leak bug in bind/connect but introduced a use-after-free if the same local is assigned to 2 different sockets. This can be triggered by the following simple program: int sock1 = socket( AF_NFC, SOCK_STREAM, NFC_SOCKPROTO_LLCP ); int sock2 = socket( AF_NFC, SOCK_STREAM, NFC_SOCKPROTO_LLCP ); memset( &addr, 0, sizeof(struct sockaddr_nfc_llcp) ); addr.sa_family = AF_NFC; addr.nfc_protocol = NFC_PROTO_NFC_DEP; bind( sock1, (struct sockaddr*) &addr, sizeof(struct sockaddr_nfc_llcp) ) bind( sock2, (struct sockaddr*) &addr, sizeof(struct sockaddr_nfc_llcp) ) close(sock1); close(sock2); Fix this by assigning NULL to llcp_sock->local after calling nfc_llcp_local_put. This addresses CVE-2021-23134. Reported-by: Or Cohen Reported-by: Nadav Markus Fixes: c33b1cc62 ("nfc: fix refcount leak in llcp_sock_bind()") Signed-off-by: Or Cohen Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 93d388c087d71aed0e79b8c7db3132f28c010197 Author: Lin Ma Date: Mon Apr 12 19:17:57 2021 +0800 bluetooth: eliminate the potential race condition when removing the HCI controller commit e2cb6b891ad2b8caa9131e3be70f45243df82a80 upstream. There is a possible race condition vulnerability between issuing a HCI command and removing the cont. Specifically, functions hci_req_sync() and hci_dev_do_close() can race each other like below: thread-A in hci_req_sync() | thread-B in hci_dev_do_close() | hci_req_sync_lock(hdev); test_bit(HCI_UP, &hdev->flags); | ... | test_and_clear_bit(HCI_UP, &hdev->flags) hci_req_sync_lock(hdev); | | In this commit we alter the sequence in function hci_req_sync(). Hence, the thread-A cannot issue th. Signed-off-by: Lin Ma Cc: Marcel Holtmann Fixes: 7c6a329e4447 ("[Bluetooth] Fix regression from using default link policy") Signed-off-by: Greg Kroah-Hartman commit c026c3dc3947c714a19779d0a6c596b55e63685d Author: Archie Pusaka Date: Mon Mar 22 14:03:11 2021 +0800 Bluetooth: verify AMP hci_chan before amp_destroy commit 5c4c8c9544099bb9043a10a5318130a943e32fc3 upstream. hci_chan can be created in 2 places: hci_loglink_complete_evt() if it is an AMP hci_chan, or l2cap_conn_add() otherwise. In theory, Only AMP hci_chan should be removed by a call to hci_disconn_loglink_complete_evt(). However, the controller might mess up, call that function, and destroy an hci_chan which is not initiated by hci_loglink_complete_evt(). This patch adds a verification that the destroyed hci_chan must have been init'd by hci_loglink_complete_evt(). Example crash call trace: Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xe3/0x144 lib/dump_stack.c:118 print_address_description+0x67/0x22a mm/kasan/report.c:256 kasan_report_error mm/kasan/report.c:354 [inline] kasan_report mm/kasan/report.c:412 [inline] kasan_report+0x251/0x28f mm/kasan/report.c:396 hci_send_acl+0x3b/0x56e net/bluetooth/hci_core.c:4072 l2cap_send_cmd+0x5af/0x5c2 net/bluetooth/l2cap_core.c:877 l2cap_send_move_chan_cfm_icid+0x8e/0xb1 net/bluetooth/l2cap_core.c:4661 l2cap_move_fail net/bluetooth/l2cap_core.c:5146 [inline] l2cap_move_channel_rsp net/bluetooth/l2cap_core.c:5185 [inline] l2cap_bredr_sig_cmd net/bluetooth/l2cap_core.c:5464 [inline] l2cap_sig_channel net/bluetooth/l2cap_core.c:5799 [inline] l2cap_recv_frame+0x1d12/0x51aa net/bluetooth/l2cap_core.c:7023 l2cap_recv_acldata+0x2ea/0x693 net/bluetooth/l2cap_core.c:7596 hci_acldata_packet net/bluetooth/hci_core.c:4606 [inline] hci_rx_work+0x2bd/0x45e net/bluetooth/hci_core.c:4796 process_one_work+0x6f8/0xb50 kernel/workqueue.c:2175 worker_thread+0x4fc/0x670 kernel/workqueue.c:2321 kthread+0x2f0/0x304 kernel/kthread.c:253 ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:415 Allocated by task 38: set_track mm/kasan/kasan.c:460 [inline] kasan_kmalloc+0x8d/0x9a mm/kasan/kasan.c:553 kmem_cache_alloc_trace+0x102/0x129 mm/slub.c:2787 kmalloc include/linux/slab.h:515 [inline] kzalloc include/linux/slab.h:709 [inline] hci_chan_create+0x86/0x26d net/bluetooth/hci_conn.c:1674 l2cap_conn_add.part.0+0x1c/0x814 net/bluetooth/l2cap_core.c:7062 l2cap_conn_add net/bluetooth/l2cap_core.c:7059 [inline] l2cap_connect_cfm+0x134/0x852 net/bluetooth/l2cap_core.c:7381 hci_connect_cfm+0x9d/0x122 include/net/bluetooth/hci_core.h:1404 hci_remote_ext_features_evt net/bluetooth/hci_event.c:4161 [inline] hci_event_packet+0x463f/0x72fa net/bluetooth/hci_event.c:5981 hci_rx_work+0x197/0x45e net/bluetooth/hci_core.c:4791 process_one_work+0x6f8/0xb50 kernel/workqueue.c:2175 worker_thread+0x4fc/0x670 kernel/workqueue.c:2321 kthread+0x2f0/0x304 kernel/kthread.c:253 ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:415 Freed by task 1732: set_track mm/kasan/kasan.c:460 [inline] __kasan_slab_free mm/kasan/kasan.c:521 [inline] __kasan_slab_free+0x106/0x128 mm/kasan/kasan.c:493 slab_free_hook mm/slub.c:1409 [inline] slab_free_freelist_hook+0xaa/0xf6 mm/slub.c:1436 slab_free mm/slub.c:3009 [inline] kfree+0x182/0x21e mm/slub.c:3972 hci_disconn_loglink_complete_evt net/bluetooth/hci_event.c:4891 [inline] hci_event_packet+0x6a1c/0x72fa net/bluetooth/hci_event.c:6050 hci_rx_work+0x197/0x45e net/bluetooth/hci_core.c:4791 process_one_work+0x6f8/0xb50 kernel/workqueue.c:2175 worker_thread+0x4fc/0x670 kernel/workqueue.c:2321 kthread+0x2f0/0x304 kernel/kthread.c:253 ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:415 The buggy address belongs to the object at ffff8881d7af9180 which belongs to the cache kmalloc-128 of size 128 The buggy address is located 24 bytes inside of 128-byte region [ffff8881d7af9180, ffff8881d7af9200) The buggy address belongs to the page: page:ffffea00075ebe40 count:1 mapcount:0 mapping:ffff8881da403200 index:0x0 flags: 0x8000000000000200(slab) raw: 8000000000000200 dead000000000100 dead000000000200 ffff8881da403200 raw: 0000000000000000 0000000080150015 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8881d7af9080: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb ffff8881d7af9100: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc >ffff8881d7af9180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8881d7af9200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff8881d7af9280: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc Signed-off-by: Archie Pusaka Reported-by: syzbot+98228e7407314d2d4ba2@syzkaller.appspotmail.com Reviewed-by: Alain Michaud Reviewed-by: Abhishek Pandit-Subedi Signed-off-by: Marcel Holtmann Cc: George Kennedy Signed-off-by: Greg Kroah-Hartman commit d795d7b5846cb98eaa66abeb2b0927499ede2af5 Author: Greg Kroah-Hartman Date: Wed May 12 08:40:05 2021 +0200 Linux 5.12.3 Tested-by: Jon Hunter Reviewed-by: Florian Fainelli Tested-by: Linux Kernel Functional Testing Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Jason Self Tested-by: Shuah Khan Tested-by: Justin M. Forbes Link: https://lore.kernel.org/r/20210510102014.849075526@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit 142703b82c36834a286ce667ce20f714577b8ced Author: Lukasz Luba Date: Thu Apr 22 16:36:22 2021 +0100 thermal/core/fair share: Lock the thermal zone while looping over instances commit fef05776eb02238dcad8d5514e666a42572c3f32 upstream. The tz->lock must be hold during the looping over the instances in that thermal zone. This lock was missing in the governor code since the beginning, so it's hard to point into a particular commit. CC: stable@vger.kernel.org # 4.4+ Signed-off-by: Lukasz Luba Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20210422153624.6074-2-lukasz.luba@arm.com Signed-off-by: Greg Kroah-Hartman commit 6bf443acf6ca4f666d0e4225614ba9993a3aa1a9 Author: brian-sy yang Date: Tue Dec 29 13:08:31 2020 +0800 thermal/drivers/cpufreq_cooling: Fix slab OOB issue commit 34ab17cc6c2c1ac93d7e5d53bb972df9a968f085 upstream. Slab OOB issue is scanned by KASAN in cpu_power_to_freq(). If power is limited below the power of OPP0 in EM table, it will cause slab out-of-bound issue with negative array index. Return the lowest frequency if limited power cannot found a suitable OPP in EM table to fix this issue. Backtrace: [] die+0x104/0x5ac [] bug_handler+0x64/0xd0 [] brk_handler+0x160/0x258 [] do_debug_exception+0x248/0x3f0 [] el1_dbg+0x14/0xbc [] __kasan_report+0x1dc/0x1e0 [] kasan_report+0x10/0x20 [] __asan_report_load8_noabort+0x18/0x28 [] cpufreq_power2state+0x180/0x43c [] power_actor_set_power+0x114/0x1d4 [] allocate_power+0xaec/0xde0 [] power_allocator_throttle+0x3ec/0x5a4 [] handle_thermal_trip+0x160/0x294 [] thermal_zone_device_check+0xe4/0x154 [] process_one_work+0x5e4/0xe28 [] worker_thread+0xa4c/0xfac [] kthread+0x33c/0x358 [] ret_from_fork+0xc/0x18 Fixes: 371a3bc79c11b ("thermal/drivers/cpufreq_cooling: Fix wrong frequency converted from power") Signed-off-by: brian-sy yang Signed-off-by: Michael Kao Reviewed-by: Lukasz Luba Cc: stable@vger.kernel.org #v5.7 Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20201229050831.19493-1-michael.kao@mediatek.com Signed-off-by: Greg Kroah-Hartman commit c23e941b235179d75ca8bd47e810836ee9e07789 Author: Rasmus Villemoes Date: Fri Apr 23 11:45:29 2021 +0200 lib/vsprintf.c: remove leftover 'f' and 'F' cases from bstr_printf() commit 84696cfaf4d90945eb2a8302edc6cf627db56b84 upstream. Commit 9af7706492f9 ("lib/vsprintf: Remove support for %pF and %pf in favour of %pS and %ps") removed support for %pF and %pf, and correctly removed the handling of those cases in vbin_printf(). However, the corresponding cases in bstr_printf() were left behind. In the same series, %pf was re-purposed for dealing with fwnodes (3bd32d6a2ee6, "lib/vsprintf: Add %pfw conversion specifier for printing fwnode names"). So should anyone use %pf with the binary printf routines, vbin_printf() would (correctly, as it involves dereferencing the pointer) do the string formatting to the u32 array, but bstr_printf() would not copy the string from the u32 array, but instead interpret the first sizeof(void*) bytes of the formatted string as a pointer - which generally won't end well (also, all subsequent get_args would be out of sync). Fixes: 9af7706492f9 ("lib/vsprintf: Remove support for %pF and %pf in favour of %pS and %ps") Cc: stable@vger.kernel.org Signed-off-by: Rasmus Villemoes Reviewed-by: Sakari Ailus Signed-off-by: Petr Mladek Link: https://lore.kernel.org/r/20210423094529.1862521-1-linux@rasmusvillemoes.dk Signed-off-by: Greg Kroah-Hartman commit 87bc16ed037b0daf8939d926ef3fa2e1e5ccbdf4 Author: 周琰杰 (Zhou Yanjie) Date: Sun Apr 18 22:44:23 2021 +0800 pinctrl: Ingenic: Add support for read the pin configuration of X1830. commit 1d0bd580ef83b78a10c0b37f3313eaa59d8c80db upstream. Add X1830 support in "ingenic_pinconf_get()", so that it can read the configuration of X1830 SoC correctly. Fixes: d7da2a1e4e08 ("pinctrl: Ingenic: Add pinctrl driver for X1830.") Cc: Signed-off-by: 周琰杰 (Zhou Yanjie) Reviewed-by: Andy Shevchenko Reviewed-by: Paul Cercueil Link: https://lore.kernel.org/r/1618757073-1724-3-git-send-email-zhouyanjie@wanyeetech.com Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit dc1a515ba108d26b0c028afbed4b02239cdae13e Author: 周琰杰 (Zhou Yanjie) Date: Sun Apr 18 22:44:22 2021 +0800 pinctrl: Ingenic: Add missing pins to the JZ4770 MAC MII group. commit 65afd97630a9d6dd9ea83ff182dfdb15bc58c5d1 upstream. The MII group of JZ4770's MAC should have 7 pins, add missing pins to the MII group. Fixes: 5de1a73e78ed ("Pinctrl: Ingenic: Add missing parts for JZ4770 and JZ4780.") Cc: Signed-off-by: 周琰杰 (Zhou Yanjie) Reviewed-by: Andy Shevchenko Reviewed-by: Paul Cercueil Link: https://lore.kernel.org/r/1618757073-1724-2-git-send-email-zhouyanjie@wanyeetech.com Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit d757bf4c69cda3c3ab7f775dfabbf5a80e2f6f9d Author: Benjamin Block Date: Thu Apr 29 23:37:00 2021 +0200 dm rq: fix double free of blk_mq_tag_set in dev remove after table load fails commit 8e947c8f4a5620df77e43c9c75310dc510250166 upstream. When loading a device-mapper table for a request-based mapped device, and the allocation/initialization of the blk_mq_tag_set for the device fails, a following device remove will cause a double free. E.g. (dmesg): device-mapper: core: Cannot initialize queue for request-based dm-mq mapped device device-mapper: ioctl: unable to set up device queue for new table. Unable to handle kernel pointer dereference in virtual kernel address space Failing address: 0305e098835de000 TEID: 0305e098835de803 Fault in home space mode while using kernel ASCE. AS:000000025efe0007 R3:0000000000000024 Oops: 0038 ilc:3 [#1] SMP Modules linked in: ... lots of modules ... Supported: Yes, External CPU: 0 PID: 7348 Comm: multipathd Kdump: loaded Tainted: G W X 5.3.18-53-default #1 SLE15-SP3 Hardware name: IBM 8561 T01 7I2 (LPAR) Krnl PSW : 0704e00180000000 000000025e368eca (kfree+0x42/0x330) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3 Krnl GPRS: 000000000000004a 000000025efe5230 c1773200d779968d 0000000000000000 000000025e520270 000000025e8d1b40 0000000000000003 00000007aae10000 000000025e5202a2 0000000000000001 c1773200d779968d 0305e098835de640 00000007a8170000 000003ff80138650 000000025e5202a2 000003e00396faa8 Krnl Code: 000000025e368eb8: c4180041e100 lgrl %r1,25eba50b8 000000025e368ebe: ecba06b93a55 risbg %r11,%r10,6,185,58 #000000025e368ec4: e3b010000008 ag %r11,0(%r1) >000000025e368eca: e310b0080004 lg %r1,8(%r11) 000000025e368ed0: a7110001 tmll %r1,1 000000025e368ed4: a7740129 brc 7,25e369126 000000025e368ed8: e320b0080004 lg %r2,8(%r11) 000000025e368ede: b904001b lgr %r1,%r11 Call Trace: [<000000025e368eca>] kfree+0x42/0x330 [<000000025e5202a2>] blk_mq_free_tag_set+0x72/0xb8 [<000003ff801316a8>] dm_mq_cleanup_mapped_device+0x38/0x50 [dm_mod] [<000003ff80120082>] free_dev+0x52/0xd0 [dm_mod] [<000003ff801233f0>] __dm_destroy+0x150/0x1d0 [dm_mod] [<000003ff8012bb9a>] dev_remove+0x162/0x1c0 [dm_mod] [<000003ff8012a988>] ctl_ioctl+0x198/0x478 [dm_mod] [<000003ff8012ac8a>] dm_ctl_ioctl+0x22/0x38 [dm_mod] [<000000025e3b11ee>] ksys_ioctl+0xbe/0xe0 [<000000025e3b127a>] __s390x_sys_ioctl+0x2a/0x40 [<000000025e8c15ac>] system_call+0xd8/0x2c8 Last Breaking-Event-Address: [<000000025e52029c>] blk_mq_free_tag_set+0x6c/0xb8 Kernel panic - not syncing: Fatal exception: panic_on_oops When allocation/initialization of the blk_mq_tag_set fails in dm_mq_init_request_queue(), it is uninitialized/freed, but the pointer is not reset to NULL; so when dev_remove() later gets into dm_mq_cleanup_mapped_device() it sees the pointer and tries to uninitialize and free it again. Fix this by setting the pointer to NULL in dm_mq_init_request_queue() error-handling. Also set it to NULL in dm_mq_cleanup_mapped_device(). Cc: # 4.6+ Fixes: 1c357a1e86a4 ("dm: allocate blk_mq_tag_set rather than embed in mapped_device") Signed-off-by: Benjamin Block Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit f2b61e8ba153a0f79eac22ce6e5c6e9af300d44b Author: Tian Tao Date: Wed Apr 14 09:43:44 2021 +0800 dm integrity: fix missing goto in bitmap_flush_interval error handling commit 17e9e134a8efabbbf689a0904eee92bb5a868172 upstream. Fixes: 468dfca38b1a ("dm integrity: add a bitmap mode") Cc: stable@vger.kernel.org Signed-off-by: Tian Tao Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 578f39e1f2b3739c9de900f1ab0301a6b8f57dbc Author: Joe Thornber Date: Tue Apr 13 09:11:53 2021 +0100 dm space map common: fix division bug in sm_ll_find_free_block() commit 5208692e80a1f3c8ce2063a22b675dd5589d1d80 upstream. This division bug meant the search for free metadata space could skip the final allocation bitmap's worth of entries. Fix affects DM thinp, cache and era targets. Cc: stable@vger.kernel.org Signed-off-by: Joe Thornber Tested-by: Ming-Hung Tsai Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 2f97deb8b0da818c04abf89af5f3b2325b9575de Author: Joe Thornber Date: Mon Mar 29 16:34:57 2021 +0100 dm persistent data: packed struct should have an aligned() attribute too commit a88b2358f1da2c9f9fcc432f2e0a79617fea397c upstream. Otherwise most non-x86 architectures (e.g. riscv, arm) will resort to byte-by-byte access. Cc: stable@vger.kernel.org Signed-off-by: Joe Thornber Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 2a1bd74b8186d7938bf004f5603f25b84785f63e Author: Steven Rostedt (VMware) Date: Fri Apr 30 12:17:58 2021 -0400 tracing: Restructure trace_clock_global() to never block commit aafe104aa9096827a429bc1358f8260ee565b7cc upstream. It was reported that a fix to the ring buffer recursion detection would cause a hung machine when performing suspend / resume testing. The following backtrace was extracted from debugging that case: Call Trace: trace_clock_global+0x91/0xa0 __rb_reserve_next+0x237/0x460 ring_buffer_lock_reserve+0x12a/0x3f0 trace_buffer_lock_reserve+0x10/0x50 __trace_graph_return+0x1f/0x80 trace_graph_return+0xb7/0xf0 ? trace_clock_global+0x91/0xa0 ftrace_return_to_handler+0x8b/0xf0 ? pv_hash+0xa0/0xa0 return_to_handler+0x15/0x30 ? ftrace_graph_caller+0xa0/0xa0 ? trace_clock_global+0x91/0xa0 ? __rb_reserve_next+0x237/0x460 ? ring_buffer_lock_reserve+0x12a/0x3f0 ? trace_event_buffer_lock_reserve+0x3c/0x120 ? trace_event_buffer_reserve+0x6b/0xc0 ? trace_event_raw_event_device_pm_callback_start+0x125/0x2d0 ? dpm_run_callback+0x3b/0xc0 ? pm_ops_is_empty+0x50/0x50 ? platform_get_irq_byname_optional+0x90/0x90 ? trace_device_pm_callback_start+0x82/0xd0 ? dpm_run_callback+0x49/0xc0 With the following RIP: RIP: 0010:native_queued_spin_lock_slowpath+0x69/0x200 Since the fix to the recursion detection would allow a single recursion to happen while tracing, this lead to the trace_clock_global() taking a spin lock and then trying to take it again: ring_buffer_lock_reserve() { trace_clock_global() { arch_spin_lock() { queued_spin_lock_slowpath() { /* lock taken */ (something else gets traced by function graph tracer) ring_buffer_lock_reserve() { trace_clock_global() { arch_spin_lock() { queued_spin_lock_slowpath() { /* DEAD LOCK! */ Tracing should *never* block, as it can lead to strange lockups like the above. Restructure the trace_clock_global() code to instead of simply taking a lock to update the recorded "prev_time" simply use it, as two events happening on two different CPUs that calls this at the same time, really doesn't matter which one goes first. Use a trylock to grab the lock for updating the prev_time, and if it fails, simply try again the next time. If it failed to be taken, that means something else is already updating it. Link: https://lkml.kernel.org/r/20210430121758.650b6e8a@gandalf.local.home Cc: stable@vger.kernel.org Tested-by: Konstantin Kharlamov Tested-by: Todd Brandt Fixes: b02414c8f045 ("ring-buffer: Fix recursion protection transitions between interrupt context") # started showing the problem Fixes: 14131f2f98ac3 ("tracing: implement trace_clock_*() APIs") # where the bug happened Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=212761 Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 7bc6bc25a1a80554e9dab1578ef0864a5bcfe552 Author: Steven Rostedt (VMware) Date: Tue Apr 27 11:32:07 2021 -0400 tracing: Map all PIDs to command lines commit 785e3c0a3a870e72dc530856136ab4c8dd207128 upstream. The default max PID is set by PID_MAX_DEFAULT, and the tracing infrastructure uses this number to map PIDs to the comm names of the tasks, such output of the trace can show names from the recorded PIDs in the ring buffer. This mapping is also exported to user space via the "saved_cmdlines" file in the tracefs directory. But currently the mapping expects the PIDs to be less than PID_MAX_DEFAULT, which is the default maximum and not the real maximum. Recently, systemd will increases the maximum value of a PID on the system, and when tasks are traced that have a PID higher than PID_MAX_DEFAULT, its comm is not recorded. This leads to the entire trace to have "<...>" as the comm name, which is pretty useless. Instead, keep the array mapping the size of PID_MAX_DEFAULT, but instead of just mapping the index to the comm, map a mask of the PID (PID_MAX_DEFAULT - 1) to the comm, and find the full PID from the map_cmdline_to_pid array (that already exists). This bug goes back to the beginning of ftrace, but hasn't been an issue until user space started increasing the maximum value of PIDs. Link: https://lkml.kernel.org/r/20210427113207.3c601884@gandalf.local.home Cc: stable@vger.kernel.org Fixes: bc0c38d139ec7 ("ftrace: latency tracer infrastructure") Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 337b1546cde87fb8588ddaedf0201b769baa572a Author: Calvin Walton Date: Wed Apr 28 17:09:16 2021 +0800 tools/power turbostat: Fix offset overflow issue in index converting commit 13a779de4175df602366d129e41782ad7168cef0 upstream. The idx_to_offset() function returns type int (32-bit signed), but MSR_PKG_ENERGY_STAT is u32 and would be interpreted as a negative number. The end result is that it hits the if (offset < 0) check in update_msr_sum() which prevents the timer callback from updating the stat in the background when long durations are used. The similar issue exists in offset_to_idx() and update_msr_sum(). Fix this issue by converting the 'int' to 'off_t' accordingly. Fixes: 9972d5d84d76 ("tools/power turbostat: Enable accumulate RAPL display") Signed-off-by: Calvin Walton Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman commit 0452b0b041884b7268ca8b5e3dd69e72f4b5c123 Author: Marek Vasut Date: Sun Mar 28 00:59:32 2021 +0100 rsi: Use resume_noirq for SDIO commit c434e5e48dc4e626364491455f97e2db0aa137b1 upstream. The rsi_resume() does access the bus to enable interrupts on the RSI SDIO WiFi card, however when calling sdio_claim_host() in the resume path, it is possible the bus is already claimed and sdio_claim_host() spins indefinitelly. Enable the SDIO card interrupts in resume_noirq instead to prevent anything else from claiming the SDIO bus first. Fixes: 20db07332736 ("rsi: sdio suspend and resume support") Signed-off-by: Marek Vasut Cc: Amitkumar Karwar Cc: Angus Ainslie Cc: David S. Miller Cc: Jakub Kicinski Cc: Kalle Valo Cc: Karun Eagalapati Cc: Martin Kepplinger Cc: Sebastian Krzyszkowiak Cc: Siva Rebbagondla Cc: netdev@vger.kernel.org Cc: stable@vger.kernel.org Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210327235932.175896-1-marex@denx.de Signed-off-by: Greg Kroah-Hartman commit a46bbc14f4f0529431e15be9b392a012d562f48a Author: Pavel Skripkin Date: Sun Mar 28 00:44:43 2021 +0300 tty: fix memory leak in vc_deallocate commit 211b4d42b70f1c1660feaa968dac0efc2a96ac4d upstream. syzbot reported memory leak in tty/vt. The problem was in VT_DISALLOCATE ioctl cmd. After allocating unimap with PIO_UNIMAP it wasn't freed via VT_DISALLOCATE, but vc_cons[currcons].d was zeroed. Reported-by: syzbot+bcc922b19ccc64240b42@syzkaller.appspotmail.com Signed-off-by: Pavel Skripkin Cc: stable Link: https://lore.kernel.org/r/20210327214443.21548-1-paskripkin@gmail.com Signed-off-by: Greg Kroah-Hartman commit bb2511e92a5da1e16a9b48bf81fdab99f540dd28 Author: Hou Zhiqiang Date: Tue Apr 13 17:22:19 2021 +0300 PCI: dwc: Move iATU detection earlier commit 8bcca26585585ae4b44d25d30f351ad0afa4976b upstream. dw_pcie_ep_init() depends on the detected iATU region numbers to allocate the in/outbound window management bitmap. It fails after 281f1f99cf3a ("PCI: dwc: Detect number of iATU windows"). Move the iATU region detection into a new function, move the detection to the very beginning of dw_pcie_host_init() and dw_pcie_ep_init(). Also remove it from the dw_pcie_setup(), since it's more like a software initialization step than hardware setup. Link: https://lore.kernel.org/r/20210125044803.4310-1-Zhiqiang.Hou@nxp.com Link: https://lore.kernel.org/linux-pci/20210407131255.702054-1-dmitry.baryshkov@linaro.org Link: https://lore.kernel.org/r/20210413142219.2301430-1-dmitry.baryshkov@linaro.org Fixes: 281f1f99cf3a ("PCI: dwc: Detect number of iATU windows") Tested-by: Kunihiko Hayashi Tested-by: Marek Szyprowski Tested-by: Manivannan Sadhasivam Signed-off-by: Hou Zhiqiang [DB: moved dw_pcie_iatu_detect to happen after host_init callback] Signed-off-by: Dmitry Baryshkov Signed-off-by: Lorenzo Pieralisi Reviewed-by: Rob Herring Cc: stable@vger.kernel.org # v5.11+ Cc: Marek Szyprowski Signed-off-by: Greg Kroah-Hartman commit 07009d765c573e98420648bd52cbb9472f71ea0f Author: Artur Petrosyan Date: Thu Apr 8 13:45:49 2021 +0400 usb: dwc2: Fix session request interrupt handler commit 42b32b164acecd850edef010915a02418345a033 upstream. According to programming guide in host mode, port power must be turned on in session request interrupt handlers. Fixes: 21795c826a45 ("usb: dwc2: exit hibernation on session request") Cc: Acked-by: Minas Harutyunyan Signed-off-by: Artur Petrosyan Link: https://lore.kernel.org/r/20210408094550.75484A0094@mailhost.synopsys.com Signed-off-by: Greg Kroah-Hartman commit 1c10fd60c8595ea7ff7e29d3cf1fa88069941da3 Author: Yu Chen Date: Thu Apr 15 15:20:30 2021 -0700 usb: dwc3: core: Do core softreset when switch mode commit f88359e1588b85cf0e8209ab7d6620085f3441d9 upstream. From: John Stultz According to the programming guide, to switch mode for DRD controller, the driver needs to do the following. To switch from device to host: 1. Reset controller with GCTL.CoreSoftReset 2. Set GCTL.PrtCapDir(host mode) 3. Reset the host with USBCMD.HCRESET 4. Then follow up with the initializing host registers sequence To switch from host to device: 1. Reset controller with GCTL.CoreSoftReset 2. Set GCTL.PrtCapDir(device mode) 3. Reset the device with DCTL.CSftRst 4. Then follow up with the initializing registers sequence Currently we're missing step 1) to do GCTL.CoreSoftReset and step 3) of switching from host to device. John Stult reported a lockup issue seen with HiKey960 platform without these steps[1]. Similar issue is observed with Ferry's testing platform[2]. So, apply the required steps along with some fixes to Yu Chen's and John Stultz's version. The main fixes to their versions are the missing wait for clocks synchronization before clearing GCTL.CoreSoftReset and only apply DCTL.CSftRst when switching from host to device. [1] https://lore.kernel.org/linux-usb/20210108015115.27920-1-john.stultz@linaro.org/ [2] https://lore.kernel.org/linux-usb/0ba7a6ba-e6a7-9cd4-0695-64fc927e01f1@gmail.com/ Fixes: 41ce1456e1db ("usb: dwc3: core: make dwc3_set_mode() work properly") Cc: Andy Shevchenko Cc: Ferry Toth Cc: Wesley Cheng Cc: Tested-by: John Stultz Tested-by: Wesley Cheng Signed-off-by: Yu Chen Signed-off-by: John Stultz Signed-off-by: Thinh Nguyen Link: https://lore.kernel.org/r/374440f8dcd4f06c02c2caf4b1efde86774e02d9.1618521663.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman commit d91827a96d388f57f07efdc66cef64a647db9f8b Author: Thinh Nguyen Date: Mon Apr 19 19:11:12 2021 -0700 usb: dwc3: gadget: Fix START_TRANSFER link state check commit c560e76319a94a3b9285bc426c609903408e4826 upstream. The START_TRANSFER command needs to be executed while in ON/U0 link state (with an exception during register initialization). Don't use dwc->link_state to check this since the driver only tracks the link state when the link state change interrupt is enabled. Check the link state from DSTS register instead. Note that often the host already brings the device out of low power before it sends/requests the next transfer. So, the user won't see any issue when the device starts transfer then. This issue is more noticeable in cases when the device delays starting transfer, which can happen during delayed control status after the host put the device in low power. Fixes: 799e9dc82968 ("usb: dwc3: gadget: conditionally disable Link State change events") Cc: Acked-by: Felipe Balbi Signed-off-by: Thinh Nguyen Link: https://lore.kernel.org/r/bcefaa9ecbc3e1936858c0baa14de6612960e909.1618884221.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit dda85fb8b1134bcb8059d31b7cc0c2ed0ff3ecda Author: Thinh Nguyen Date: Thu Apr 15 00:41:58 2021 -0700 usb: dwc3: gadget: Remove FS bInterval_m1 limitation commit 3232a3ce55edfc0d7f8904543b4088a5339c2b2b upstream. The programming guide incorrectly stated that the DCFG.bInterval_m1 must be set to 0 when operating in fullspeed. There's no such limitation for all IPs. See DWC_usb3x programming guide section 3.2.2.1. Fixes: a1679af85b2a ("usb: dwc3: gadget: Fix setting of DEPCFG.bInterval_m1") Cc: Acked-by: Felipe Balbi Signed-off-by: Thinh Nguyen Link: https://lore.kernel.org/r/5d4139ae89d810eb0a2d8577fb096fc88e87bfab.1618472454.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman commit dfdc7ec6321356342a463f69009b8b54ab854291 Author: Dean Anderson Date: Wed Mar 17 15:41:09 2021 -0700 usb: gadget/function/f_fs string table fix for multiple languages commit 55b74ce7d2ce0b0058f3e08cab185a0afacfe39e upstream. Fixes bug with the handling of more than one language in the string table in f_fs.c. str_count was not reset for subsequent language codes. str_count-- "rolls under" and processes u32 max strings on the processing of the second language entry. The existing bug can be reproduced by adding a second language table to the structure "strings" in tools/usb/ffs-test.c. Signed-off-by: Dean Anderson Link: https://lore.kernel.org/r/20210317224109.21534-1-dean@sensoray.com Cc: stable Signed-off-by: Greg Kroah-Hartman commit d7a096551b86223eb6682d7c83943ebe48ef23da Author: Hemant Kumar Date: Wed Apr 21 12:47:32 2021 -0700 usb: gadget: Fix double free of device descriptor pointers commit 43c4cab006f55b6ca549dd1214e22f5965a8675f upstream. Upon driver unbind usb_free_all_descriptors() function frees all speed descriptor pointers without setting them to NULL. In case gadget speed changes (i.e from super speed plus to super speed) after driver unbind only upto super speed descriptor pointers get populated. Super speed plus desc still holds the stale (already freed) pointer. Fix this issue by setting all descriptor pointers to NULL after freeing them in usb_free_all_descriptors(). Fixes: f5c61225cf29 ("usb: gadget: Update function for SuperSpeedPlus") cc: stable@vger.kernel.org Reviewed-by: Peter Chen Signed-off-by: Hemant Kumar Signed-off-by: Wesley Cheng Link: https://lore.kernel.org/r/1619034452-17334-1-git-send-email-wcheng@codeaurora.org Signed-off-by: Greg Kroah-Hartman commit 3c6f653256879209fdbc0ea082714bbd251bb811 Author: Anirudh Rayabharam Date: Mon Apr 19 09:07:08 2021 +0530 usb: gadget: dummy_hcd: fix gpf in gadget_setup commit 4a5d797a9f9c4f18585544237216d7812686a71f upstream. Fix a general protection fault reported by syzbot due to a race between gadget_setup() and gadget_unbind() in raw_gadget. The gadget core is supposed to guarantee that there won't be any more callbacks to the gadget driver once the driver's unbind routine is called. That guarantee is enforced in usb_gadget_remove_driver as follows: usb_gadget_disconnect(udc->gadget); if (udc->gadget->irq) synchronize_irq(udc->gadget->irq); udc->driver->unbind(udc->gadget); usb_gadget_udc_stop(udc); usb_gadget_disconnect turns off the pullup resistor, telling the host that the gadget is no longer connected and preventing the transmission of any more USB packets. Any packets that have already been received are sure to processed by the UDC driver's interrupt handler by the time synchronize_irq returns. But this doesn't work with dummy_hcd, because dummy_hcd doesn't use interrupts; it uses a timer instead. It does have code to emulate the effect of synchronize_irq, but that code doesn't get invoked at the right time -- it currently runs in usb_gadget_udc_stop, after the unbind callback instead of before. Indeed, there's no way for usb_gadget_remove_driver to invoke this code before the unbind callback. To fix this, move the synchronize_irq() emulation code to dummy_pullup so that it runs before unbind. Also, add a comment explaining why it is necessary to have it there. Reported-by: syzbot+eb4674092e6cc8d9e0bd@syzkaller.appspotmail.com Suggested-by: Alan Stern Acked-by: Alan Stern Signed-off-by: Anirudh Rayabharam Link: https://lore.kernel.org/r/20210419033713.3021-1-mail@anirudhrb.com Cc: stable Signed-off-by: Greg Kroah-Hartman commit c5bddca814e9677c3a609061703480f9bf323e88 Author: Palash Oswal Date: Tue Apr 27 18:21:49 2021 +0530 io_uring: Check current->io_uring in io_uring_cancel_sqpoll commit 6d042ffb598ed83e7d5623cc961d249def5b9829 upstream. syzkaller identified KASAN: null-ptr-deref Write in io_uring_cancel_sqpoll. io_uring_cancel_sqpoll is called by io_sq_thread before calling io_uring_alloc_task_context. This leads to current->io_uring being NULL. io_uring_cancel_sqpoll should not have to deal with threads where current->io_uring is NULL. In order to cast a wider safety net, perform input sanitisation directly in io_uring_cancel_sqpoll and return for NULL value of current->io_uring. This is safe since if current->io_uring isn't set, then there's no way for the task to have submitted any requests. Reported-by: syzbot+be51ca5a4d97f017cd50@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Signed-off-by: Palash Oswal Link: https://lore.kernel.org/r/20210427125148.21816-1-hello@oswalpalash.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit cabc762764cce781d6bb9cb202c997c2254db9cd Author: Pavel Begunkov Date: Sun Apr 25 23:34:45 2021 +0100 io_uring: fix work_exit sqpoll cancellations commit 28090c133869b461c5366195a856d73469ab87d9 upstream. After closing an SQPOLL ring, io_ring_exit_work() kicks in and starts doing cancellations via io_uring_try_cancel_requests(). It will go through io_uring_try_cancel_iowq(), which uses ctx->tctx_list, but as SQPOLL task don't have a ctx note, its io-wq won't be reachable and so is left not cancelled. It will eventually cancelled when one of the tasks dies, but if a thread group survives for long and changes rings, it will spawn lots of unreclaimed resources and live locked works. Cancel SQPOLL task's io-wq separately in io_ring_exit_work(). Cc: stable@vger.kernel.org Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/r/a71a7fe345135d684025bb529d5cb1d8d6b46e10.1619389911.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit cb5e0b3d0f993a6268c1a2c7ede2f9aa0c17ef68 Author: Pavel Begunkov Date: Sun Apr 18 14:52:09 2021 +0100 io_uring: fix shared sqpoll cancellation hangs commit 734551df6f9bedfbefcd113ede665945e9de0b99 upstream. [ 736.982891] INFO: task iou-sqp-4294:4295 blocked for more than 122 seconds. [ 736.982897] Call Trace: [ 736.982901] schedule+0x68/0xe0 [ 736.982903] io_uring_cancel_sqpoll+0xdb/0x110 [ 736.982908] io_sqpoll_cancel_cb+0x24/0x30 [ 736.982911] io_run_task_work_head+0x28/0x50 [ 736.982913] io_sq_thread+0x4e3/0x720 We call io_uring_cancel_sqpoll() one by one for each ctx either in sq_thread() itself or via task works, and it's intended to cancel all requests of a specified context. However the function uses per-task counters to track the number of inflight requests, so it counts more requests than available via currect io_uring ctx and goes to sleep for them to appear (e.g. from IRQ), that will never happen. Cancel a bit more than before, i.e. all ctxs that share sqpoll and continue to use shared counters. Don't forget that we should not remove ctx from the list before running that task_work sqpoll-cancel, otherwise the function wouldn't be able to find the context and will hang. Reported-by: Joakim Hassila Reported-by: Jens Axboe Fixes: 37d1e2e3642e2 ("io_uring: move SQPOLL thread io-wq forked worker") Cc: stable@vger.kernel.org Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/r/1bded7e6c6b32e0bae25fce36be2868e46b116a0.1618752958.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 949938b5d3713831c49ada46d568e78e227bfa3e Author: Pavel Begunkov Date: Sun Apr 18 14:52:08 2021 +0100 io_uring: remove extra sqpoll submission halting commit 3b763ba1c77da5806e4fdc5684285814fe970c98 upstream. SQPOLL task won't submit requests for a context that is currently dying, so no need to remove ctx from sqd_list prior the main loop of io_ring_exit_work(). Kill it, will be removed by io_sq_thread_finish() and only brings confusion and lockups. Cc: stable@vger.kernel.org Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/r/f220c2b786ba0f9499bebc9f3cd9714d29efb6a5.1618752958.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit b60741f40668693e9c1c6cf7c6f93efa6c4d59fe Author: Stanimir Varbanov Date: Sun Mar 7 12:17:27 2021 +0100 media: venus: hfi_parser: Check for instance after hfi platform get commit 9b5d8fd580caa898c6e1b8605c774f2517f786ab upstream. The inst function argument is != NULL only for Venus v1 and we did not migrate v1 to a hfi_platform abstraction yet. So check for instance != NULL only after hfi_platform_get returns no error. Fixes: e29929266be1 ("media: venus: Get codecs and capabilities from hfi platform") Cc: stable@vger.kernel.org # v5.12 Signed-off-by: Stanimir Varbanov Tested-by: Bryan O'Donoghue Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit dbe610d5d415692487be847f3c7b9b76a635e808 Author: Stanimir Varbanov Date: Sun Mar 7 12:16:03 2021 +0100 media: venus: hfi_parser: Don't initialize parser on v1 commit 834124c596e2dddbbdba06620835710ccca32fd0 upstream. The Venus v1 behaves differently comparing with the other Venus version in respect to capability parsing and when they are send to the driver. So we don't need to initialize hfi parser for multiple invocations like what we do for > v1 Venus versions. Fixes: 10865c98986b ("media: venus: parser: Prepare parser for multiple invocations") Cc: stable@vger.kernel.org # v5.10+ Signed-off-by: Stanimir Varbanov Tested-by: Bryan O'Donoghue Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit bdb64c3da67f8dbcb2c8f15bd3323f7a791694a6 Author: Stanimir Varbanov Date: Sat Mar 6 13:16:41 2021 +0100 media: venus: hfi_cmds: Support plane-actual-info property from v1 commit 15447d18b1b877d9c6f979bd00088e470a4e0e9f upstream. The property is supported from v1 and upwards. So move it to set_property_1x. Fixes: 01e869e78756 ("media: venus: venc: fix handlig of S_SELECTION and G_SELECTION") Cc: stable@vger.kernel.org # v5.12 Signed-off-by: Stanimir Varbanov Tested-by: Bryan O'Donoghue Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 63697f519be40d8a859655a6fd2505a79036cd92 Author: Stanimir Varbanov Date: Sat Mar 6 13:13:46 2021 +0100 media: venus: venc_ctrls: Change default header mode commit 39a6b9185d305d236bff625509ee63801b50301b upstream. It is observed that on Venus v1 the default header-mode is producing a bitstream which is not playble. Change the default header-mode to joined with 1st frame. Fixes: 002c22bd360e ("media: venus: venc: set inband mode property to FW.") Cc: stable@vger.kernel.org # v5.12 Signed-off-by: Stanimir Varbanov Tested-by: Bryan O'Donoghue Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit fc437f92ebb7f63b196f73f7afbde21c36cd4b1f Author: Stanimir Varbanov Date: Thu Feb 25 15:28:57 2021 +0100 media: venus: pm_helpers: Set opp clock name for v1 commit 3215887167af7db9af9fa23d61321ebfbd6ed6d3 upstream. The rate of the core clock is set through devm_pm_opp_set_rate and to avoid errors from it we have to set the name of the clock via dev_pm_opp_set_clkname. Fixes: 9a538b83612c ("media: venus: core: Add support for opp tables/perf voting") Cc: stable@vger.kernel.org # v5.10+ Signed-off-by: Stanimir Varbanov Tested-by: Bryan O'Donoghue Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 259f7f0fabc3e1a362332f3468d75742da839450 Author: Marco Felsch Date: Fri Mar 5 09:23:54 2021 +0100 media: coda: fix macroblocks count control usage commit 0b276e470a4d43e1365d3eb53c608a3d208cabd4 upstream. Commit b2d3bef1aa78 ("media: coda: Add a V4L2 user for control error macroblocks count") add the control for the decoder devices. But during streamon() this ioctl gets called for all (encoder and decoder) devices and on encoder devices this causes a null pointer exception. Fix this by setting the control only if it is really accessible. Fixes: b2d3bef1aa78 ("media: coda: Add a V4L2 user for control error macroblocks count") Signed-off-by: Marco Felsch Cc: Reviewed-by: Philipp Zabel Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 78cc3a571850c26df20ca5786a8bea75f984140a Author: Hans Verkuil Date: Mon Apr 12 13:51:23 2021 +0200 media: v4l2-ctrls: fix reference to freed memory commit ac34b79da14d67a9b494f6125186becbd067e225 upstream. When controls are used together with the Request API, then for each request a v4l2_ctrl_handler struct is allocated. This contains the controls that can be set in a request. If a control is *not* set in the request, then the value used in the most recent previous request must be used, or the current value if it is not found in any outstanding requests. The framework tried to find such a previous request and it would set the 'req' pointer in struct v4l2_ctrl_ref to the v4l2_ctrl_ref of the control in such a previous request. So far, so good. However, when that previous request was applied to the hardware, returned to userspace, and then userspace would re-init or free that request, any 'ref' pointer in still-queued requests would suddenly point to freed memory. This was not noticed before since the drivers that use this expected that each request would always have the controls set, so there was never any need to find a control in older requests. This requirement was relaxed, and now this bug surfaced. It was also made worse by changeset 2fae4d6aabc8 ("media: v4l2-ctrls: v4l2_ctrl_request_complete() should always set ref->req") which increased the chance of this happening. The use of the 'req' pointer in v4l2_ctrl_ref was very fragile, so drop this entirely. Instead add a valid_p_req bool to indicate that p_req contains a valid value for this control. And if it is false, then just use the current value of the control. Note that VIDIOC_G_EXT_CTRLS will always return -EACCES when attempting to get a control from a request until the request is completed. And in that case, all controls in the request will have the control value set (i.e. valid_p_req is true). This means that the whole 'find the most recent previous request containing a control' idea is pointless, and the code can be simplified considerably. The v4l2_g_ext_ctrls_common() function was refactored a bit to make it more understandable. It also avoids updating volatile controls in a completed request since that was already done when the request was completed. Signed-off-by: Hans Verkuil Fixes: 2fae4d6aabc8 ("media: v4l2-ctrls: v4l2_ctrl_request_complete() should always set ref->req") Fixes: 6fa6f831f095 ("media: v4l2-ctrls: add core request support") Cc: # for v5.9 and up Tested-by: Alexandre Courbot Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit cdaf358483b350c7c02719e44787149c20a1dc07 Author: Ricardo Ribalda Date: Fri Apr 9 10:41:35 2021 +0200 media: staging/intel-ipu3: Fix race condition during set_fmt commit dccfe2548746ca9cca3a20401ece4cf255d1f171 upstream. Do not modify imgu_pipe->nodes[inode].vdev_fmt.fmt.pix_mp, until the format has been correctly validated. Otherwise, even if we use a backup variable, there is a period of time where imgu_pipe->nodes[inode].vdev_fmt.fmt.pix_mp might have an invalid value that can be used by other functions. Cc: stable@vger.kernel.org Fixes: ad91849996f9 ("media: staging/intel-ipu3: Fix set_fmt error handling") Reviewed-by: Tomasz Figa Signed-off-by: Ricardo Ribalda Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 6fb617e37a39db0a3eca4489431359d0bdf3b9bc Author: Ricardo Ribalda Date: Wed Mar 10 01:16:46 2021 +0100 media: staging/intel-ipu3: Fix set_fmt error handling commit ad91849996f9dd79741a961fd03585a683b08356 upstream. If there in an error during a set_fmt, do not overwrite the previous sizes with the invalid config. Without this patch, v4l2-compliance ends up allocating 4GiB of RAM and causing the following OOPs [ 38.662975] ipu3-imgu 0000:00:05.0: swiotlb buffer is full (sz: 4096 bytes) [ 38.662980] DMA: Out of SW-IOMMU space for 4096 bytes at device 0000:00:05.0 [ 38.663010] general protection fault: 0000 [#1] PREEMPT SMP Cc: stable@vger.kernel.org Fixes: 6d5f26f2e045 ("media: staging/intel-ipu3-v4l: reduce kernel stack usage") Signed-off-by: Ricardo Ribalda Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 74ba0adb5e983503b18a96121d965cad34ac7ce3 Author: Ricardo Ribalda Date: Mon Mar 15 13:34:05 2021 +0100 media: staging/intel-ipu3: Fix memory leak in imu_fmt commit 3630901933afba1d16c462b04d569b7576339223 upstream. We are losing the reference to an allocated memory if try. Change the order of the check to avoid that. Cc: stable@vger.kernel.org Fixes: 6d5f26f2e045 ("media: staging/intel-ipu3-v4l: reduce kernel stack usage") Signed-off-by: Ricardo Ribalda Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit e046910804f6099dc12fbaca097418062f742cd0 Author: Takashi Iwai Date: Mon Feb 1 09:32:46 2021 +0100 media: dvb-usb: Fix memory leak at error in dvb_usb_device_init() commit 13a79f14ab285120bc4977e00a7c731e8143f548 upstream. dvb_usb_device_init() allocates a dvb_usb_device object, but it doesn't release the object by itself even at errors. The object is released in the callee side (dvb_usb_init()) in some error cases via dvb_usb_exit() call, but it also missed the object free in other error paths. And, the caller (it's only dvb_usb_device_init()) doesn't seem caring the resource management as well, hence those memories are leaked. This patch assures releasing the memory at the error path in dvb_usb_device_init(). Now dvb_usb_init() frees the resources it allocated but leaves the passed dvb_usb_device object intact. In turn, the dvb_usb_device object is released in dvb_usb_device_init() instead. We could use dvb_usb_exit() function for releasing everything in the callee (as it was used for some error cases in the original code), but releasing the passed object in the callee is non-intuitive and error-prone. So I took this approach (which is more standard in Linus kernel code) although it ended with a bit more open codes. Along with the change, the patch makes sure that USB intfdata is reset and don't return the bogus pointer to the caller of dvb_usb_device_init() at the error path, too. Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 2aabd8da8f0d4bed272a29f789d7fd2625bd91dd Author: Takashi Iwai Date: Mon Feb 1 09:32:47 2021 +0100 media: dvb-usb: Fix use-after-free access commit c49206786ee252f28b7d4d155d1fff96f145a05d upstream. dvb_usb_device_init() copies the properties to the own data, so that the callers can release the original properties later (as done in the commit 299c7007e936 ("media: dw2102: Fix memleak on sequence of probes")). However, it also stores dev->desc pointer that is a reference to the original properties data. Since dev->desc is referred later, it may result in use-after-free, in the worst case, leading to a kernel Oops as reported. This patch addresses the problem by allocating and copying the properties at first, then get the desc from the copied properties. Reported-and-tested-by: Stefan Seyfried BugLink: http://bugzilla.opensuse.org/show_bug.cgi?id=1181104 Reviewed-by: Robert Foss Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit cede24d13be6c2a62be6d7ceea63c2719b0cfa82 Author: Peilin Ye Date: Fri Dec 11 09:30:39 2020 +0100 media: dvbdev: Fix memory leak in dvb_media_device_free() commit bf9a40ae8d722f281a2721779595d6df1c33a0bf upstream. dvb_media_device_free() is leaking memory. Free `dvbdev->adapter->conn` before setting it to NULL, as documented in include/media/media-device.h: "The media_entity instance itself must be freed explicitly by the driver if required." Link: https://syzkaller.appspot.com/bug?id=9bbe4b842c98f0ed05c5eed77a226e9de33bf298 Link: https://lore.kernel.org/linux-media/20201211083039.521617-1-yepeilin.cs@gmail.com Cc: stable@vger.kernel.org Fixes: 0230d60e4661 ("[media] dvbdev: Add RF connector if needed") Reported-by: syzbot+7f09440acc069a0d38ac@syzkaller.appspotmail.com Signed-off-by: Peilin Ye Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit a1d50db9020fbdfa5fce29945e50739394069c43 Author: Jan Kara Date: Thu Apr 15 17:54:17 2021 +0200 ext4: Fix occasional generic/418 failure commit 5899593f51e63dde2f07c67358bd65a641585abb upstream. Eric has noticed that after pagecache read rework, generic/418 is occasionally failing for ext4 when blocksize < pagesize. In fact, the pagecache rework just made hard to hit race in ext4 more likely. The problem is that since ext4 conversion of direct IO writes to iomap framework (commit 378f32bab371), we update inode size after direct IO write only after invalidating page cache. Thus if buffered read sneaks at unfortunate moment like: CPU1 - write at offset 1k CPU2 - read from offset 0 iomap_dio_rw(..., IOMAP_DIO_FORCE_WAIT); ext4_readpage(); ext4_handle_inode_extension() the read will zero out tail of the page as it still sees smaller inode size and thus page cache becomes inconsistent with on-disk contents with all the consequences. Fix the problem by moving inode size update into end_io handler which gets called before the page cache is invalidated. Reported-and-tested-by: Eric Whitney Fixes: 378f32bab371 ("ext4: introduce direct I/O write using iomap infrastructure") CC: stable@vger.kernel.org Signed-off-by: Jan Kara Acked-by: Dave Chinner Link: https://lore.kernel.org/r/20210415155417.4734-1-jack@suse.cz Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 16e4d107b5d73a2f487a2e92221cc38f4c8369ea Author: Theodore Ts'o Date: Mon Apr 12 17:19:00 2021 -0400 ext4: allow the dax flag to be set and cleared on inline directories commit 4811d9929cdae4238baf5b2522247bd2f9fa7b50 upstream. This is needed to allow generic/607 to pass for file systems with the inline data_feature enabled, and it allows the use of file systems where the directories use inline_data, while the files are accessed via DAX. Cc: stable@kernel.org Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit c9d79b206f74a4783f5562174c5479e6631cea38 Author: Xu Yihang Date: Thu Apr 8 15:00:33 2021 +0800 ext4: fix error return code in ext4_fc_perform_commit() commit e1262cd2e68a0870fb9fc95eb202d22e8f0074b7 upstream. In case of if not ext4_fc_add_tlv branch, an error return code is missing. Cc: stable@kernel.org Fixes: aa75f4d3daae ("ext4: main fast-commit commit path") Reported-by: Hulk Robot Signed-off-by: Xu Yihang Reviewed-by: Harshad Shirwadkar Link: https://lore.kernel.org/r/20210408070033.123047-1-xuyihang@huawei.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 5a611ecc0df71e966af07d1c84b402587ada2420 Author: Ye Bin Date: Tue Apr 6 10:53:31 2021 +0800 ext4: fix ext4_error_err save negative errno into superblock commit 6810fad956df9e5467e8e8a5ac66fda0836c71fa upstream. Fix As write_mmp_block() so that it returns -EIO instead of 1, so that the correct error gets saved into the superblock. Cc: stable@kernel.org Fixes: 54d3adbc29f0 ("ext4: save all error info in save_error_info() and drop ext4_set_errno()") Reported-by: Liu Zhi Qiang Signed-off-by: Ye Bin Reviewed-by: Andreas Dilger Link: https://lore.kernel.org/r/20210406025331.148343-1-yebin10@huawei.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit f61f62d574c29b327da8f0b4e90a373f7593a98c Author: Fengnan Chang Date: Fri Apr 2 18:16:31 2021 +0800 ext4: fix error code in ext4_commit_super commit f88f1466e2a2e5ca17dfada436d3efa1b03a3972 upstream. We should set the error code when ext4_commit_super check argument failed. Found in code review. Fixes: c4be0c1dc4cdc ("filesystem freeze: add error handling of write_super_lockfs/unlockfs"). Cc: stable@kernel.org Signed-off-by: Fengnan Chang Reviewed-by: Andreas Dilger Link: https://lore.kernel.org/r/20210402101631.561-1-changfengnan@vivo.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 1e9ea8f4637026b8e965128953f2da061ccae9c4 Author: Ye Bin Date: Thu Apr 1 16:19:03 2021 +0800 ext4: always panic when errors=panic is specified commit ac2f7ca51b0929461ea49918f27c11b680f28995 upstream. Before commit 014c9caa29d3 ("ext4: make ext4_abort() use __ext4_error()"), the following series of commands would trigger a panic: 1. mount /dev/sda -o ro,errors=panic test 2. mount /dev/sda -o remount,abort test After commit 014c9caa29d3, remounting a file system using the test mount option "abort" will no longer trigger a panic. This commit will restore the behaviour immediately before commit 014c9caa29d3. (However, note that the Linux kernel's behavior has not been consistent; some previous kernel versions, including 5.4 and 4.19 similarly did not panic after using the mount option "abort".) This also makes a change to long-standing behaviour; namely, the following series commands will now cause a panic, when previously it did not: 1. mount /dev/sda -o ro,errors=panic test 2. echo test > /sys/fs/ext4/sda/trigger_fs_error However, this makes ext4's behaviour much more consistent, so this is a good thing. Cc: stable@kernel.org Fixes: 014c9caa29d3 ("ext4: make ext4_abort() use __ext4_error()") Signed-off-by: Ye Bin Link: https://lore.kernel.org/r/20210401081903.3421208-1-yebin10@huawei.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit b64a3fb6ea0274483d66daac9d0cd4f3d2c8fbbc Author: Zhang Yi Date: Wed Mar 31 11:31:38 2021 +0800 ext4: do not set SB_ACTIVE in ext4_orphan_cleanup() commit 72ffb49a7b623c92a37657eda7cc46a06d3e8398 upstream. When CONFIG_QUOTA is enabled, if we failed to mount the filesystem due to some error happens behind ext4_orphan_cleanup(), it will end up triggering a after free issue of super_block. The problem is that ext4_orphan_cleanup() will set SB_ACTIVE flag if CONFIG_QUOTA is enabled, after we cleanup the truncated inodes, the last iput() will put them into the lru list, and these inodes' pages may probably dirty and will be write back by the writeback thread, so it could be raced by freeing super_block in the error path of mount_bdev(). After check the setting of SB_ACTIVE flag in ext4_orphan_cleanup(), it was used to ensure updating the quota file properly, but evict inode and trash data immediately in the last iput does not affect the quotafile, so setting the SB_ACTIVE flag seems not required[1]. Fix this issue by just remove the SB_ACTIVE setting. [1] https://lore.kernel.org/linux-ext4/99cce8ca-e4a0-7301-840f-2ace67c551f3@huawei.com/T/#m04990cfbc4f44592421736b504afcc346b2a7c00 Cc: stable@kernel.org Signed-off-by: Zhang Yi Tested-by: Jan Kara Reviewed-by: Jan Kara Link: https://lore.kernel.org/r/20210331033138.918975-1-yi.zhang@huawei.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit e18d76a12b34791bc0318a0e0c0fa5863cd8dabf Author: Zhang Yi Date: Wed Mar 31 20:15:16 2021 +0800 ext4: fix check to prevent false positive report of incorrect used inodes commit a149d2a5cabbf6507a7832a1c4fd2593c55fd450 upstream. Commit <50122847007> ("ext4: fix check to prevent initializing reserved inodes") check the block group zero and prevent initializing reserved inodes. But in some special cases, the reserved inode may not all belong to the group zero, it may exist into the second group if we format filesystem below. mkfs.ext4 -b 4096 -g 8192 -N 1024 -I 4096 /dev/sda So, it will end up triggering a false positive report of a corrupted file system. This patch fix it by avoid check reserved inodes if no free inode blocks will be zeroed. Cc: stable@kernel.org Fixes: 50122847007 ("ext4: fix check to prevent initializing reserved inodes") Signed-off-by: Zhang Yi Suggested-by: Jan Kara Link: https://lore.kernel.org/r/20210331121516.2243099-1-yi.zhang@huawei.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 222c345267b57a4023c418b61bb76628a3584994 Author: Jan Kara Date: Tue Apr 6 18:18:00 2021 +0200 ext4: annotate data race in jbd2_journal_dirty_metadata() commit 83fe6b18b8d04c6c849379005e1679bac9752466 upstream. Assertion checks in jbd2_journal_dirty_metadata() are known to be racy but we don't want to be grabbing locks just for them. We thus recheck them under b_state_lock only if it looks like they would fail. Annotate the checks with data_race(). Cc: stable@kernel.org Reported-by: Hao Sun Signed-off-by: Jan Kara Link: https://lore.kernel.org/r/20210406161804.20150-2-jack@suse.cz Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit cfc9b6d1521c5e6623c5c0d43e77d4b3cde42da4 Author: Jan Kara Date: Tue Apr 6 18:17:59 2021 +0200 ext4: annotate data race in start_this_handle() commit 3b1833e92baba135923af4a07e73fe6e54be5a2f upstream. Access to journal->j_running_transaction is not protected by appropriate lock and thus is racy. We are well aware of that and the code handles the race properly. Just add a comment and data_race() annotation. Cc: stable@kernel.org Reported-by: syzbot+30774a6acf6a2cf6d535@syzkaller.appspotmail.com Signed-off-by: Jan Kara Link: https://lore.kernel.org/r/20210406161804.20150-1-jack@suse.cz Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 8cb6d877b0b2fb11739f6e8f0122d2d1011e10f6 Author: Masahiro Yamada Date: Sun Apr 25 15:24:07 2021 +0900 kbuild: update config_data.gz only when the content of .config is changed commit 46b41d5dd8019b264717978c39c43313a524d033 upstream. If the timestamp of the .config file is updated, config_data.gz is regenerated, then vmlinux is re-linked. This occurs even if the content of the .config has not changed at all. This issue was mitigated by commit 67424f61f813 ("kconfig: do not write .config if the content is the same"); Kconfig does not update the .config when it ends up with the identical configuration. The issue is remaining when the .config is created by *_defconfig with some config fragment(s) applied on top. This is typical for powerpc and mips, where several *_defconfig targets are constructed by using merge_config.sh. One workaround is to have the copy of the .config. The filechk rule updates the copy, kernel/config_data, by checking the content instead of the timestamp. With this commit, the second run with the same configuration avoids the needless rebuilds. $ make ARCH=mips defconfig all [ snip ] $ make ARCH=mips defconfig all *** Default configuration is based on target '32r2el_defconfig' Using ./arch/mips/configs/generic_defconfig as base Merging arch/mips/configs/generic/32r2.config Merging arch/mips/configs/generic/el.config Merging ./arch/mips/configs/generic/board-boston.config Merging ./arch/mips/configs/generic/board-ni169445.config Merging ./arch/mips/configs/generic/board-ocelot.config Merging ./arch/mips/configs/generic/board-ranchu.config Merging ./arch/mips/configs/generic/board-sead-3.config Merging ./arch/mips/configs/generic/board-xilfpga.config # # configuration written to .config # SYNC include/config/auto.conf CALL scripts/checksyscalls.sh CALL scripts/atomic/check-atomics.sh CHK include/generated/compile.h CHK include/generated/autoksyms.h Reported-by: Elliot Berman Signed-off-by: Masahiro Yamada Signed-off-by: Greg Kroah-Hartman commit 0fc0b094a4de022549c6089cd891305133bf9eff Author: Sean Christopherson Date: Tue May 4 15:56:31 2021 -0700 x86/cpu: Initialize MSR_TSC_AUX if RDTSCP *or* RDPID is supported commit b6b4fbd90b155a0025223df2c137af8a701d53b3 upstream. Initialize MSR_TSC_AUX with CPU node information if RDTSCP or RDPID is supported. This fixes a bug where vdso_read_cpunode() will read garbage via RDPID if RDPID is supported but RDTSCP is not. While no known CPU supports RDPID but not RDTSCP, both Intel's SDM and AMD's APM allow for RDPID to exist without RDTSCP, e.g. it's technically a legal CPU model for a virtual machine. Note, technically MSR_TSC_AUX could be initialized if and only if RDPID is supported since RDTSCP is currently not used to retrieve the CPU node. But, the cost of the superfluous WRMSR is negigible, whereas leaving MSR_TSC_AUX uninitialized is just asking for future breakage if someone decides to utilize RDTSCP. Fixes: a582c540ac1b ("x86/vdso: Use RDPID in preference to LSL when available") Signed-off-by: Sean Christopherson Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210504225632.1532621-2-seanjc@google.com Signed-off-by: Greg Kroah-Hartman commit 13b5638e78d81e78c1cb1da72cdd00aaba88a2a8 Author: Thomas Gleixner Date: Thu Apr 22 21:44:19 2021 +0200 futex: Do not apply time namespace adjustment on FUTEX_LOCK_PI commit cdf78db4070967869e4d027c11f4dd825d8f815a upstream. FUTEX_LOCK_PI does not require to have the FUTEX_CLOCK_REALTIME bit set because it has been using CLOCK_REALTIME based absolute timeouts forever. Due to that, the time namespace adjustment which is applied when FUTEX_CLOCK_REALTIME is not set, will wrongly take place for FUTEX_LOCK_PI and wreckage the timeout. Exclude it from that procedure. Fixes: c2f7d08cccf4 ("futex: Adjust absolute futex timeouts with per time namespace offset") Signed-off-by: Thomas Gleixner Acked-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210422194704.984540159@linutronix.de Signed-off-by: Greg Kroah-Hartman commit 600de799010689ad8d16f7b1932ca718809f0719 Author: Thomas Gleixner Date: Thu Apr 22 21:44:18 2021 +0200 Revert 337f13046ff0 ("futex: Allow FUTEX_CLOCK_REALTIME with FUTEX_WAIT op") commit 4fbf5d6837bf81fd7a27d771358f4ee6c4f243f8 upstream. The FUTEX_WAIT operand has historically a relative timeout which means that the clock id is irrelevant as relative timeouts on CLOCK_REALTIME are not subject to wall clock changes and therefore are mapped by the kernel to CLOCK_MONOTONIC for simplicity. If a caller would set FUTEX_CLOCK_REALTIME for FUTEX_WAIT the timeout is still treated relative vs. CLOCK_MONOTONIC and then the wait arms that timeout based on CLOCK_REALTIME which is broken and obviously has never been used or even tested. Reject any attempt to use FUTEX_CLOCK_REALTIME with FUTEX_WAIT again. The desired functionality can be achieved with FUTEX_WAIT_BITSET and a FUTEX_BITSET_MATCH_ANY argument. Fixes: 337f13046ff0 ("futex: Allow FUTEX_CLOCK_REALTIME with FUTEX_WAIT op") Signed-off-by: Thomas Gleixner Acked-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210422194704.834797921@linutronix.de Signed-off-by: Greg Kroah-Hartman commit 1ca4f55a7e8ae1bade645ecd958f68c45741abad Author: Steve French Date: Fri May 7 20:00:41 2021 -0500 smb3: do not attempt multichannel to server which does not support it commit 9c2dc11df50d1c8537075ff6b98472198e24438e upstream. We were ignoring CAP_MULTI_CHANNEL in the server response - if the server doesn't support multichannel we should not be attempting it. See MS-SMB2 section 3.2.5.2 Reviewed-by: Shyam Prasad N Reviewed-By: Tom Talpey Cc: # v5.8+ Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 0470ef330390bdffb1cf75179af5d610db5a7daa Author: Steve French Date: Fri May 7 19:33:51 2021 -0500 smb3: if max_channels set to more than one channel request multichannel commit c1f8a398b6d661b594556a91224b096d92293061 upstream. Mounting with "multichannel" is obviously implied if user requested more than one channel on mount (ie mount parm max_channels>1). Currently both have to be specified. Fix that so that if max_channels is greater than 1 on mount, enable multichannel rather than silently falling back to non-multichannel. Signed-off-by: Steve French Reviewed-By: Tom Talpey Cc: # v5.11+ Reviewed-by: Shyam Prasad N Signed-off-by: Greg Kroah-Hartman commit 524fc5482ffb17a80d92a1c2f2a2be1f23a5d44b Author: Steve French Date: Fri May 7 18:24:11 2021 -0500 smb3: when mounting with multichannel include it in requested capabilities commit 679971e7213174efb56abc8fab1299d0a88db0e8 upstream. In the SMB3/SMB3.1.1 negotiate protocol request, we are supposed to advertise CAP_MULTICHANNEL capability when establishing multiple channels has been requested by the user doing the mount. See MS-SMB2 sections 2.2.3 and 3.2.5.2 Without setting it there is some risk that multichannel could fail if the server interpreted the field strictly. Reviewed-By: Tom Talpey Reviewed-by: Shyam Prasad N Cc: # v5.8+ Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 2831dd51bec25d5b8a499a8e8e15de6237771a80 Author: Linus Torvalds Date: Tue Apr 27 17:05:53 2021 -0700 Fix misc new gcc warnings commit e7c6e405e171fb33990a12ecfd14e6500d9e5cf2 upstream. It seems like Fedora 34 ends up enabling a few new gcc warnings, notably "-Wstringop-overread" and "-Warray-parameter". Both of them cause what seem to be valid warnings in the kernel, where we have array size mismatches in function arguments (that are no longer just silently converted to a pointer to element, but actually checked). This fixes most of the trivial ones, by making the function declaration match the function definition, and in the case of intel_pm.c, removing the over-specified array size from the argument declaration. At least one 'stringop-overread' warning remains in the i915 driver, but that one doesn't have the same obvious trivial fix, and may or may not actually be indicative of a bug. [ It was a mistake to upgrade one of my machines to Fedora 34 while being busy with the merge window, but if this is the extent of the compiler upgrade problems, things are better than usual - Linus ] Signed-off-by: Linus Torvalds Cc: Andrey Zhizhikin Signed-off-by: Greg Kroah-Hartman commit 3cc63b1c6e7a2f2cbf2af5f9f200f9739ac0b88c Author: Arnd Bergmann Date: Mon Mar 22 17:02:41 2021 +0100 security: commoncap: fix -Wstringop-overread warning commit 82e5d8cc768b0c7b03c551a9ab1f8f3f68d5f83f upstream. gcc-11 introdces a harmless warning for cap_inode_getsecurity: security/commoncap.c: In function ‘cap_inode_getsecurity’: security/commoncap.c:440:33: error: ‘memcpy’ reading 16 bytes from a region of size 0 [-Werror=stringop-overread] 440 | memcpy(&nscap->data, &cap->data, sizeof(__le32) * 2 * VFS_CAP_U32); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The problem here is that tmpbuf is initialized to NULL, so gcc assumes it is not accessible unless it gets set by vfs_getxattr_alloc(). This is a legitimate warning as far as I can tell, but the code is correct since it correctly handles the error when that function fails. Add a separate NULL check to tell gcc about it as well. Signed-off-by: Arnd Bergmann Acked-by: Christian Brauner Signed-off-by: James Morris Cc: Andrey Zhizhikin Signed-off-by: Greg Kroah-Hartman commit deaaae2f918c9fc97a1418457616c9a8d2021890 Author: Frederic Weisbecker Date: Tue Feb 23 01:09:59 2021 +0100 rcu/nocb: Fix missed nocb_timer requeue commit b2fcf2102049f6e56981e0ab3d9b633b8e2741da upstream. This sequence of events can lead to a failure to requeue a CPU's ->nocb_timer: 1. There are no callbacks queued for any CPU covered by CPU 0-2's ->nocb_gp_kthread. Note that ->nocb_gp_kthread is associated with CPU 0. 2. CPU 1 enqueues its first callback with interrupts disabled, and thus must defer awakening its ->nocb_gp_kthread. It therefore queues its rcu_data structure's ->nocb_timer. At this point, CPU 1's rdp->nocb_defer_wakeup is RCU_NOCB_WAKE. 3. CPU 2, which shares the same ->nocb_gp_kthread, also enqueues a callback, but with interrupts enabled, allowing it to directly awaken the ->nocb_gp_kthread. 4. The newly awakened ->nocb_gp_kthread associates both CPU 1's and CPU 2's callbacks with a future grace period and arranges for that grace period to be started. 5. This ->nocb_gp_kthread goes to sleep waiting for the end of this future grace period. 6. This grace period elapses before the CPU 1's timer fires. This is normally improbably given that the timer is set for only one jiffy, but timers can be delayed. Besides, it is possible that kernel was built with CONFIG_RCU_STRICT_GRACE_PERIOD=y. 7. The grace period ends, so rcu_gp_kthread awakens the ->nocb_gp_kthread, which in turn awakens both CPU 1's and CPU 2's ->nocb_cb_kthread. Then ->nocb_gb_kthread sleeps waiting for more newly queued callbacks. 8. CPU 1's ->nocb_cb_kthread invokes its callback, then sleeps waiting for more invocable callbacks. 9. Note that neither kthread updated any ->nocb_timer state, so CPU 1's ->nocb_defer_wakeup is still set to RCU_NOCB_WAKE. 10. CPU 1 enqueues its second callback, this time with interrupts enabled so it can wake directly ->nocb_gp_kthread. It does so with calling wake_nocb_gp() which also cancels the pending timer that got queued in step 2. But that doesn't reset CPU 1's ->nocb_defer_wakeup which is still set to RCU_NOCB_WAKE. So CPU 1's ->nocb_defer_wakeup and its ->nocb_timer are now desynchronized. 11. ->nocb_gp_kthread associates the callback queued in 10 with a new grace period, arranges for that grace period to start and sleeps waiting for it to complete. 12. The grace period ends, rcu_gp_kthread awakens ->nocb_gp_kthread, which in turn wakes up CPU 1's ->nocb_cb_kthread which then invokes the callback queued in 10. 13. CPU 1 enqueues its third callback, this time with interrupts disabled so it must queue a timer for a deferred wakeup. However the value of its ->nocb_defer_wakeup is RCU_NOCB_WAKE which incorrectly indicates that a timer is already queued. Instead, CPU 1's ->nocb_timer was cancelled in 10. CPU 1 therefore fails to queue the ->nocb_timer. 14. CPU 1 has its pending callback and it may go unnoticed until some other CPU ever wakes up ->nocb_gp_kthread or CPU 1 ever calls an explicit deferred wakeup, for example, during idle entry. This commit fixes this bug by resetting rdp->nocb_defer_wakeup everytime we delete the ->nocb_timer. It is quite possible that there is a similar scenario involving ->nocb_bypass_timer and ->nocb_defer_wakeup. However, despite some effort from several people, a failure scenario has not yet been located. However, that by no means guarantees that no such scenario exists. Finding a failure scenario is left as an exercise for the reader, and the "Fixes:" tag below relates to ->nocb_bypass_timer instead of ->nocb_timer. Fixes: d1b222c6be1f (rcu/nocb: Add bypass callback queueing) Cc: Cc: Josh Triplett Cc: Lai Jiangshan Cc: Joel Fernandes Cc: Boqun Feng Reviewed-by: Neeraj Upadhyay Signed-off-by: Frederic Weisbecker Signed-off-by: Paul E. McKenney Signed-off-by: Greg Kroah-Hartman commit ebeac958b690123a0b40aa61f688f2f170035fad Author: Ignat Korchagin Date: Tue Apr 27 22:09:38 2021 +0100 sfc: adjust efx->xdp_tx_queue_count with the real number of initialized queues commit 99ba0ea616aabdc8e26259fd722503e012199a76 upstream. efx->xdp_tx_queue_count is initially initialized to num_possible_cpus() and is later used to allocate and traverse efx->xdp_tx_queues lookup array. However, we may end up not initializing all the array slots with real queues during probing. This results, for example, in a NULL pointer dereference, when running "# ethtool -S ", similar to below [2570283.664955][T4126959] BUG: kernel NULL pointer dereference, address: 00000000000000f8 [2570283.681283][T4126959] #PF: supervisor read access in kernel mode [2570283.695678][T4126959] #PF: error_code(0x0000) - not-present page [2570283.710013][T4126959] PGD 0 P4D 0 [2570283.721649][T4126959] Oops: 0000 [#1] SMP PTI [2570283.734108][T4126959] CPU: 23 PID: 4126959 Comm: ethtool Tainted: G O 5.10.20-cloudflare-2021.3.1 #1 [2570283.752641][T4126959] Hardware name: [2570283.781408][T4126959] RIP: 0010:efx_ethtool_get_stats+0x2ca/0x330 [sfc] [2570283.796073][T4126959] Code: 00 85 c0 74 39 48 8b 95 a8 0f 00 00 48 85 d2 74 2d 31 c0 eb 07 48 8b 95 a8 0f 00 00 48 63 c8 49 83 c4 08 83 c0 01 48 8b 14 ca <48> 8b 92 f8 00 00 00 49 89 54 24 f8 39 85 a0 0f 00 00 77 d7 48 8b [2570283.831259][T4126959] RSP: 0018:ffffb79a77657ce8 EFLAGS: 00010202 [2570283.845121][T4126959] RAX: 0000000000000019 RBX: ffffb799cd0c9280 RCX: 0000000000000018 [2570283.860872][T4126959] RDX: 0000000000000000 RSI: ffff96dd970ce000 RDI: 0000000000000005 [2570283.876525][T4126959] RBP: ffff96dd86f0a000 R08: ffff96dd970ce480 R09: 000000000000005f [2570283.892014][T4126959] R10: ffffb799cd0c9fff R11: ffffb799cd0c9000 R12: ffffb799cd0c94f8 [2570283.907406][T4126959] R13: ffffffffc11b1090 R14: ffff96dd970ce000 R15: ffffffffc11cd66c [2570283.922705][T4126959] FS: 00007fa7723f8740(0000) GS:ffff96f51fac0000(0000) knlGS:0000000000000000 [2570283.938848][T4126959] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [2570283.952524][T4126959] CR2: 00000000000000f8 CR3: 0000001a73e6e006 CR4: 00000000007706e0 [2570283.967529][T4126959] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [2570283.982400][T4126959] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [2570283.997308][T4126959] PKRU: 55555554 [2570284.007649][T4126959] Call Trace: [2570284.017598][T4126959] dev_ethtool+0x1832/0x2830 Fix this by adjusting efx->xdp_tx_queue_count after probing to reflect the true value of initialized slots in efx->xdp_tx_queues. Signed-off-by: Ignat Korchagin Fixes: e26ca4b53582 ("sfc: reduce the number of requested xdp ev queues") Cc: # 5.12.x Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit e531db1ea6f98c9612cb2de093a107c7eadfb96c Author: Edward Cree Date: Tue Apr 20 13:28:28 2021 +0100 sfc: farch: fix TX queue lookup in TX event handling commit 83b09a1807415608b387c7bc748d329fefc5617e upstream. We're starting from a TXQ label, not a TXQ type, so efx_channel_get_tx_queue() is inappropriate (and could return NULL, leading to panics). Fixes: 12804793b17c ("sfc: decouple TXQ type from label") Cc: stable@vger.kernel.org Signed-off-by: Edward Cree Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 98d91180748986bfb6dfb3e72765f3225719a647 Author: Edward Cree Date: Tue Apr 20 13:27:22 2021 +0100 sfc: farch: fix TX queue lookup in TX flush done handling commit 5b1faa92289b53cad654123ed2bc8e10f6ddd4ac upstream. We're starting from a TXQ instance number ('qid'), not a TXQ type, so efx_get_tx_queue() is inappropriate (and could return NULL, leading to panics). Fixes: 12804793b17c ("sfc: decouple TXQ type from label") Reported-by: Trevor Hemsley Cc: stable@vger.kernel.org Signed-off-by: Edward Cree Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 473ffbe0b25cdf3fc5157a5223d426cc722fb98c Author: Hyeongseok Kim Date: Thu Mar 4 09:15:34 2021 +0900 exfat: fix erroneous discard when clear cluster bit commit 77edfc6e51055b61cae2f54c8e6c3bb7c762e4fe upstream. If mounted with discard option, exFAT issues discard command when clear cluster bit to remove file. But the input parameter of cluster-to-sector calculation is abnormally added by reserved cluster size which is 2, leading to discard unrelated sectors included in target+2 cluster. With fixing this, remove the wrong comments in set/clear/find bitmap functions. Fixes: 1e49a94cf707 ("exfat: add bitmap operations") Cc: stable@vger.kernel.org # v5.7+ Signed-off-by: Hyeongseok Kim Acked-by: Sungjong Seo Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit d04d56f855fa9fda66998dde69e39c3f8432011d Author: Sergei Trofimovich Date: Thu Apr 29 23:02:11 2021 -0700 mm: page_alloc: ignore init_on_free=1 for debug_pagealloc=1 commit 9df65f522536719682bccd24245ff94db956256c upstream. On !ARCH_SUPPORTS_DEBUG_PAGEALLOC (like ia64) debug_pagealloc=1 implies page_poison=on: if (page_poisoning_enabled() || (!IS_ENABLED(CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC) && debug_pagealloc_enabled())) static_branch_enable(&_page_poisoning_enabled); page_poison=on needs to override init_on_free=1. Before the change it did not work as expected for the following case: - have PAGE_POISONING=y - have page_poison unset - have !ARCH_SUPPORTS_DEBUG_PAGEALLOC arch (like ia64) - have init_on_free=1 - have debug_pagealloc=1 That way we get both keys enabled: - static_branch_enable(&init_on_free); - static_branch_enable(&_page_poisoning_enabled); which leads to poisoned pages returned for __GFP_ZERO pages. After the change we execute only: - static_branch_enable(&_page_poisoning_enabled); and ignore init_on_free=1. Link: https://lkml.kernel.org/r/20210329222555.3077928-1-slyfox@gentoo.org Link: https://lkml.org/lkml/2021/3/26/443 Fixes: 8db26a3d4735 ("mm, page_poison: use static key more efficiently") Signed-off-by: Sergei Trofimovich Acked-by: Vlastimil Babka Reviewed-by: David Hildenbrand Cc: Andrey Konovalov Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit b945c480ae85ad2dbeaf2f7f10b4a3baa4263cf0 Author: Vivek Goyal Date: Wed Oct 21 16:12:49 2020 -0400 fuse: fix write deadlock commit 4f06dd92b5d0a6f8eec6a34b8d6ef3e1f4ac1e10 upstream. There are two modes for write(2) and friends in fuse: a) write through (update page cache, send sync WRITE request to userspace) b) buffered write (update page cache, async writeout later) The write through method kept all the page cache pages locked that were used for the request. Keeping more than one page locked is deadlock prone and Qian Cai demonstrated this with trinity fuzzing. The reason for keeping the pages locked is that concurrent mapped reads shouldn't try to pull possibly stale data into the page cache. For full page writes, the easy way to fix this is to make the cached page be the authoritative source by marking the page PG_uptodate immediately. After this the page can be safely unlocked, since mapped/cached reads will take the written data from the cache. Concurrent mapped writes will now cause data in the original WRITE request to be updated; this however doesn't cause any data inconsistency and this scenario should be exceedingly rare anyway. If the WRITE request returns with an error in the above case, currently the page is not marked uptodate; this means that a concurrent read will always read consistent data. After this patch the page is uptodate between writing to the cache and receiving the error: there's window where a cached read will read the wrong data. While theoretically this could be a regression, it is unlikely to be one in practice, since this is normal for buffered writes. In case of a partial page write to an already uptodate page the locking is also unnecessary, with the above caveats. Partial write of a not uptodate page still needs to be handled. One way would be to read the complete page before doing the write. This is not possible, since it might break filesystems that don't expect any READ requests when the file was opened O_WRONLY. The other solution is to serialize the synchronous write with reads from the partial pages. The easiest way to do this is to keep the partial pages locked. The problem is that a write() may involve two such pages (one head and one tail). This patch fixes it by only locking the partial tail page. If there's a partial head page as well, then split that off as a separate WRITE request. Reported-by: Qian Cai Link: https://lore.kernel.org/linux-fsdevel/4794a3fa3742a5e84fb0f934944204b55730829b.camel@lca.pw/ Fixes: ea9b9907b82a ("fuse: implement perform_write") Cc: # v2.6.26 Signed-off-by: Vivek Goyal Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 00fd897153cadc2fd94c937bedf60cec25707762 Author: Heinz Mauelshagen Date: Wed Apr 21 23:32:36 2021 +0200 dm raid: fix inconclusive reshape layout on fast raid4/5/6 table reload sequences commit f99a8e4373eeacb279bc9696937a55adbff7a28a upstream. If fast table reloads occur during an ongoing reshape of raid4/5/6 devices the target may race reading a superblock vs the the MD resync thread; causing an inconclusive reshape state to be read in its constructor. lvm2 test lvconvert-raid-reshape-stripes-load-reload.sh can cause BUG_ON() to trigger in md_run(), e.g.: "kernel BUG at drivers/md/raid5.c:7567!". Scenario triggering the bug: 1. the MD sync thread calls end_reshape() from raid5_sync_request() when done reshaping. However end_reshape() _only_ updates the reshape position to MaxSector keeping the changed layout configuration though (i.e. any delta disks, chunk sector or RAID algorithm changes). That inconclusive configuration is stored in the superblock. 2. dm-raid constructs a mapping, loading named inconsistent superblock as of step 1 before step 3 is able to finish resetting the reshape state completely, and calls md_run() which leads to mentioned bug in raid5.c. 3. the MD RAID personality's finish_reshape() is called; which resets the reshape information on chunk sectors, delta disks, etc. This explains why the bug is rarely seen on multi-core machines, as MD's finish_reshape() superblock update races with the dm-raid constructor's superblock load in step 2. Fix identifies inconclusive superblock content in the dm-raid constructor and resets it before calling md_run(), factoring out identifying checks into rs_is_layout_change() to share in existing rs_reshape_requested() and new rs_reset_inclonclusive_reshape(). Also enhance a comment and remove an empty line. Cc: stable@vger.kernel.org Signed-off-by: Heinz Mauelshagen Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 538244fba59fde17186322776247cd9c05be86dd Author: Paul Clements Date: Thu Apr 15 17:17:57 2021 -0400 md/raid1: properly indicate failure when ending a failed write request commit 2417b9869b81882ab90fd5ed1081a1cb2d4db1dd upstream. This patch addresses a data corruption bug in raid1 arrays using bitmaps. Without this fix, the bitmap bits for the failed I/O end up being cleared. Since we are in the failure leg of raid1_end_write_request, the request either needs to be retried (R1BIO_WriteError) or failed (R1BIO_Degraded). Fixes: eeba6809d8d5 ("md/raid1: end bio when the device faulty") Cc: stable@vger.kernel.org # v5.2+ Signed-off-by: Paul Clements Signed-off-by: Song Liu Signed-off-by: Greg Kroah-Hartman commit 3606420d57140dfbcda3fd2c0ae94bdb26635639 Author: Eric Biggers Date: Sun Mar 21 22:07:48 2021 -0700 crypto: rng - fix crypto_rng_reset() refcounting when !CRYPTO_STATS commit 30d0f6a956fc74bb2e948398daf3278c6b08c7e9 upstream. crypto_stats_get() is a no-op when the kernel is compiled without CONFIG_CRYPTO_STATS, so pairing it with crypto_alg_put() unconditionally (as crypto_rng_reset() does) is wrong. Fix this by moving the call to crypto_stats_get() to just before the actual algorithm operation which might need it. This makes it always paired with crypto_stats_rng_seed(). Fixes: eed74b3eba9e ("crypto: rng - Fix a refcounting bug in crypto_rng_reset()") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 694d9d5b59e296e4229b90eb939a2e4249ac5506 Author: Nathan Chancellor Date: Fri Apr 9 15:11:55 2021 -0700 crypto: arm/curve25519 - Move '.fpu' after '.arch' commit 44200f2d9b8b52389c70e6c7bbe51e0dc6eaf938 upstream. Debian's clang carries a patch that makes the default FPU mode 'vfp3-d16' instead of 'neon' for 'armv7-a' to avoid generating NEON instructions on hardware that does not support them: https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/raw/5a61ca6f21b4ad8c6ac4970e5ea5a7b5b4486d22/debian/patches/clang-arm-default-vfp3-on-armv7a.patch https://bugs.debian.org/841474 https://bugs.debian.org/842142 https://bugs.debian.org/914268 This results in the following build error when clang's integrated assembler is used because the '.arch' directive overrides the '.fpu' directive: arch/arm/crypto/curve25519-core.S:25:2: error: instruction requires: NEON vmov.i32 q0, #1 ^ arch/arm/crypto/curve25519-core.S:26:2: error: instruction requires: NEON vshr.u64 q1, q0, #7 ^ arch/arm/crypto/curve25519-core.S:27:2: error: instruction requires: NEON vshr.u64 q0, q0, #8 ^ arch/arm/crypto/curve25519-core.S:28:2: error: instruction requires: NEON vmov.i32 d4, #19 ^ Shuffle the order of the '.arch' and '.fpu' directives so that the code builds regardless of the default FPU mode. This has been tested against both clang with and without Debian's patch and GCC. Cc: stable@vger.kernel.org Fixes: d8f1308a025f ("crypto: arm/curve25519 - wire up NEON implementation") Link: https://github.com/ClangBuiltLinux/continuous-integration2/issues/118 Reported-by: Arnd Bergmann Suggested-by: Arnd Bergmann Suggested-by: Jessica Clarke Signed-off-by: Nathan Chancellor Acked-by: Jason A. Donenfeld Reviewed-by: Nick Desaulniers Tested-by: Nick Desaulniers Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 9afbad5eb1439e9e03f1b6600c94b43e1074c2b6 Author: Stefan Berger Date: Wed Mar 10 17:19:16 2021 -0500 tpm: vtpm_proxy: Avoid reading host log when using a virtual device commit 9716ac65efc8f780549b03bddf41e60c445d4709 upstream. Avoid allocating memory and reading the host log when a virtual device is used since this log is of no use to that driver. A virtual device can be identified through the flag TPM_CHIP_FLAG_VIRTUAL, which is only set for the tpm_vtpm_proxy driver. Cc: stable@vger.kernel.org Fixes: 6f99612e2500 ("tpm: Proxy driver for supporting multiple emulated TPMs") Signed-off-by: Stefan Berger Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit ac07c557ca12ec9276c0375517bac7ae5be4e50c Author: Stefan Berger Date: Wed Mar 10 17:19:14 2021 -0500 tpm: efi: Use local variable for calculating final log size commit 48cff270b037022e37835d93361646205ca25101 upstream. When tpm_read_log_efi is called multiple times, which happens when one loads and unloads a TPM2 driver multiple times, then the global variable efi_tpm_final_log_size will at some point become a negative number due to the subtraction of final_events_preboot_size occurring each time. Use a local variable to avoid this integer underflow. The following issue is now resolved: Mar 8 15:35:12 hibinst kernel: Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Mar 8 15:35:12 hibinst kernel: Workqueue: tpm-vtpm vtpm_proxy_work [tpm_vtpm_proxy] Mar 8 15:35:12 hibinst kernel: RIP: 0010:__memcpy+0x12/0x20 Mar 8 15:35:12 hibinst kernel: Code: 00 b8 01 00 00 00 85 d2 74 0a c7 05 44 7b ef 00 0f 00 00 00 c3 cc cc cc 66 66 90 66 90 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 f3 a4 Mar 8 15:35:12 hibinst kernel: RSP: 0018:ffff9ac4c0fcfde0 EFLAGS: 00010206 Mar 8 15:35:12 hibinst kernel: RAX: ffff88f878cefed5 RBX: ffff88f878ce9000 RCX: 1ffffffffffffe0f Mar 8 15:35:12 hibinst kernel: RDX: 0000000000000003 RSI: ffff9ac4c003bff9 RDI: ffff88f878cf0e4d Mar 8 15:35:12 hibinst kernel: RBP: ffff9ac4c003b000 R08: 0000000000001000 R09: 000000007e9d6073 Mar 8 15:35:12 hibinst kernel: R10: ffff9ac4c003b000 R11: ffff88f879ad3500 R12: 0000000000000ed5 Mar 8 15:35:12 hibinst kernel: R13: ffff88f878ce9760 R14: 0000000000000002 R15: ffff88f77de7f018 Mar 8 15:35:12 hibinst kernel: FS: 0000000000000000(0000) GS:ffff88f87bd00000(0000) knlGS:0000000000000000 Mar 8 15:35:12 hibinst kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Mar 8 15:35:12 hibinst kernel: CR2: ffff9ac4c003c000 CR3: 00000001785a6004 CR4: 0000000000060ee0 Mar 8 15:35:12 hibinst kernel: Call Trace: Mar 8 15:35:12 hibinst kernel: tpm_read_log_efi+0x152/0x1a7 Mar 8 15:35:12 hibinst kernel: tpm_bios_log_setup+0xc8/0x1c0 Mar 8 15:35:12 hibinst kernel: tpm_chip_register+0x8f/0x260 Mar 8 15:35:12 hibinst kernel: vtpm_proxy_work+0x16/0x60 [tpm_vtpm_proxy] Mar 8 15:35:12 hibinst kernel: process_one_work+0x1b4/0x370 Mar 8 15:35:12 hibinst kernel: worker_thread+0x53/0x3e0 Mar 8 15:35:12 hibinst kernel: ? process_one_work+0x370/0x370 Cc: stable@vger.kernel.org Fixes: 166a2809d65b ("tpm: Don't duplicate events from the final event log in the TCG2 log") Signed-off-by: Stefan Berger Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit e09145e208326b747c135ad6c59bdd7c8591e664 Author: Alexander Shishkin Date: Wed Apr 14 20:12:51 2021 +0300 intel_th: pci: Add Alder Lake-M support commit 48cb17531b15967d9d3f34c770a25cc6c4ca6ad1 upstream. This adds support for the Trace Hub in Alder Lake-M PCH. Signed-off-by: Alexander Shishkin Reviewed-by: Andy Shevchenko Cc: stable@vger.kernel.org # v4.14+ Link: https://lore.kernel.org/r/20210414171251.14672-8-alexander.shishkin@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 467c41f8b18d5ae633ad276942a23e3cbf3c550a Author: Michael Ellerman Date: Sun Apr 25 21:58:31 2021 +1000 powerpc/kvm: Fix build error when PPC_MEM_KEYS/PPC_PSERIES=n commit ee1bc694fbaec1a662770703fc34a74abf418938 upstream. lkp reported a randconfig failure: In file included from arch/powerpc/include/asm/book3s/64/pkeys.h:6, from arch/powerpc/kvm/book3s_64_mmu_host.c:15: arch/powerpc/include/asm/book3s/64/hash-pkey.h: In function 'hash__vmflag_to_pte_pkey_bits': >> arch/powerpc/include/asm/book3s/64/hash-pkey.h:10:23: error: 'VM_PKEY_BIT0' undeclared 10 | return (((vm_flags & VM_PKEY_BIT0) ? H_PTE_PKEY_BIT0 : 0x0UL) | | ^~~~~~~~~~~~ We added the include of book3s/64/pkeys.h for pte_to_hpte_pkey_bits(), but that header on its own should only be included when PPC_MEM_KEYS=y. Instead include linux/pkeys.h, which brings in the right definitions when PPC_MEM_KEYS=y and also provides empty stubs when PPC_MEM_KEYS=n. Fixes: e4e8bc1df691 ("powerpc/kvm: Fix PR KVM with KUAP/MEM_KEYS enabled") Cc: stable@vger.kernel.org # v5.11+ Reported-by: kernel test robot Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210425115831.2818434-1-mpe@ellerman.id.au Signed-off-by: Greg Kroah-Hartman commit 5fa84d105f27bd984c86a7c723925dff0f745ecf Author: Michael Ellerman Date: Mon Apr 19 22:01:39 2021 +1000 powerpc/kvm: Fix PR KVM with KUAP/MEM_KEYS enabled commit e4e8bc1df691ba5ba749d1e2b67acf9827e51a35 upstream. The changes to add KUAP support with the hash MMU broke booting of KVM PR guests. The symptom is no visible progress of the guest, or possibly just "SLOF" being printed to the qemu console. Host code is still executing, but breaking into xmon might show a stack trace such as: __might_fault+0x84/0xe0 (unreliable) kvm_read_guest+0x1c8/0x2f0 [kvm] kvmppc_ld+0x1b8/0x2d0 [kvm] kvmppc_load_last_inst+0x50/0xa0 [kvm] kvmppc_exit_pr_progint+0x178/0x220 [kvm_pr] kvmppc_handle_exit_pr+0x31c/0xe30 [kvm_pr] after_sprg3_load+0x80/0x90 [kvm_pr] kvmppc_vcpu_run_pr+0x104/0x260 [kvm_pr] kvmppc_vcpu_run+0x34/0x48 [kvm] kvm_arch_vcpu_ioctl_run+0x340/0x450 [kvm] kvm_vcpu_ioctl+0x2ac/0x8c0 [kvm] sys_ioctl+0x320/0x1060 system_call_exception+0x160/0x270 system_call_common+0xf0/0x27c Bisect points to commit b2ff33a10c8b ("powerpc/book3s64/hash/kuap: Enable kuap on hash"), but that's just the commit that enabled KUAP with hash and made the bug visible. The root cause seems to be that KVM PR is creating kernel mappings that don't use the correct key, since we switched to using key 3. We have a helper for adding the right key value, however it's designed to take a pteflags variable, which the KVM code doesn't have. But we can make it work by passing 0 for the pteflags, and tell it explicitly that it should use the kernel key. With that changed guests boot successfully. Fixes: d94b827e89dc ("powerpc/book3s64/kuap: Use Key 3 for kernel mapping with hash translation") Cc: stable@vger.kernel.org # v5.11+ Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210419120139.1455937-1-mpe@ellerman.id.au Signed-off-by: Greg Kroah-Hartman commit 524a894b21e64ae86d53030e2aab1182c2ce4083 Author: Tony Ambardar Date: Thu Sep 17 06:54:37 2020 -0700 powerpc: fix EDEADLOCK redefinition error in uapi/asm/errno.h commit 7de21e679e6a789f3729e8402bc440b623a28eae upstream. A few archs like powerpc have different errno.h values for macros EDEADLOCK and EDEADLK. In code including both libc and linux versions of errno.h, this can result in multiple definitions of EDEADLOCK in the include chain. Definitions to the same value (e.g. seen with mips) do not raise warnings, but on powerpc there are redefinitions changing the value, which raise warnings and errors (if using "-Werror"). Guard against these redefinitions to avoid build errors like the following, first seen cross-compiling libbpf v5.8.9 for powerpc using GCC 8.4.0 with musl 1.1.24: In file included from ../../arch/powerpc/include/uapi/asm/errno.h:5, from ../../include/linux/err.h:8, from libbpf.c:29: ../../include/uapi/asm-generic/errno.h:40: error: "EDEADLOCK" redefined [-Werror] #define EDEADLOCK EDEADLK In file included from toolchain-powerpc_8540_gcc-8.4.0_musl/include/errno.h:10, from libbpf.c:26: toolchain-powerpc_8540_gcc-8.4.0_musl/include/bits/errno.h:58: note: this is the location of the previous definition #define EDEADLOCK 58 cc1: all warnings being treated as errors Cc: Stable Reported-by: Rosen Penev Signed-off-by: Tony Ambardar Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200917135437.1238787-1-Tony.Ambardar@gmail.com Signed-off-by: Greg Kroah-Hartman commit fe261343667365a07d978bed8df59e94e2a4836d Author: Christophe Leroy Date: Thu Apr 29 16:52:09 2021 +0000 powerpc/32: Fix boot failure with CONFIG_STACKPROTECTOR commit f5668260b872e89b8d3942a8b7d4278aa9c2c981 upstream. Commit 7c95d8893fb5 ("powerpc: Change calling convention for create_branch() et. al.") complexified the frame of function do_feature_fixups(), leading to GCC setting up a stack guard when CONFIG_STACKPROTECTOR is selected. The problem is that do_feature_fixups() is called very early while 'current' in r2 is not set up yet and the code is still not at the final address used at link time. So, like other instrumentation, stack protection needs to be deactivated for feature-fixups.c and code-patching.c Fixes: 7c95d8893fb5 ("powerpc: Change calling convention for create_branch() et. al.") Cc: stable@vger.kernel.org # v5.8+ Reported-by: Jonathan Neuschaefer Signed-off-by: Christophe Leroy Tested-by: Jonathan Neuschaefer Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/b688fe82927b330349d9e44553363fa451ea4d95.1619715114.git.christophe.leroy@csgroup.eu Signed-off-by: Greg Kroah-Hartman commit b54b85bd073acc2a51615ea9b74cc594d70a6b55 Author: Sourabh Jain Date: Thu Apr 29 11:32:56 2021 +0530 powerpc/kexec_file: Use current CPU info while setting up FDT commit 40c753993e3aad51a12c21233486e2037417a4d6 upstream. kexec_file_load() uses initial_boot_params in setting up the device tree for the kernel to be loaded. Though initial_boot_params holds info about CPUs at the time of boot, it doesn't account for hot added CPUs. So, kexec'ing with kexec_file_load() syscall leaves the kexec'ed kernel with inaccurate CPU info. If kdump kernel is loaded with kexec_file_load() syscall and the system crashes on a hot added CPU, the capture kernel hangs failing to identify the boot CPU, with no output. To avoid this from happening, extract current CPU info from of_root device node and use it for setting up the fdt in kexec_file_load case. Fixes: 6ecd0163d360 ("powerpc/kexec_file: Add appropriate regions for memory reserve map") Cc: stable@vger.kernel.org # v5.9+ Signed-off-by: Sourabh Jain Reviewed-by: Hari Bathini Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210429060256.199714-1-sourabhjain@linux.ibm.com Signed-off-by: Greg Kroah-Hartman commit a43ae32fc22bb8bae4c03e0d83bf6511ec4dd849 Author: Mahesh Salgaonkar Date: Mon Apr 12 13:22:50 2021 +0530 powerpc/eeh: Fix EEH handling for hugepages in ioremap space. commit 5ae5bc12d0728db60a0aa9b62160ffc038875f1a upstream. During the EEH MMIO error checking, the current implementation fails to map the (virtual) MMIO address back to the pci device on radix with hugepage mappings for I/O. This results into failure to dispatch EEH event with no recovery even when EEH capability has been enabled on the device. eeh_check_failure(token) # token = virtual MMIO address addr = eeh_token_to_phys(token); edev = eeh_addr_cache_get_dev(addr); if (!edev) return 0; eeh_dev_check_failure(edev); <= Dispatch the EEH event In case of hugepage mappings, eeh_token_to_phys() has a bug in virt -> phys translation that results in wrong physical address, which is then passed to eeh_addr_cache_get_dev() to match it against cached pci I/O address ranges to get to a PCI device. Hence, it fails to find a match and the EEH event never gets dispatched leaving the device in failed state. The commit 33439620680be ("powerpc/eeh: Handle hugepages in ioremap space") introduced following logic to translate virt to phys for hugepage mappings: eeh_token_to_phys(): + pa = pte_pfn(*ptep); + + /* On radix we can do hugepage mappings for io, so handle that */ + if (hugepage_shift) { + pa <<= hugepage_shift; <= This is wrong + pa |= token & ((1ul << hugepage_shift) - 1); + } This patch fixes the virt -> phys translation in eeh_token_to_phys() function. $ cat /sys/kernel/debug/powerpc/eeh_address_cache mem addr range [0x0000040080000000-0x00000400807fffff]: 0030:01:00.1 mem addr range [0x0000040080800000-0x0000040080ffffff]: 0030:01:00.1 mem addr range [0x0000040081000000-0x00000400817fffff]: 0030:01:00.0 mem addr range [0x0000040081800000-0x0000040081ffffff]: 0030:01:00.0 mem addr range [0x0000040082000000-0x000004008207ffff]: 0030:01:00.1 mem addr range [0x0000040082080000-0x00000400820fffff]: 0030:01:00.0 mem addr range [0x0000040082100000-0x000004008210ffff]: 0030:01:00.1 mem addr range [0x0000040082110000-0x000004008211ffff]: 0030:01:00.0 Above is the list of cached io address ranges of pci 0030:01:00.. Before this patch: Tracing 'arg1' of function eeh_addr_cache_get_dev() during error injection clearly shows that 'addr=' contains wrong physical address: kworker/u16:0-7 [001] .... 108.883775: eeh_addr_cache_get_dev: (eeh_addr_cache_get_dev+0xc/0xf0) addr=0x80103000a510 dmesg shows no EEH recovery messages: [ 108.563768] bnx2x: [bnx2x_timer:5801(eth2)]MFW seems hanged: drv_pulse (0x9ae) != mcp_pulse (0x7fff) [ 108.563788] bnx2x: [bnx2x_hw_stats_update:870(eth2)]NIG timer max (4294967295) [ 108.883788] bnx2x: [bnx2x_acquire_hw_lock:2013(eth1)]lock_status 0xffffffff resource_bit 0x1 [ 108.884407] bnx2x 0030:01:00.0 eth1: MDC/MDIO access timeout [ 108.884976] bnx2x 0030:01:00.0 eth1: MDC/MDIO access timeout <..> After this patch: eeh_addr_cache_get_dev() trace shows correct physical address: -0 [001] ..s. 1043.123828: eeh_addr_cache_get_dev: (eeh_addr_cache_get_dev+0xc/0xf0) addr=0x40080bc7cd8 dmesg logs shows EEH recovery getting triggerred: [ 964.323980] bnx2x: [bnx2x_timer:5801(eth2)]MFW seems hanged: drv_pulse (0x746f) != mcp_pulse (0x7fff) [ 964.323991] EEH: Recovering PHB#30-PE#10000 [ 964.324002] EEH: PE location: N/A, PHB location: N/A [ 964.324006] EEH: Frozen PHB#30-PE#10000 detected <..> Fixes: 33439620680b ("powerpc/eeh: Handle hugepages in ioremap space") Cc: stable@vger.kernel.org # v5.3+ Reported-by: Dominic DeMarco Signed-off-by: Mahesh Salgaonkar Signed-off-by: Aneesh Kumar K.V Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/161821396263.48361.2796709239866588652.stgit@jupiter Signed-off-by: Greg Kroah-Hartman commit a9a8818919226e60c34693a129449594d15d38be Author: Nicholas Piggin Date: Fri Apr 2 12:41:24 2021 +1000 powerpc/powernv: Enable HAIL (HV AIL) for ISA v3.1 processors commit 49c1d07fd04f54eb588c4a1dfcedc8d22c5ffd50 upstream. Starting with ISA v3.1, LPCR[AIL] no longer controls the interrupt mode for HV=1 interrupts. Instead, a new LPCR[HAIL] bit is defined which behaves like AIL=3 for HV interrupts when set. Set HAIL on bare metal to give us mmu-on interrupts and improve performance. This also fixes an scv bug: we don't implement scv real mode (AIL=0) vectors because they are at an inconvenient location, so we just disable scv support when AIL can not be set. However powernv assumes that LPCR[AIL] will enable AIL mode so it enables scv support despite HV interrupts being AIL=0, which causes scv interrupts to go off into the weeds. Fixes: 7fa95f9adaee ("powerpc/64s: system call support for scv/rfscv instructions") Cc: stable@vger.kernel.org # v5.9+ Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210402024124.545826-1-npiggin@gmail.com Signed-off-by: Greg Kroah-Hartman commit f486ef7e762e7b38482c27ee833918bfa528bf35 Author: Dmitry Safonov <0x7f454c46@gmail.com> Date: Wed Mar 31 16:48:46 2021 +0000 powerpc/vdso: Separate vvar vma from vdso commit 1c4bce6753857dc409a0197342d18764e7f4b741 upstream. Since commit 511157ab641e ("powerpc/vdso: Move vdso datapage up front") VVAR page is in front of the VDSO area. In result it breaks CRIU (Checkpoint Restore In Userspace) [1], where CRIU expects that "[vdso]" from /proc/../maps points at ELF/vdso image, rather than at VVAR data page. Laurent made a patch to keep CRIU working (by reading aux vector). But I think it still makes sence to separate two mappings into different VMAs. It will also make ppc64 less "special" for userspace and as a side-bonus will make VVAR page un-writable by debugger (which previously would COW page and can be unexpected). I opportunistically Cc stable on it: I understand that usually such stuff isn't a stable material, but that will allow us in CRIU have one workaround less that is needed just for one release (v5.11) on one platform (ppc64), which we otherwise have to maintain. I wouldn't go as far as to say that the commit 511157ab641e is ABI regression as no other userspace got broken, but I'd really appreciate if it gets backported to v5.11 after v5.12 is released, so as not to complicate already non-simple CRIU-vdso code. Thanks! [1]: https://github.com/checkpoint-restore/criu/issues/1417 Cc: stable@vger.kernel.org # v5.11 Signed-off-by: Dmitry Safonov Signed-off-by: Christophe Leroy Tested-by: Christophe Leroy Reviewed-by: Vincenzo Frascino # vDSO parts. Acked-by: Andrei Vagin Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/f401eb1ebc0bfc4d8f0e10dc8e525fd409eb68e2.1617209142.git.christophe.leroy@csgroup.eu Signed-off-by: Greg Kroah-Hartman commit 43aa1cfeebf447a263682379e3de57c1673ad918 Author: Longpeng(Mike) Date: Thu Apr 15 08:46:28 2021 +0800 iommu/vt-d: Force to flush iotlb before creating superpage commit 38c527aeb41926c71902dd42f788a8b093b21416 upstream. The translation caches may preserve obsolete data when the mapping size is changed, suppose the following sequence which can reveal the problem with high probability. 1.mmap(4GB,MAP_HUGETLB) 2. while (1) { (a) DMA MAP 0,0xa0000 (b) DMA UNMAP 0,0xa0000 (c) DMA MAP 0,0xc0000000 * DMA read IOVA 0 may failure here (Not present) * if the problem occurs. (d) DMA UNMAP 0,0xc0000000 } The page table(only focus on IOVA 0) after (a) is: PML4: 0x19db5c1003 entry:0xffff899bdcd2f000 PDPE: 0x1a1cacb003 entry:0xffff89b35b5c1000 PDE: 0x1a30a72003 entry:0xffff89b39cacb000 PTE: 0x21d200803 entry:0xffff89b3b0a72000 The page table after (b) is: PML4: 0x19db5c1003 entry:0xffff899bdcd2f000 PDPE: 0x1a1cacb003 entry:0xffff89b35b5c1000 PDE: 0x1a30a72003 entry:0xffff89b39cacb000 PTE: 0x0 entry:0xffff89b3b0a72000 The page table after (c) is: PML4: 0x19db5c1003 entry:0xffff899bdcd2f000 PDPE: 0x1a1cacb003 entry:0xffff89b35b5c1000 PDE: 0x21d200883 entry:0xffff89b39cacb000 (*) Because the PDE entry after (b) is present, it won't be flushed even if the iommu driver flush cache when unmap, so the obsolete data may be preserved in cache, which would cause the wrong translation at end. However, we can see the PDE entry is finally switch to 2M-superpage mapping, but it does not transform to 0x21d200883 directly: 1. PDE: 0x1a30a72003 2. __domain_mapping dma_pte_free_pagetable Set the PDE entry to ZERO Set the PDE entry to 0x21d200883 So we must flush the cache after the entry switch to ZERO to avoid the obsolete info be preserved. Cc: David Woodhouse Cc: Lu Baolu Cc: Nadav Amit Cc: Alex Williamson Cc: Joerg Roedel Cc: Kevin Tian Cc: Gonglei (Arei) Fixes: 6491d4d02893 ("intel-iommu: Free old page tables before creating superpage") Cc: # v3.0+ Link: https://lore.kernel.org/linux-iommu/670baaf8-4ff8-4e84-4be3-030b95ab5a5e@huawei.com/ Suggested-by: Lu Baolu Signed-off-by: Longpeng(Mike) Acked-by: Lu Baolu Link: https://lore.kernel.org/r/20210415004628.1779-1-longpeng2@huawei.com Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit a72354b22114e35427bcbdd54427928302ced0f2 Author: Joel Stanley Date: Wed Mar 31 00:15:37 2021 +1030 jffs2: Hook up splice_write callback commit 42984af09afc414d540fcc8247f42894b0378a91 upstream. overlayfs using jffs2 as the upper filesystem would fail in some cases since moving to v5.10. The test case used was to run 'touch' on a file that exists in the lower fs, causing the modification time to be updated. It returns EINVAL when the bug is triggered. A bisection showed this was introduced in v5.9-rc1, with commit 36e2c7421f02 ("fs: don't allow splice read/write without explicit ops"). Reverting that commit restores the expected behaviour. Some digging showed that this was due to jffs2 lacking an implementation of splice_write. (For unknown reasons the warn_unsupported that should trigger was not displaying any output). Adding this patch resolved the issue and the test now passes. Cc: stable@vger.kernel.org Fixes: 36e2c7421f02 ("fs: don't allow splice read/write without explicit ops") Signed-off-by: Joel Stanley Reviewed-by: Christoph Hellwig Tested-by: Lei YU Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit 58db0dd22decdb97f44cf126999562c88de67dcf Author: lizhe Date: Thu Mar 18 11:06:57 2021 +0800 jffs2: Fix kasan slab-out-of-bounds problem commit 960b9a8a7676b9054d8b46a2c7db52a0c8766b56 upstream. KASAN report a slab-out-of-bounds problem. The logs are listed below. It is because in function jffs2_scan_dirent_node, we alloc "checkedlen+1" bytes for fd->name and we check crc with length rd->nsize. If checkedlen is less than rd->nsize, it will cause the slab-out-of-bounds problem. jffs2: Dirent at *** has zeroes in name. Truncating to %d char ================================================================== BUG: KASAN: slab-out-of-bounds in crc32_le+0x1ce/0x260 at addr ffff8800842cf2d1 Read of size 1 by task test_JFFS2/915 ============================================================================= BUG kmalloc-64 (Tainted: G B O ): kasan: bad access detected ----------------------------------------------------------------------------- INFO: Allocated in jffs2_alloc_full_dirent+0x2a/0x40 age=0 cpu=1 pid=915 ___slab_alloc+0x580/0x5f0 __slab_alloc.isra.24+0x4e/0x64 __kmalloc+0x170/0x300 jffs2_alloc_full_dirent+0x2a/0x40 jffs2_scan_eraseblock+0x1ca4/0x3b64 jffs2_scan_medium+0x285/0xfe0 jffs2_do_mount_fs+0x5fb/0x1bbc jffs2_do_fill_super+0x245/0x6f0 jffs2_fill_super+0x287/0x2e0 mount_mtd_aux.isra.0+0x9a/0x144 mount_mtd+0x222/0x2f0 jffs2_mount+0x41/0x60 mount_fs+0x63/0x230 vfs_kern_mount.part.6+0x6c/0x1f4 do_mount+0xae8/0x1940 SyS_mount+0x105/0x1d0 INFO: Freed in jffs2_free_full_dirent+0x22/0x40 age=27 cpu=1 pid=915 __slab_free+0x372/0x4e4 kfree+0x1d4/0x20c jffs2_free_full_dirent+0x22/0x40 jffs2_build_remove_unlinked_inode+0x17a/0x1e4 jffs2_do_mount_fs+0x1646/0x1bbc jffs2_do_fill_super+0x245/0x6f0 jffs2_fill_super+0x287/0x2e0 mount_mtd_aux.isra.0+0x9a/0x144 mount_mtd+0x222/0x2f0 jffs2_mount+0x41/0x60 mount_fs+0x63/0x230 vfs_kern_mount.part.6+0x6c/0x1f4 do_mount+0xae8/0x1940 SyS_mount+0x105/0x1d0 entry_SYSCALL_64_fastpath+0x1e/0x97 Call Trace: [] dump_stack+0x59/0x7e [] print_trailer+0x125/0x1b0 [] object_err+0x34/0x40 [] kasan_report.part.1+0x21f/0x534 [] ? vprintk+0x2d/0x40 [] ? crc32_le+0x1ce/0x260 [] kasan_report+0x26/0x30 [] __asan_load1+0x3d/0x50 [] crc32_le+0x1ce/0x260 [] ? jffs2_alloc_full_dirent+0x2a/0x40 [] jffs2_scan_eraseblock+0x1d0c/0x3b64 [] ? jffs2_scan_medium+0xccf/0xfe0 [] ? jffs2_scan_make_ino_cache+0x14c/0x14c [] ? kasan_unpoison_shadow+0x35/0x50 [] ? kasan_unpoison_shadow+0x35/0x50 [] ? kasan_kmalloc+0x5e/0x70 [] ? kmem_cache_alloc_trace+0x10c/0x2cc [] ? mtd_point+0xf7/0x130 [] jffs2_scan_medium+0x285/0xfe0 [] ? jffs2_scan_eraseblock+0x3b64/0x3b64 [] ? kasan_unpoison_shadow+0x35/0x50 [] ? kasan_unpoison_shadow+0x35/0x50 [] ? kasan_kmalloc+0x5e/0x70 [] ? __kmalloc+0x12b/0x300 [] ? kasan_kmalloc+0x5e/0x70 [] ? jffs2_sum_init+0x9f/0x240 [] jffs2_do_mount_fs+0x5fb/0x1bbc [] ? jffs2_del_noinode_dirent+0x640/0x640 [] ? kasan_kmalloc+0x5e/0x70 [] ? __init_rwsem+0x97/0xac [] jffs2_do_fill_super+0x245/0x6f0 [] jffs2_fill_super+0x287/0x2e0 [] ? jffs2_parse_options+0x594/0x594 [] mount_mtd_aux.isra.0+0x9a/0x144 [] mount_mtd+0x222/0x2f0 [] ? jffs2_parse_options+0x594/0x594 [] ? mount_mtd_aux.isra.0+0x144/0x144 [] ? free_pages+0x13/0x1c [] ? selinux_sb_copy_data+0x278/0x2e0 [] jffs2_mount+0x41/0x60 [] mount_fs+0x63/0x230 [] ? alloc_vfsmnt+0x32f/0x3b0 [] vfs_kern_mount.part.6+0x6c/0x1f4 [] do_mount+0xae8/0x1940 [] ? audit_filter_rules.constprop.6+0x1d10/0x1d10 [] ? copy_mount_string+0x40/0x40 [] ? alloc_pages_current+0xa4/0x1bc [] ? __get_free_pages+0x25/0x50 [] ? copy_mount_options.part.17+0x183/0x264 [] SyS_mount+0x105/0x1d0 [] ? copy_mnt_ns+0x560/0x560 [] ? msa_space_switch_handler+0x13d/0x190 [] entry_SYSCALL_64_fastpath+0x1e/0x97 [] ? msa_space_switch+0xb0/0xe0 Memory state around the buggy address: ffff8800842cf180: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff8800842cf200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff8800842cf280: fc fc fc fc fc fc 00 00 00 00 01 fc fc fc fc fc ^ ffff8800842cf300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff8800842cf380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ================================================================== Cc: stable@vger.kernel.org Reported-by: Kunkun Xu Signed-off-by: lizhe Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit 5f41065f6960a808f64e464d945ea3d89c1431c0 Author: Hansem Ro Date: Thu May 6 13:27:10 2021 -0700 Input: ili210x - add missing negation for touch indication on ili210x commit ac05a8a927e5a1027592d8f98510a511dadeed14 upstream. This adds the negation needed for proper finger detection on Ilitek ili2107/ili210x. This fixes polling issues (on Amazon Kindle Fire) caused by returning false for the cooresponding finger on the touchscreen. Signed-off-by: Hansem Ro Fixes: e3559442afd2a ("ili210x - rework the touchscreen sample processing") Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 7e65ea887d0c0997f3053acd91a027af45e71c5b Author: Trond Myklebust Date: Sun Apr 18 15:00:45 2021 -0400 NFSv4: Don't discard segments marked for return in _pnfs_return_layout() commit de144ff4234f935bd2150108019b5d87a90a8a96 upstream. If the pNFS layout segment is marked with the NFS_LSEG_LAYOUTRETURN flag, then the assumption is that it has some reporting requirement to perform through a layoutreturn (e.g. flexfiles layout stats or error information). Fixes: 6d597e175012 ("pnfs: only tear down lsegs that precede seqid in LAYOUTRETURN args") Cc: stable@vger.kernel.org Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 7cf20aa8a194a1c9913aa69c297e6d9b0af05598 Author: Trond Myklebust Date: Thu Apr 15 15:41:57 2021 -0400 NFS: Don't discard pNFS layout segments that are marked for return commit 39fd01863616964f009599e50ca5c6ea9ebf88d6 upstream. If the pNFS layout segment is marked with the NFS_LSEG_LAYOUTRETURN flag, then the assumption is that it has some reporting requirement to perform through a layoutreturn (e.g. flexfiles layout stats or error information). Fixes: e0b7d420f72a ("pNFS: Don't discard layout segments that are marked for return") Cc: stable@vger.kernel.org Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 3d0163821c035040a46d816a42c0780f0f0a30a8 Author: Randy Dunlap Date: Mon Mar 1 16:19:30 2021 -0800 NFS: fs_context: validate UDP retrans to prevent shift out-of-bounds commit c09f11ef35955785f92369e25819bf0629df2e59 upstream. Fix shift out-of-bounds in xprt_calc_majortimeo(). This is caused by a garbage timeout (retrans) mount option being passed to nfs mount, in this case from syzkaller. If the protocol is XPRT_TRANSPORT_UDP, then 'retrans' is a shift value for a 64-bit long integer, so 'retrans' cannot be >= 64. If it is >= 64, fail the mount and return an error. Fixes: 9954bf92c0cd ("NFS: Move mount parameterisation bits into their own file") Reported-by: syzbot+ba2e91df8f74809417fa@syzkaller.appspotmail.com Reported-by: syzbot+f3a0fa110fd630ab56c8@syzkaller.appspotmail.com Signed-off-by: Randy Dunlap Cc: Trond Myklebust Cc: Anna Schumaker Cc: linux-nfs@vger.kernel.org Cc: David Howells Cc: Al Viro Cc: stable@vger.kernel.org Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 596e079c362ac17ed02aa1b99fdc444d62072a01 Author: Marc Zyngier Date: Wed Apr 21 17:43:16 2021 +0100 ACPI: GTDT: Don't corrupt interrupt mappings on watchdow probe failure commit 1ecd5b129252249b9bc03d7645a7bda512747277 upstream. When failing the driver probe because of invalid firmware properties, the GTDT driver unmaps the interrupt that it mapped earlier. However, it never checks whether the mapping of the interrupt actially succeeded. Even more, should the firmware report an illegal interrupt number that overlaps with the GIC SGI range, this can result in an IPI being unmapped, and subsequent fireworks (as reported by Dann Frazier). Rework the driver to have a slightly saner behaviour and actually check whether the interrupt has been mapped before unmapping things. Reported-by: dann frazier Fixes: ca9ae5ec4ef0 ("acpi/arm64: Add SBSA Generic Watchdog support in GTDT driver") Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/YH87dtTfwYgavusz@xps13.dannf Cc: Cc: Fu Wei Reviewed-by: Sudeep Holla Tested-by: dann frazier Tested-by: Hanjun Guo Reviewed-by: Hanjun Guo Reviewed-by: Lorenzo Pieralisi Link: https://lore.kernel.org/r/20210421164317.1718831-2-maz@kernel.org Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 8e6dfb7beeb6489ac1365b8a71052e737f5da76e Author: Davide Caratti Date: Wed Apr 28 15:23:14 2021 +0200 net/sched: sch_frag: fix stack OOB read while fragmenting IPv4 packets commit 31fe34a0118e0acc958c802e830ad5d37ef6b1d3 upstream. when 'act_mirred' tries to fragment IPv4 packets that had been previously re-assembled using 'act_ct', splats like the following can be observed on kernels built with KASAN: BUG: KASAN: stack-out-of-bounds in ip_do_fragment+0x1b03/0x1f60 Read of size 1 at addr ffff888147009574 by task ping/947 CPU: 0 PID: 947 Comm: ping Not tainted 5.12.0-rc6+ #418 Hardware name: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 04/01/2014 Call Trace: dump_stack+0x92/0xc1 print_address_description.constprop.7+0x1a/0x150 kasan_report.cold.13+0x7f/0x111 ip_do_fragment+0x1b03/0x1f60 sch_fragment+0x4bf/0xe40 tcf_mirred_act+0xc3d/0x11a0 [act_mirred] tcf_action_exec+0x104/0x3e0 fl_classify+0x49a/0x5e0 [cls_flower] tcf_classify_ingress+0x18a/0x820 __netif_receive_skb_core+0xae7/0x3340 __netif_receive_skb_one_core+0xb6/0x1b0 process_backlog+0x1ef/0x6c0 __napi_poll+0xaa/0x500 net_rx_action+0x702/0xac0 __do_softirq+0x1e4/0x97f do_softirq+0x71/0x90 __local_bh_enable_ip+0xdb/0xf0 ip_finish_output2+0x760/0x2120 ip_do_fragment+0x15a5/0x1f60 __ip_finish_output+0x4c2/0xea0 ip_output+0x1ca/0x4d0 ip_send_skb+0x37/0xa0 raw_sendmsg+0x1c4b/0x2d00 sock_sendmsg+0xdb/0x110 __sys_sendto+0x1d7/0x2b0 __x64_sys_sendto+0xdd/0x1b0 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f82e13853eb Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 f3 0f 1e fa 48 8d 05 75 42 2c 00 41 89 ca 8b 00 85 c0 75 14 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 75 c3 0f 1f 40 00 41 57 4d 89 c7 41 56 41 89 RSP: 002b:00007ffe01fad888 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00005571aac13700 RCX: 00007f82e13853eb RDX: 0000000000002330 RSI: 00005571aac13700 RDI: 0000000000000003 RBP: 0000000000002330 R08: 00005571aac10500 R09: 0000000000000010 R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffe01faefb0 R13: 00007ffe01fad890 R14: 00007ffe01fad980 R15: 00005571aac0f0a0 The buggy address belongs to the page: page:000000001dff2e03 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x147009 flags: 0x17ffffc0001000(reserved) raw: 0017ffffc0001000 ffffea00051c0248 ffffea00051c0248 0000000000000000 raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888147009400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888147009480: f1 f1 f1 f1 04 f2 f2 f2 f2 f2 f2 f2 00 00 00 00 >ffff888147009500: 00 00 00 00 00 00 00 00 00 00 f2 f2 f2 f2 f2 f2 ^ ffff888147009580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888147009600: 00 00 00 00 00 00 00 00 00 00 00 00 00 f2 f2 f2 for IPv4 packets, sch_fragment() uses a temporary struct dst_entry. Then, in the following call graph: ip_do_fragment() ip_skb_dst_mtu() ip_dst_mtu_maybe_forward() ip_mtu_locked() the pointer to struct dst_entry is used as pointer to struct rtable: this turns the access to struct members like rt_mtu_locked into an OOB read in the stack. Fix this changing the temporary variable used for IPv4 packets in sch_fragment(), similarly to what is done for IPv6 few lines below. Fixes: c129412f74e9 ("net/sched: sch_frag: add generic packet fragment support.") Cc: # 5.11 Reported-by: Shuang Li Acked-by: Marcelo Ricardo Leitner Acked-by: Cong Wang Signed-off-by: Davide Caratti Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b3502b04e84ac5349be95fc033c17bd701d2787a Author: Davide Caratti Date: Wed Apr 28 15:23:07 2021 +0200 openvswitch: fix stack OOB read while fragmenting IPv4 packets commit 7c0ea5930c1c211931819d83cfb157bff1539a4c upstream. running openvswitch on kernels built with KASAN, it's possible to see the following splat while testing fragmentation of IPv4 packets: BUG: KASAN: stack-out-of-bounds in ip_do_fragment+0x1b03/0x1f60 Read of size 1 at addr ffff888112fc713c by task handler2/1367 CPU: 0 PID: 1367 Comm: handler2 Not tainted 5.12.0-rc6+ #418 Hardware name: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 04/01/2014 Call Trace: dump_stack+0x92/0xc1 print_address_description.constprop.7+0x1a/0x150 kasan_report.cold.13+0x7f/0x111 ip_do_fragment+0x1b03/0x1f60 ovs_fragment+0x5bf/0x840 [openvswitch] do_execute_actions+0x1bd5/0x2400 [openvswitch] ovs_execute_actions+0xc8/0x3d0 [openvswitch] ovs_packet_cmd_execute+0xa39/0x1150 [openvswitch] genl_family_rcv_msg_doit.isra.15+0x227/0x2d0 genl_rcv_msg+0x287/0x490 netlink_rcv_skb+0x120/0x380 genl_rcv+0x24/0x40 netlink_unicast+0x439/0x630 netlink_sendmsg+0x719/0xbf0 sock_sendmsg+0xe2/0x110 ____sys_sendmsg+0x5ba/0x890 ___sys_sendmsg+0xe9/0x160 __sys_sendmsg+0xd3/0x170 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f957079db07 Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 eb ec ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 24 ed ff ff 48 RSP: 002b:00007f956ce35a50 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000000000000019 RCX: 00007f957079db07 RDX: 0000000000000000 RSI: 00007f956ce35ae0 RDI: 0000000000000019 RBP: 00007f956ce35ae0 R08: 0000000000000000 R09: 00007f9558006730 R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 00007f956ce37308 R14: 00007f956ce35f80 R15: 00007f956ce35ae0 The buggy address belongs to the page: page:00000000af2a1d93 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x112fc7 flags: 0x17ffffc0000000() raw: 0017ffffc0000000 0000000000000000 dead000000000122 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected addr ffff888112fc713c is located in stack of task handler2/1367 at offset 180 in frame: ovs_fragment+0x0/0x840 [openvswitch] this frame has 2 objects: [32, 144) 'ovs_dst' [192, 424) 'ovs_rt' Memory state around the buggy address: ffff888112fc7000: f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888112fc7080: 00 f1 f1 f1 f1 00 00 00 00 00 00 00 00 00 00 00 >ffff888112fc7100: 00 00 00 f2 f2 f2 f2 f2 f2 00 00 00 00 00 00 00 ^ ffff888112fc7180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888112fc7200: 00 00 00 00 00 00 f2 f2 f2 00 00 00 00 00 00 00 for IPv4 packets, ovs_fragment() uses a temporary struct dst_entry. Then, in the following call graph: ip_do_fragment() ip_skb_dst_mtu() ip_dst_mtu_maybe_forward() ip_mtu_locked() the pointer to struct dst_entry is used as pointer to struct rtable: this turns the access to struct members like rt_mtu_locked into an OOB read in the stack. Fix this changing the temporary variable used for IPv4 packets in ovs_fragment(), similarly to what is done for IPv6 few lines below. Fixes: d52e5a7e7ca4 ("ipv4: lock mtu in fnhe when received PMTU < net.ipv4.route.min_pmt") Cc: Acked-by: Eelco Chaudron Signed-off-by: Davide Caratti Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit e0041e24ad15a685da41b3b6fd0ccd26ab90815d Author: Ido Schimmel Date: Thu May 6 10:23:08 2021 +0300 mlxsw: spectrum_mr: Update egress RIF list before route's action commit cbaf3f6af9c268caf558c8e7ec52bcb35c5455dd upstream. Each multicast route that is forwarding packets (as opposed to trapping them) points to a list of egress router interfaces (RIFs) through which packets are replicated. A route's action can transition from trap to forward when a RIF is created for one of the route's egress virtual interfaces (eVIF). When this happens, the route's action is first updated and only later the list of egress RIFs is committed to the device. This results in the route pointing to an invalid list. In case the list pointer is out of range (due to uninitialized memory), the device will complain: mlxsw_spectrum2 0000:06:00.0: EMAD reg access failed (tid=5733bf490000905c,reg_id=300f(pefa),type=write,status=7(bad parameter)) Fix this by first committing the list of egress RIFs to the device and only later update the route's action. Note that a fix is not needed in the reverse function (i.e., mlxsw_sp_mr_route_evif_unresolve()), as there the route's action is first updated and only later the RIF is removed from the list. Cc: stable@vger.kernel.org Fixes: c011ec1bbfd6 ("mlxsw: spectrum: Add the multicast routing offloading logic") Signed-off-by: Ido Schimmel Reviewed-by: Petr Machata Link: https://lore.kernel.org/r/20210506072308.3834303-1-idosch@idosch.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 0b60f23e29c8dfcf1b8a037fae1167e4f2e3249e Author: Chao Yu Date: Mon Mar 22 19:47:30 2021 +0800 f2fs: fix to avoid out-of-bounds memory access commit b862676e371715456c9dade7990c8004996d0d9e upstream. butt3rflyh4ck reported a bug found by syzkaller fuzzer with custom modifications in 5.12.0-rc3+ [1]: dump_stack+0xfa/0x151 lib/dump_stack.c:120 print_address_description.constprop.0.cold+0x82/0x32c mm/kasan/report.c:232 __kasan_report mm/kasan/report.c:399 [inline] kasan_report.cold+0x7c/0xd8 mm/kasan/report.c:416 f2fs_test_bit fs/f2fs/f2fs.h:2572 [inline] current_nat_addr fs/f2fs/node.h:213 [inline] get_next_nat_page fs/f2fs/node.c:123 [inline] __flush_nat_entry_set fs/f2fs/node.c:2888 [inline] f2fs_flush_nat_entries+0x258e/0x2960 fs/f2fs/node.c:2991 f2fs_write_checkpoint+0x1372/0x6a70 fs/f2fs/checkpoint.c:1640 f2fs_issue_checkpoint+0x149/0x410 fs/f2fs/checkpoint.c:1807 f2fs_sync_fs+0x20f/0x420 fs/f2fs/super.c:1454 __sync_filesystem fs/sync.c:39 [inline] sync_filesystem fs/sync.c:67 [inline] sync_filesystem+0x1b5/0x260 fs/sync.c:48 generic_shutdown_super+0x70/0x370 fs/super.c:448 kill_block_super+0x97/0xf0 fs/super.c:1394 The root cause is, if nat entry in checkpoint journal area is corrupted, e.g. nid of journalled nat entry exceeds max nid value, during checkpoint, once it tries to flush nat journal to NAT area, get_next_nat_page() may access out-of-bounds memory on nat_bitmap due to it uses wrong nid value as bitmap offset. [1] https://lore.kernel.org/lkml/CAFcO6XOMWdr8pObek6eN6-fs58KG9doRFadgJj-FnF-1x43s2g@mail.gmail.com/T/#u Reported-and-tested-by: butt3rflyh4ck Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit befeb96e17f7923a5d891b5b55995a6ab745cd05 Author: Eric Biggers Date: Thu Mar 4 21:43:10 2021 -0800 f2fs: fix error handling in f2fs_end_enable_verity() commit 3c0315424f5e3d2a4113c7272367bee1e8e6a174 upstream. f2fs didn't properly clean up if verity failed to be enabled on a file: - It left verity metadata (pages past EOF) in the page cache, which would be exposed to userspace if the file was later extended. - It didn't truncate the verity metadata at all (either from cache or from disk) if an error occurred while setting the verity bit. Fix these bugs by adding a call to truncate_inode_pages() and ensuring that we truncate the verity metadata (both from cache and from disk) in all error paths. Also rework the code to cleanly separate the success path from the error paths, which makes it much easier to understand. Finally, log a message if f2fs_truncate() fails, since it might otherwise fail silently. Reported-by: Yunlei He Fixes: 95ae251fe828 ("f2fs: add fs-verity support") Cc: # v5.4+ Signed-off-by: Eric Biggers Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 325b731983d010d358505bf2c40f5e0069af62d2 Author: Guochun Mao Date: Tue Mar 16 16:52:14 2021 +0800 ubifs: Only check replay with inode type to judge if inode linked commit 3e903315790baf4a966436e7f32e9c97864570ac upstream. Conside the following case, it just write a big file into flash, when complete writing, delete the file, and then power off promptly. Next time power on, we'll get a replay list like: ... LEB 1105:211344 len 4144 deletion 0 sqnum 428783 key type 1 inode 80 LEB 15:233544 len 160 deletion 1 sqnum 428785 key type 0 inode 80 LEB 1105:215488 len 4144 deletion 0 sqnum 428787 key type 1 inode 80 ... In the replay list, data nodes' deletion are 0, and the inode node's deletion is 1. In current logic, the file's dentry will be removed, but inode and the flash space it occupied will be reserved. User will see that much free space been disappeared. We only need to check the deletion value of the following inode type node of the replay entry. Fixes: e58725d51fa8 ("ubifs: Handle re-linking of inodes correctly while recovery") Cc: stable@vger.kernel.org Signed-off-by: Guochun Mao Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit 205332585eebe3faddb4c77eeff7ef9bf9fd375c Author: Marco Elver Date: Wed Mar 3 10:38:45 2021 +0100 kcsan, debugfs: Move debugfs file creation out of early init commit e36299efe7d749976fbdaaf756dee6ef32543c2c upstream. Commit 56348560d495 ("debugfs: do not attempt to create a new file before the filesystem is initalized") forbids creating new debugfs files until debugfs is fully initialized. This means that KCSAN's debugfs file creation, which happened at the end of __init(), no longer works. And was apparently never supposed to work! However, there is no reason to create KCSAN's debugfs file so early. This commit therefore moves its creation to a late_initcall() callback. Cc: "Rafael J. Wysocki" Cc: stable Fixes: 56348560d495 ("debugfs: do not attempt to create a new file before the filesystem is initalized") Reviewed-by: Greg Kroah-Hartman Signed-off-by: Marco Elver Signed-off-by: Paul E. McKenney Signed-off-by: Greg Kroah-Hartman commit 5116e79fc6e6725b8acdad8b7e928a83ab7b47e6 Author: Luis Henriques Date: Wed Mar 17 08:44:43 2021 +0000 virtiofs: fix memory leak in virtio_fs_probe() commit c79c5e0178922a9e092ec8fed026750f39dcaef4 upstream. When accidentally passing twice the same tag to qemu, kmemleak ended up reporting a memory leak in virtiofs. Also, looking at the log I saw the following error (that's when I realised the duplicated tag): virtiofs: probe of virtio5 failed with error -17 Here's the kmemleak log for reference: unreferenced object 0xffff888103d47800 (size 1024): comm "systemd-udevd", pid 118, jiffies 4294893780 (age 18.340s) hex dump (first 32 bytes): 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... ff ff ff ff ff ff ff ff 80 90 02 a0 ff ff ff ff ................ backtrace: [<000000000ebb87c1>] virtio_fs_probe+0x171/0x7ae [virtiofs] [<00000000f8aca419>] virtio_dev_probe+0x15f/0x210 [<000000004d6baf3c>] really_probe+0xea/0x430 [<00000000a6ceeac8>] device_driver_attach+0xa8/0xb0 [<00000000196f47a7>] __driver_attach+0x98/0x140 [<000000000b20601d>] bus_for_each_dev+0x7b/0xc0 [<00000000399c7b7f>] bus_add_driver+0x11b/0x1f0 [<0000000032b09ba7>] driver_register+0x8f/0xe0 [<00000000cdd55998>] 0xffffffffa002c013 [<000000000ea196a2>] do_one_initcall+0x64/0x2e0 [<0000000008f727ce>] do_init_module+0x5c/0x260 [<000000003cdedab6>] __do_sys_finit_module+0xb5/0x120 [<00000000ad2f48c6>] do_syscall_64+0x33/0x40 [<00000000809526b5>] entry_SYSCALL_64_after_hwframe+0x44/0xae Cc: stable@vger.kernel.org Signed-off-by: Luis Henriques Fixes: a62a8ef9d97d ("virtio-fs: add virtiofs filesystem") Reviewed-by: Stefan Hajnoczi Reviewed-by: Vivek Goyal Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit f7c80e8a1b0bf3fe9175f723b65567a2cb71e08f Author: Theodore Ts'o Date: Sat Apr 17 23:03:50 2021 -0400 fs: fix reporting supported extra file attributes for statx() commit 5afa7e8b70d65819245fece61a65fd753b4aae33 upstream. statx(2) notes that any attribute that is not indicated as supported by stx_attributes_mask has no usable value. Commits 801e523796004 ("fs: move generic stat response attr handling to vfs_getattr_nosec") and 712b2698e4c02 ("fs/stat: Define DAX statx attribute") sets STATX_ATTR_AUTOMOUNT and STATX_ATTR_DAX, respectively, without setting stx_attributes_mask, which can cause xfstests generic/532 to fail. Fix this in the same way as commit 1b9598c8fb99 ("xfs: fix reporting supported extra file attributes for statx()") Fixes: 801e523796004 ("fs: move generic stat response attr handling to vfs_getattr_nosec") Fixes: 712b2698e4c02 ("fs/stat: Define DAX statx attribute") Cc: stable@kernel.org Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit fd0f06590d35c99f98d12c7984897ec4201a6263 Author: Liao Chang Date: Tue Mar 30 16:18:48 2021 +0800 riscv/kprobe: fix kernel panic when invoking sys_read traced by kprobe commit b1ebaa0e1318494a7637099a26add50509e37964 upstream. The execution of sys_read end up hitting a BUG_ON() in __find_get_block after installing kprobe at sys_read, the BUG message like the following: [ 65.708663] ------------[ cut here ]------------ [ 65.709987] kernel BUG at fs/buffer.c:1251! [ 65.711283] Kernel BUG [#1] [ 65.712032] Modules linked in: [ 65.712925] CPU: 0 PID: 51 Comm: sh Not tainted 5.12.0-rc4 #1 [ 65.714407] Hardware name: riscv-virtio,qemu (DT) [ 65.715696] epc : __find_get_block+0x218/0x2c8 [ 65.716835] ra : __getblk_gfp+0x1c/0x4a [ 65.717831] epc : ffffffe00019f11e ra : ffffffe00019f56a sp : ffffffe002437930 [ 65.719553] gp : ffffffe000f06030 tp : ffffffe0015abc00 t0 : ffffffe00191e038 [ 65.721290] t1 : ffffffe00191e038 t2 : 000000000000000a s0 : ffffffe002437960 [ 65.723051] s1 : ffffffe00160ad00 a0 : ffffffe00160ad00 a1 : 000000000000012a [ 65.724772] a2 : 0000000000000400 a3 : 0000000000000008 a4 : 0000000000000040 [ 65.726545] a5 : 0000000000000000 a6 : ffffffe00191e000 a7 : 0000000000000000 [ 65.728308] s2 : 000000000000012a s3 : 0000000000000400 s4 : 0000000000000008 [ 65.730049] s5 : 000000000000006c s6 : ffffffe00240f800 s7 : ffffffe000f080a8 [ 65.731802] s8 : 0000000000000001 s9 : 000000000000012a s10: 0000000000000008 [ 65.733516] s11: 0000000000000008 t3 : 00000000000003ff t4 : 000000000000000f [ 65.734434] t5 : 00000000000003ff t6 : 0000000000040000 [ 65.734613] status: 0000000000000100 badaddr: 0000000000000000 cause: 0000000000000003 [ 65.734901] Call Trace: [ 65.735076] [] __find_get_block+0x218/0x2c8 [ 65.735417] [] __ext4_get_inode_loc+0xb2/0x2f6 [ 65.735618] [] ext4_get_inode_loc+0x3a/0x8a [ 65.735802] [] ext4_reserve_inode_write+0x2e/0x8c [ 65.735999] [] __ext4_mark_inode_dirty+0x4c/0x18e [ 65.736208] [] ext4_dirty_inode+0x46/0x66 [ 65.736387] [] __mark_inode_dirty+0x12c/0x3da [ 65.736576] [] touch_atime+0x146/0x150 [ 65.736748] [] filemap_read+0x234/0x246 [ 65.736920] [] generic_file_read_iter+0xc0/0x114 [ 65.737114] [] ext4_file_read_iter+0x42/0xea [ 65.737310] [] new_sync_read+0xe2/0x15a [ 65.737483] [] vfs_read+0xca/0xf2 [ 65.737641] [] ksys_read+0x5e/0xc8 [ 65.737816] [] sys_read+0xe/0x16 [ 65.737973] [] ret_from_syscall+0x0/0x2 [ 65.738858] ---[ end trace fe93f985456c935d ]--- A simple reproducer looks like: echo 'p:myprobe sys_read fd=%a0 buf=%a1 count=%a2' > /sys/kernel/debug/tracing/kprobe_events echo 1 > /sys/kernel/debug/tracing/events/kprobes/myprobe/enable cat /sys/kernel/debug/tracing/trace Here's what happens to hit that BUG_ON(): 1) After installing kprobe at entry of sys_read, the first instruction is replaced by 'ebreak' instruction on riscv64 platform. 2) Once kernel reach the 'ebreak' instruction at the entry of sys_read, it trap into the riscv breakpoint handler, where it do something to setup for coming single-step of origin instruction, including backup the 'sstatus' in pt_regs, followed by disable interrupt during single stepping via clear 'SIE' bit of 'sstatus' in pt_regs. 3) Then kernel restore to the instruction slot contains two instructions, one is original instruction at entry of sys_read, the other is 'ebreak'. Here it trigger a 'Instruction page fault' exception (value at 'scause' is '0xc'), if PF is not filled into PageTabe for that slot yet. 4) Again kernel trap into page fault exception handler, where it choose different policy according to the state of running kprobe. Because afte 2) the state is KPROBE_HIT_SS, so kernel reset the current kprobe and 'pc' points back to the probe address. 5) Because 'epc' point back to 'ebreak' instrution at sys_read probe, kernel trap into breakpoint handler again, and repeat the operations at 2), however 'sstatus' without 'SIE' is keep at 4), it cause the real 'sstatus' saved at 2) is overwritten by the one withou 'SIE'. 6) When kernel cross the probe the 'sstatus' CSR restore with value without 'SIE', and reach __find_get_block where it requires the interrupt must be enabled. Fix this is very trivial, just restore the value of 'sstatus' in pt_regs with backup one at 2) when the instruction being single stepped cause a page fault. Fixes: c22b0bcb1dd02 ("riscv: Add kprobes supported") Signed-off-by: Liao Chang Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt Signed-off-by: Greg Kroah-Hartman commit e4228d7587b6323326618006cb64a0425c798af6 Author: Nathan Chancellor Date: Wed Apr 28 18:23:50 2021 -0700 Makefile: Move -Wno-unused-but-set-variable out of GCC only block commit 885480b084696331bea61a4f7eba10652999a9c1 upstream. Currently, -Wunused-but-set-variable is only supported by GCC so it is disabled unconditionally in a GCC only block (it is enabled with W=1). clang currently has its implementation for this warning in review so preemptively move this statement out of the GCC only block and wrap it with cc-disable-warning so that both compilers function the same. Cc: stable@vger.kernel.org Link: https://reviews.llvm.org/D100581 Signed-off-by: Nathan Chancellor Reviewed-by: Nick Desaulniers Tested-by: Nick Desaulniers Signed-off-by: Masahiro Yamada Signed-off-by: Greg Kroah-Hartman commit 48f9d3dd62833c3318a869ed895937ecd1de8fc1 Author: Bill Wendling Date: Fri Apr 23 13:51:59 2021 -0700 arm64/vdso: Discard .note.gnu.property sections in vDSO [ Upstream commit 388708028e6937f3fc5fc19aeeb847f8970f489c ] The arm64 assembler in binutils 2.32 and above generates a program property note in a note section, .note.gnu.property, to encode used x86 ISAs and features. But the kernel linker script only contains a single NOTE segment: PHDRS { text PT_LOAD FLAGS(5) FILEHDR PHDRS; /* PF_R|PF_X */ dynamic PT_DYNAMIC FLAGS(4); /* PF_R */ note PT_NOTE FLAGS(4); /* PF_R */ } The NOTE segment generated by the vDSO linker script is aligned to 4 bytes. But the .note.gnu.property section must be aligned to 8 bytes on arm64. $ readelf -n vdso64.so Displaying notes found in: .note Owner Data size Description Linux 0x00000004 Unknown note type: (0x00000000) description data: 06 00 00 00 readelf: Warning: note with invalid namesz and/or descsz found at offset 0x20 readelf: Warning: type: 0x78, namesize: 0x00000100, descsize: 0x756e694c, alignment: 8 Since the note.gnu.property section in the vDSO is not checked by the dynamic linker, discard the .note.gnu.property sections in the vDSO. Similar to commit 4caffe6a28d31 ("x86/vdso: Discard .note.gnu.property sections in vDSO"), but for arm64. Signed-off-by: Bill Wendling Reviewed-by: Kees Cook Acked-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20210423205159.830854-1-morbo@google.com Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 868c10b9be11ac0c9cc8adb3559a1b6d21bef4e8 Author: BingJing Chang Date: Thu Mar 25 09:56:22 2021 +0800 btrfs: fix a potential hole punching failure [ Upstream commit 3227788cd369d734d2d3cd94f8af7536b60fa552 ] In commit d77815461f04 ("btrfs: Avoid trucating page or punching hole in a already existed hole."), existing holes can be skipped by calling find_first_non_hole() to adjust start and len. However, if the given len is invalid and large, when an EXTENT_MAP_HOLE extent is found, len will not be set to zero because (em->start + em->len) is less than (start + len). Then the ret will be 1 but len will not be set to 0. The propagated non-zero ret will result in fallocate failure. In the while-loop of btrfs_replace_file_extents(), len is not updated every time before it calls find_first_non_hole(). That is, after btrfs_drop_extents() successfully drops the last non-hole file extent, it may fail with ENOSPC when attempting to drop a file extent item representing a hole. The problem can happen. After it calls find_first_non_hole(), the cur_offset will be adjusted to be larger than or equal to end. However, since the len is not set to zero, the break-loop condition (ret && !len) will not be met. After it leaves the while-loop, fallocate will return 1, which is an unexpected return value. We're not able to construct a reproducible way to let btrfs_drop_extents() fail with ENOSPC after it drops the last non-hole file extent but with remaining holes left. However, it's quite easy to fix. We just need to update and check the len every time before we call find_first_non_hole(). To make the while loop more readable, we also pull the variable updates to the bottom of loop like this: while (cur_offset < end) { ... // update cur_offset & len // advance cur_offset & len in hole-punching case if needed } Reported-by: Robbie Ko Fixes: d77815461f04 ("btrfs: Avoid trucating page or punching hole in a already existed hole.") CC: stable@vger.kernel.org # 4.4+ Reviewed-by: Robbie Ko Reviewed-by: Chung-Chiang Cheng Reviewed-by: Filipe Manana Signed-off-by: BingJing Chang Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 40b87e9b12b5fcb5dc92640c3c9ccd58397b025a Author: Filipe Manana Date: Tue Apr 20 10:55:44 2021 +0100 btrfs: fix race when picking most recent mod log operation for an old root [ Upstream commit f9690f426b2134cc3e74bfc5d9dfd6a4b2ca5281 ] Commit dbcc7d57bffc0c ("btrfs: fix race when cloning extent buffer during rewind of an old root"), fixed a race when we need to rewind the extent buffer of an old root. It was caused by picking a new mod log operation for the extent buffer while getting a cloned extent buffer with an outdated number of items (off by -1), because we cloned the extent buffer without locking it first. However there is still another similar race, but in the opposite direction. The cloned extent buffer has a number of items that does not match the number of tree mod log operations that are going to be replayed. This is because right after we got the last (most recent) tree mod log operation to replay and before locking and cloning the extent buffer, another task adds a new pointer to the extent buffer, which results in adding a new tree mod log operation and incrementing the number of items in the extent buffer. So after cloning we have mismatch between the number of items in the extent buffer and the number of mod log operations we are going to apply to it. This results in hitting a BUG_ON() that produces the following stack trace: ------------[ cut here ]------------ kernel BUG at fs/btrfs/tree-mod-log.c:675! invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 3 PID: 4811 Comm: crawl_1215 Tainted: G W 5.12.0-7d1efdf501f8-misc-next+ #99 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:tree_mod_log_rewind+0x3b1/0x3c0 Code: 05 48 8d 74 10 (...) RSP: 0018:ffffc90001027090 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8880a8514600 RCX: ffffffffaa9e59b6 RDX: 0000000000000007 RSI: dffffc0000000000 RDI: ffff8880a851462c RBP: ffffc900010270e0 R08: 00000000000000c0 R09: ffffed1004333417 R10: ffff88802199a0b7 R11: ffffed1004333416 R12: 000000000000000e R13: ffff888135af8748 R14: ffff88818766ff00 R15: ffff8880a851462c FS: 00007f29acf62700(0000) GS:ffff8881f2200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f0e6013f718 CR3: 000000010d42e003 CR4: 0000000000170ee0 Call Trace: btrfs_get_old_root+0x16a/0x5c0 ? lock_downgrade+0x400/0x400 btrfs_search_old_slot+0x192/0x520 ? btrfs_search_slot+0x1090/0x1090 ? free_extent_buffer.part.61+0xd7/0x140 ? free_extent_buffer+0x13/0x20 resolve_indirect_refs+0x3e9/0xfc0 ? lock_downgrade+0x400/0x400 ? __kasan_check_read+0x11/0x20 ? add_prelim_ref.part.11+0x150/0x150 ? lock_downgrade+0x400/0x400 ? __kasan_check_read+0x11/0x20 ? lock_acquired+0xbb/0x620 ? __kasan_check_write+0x14/0x20 ? do_raw_spin_unlock+0xa8/0x140 ? rb_insert_color+0x340/0x360 ? prelim_ref_insert+0x12d/0x430 find_parent_nodes+0x5c3/0x1830 ? stack_trace_save+0x87/0xb0 ? resolve_indirect_refs+0xfc0/0xfc0 ? fs_reclaim_acquire+0x67/0xf0 ? __kasan_check_read+0x11/0x20 ? lockdep_hardirqs_on_prepare+0x210/0x210 ? fs_reclaim_acquire+0x67/0xf0 ? __kasan_check_read+0x11/0x20 ? ___might_sleep+0x10f/0x1e0 ? __kasan_kmalloc+0x9d/0xd0 ? trace_hardirqs_on+0x55/0x120 btrfs_find_all_roots_safe+0x142/0x1e0 ? find_parent_nodes+0x1830/0x1830 ? trace_hardirqs_on+0x55/0x120 ? ulist_free+0x1f/0x30 ? btrfs_inode_flags_to_xflags+0x50/0x50 iterate_extent_inodes+0x20e/0x580 ? tree_backref_for_extent+0x230/0x230 ? release_extent_buffer+0x225/0x280 ? read_extent_buffer+0xdd/0x110 ? lock_downgrade+0x400/0x400 ? __kasan_check_read+0x11/0x20 ? lock_acquired+0xbb/0x620 ? __kasan_check_write+0x14/0x20 ? do_raw_spin_unlock+0xa8/0x140 ? _raw_spin_unlock+0x22/0x30 ? release_extent_buffer+0x225/0x280 iterate_inodes_from_logical+0x129/0x170 ? iterate_inodes_from_logical+0x129/0x170 ? btrfs_inode_flags_to_xflags+0x50/0x50 ? iterate_extent_inodes+0x580/0x580 ? __vmalloc_node+0x92/0xb0 ? init_data_container+0x34/0xb0 ? init_data_container+0x34/0xb0 ? kvmalloc_node+0x60/0x80 btrfs_ioctl_logical_to_ino+0x158/0x230 btrfs_ioctl+0x2038/0x4360 ? __kasan_check_write+0x14/0x20 ? mmput+0x3b/0x220 ? btrfs_ioctl_get_supported_features+0x30/0x30 ? __kasan_check_read+0x11/0x20 ? __kasan_check_read+0x11/0x20 ? lock_release+0xc8/0x650 ? __might_fault+0x64/0xd0 ? __kasan_check_read+0x11/0x20 ? lock_downgrade+0x400/0x400 ? lockdep_hardirqs_on_prepare+0x210/0x210 ? lockdep_hardirqs_on_prepare+0x13/0x210 ? _raw_spin_unlock_irqrestore+0x51/0x63 ? __kasan_check_read+0x11/0x20 ? do_vfs_ioctl+0xfc/0x9d0 ? ioctl_file_clone+0xe0/0xe0 ? lock_downgrade+0x400/0x400 ? lockdep_hardirqs_on_prepare+0x210/0x210 ? __kasan_check_read+0x11/0x20 ? lock_release+0xc8/0x650 ? __task_pid_nr_ns+0xd3/0x250 ? __kasan_check_read+0x11/0x20 ? __fget_files+0x160/0x230 ? __fget_light+0xf2/0x110 __x64_sys_ioctl+0xc3/0x100 do_syscall_64+0x37/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f29ae85b427 Code: 00 00 90 48 8b (...) RSP: 002b:00007f29acf5fcf8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007f29acf5ff40 RCX: 00007f29ae85b427 RDX: 00007f29acf5ff48 RSI: 00000000c038943b RDI: 0000000000000003 RBP: 0000000001000000 R08: 0000000000000000 R09: 00007f29acf60120 R10: 00005640d5fc7b00 R11: 0000000000000246 R12: 0000000000000003 R13: 00007f29acf5ff48 R14: 00007f29acf5ff40 R15: 00007f29acf5fef8 Modules linked in: ---[ end trace 85e5fce078dfbe04 ]--- (gdb) l *(tree_mod_log_rewind+0x3b1) 0xffffffff819e5b21 is in tree_mod_log_rewind (fs/btrfs/tree-mod-log.c:675). 670 * the modification. As we're going backwards, we do the 671 * opposite of each operation here. 672 */ 673 switch (tm->op) { 674 case BTRFS_MOD_LOG_KEY_REMOVE_WHILE_FREEING: 675 BUG_ON(tm->slot < n); 676 fallthrough; 677 case BTRFS_MOD_LOG_KEY_REMOVE_WHILE_MOVING: 678 case BTRFS_MOD_LOG_KEY_REMOVE: 679 btrfs_set_node_key(eb, &tm->key, tm->slot); (gdb) quit The following steps explain in more detail how it happens: 1) We have one tree mod log user (through fiemap or the logical ino ioctl), with a sequence number of 1, so we have fs_info->tree_mod_seq == 1. This is task A; 2) Another task is at ctree.c:balance_level() and we have eb X currently as the root of the tree, and we promote its single child, eb Y, as the new root. Then, at ctree.c:balance_level(), we call: ret = btrfs_tree_mod_log_insert_root(root->node, child, true); 3) At btrfs_tree_mod_log_insert_root() we create a tree mod log operation of type BTRFS_MOD_LOG_KEY_REMOVE_WHILE_FREEING, with a ->logical field pointing to ebX->start. We only have one item in eb X, so we create only one tree mod log operation, and store in the "tm_list" array; 4) Then, still at btrfs_tree_mod_log_insert_root(), we create a tree mod log element of operation type BTRFS_MOD_LOG_ROOT_REPLACE, ->logical set to ebY->start, ->old_root.logical set to ebX->start, ->old_root.level set to the level of eb X and ->generation set to the generation of eb X; 5) Then btrfs_tree_mod_log_insert_root() calls tree_mod_log_free_eb() with "tm_list" as argument. After that, tree_mod_log_free_eb() calls tree_mod_log_insert(). This inserts the mod log operation of type BTRFS_MOD_LOG_KEY_REMOVE_WHILE_FREEING from step 3 into the rbtree with a sequence number of 2 (and fs_info->tree_mod_seq set to 2); 6) Then, after inserting the "tm_list" single element into the tree mod log rbtree, the BTRFS_MOD_LOG_ROOT_REPLACE element is inserted, which gets the sequence number 3 (and fs_info->tree_mod_seq set to 3); 7) Back to ctree.c:balance_level(), we free eb X by calling btrfs_free_tree_block() on it. Because eb X was created in the current transaction, has no other references and writeback did not happen for it, we add it back to the free space cache/tree; 8) Later some other task B allocates the metadata extent from eb X, since it is marked as free space in the space cache/tree, and uses it as a node for some other btree; 9) The tree mod log user task calls btrfs_search_old_slot(), which calls btrfs_get_old_root(), and finally that calls tree_mod_log_oldest_root() with time_seq == 1 and eb_root == eb Y; 10) The first iteration of the while loop finds the tree mod log element with sequence number 3, for the logical address of eb Y and of type BTRFS_MOD_LOG_ROOT_REPLACE; 11) Because the operation type is BTRFS_MOD_LOG_ROOT_REPLACE, we don't break out of the loop, and set root_logical to point to tm->old_root.logical, which corresponds to the logical address of eb X; 12) On the next iteration of the while loop, the call to tree_mod_log_search_oldest() returns the smallest tree mod log element for the logical address of eb X, which has a sequence number of 2, an operation type of BTRFS_MOD_LOG_KEY_REMOVE_WHILE_FREEING and corresponds to the old slot 0 of eb X (eb X had only 1 item in it before being freed at step 7); 13) We then break out of the while loop and return the tree mod log operation of type BTRFS_MOD_LOG_ROOT_REPLACE (eb Y), and not the one for slot 0 of eb X, to btrfs_get_old_root(); 14) At btrfs_get_old_root(), we process the BTRFS_MOD_LOG_ROOT_REPLACE operation and set "logical" to the logical address of eb X, which was the old root. We then call tree_mod_log_search() passing it the logical address of eb X and time_seq == 1; 15) But before calling tree_mod_log_search(), task B locks eb X, adds a key to eb X, which results in adding a tree mod log operation of type BTRFS_MOD_LOG_KEY_ADD, with a sequence number of 4, to the tree mod log, and increments the number of items in eb X from 0 to 1. Now fs_info->tree_mod_seq has a value of 4; 16) Task A then calls tree_mod_log_search(), which returns the most recent tree mod log operation for eb X, which is the one just added by task B at the previous step, with a sequence number of 4, a type of BTRFS_MOD_LOG_KEY_ADD and for slot 0; 17) Before task A locks and clones eb X, task A adds another key to eb X, which results in adding a new BTRFS_MOD_LOG_KEY_ADD mod log operation, with a sequence number of 5, for slot 1 of eb X, increments the number of items in eb X from 1 to 2, and unlocks eb X. Now fs_info->tree_mod_seq has a value of 5; 18) Task A then locks eb X and clones it. The clone has a value of 2 for the number of items and the pointer "tm" points to the tree mod log operation with sequence number 4, not the most recent one with a sequence number of 5, so there is mismatch between the number of mod log operations that are going to be applied to the cloned version of eb X and the number of items in the clone; 19) Task A then calls tree_mod_log_rewind() with the clone of eb X, the tree mod log operation with sequence number 4 and a type of BTRFS_MOD_LOG_KEY_ADD, and time_seq == 1; 20) At tree_mod_log_rewind(), we set the local variable "n" with a value of 2, which is the number of items in the clone of eb X. Then in the first iteration of the while loop, we process the mod log operation with sequence number 4, which is targeted at slot 0 and has a type of BTRFS_MOD_LOG_KEY_ADD. This results in decrementing "n" from 2 to 1. Then we pick the next tree mod log operation for eb X, which is the tree mod log operation with a sequence number of 2, a type of BTRFS_MOD_LOG_KEY_REMOVE_WHILE_FREEING and for slot 0, it is the one added in step 5 to the tree mod log tree. We go back to the top of the loop to process this mod log operation, and because its slot is 0 and "n" has a value of 1, we hit the BUG_ON: (...) switch (tm->op) { case BTRFS_MOD_LOG_KEY_REMOVE_WHILE_FREEING: BUG_ON(tm->slot < n); fallthrough; (...) Fix this by checking for a more recent tree mod log operation after locking and cloning the extent buffer of the old root node, and use it as the first operation to apply to the cloned extent buffer when rewinding it. Stable backport notes: due to moved code and renames, in =< 5.11 the change should be applied to ctree.c:get_old_root. Reported-by: Zygo Blaxell Link: https://lore.kernel.org/linux-btrfs/20210404040732.GZ32440@hungrycats.org/ Fixes: 834328a8493079 ("Btrfs: tree mod log's old roots could still be part of the tree") CC: stable@vger.kernel.org # 4.4+ Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 900fb3279e5edf4de5154307fec7c9f6cf67958c Author: Bas Nieuwenhuizen Date: Wed Apr 28 17:09:03 2021 +0800 tools/power/turbostat: Fix turbostat for AMD Zen CPUs commit 301b1d3a9104f4f3a8ab4171cf88d0f55d632b41 upstream. It was reported that on Zen+ system turbostat started exiting, which was tracked down to the MSR_PKG_ENERGY_STAT read failing because offset_to_idx wasn't returning a non-negative index. This patch combined the modification from Bingsong Si and Bas Nieuwenhuizen and addd the MSR to the index system as alternative for MSR_PKG_ENERGY_STATUS. Fixes: 9972d5d84d76 ("tools/power turbostat: Enable accumulate RAPL display") Reported-by: youling257 Tested-by: youling257 Tested-by: Kurt Garloff Tested-by: Bingsong Si Tested-by: Artem S. Tashkinov Co-developed-by: Bingsong Si Co-developed-by: Terry Bowman Signed-off-by: Bas Nieuwenhuizen Reviewed-by: Chen Yu Signed-off-by: Len Brown Cc: Salvatore Bonaccorso Signed-off-by: Greg Kroah-Hartman commit 19c11722771f7852e3ee25c4583b127529d2e349 Author: Eckhart Mohr Date: Tue Apr 27 17:30:25 2021 +0200 ALSA: hda/realtek: Add quirk for Intel Clevo PCx0Dx commit 970e3012c04c96351c413f193a9c909e6d871ce2 upstream. This applies a SND_PCI_QUIRK(...) to the Clevo PCx0Dx barebones. This fix enables audio output over the headset jack and ensures that a microphone connected via the headset combo jack is correctly recognized when pluged in. [ Rearranged the list entries in a sorted order -- tiwai ] Signed-off-by: Eckhart Mohr Co-developed-by: Werner Sembach Signed-off-by: Werner Sembach Cc: Link: https://lore.kernel.org/r/20210427153025.451118-1-wse@tuxedocomputers.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit b821885bfcde01bb0ee632e703fb8c51aec0547c Author: Sami Loone Date: Sun Apr 25 22:37:12 2021 +0200 ALSA: hda/realtek: fix static noise on ALC285 Lenovo laptops commit 9bbb94e57df135ef61bef075d9c99b8d9e89e246 upstream. Remove a duplicate vendor+subvendor pin fixup entry as one is masking the other and making it unreachable. Consider the more specific newcomer as a second chance instead. The generic entry is made less strict to also match for laptops with slightly different 0x12 pin configuration. Tested on Lenovo Yoga 6 (AMD) where 0x12 is 0x40000000. Fixes: 607184cb1635 ("ALSA: hda/realtek - Add supported for more Lenovo ALC285 Headset Button") Signed-off-by: Sami Loone Cc: Link: https://lore.kernel.org/r/YIXS+GT/dGI/LtK6@yoga Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 14ad4409418fa2e81cf80626c4d9b4663c3f7738 Author: Kailang Yang Date: Tue Apr 20 14:17:34 2021 +0800 ALSA: hda/realtek - Headset Mic issue on HP platform commit 1c9d9dfd2d254211cb37b1513b1da3e6835b8f00 upstream. Boot with plugged headset, the Headset Mic will be gone. Signed-off-by: Kailang Yang Cc: Link: https://lore.kernel.org/r/207eecfc3189466a820720bc0c409ea9@realtek.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 2c10b675918ed1086c9eb74e7b54dea48beba3cf Author: Phil Calvin Date: Thu Apr 15 18:01:29 2021 -0400 ALSA: hda/realtek: fix mic boost on Intel NUC 8 commit d1ee66c5d3c5a0498dd5e3f2af5b8c219a98bba5 upstream. Fix two bugs with the Intel HDA Realtek ALC233 sound codec present in Intel NUC NUC8i7BEH and probably a few other similar NUC models. These codecs advertise a 4-level microphone input boost amplifier on pin 0x19, but the highest two boost settings do not work correctly, and produce only low analog noise that does not seem to contain any discernible signal. There is an existing fixup for this exact problem but for a different PCI subsystem ID, so we re-use that logic. Changing the boost level also triggers a DC spike in the input signal that bleeds off over about a second and overwhelms any input during that time. Thankfully, the existing fixup has the side effect of making the boost control show up in userspace as a mute/unmute switch, and this keeps (e.g.) PulseAudio from fiddling with it during normal input volume adjustments. Finally, the NUC hardware has built-in inverted stereo mics. This patch also enables the usual fixup for this so the two channels cancel noise instead of the actual signal. [ Re-ordered the quirk entry point by tiwai ] Signed-off-by: Phil Calvin Cc: Link: https://lore.kernel.org/r/80dc5663-7734-e7e5-25ef-15b5df24511a@philcalvin.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit fd2fec39f8a1837bee912587d19a773889dbbb47 Author: Luke D Jones Date: Mon Apr 19 15:04:11 2021 +1200 ALSA: hda/realtek: GA503 use same quirks as GA401 commit 76fae6185f5456865ff1bcb647709d44fd987eb6 upstream. The GA503 has almost exactly the same default setup as the GA401 model with the same issues. The GA401 quirks solve all the issues so we will use the full quirk chain. Signed-off-by: Luke D Jones Cc: Link: https://lore.kernel.org/r/20210419030411.28304-1-luke@ljones.dev Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 8b32a5e4e1310d8478e0358da13ceb7173eab647 Author: Jonas Witschel Date: Fri Apr 16 12:58:54 2021 +0200 ALSA: hda/realtek: fix mute/micmute LEDs for HP ProBook 445 G7 commit 75b62ab65d2715ce6ff0794033d61ab9dc4a2dfc upstream. The HP ProBook 445 G7 (17T32ES) uses ALC236. Like ALC236_FIXUP_HP_GPIO_LED, COEF index 0x34 bit 5 is used to control the playback mute LED, but the microphone mute LED is controlled using pin VREF instead of a COEF index. AlsaInfo: https://alsa-project.org/db/?f=0d3f4d1af39cc359f9fea9b550727ee87e5cf45a Signed-off-by: Jonas Witschel Cc: Link: https://lore.kernel.org/r/20210416105852.52588-1-diabonas@archlinux.org Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 8f89fb21c85a6e3038844701f4d3fb1a85c46754 Author: Timo Gurr Date: Mon May 3 13:08:22 2021 +0200 ALSA: usb-audio: Add dB range mapping for Sennheiser Communications Headset PC 8 commit ab2165e2e6ed17345ffa8ee88ca764e8788ebcd7 upstream. The decibel volume range contains a negative maximum value resulting in pipewire complaining about the device and effectivly having no sound output. The wrong values also resulted in the headset sounding muted already at a mixer level of about ~25%. PipeWire BugLink: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/1049 BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=212897 Signed-off-by: Timo Gurr Cc: Link: https://lore.kernel.org/r/20210503110822.10222-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit e117d328d397d322ad94c88b80147955a14ab015 Author: Takashi Iwai Date: Tue Apr 13 10:41:52 2021 +0200 ALSA: usb-audio: Explicitly set up the clock selector commit d2e8f641257d0d3af6e45d6ac2d6f9d56b8ea964 upstream. In the current code, we have some assumption that the audio clock selector has been set up implicitly and don't want to touch it unless it's really needed for the fallback autoclock setup. This works for most devices but some seem having a problem. Partially this was covered for the devices with a single connector at the initialization phase (commit 086b957cc17f "ALSA: usb-audio: Skip the clock selector inquiry for single connections"), but also there are cases where the wrong clock set up is kept silently. The latter seems to be the cause of the noises on Behringer devices. In this patch, we explicitly set up the audio clock selector whenever the appropriate node is found. Reported-by: Geraldo Nascimento BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=199327 Link: https://lore.kernel.org/r/CAEsQvcvF7LnO8PxyyCxuRCx=7jNeSCvFAd-+dE0g_rd1rOxxdw@mail.gmail.com Cc: Link: https://lore.kernel.org/r/20210413084152.32325-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 1699eddaa136f1d8d34452ef7823e768c79fae9a Author: Lv Yunlong Date: Mon Apr 26 07:55:41 2021 -0700 ALSA: sb: Fix two use after free in snd_sb_qsound_build commit 4fb44dd2c1dda18606348acdfdb97e8759dde9df upstream. In snd_sb_qsound_build, snd_ctl_add(..,p->qsound_switch...) and snd_ctl_add(..,p->qsound_space..) are called. But the second arguments of snd_ctl_add() could be freed via snd_ctl_add_replace() ->snd_ctl_free_one(). After the error code is returned, snd_sb_qsound_destroy(p) is called in __error branch. But in snd_sb_qsound_destroy(), the freed p->qsound_switch and p->qsound_space are still used by snd_ctl_remove(). My patch set p->qsound_switch and p->qsound_space to NULL if snd_ctl_add() failed to avoid the uaf bugs. But these codes need to further be improved with the code style. Signed-off-by: Lv Yunlong Cc: Link: https://lore.kernel.org/r/20210426145541.8070-1-lyl2019@mail.ustc.edu.cn Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 51aad882598635cd62d762695972d1dc5fb590ae Author: Takashi Iwai Date: Wed Apr 28 13:27:04 2021 +0200 ALSA: hda/conexant: Re-order CX5066 quirk table entries commit 2e6a731296be9d356fdccee9fb6ae345dad96438 upstream. Just re-order the cx5066_fixups[] entries for HP devices for avoiding the oversight of the duplicated or unapplied item in future. No functional changes. Also Cc-to-stable for the further patch applications. Cc: Link: https://lore.kernel.org/r/20210428112704.23967-14-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit ad2cd2dff035785a759557f3db814d608d1c46af Author: Lv Yunlong Date: Mon Apr 26 06:11:29 2021 -0700 ALSA: emu8000: Fix a use after free in snd_emu8000_create_mixer commit 1c98f574403dbcf2eb832d5535a10d967333ef2d upstream. Our code analyzer reported a uaf. In snd_emu8000_create_mixer, the callee snd_ctl_add(..,emu->controls[i]) calls snd_ctl_add_replace(.., kcontrol,..). Inside snd_ctl_add_replace(), if error happens, kcontrol will be freed by snd_ctl_free_one(kcontrol). Then emu->controls[i] points to a freed memory, and the execution comes to __error branch of snd_emu8000_create_mixer. The freed emu->controls[i] is used in snd_ctl_remove(card, emu->controls[i]). My patch set emu->controls[i] to NULL if snd_ctl_add() failed to avoid the uaf. Signed-off-by: Lv Yunlong Cc: Link: https://lore.kernel.org/r/20210426131129.4796-1-lyl2019@mail.ustc.edu.cn Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 21f0971f53ba440e4f50c2149fffa852aff4093f Author: Guangqing Zhu Date: Wed Apr 21 22:36:50 2021 +0800 power: supply: cpcap-battery: fix invalid usage of list cursor [ Upstream commit d0a43c12ee9f57ddb284272187bd18726c2c2c98 ] Fix invalid usage of a list_for_each_entry in cpcap_battery_irq_thread(). Empty list or fully traversed list points to list head, which is not NULL (and before the first element containing real data). Signed-off-by: Guangqing Zhu Reviewed-by: Tony Lindgren Reviewed-by: Carl Philipp Klemm Tested-by: Carl Philipp Klemm Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 284d899d90004213794f45c5506020d7782e9150 Author: Hou Pu Date: Fri Apr 16 10:45:21 2021 +0800 nvmet: avoid queuing keep-alive timer if it is disabled [ Upstream commit 8f864c595bed20ef85fef3e7314212b73800d51d ] Issue following command: nvme set-feature -f 0xf -v 0 /dev/nvme1n1 # disable keep-alive timer nvme admin-passthru -o 0x18 /dev/nvme1n1 # send keep-alive command will make keep-alive timer fired and thus delete the controller like below: [247459.907635] nvmet: ctrl 1 keep-alive timer (0 seconds) expired! [247459.930294] nvmet: ctrl 1 fatal error occurred! Avoid this by not queuing delayed keep-alive if it is disabled when keep-alive command is received from the admin queue. Signed-off-by: Hou Pu Tested-by: Chaitanya Kulkarni Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 244022d2b53d76fcd2b73be88824bf60f702698e Author: Charan Teja Reddy Date: Fri Apr 16 20:32:16 2021 +0530 sched,psi: Handle potential task count underflow bugs more gracefully [ Upstream commit 9d10a13d1e4c349b76f1c675a874a7f981d6d3b4 ] psi_group_cpu->tasks, represented by the unsigned int, stores the number of tasks that could be stalled on a psi resource(io/mem/cpu). Decrementing these counters at zero leads to wrapping which further leads to the psi_group_cpu->state_mask is being set with the respective pressure state. This could result into the unnecessary time sampling for the pressure state thus cause the spurious psi events. This can further lead to wrong actions being taken at the user land based on these psi events. Though psi_bug is set under these conditions but that just for debug purpose. Fix it by decrementing the ->tasks count only when it is non-zero. Signed-off-by: Charan Teja Reddy Signed-off-by: Peter Zijlstra (Intel) Acked-by: Johannes Weiner Link: https://lkml.kernel.org/r/1618585336-37219-1-git-send-email-charante@codeaurora.org Signed-off-by: Sasha Levin commit a78c38ebc44ec00fd1a2a2f38417a113407196bf Author: Harald Freudenberger Date: Tue Apr 20 08:23:12 2021 +0200 s390/archrandom: add parameter check for s390_arch_random_generate [ Upstream commit 28096067686c5a5cbd4c35b079749bd805df5010 ] A review of the code showed, that this function which is exposed within the whole kernel should do a parameter check for the amount of bytes requested. If this requested bytes is too high an unsigned int overflow could happen causing this function to try to memcpy a really big memory chunk. This is not a security issue as there are only two invocations of this function from arch/s390/include/asm/archrandom.h and both are not exposed to userland. Reported-by: Sven Schnelle Signed-off-by: Harald Freudenberger Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin commit 19bbb353a22eb106a5048f9c29b7b50a62af9609 Author: Pavel Begunkov Date: Tue Apr 20 12:03:32 2021 +0100 io_uring: safer sq_creds putting [ Upstream commit 07db298a1c96bdba2102d60ad51fcecb961177c9 ] Put sq_creds as a part of io_ring_ctx_free(), it's easy to miss doing it in io_sq_thread_finish(), especially considering past mistakes related to ring creation failures. Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/r/3becb1866467a1de82a97345a0a90d7fb8ff875e.1618916549.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 87a6d381613a31648781955160d69140f41b716d Author: Gioh Kim Date: Mon Apr 19 09:37:15 2021 +0200 block/rnbd-clt: Fix missing a memory free when unloading the module [ Upstream commit 12b06533104e802df73c1fbe159437c19933d6c0 ] When unloading the rnbd-clt module, it does not free a memory including the filename of the symbolic link to /sys/block/rnbdX. It is found by kmemleak as below. unreferenced object 0xffff9f1a83d3c740 (size 16): comm "bash", pid 736, jiffies 4295179665 (age 9841.310s) hex dump (first 16 bytes): 21 64 65 76 21 6e 75 6c 6c 62 30 40 62 6c 61 00 !dev!nullb0@bla. backtrace: [<0000000039f0c55e>] 0xffffffffc0456c24 [<000000001aab9513>] kernfs_fop_write+0xcf/0x1c0 [<00000000db5aa4b3>] vfs_write+0xdb/0x1d0 [<000000007a2e2207>] ksys_write+0x65/0xe0 [<00000000055e280a>] do_syscall_64+0x50/0x1b0 [<00000000c2b51831>] entry_SYSCALL_64_after_hwframe+0x49/0xbe Signed-off-by: Gioh Kim Signed-off-by: Jack Wang Link: https://lore.kernel.org/r/20210419073722.15351-13-gi-oh.kim@ionos.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit fba4bf102cf8f0ebc46d0232d59605cc0cc40a9e Author: Gioh Kim Date: Mon Apr 19 09:37:12 2021 +0200 block/rnbd-srv: Prevent a deadlock generated by accessing sysfs in parallel [ Upstream commit b168e1d85cf3201663698dd9dcb3d46c7e67f621 ] We got a warning message below. When server tries to close one session by force, it locks the sysfs interface and locks the srv_sess lock. The problem is that client can send a request to close at the same time. By close request, server locks the srv_sess lock and locks the sysfs to remove the sysfs interfaces. The simplest way to prevent that situation could be just use mutex_trylock. [ 234.153965] ====================================================== [ 234.154093] WARNING: possible circular locking dependency detected [ 234.154219] 5.4.84-storage #5.4.84-1+feature+linux+5.4.y+dbg+20201216.1319+b6b887b~deb10 Tainted: G O [ 234.154381] ------------------------------------------------------ [ 234.154531] kworker/1:1H/618 is trying to acquire lock: [ 234.154651] ffff8887a09db0a8 (kn->count#132){++++}, at: kernfs_remove_by_name_ns+0x40/0x80 [ 234.154819] but task is already holding lock: [ 234.154965] ffff8887ae5f6518 (&srv_sess->lock){+.+.}, at: rnbd_srv_rdma_ev+0x144/0x1590 [rnbd_server] [ 234.155132] which lock already depends on the new lock. [ 234.155311] the existing dependency chain (in reverse order) is: [ 234.155462] -> #1 (&srv_sess->lock){+.+.}: [ 234.155614] __mutex_lock+0x134/0xcb0 [ 234.155761] rnbd_srv_sess_dev_force_close+0x36/0x50 [rnbd_server] [ 234.155889] rnbd_srv_dev_session_force_close_store+0x69/0xc0 [rnbd_server] [ 234.156042] kernfs_fop_write+0x13f/0x240 [ 234.156162] vfs_write+0xf3/0x280 [ 234.156278] ksys_write+0xba/0x150 [ 234.156395] do_syscall_64+0x62/0x270 [ 234.156513] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 234.156632] -> #0 (kn->count#132){++++}: [ 234.156782] __lock_acquire+0x129e/0x23a0 [ 234.156900] lock_acquire+0xf3/0x210 [ 234.157043] __kernfs_remove+0x42b/0x4c0 [ 234.157161] kernfs_remove_by_name_ns+0x40/0x80 [ 234.157282] remove_files+0x3f/0xa0 [ 234.157399] sysfs_remove_group+0x4a/0xb0 [ 234.157519] rnbd_srv_destroy_dev_session_sysfs+0x19/0x30 [rnbd_server] [ 234.157648] rnbd_srv_rdma_ev+0x14c/0x1590 [rnbd_server] [ 234.157775] process_io_req+0x29a/0x6a0 [rtrs_server] [ 234.157924] __ib_process_cq+0x8c/0x100 [ib_core] [ 234.158709] ib_cq_poll_work+0x31/0xb0 [ib_core] [ 234.158834] process_one_work+0x4e5/0xaa0 [ 234.158958] worker_thread+0x65/0x5c0 [ 234.159078] kthread+0x1e0/0x200 [ 234.159194] ret_from_fork+0x24/0x30 [ 234.159309] other info that might help us debug this: [ 234.159513] Possible unsafe locking scenario: [ 234.159658] CPU0 CPU1 [ 234.159775] ---- ---- [ 234.159891] lock(&srv_sess->lock); [ 234.160005] lock(kn->count#132); [ 234.160128] lock(&srv_sess->lock); [ 234.160250] lock(kn->count#132); [ 234.160364] *** DEADLOCK *** [ 234.160536] 3 locks held by kworker/1:1H/618: [ 234.160677] #0: ffff8883ca1ed528 ((wq_completion)ib-comp-wq){+.+.}, at: process_one_work+0x40a/0xaa0 [ 234.160840] #1: ffff8883d2d5fe10 ((work_completion)(&cq->work)){+.+.}, at: process_one_work+0x40a/0xaa0 [ 234.161003] #2: ffff8887ae5f6518 (&srv_sess->lock){+.+.}, at: rnbd_srv_rdma_ev+0x144/0x1590 [rnbd_server] [ 234.161168] stack backtrace: [ 234.161312] CPU: 1 PID: 618 Comm: kworker/1:1H Tainted: G O 5.4.84-storage #5.4.84-1+feature+linux+5.4.y+dbg+20201216.1319+b6b887b~deb10 [ 234.161490] Hardware name: Supermicro H8QG6/H8QG6, BIOS 3.00 09/04/2012 [ 234.161643] Workqueue: ib-comp-wq ib_cq_poll_work [ib_core] [ 234.161765] Call Trace: [ 234.161910] dump_stack+0x96/0xe0 [ 234.162028] check_noncircular+0x29e/0x2e0 [ 234.162148] ? print_circular_bug+0x100/0x100 [ 234.162267] ? register_lock_class+0x1ad/0x8a0 [ 234.162385] ? __lock_acquire+0x68e/0x23a0 [ 234.162505] ? trace_event_raw_event_lock+0x190/0x190 [ 234.162626] __lock_acquire+0x129e/0x23a0 [ 234.162746] ? register_lock_class+0x8a0/0x8a0 [ 234.162866] lock_acquire+0xf3/0x210 [ 234.162982] ? kernfs_remove_by_name_ns+0x40/0x80 [ 234.163127] __kernfs_remove+0x42b/0x4c0 [ 234.163243] ? kernfs_remove_by_name_ns+0x40/0x80 [ 234.163363] ? kernfs_fop_readdir+0x3b0/0x3b0 [ 234.163482] ? strlen+0x1f/0x40 [ 234.163596] ? strcmp+0x30/0x50 [ 234.163712] kernfs_remove_by_name_ns+0x40/0x80 [ 234.163832] remove_files+0x3f/0xa0 [ 234.163948] sysfs_remove_group+0x4a/0xb0 [ 234.164068] rnbd_srv_destroy_dev_session_sysfs+0x19/0x30 [rnbd_server] [ 234.164196] rnbd_srv_rdma_ev+0x14c/0x1590 [rnbd_server] [ 234.164345] ? _raw_spin_unlock_irqrestore+0x43/0x50 [ 234.164466] ? lockdep_hardirqs_on+0x1a8/0x290 [ 234.164597] ? mlx4_ib_poll_cq+0x927/0x1280 [mlx4_ib] [ 234.164732] ? rnbd_get_sess_dev+0x270/0x270 [rnbd_server] [ 234.164859] process_io_req+0x29a/0x6a0 [rtrs_server] [ 234.164982] ? rnbd_get_sess_dev+0x270/0x270 [rnbd_server] [ 234.165130] __ib_process_cq+0x8c/0x100 [ib_core] [ 234.165279] ib_cq_poll_work+0x31/0xb0 [ib_core] [ 234.165404] process_one_work+0x4e5/0xaa0 [ 234.165550] ? pwq_dec_nr_in_flight+0x160/0x160 [ 234.165675] ? do_raw_spin_lock+0x119/0x1d0 [ 234.165796] worker_thread+0x65/0x5c0 [ 234.165914] ? process_one_work+0xaa0/0xaa0 [ 234.166031] kthread+0x1e0/0x200 [ 234.166147] ? kthread_create_worker_on_cpu+0xc0/0xc0 [ 234.166268] ret_from_fork+0x24/0x30 [ 234.251591] rnbd_server L243: : Device closed [ 234.604221] rnbd_server L264: RTRS Session close_device_session disconnected Signed-off-by: Gioh Kim Signed-off-by: Md Haris Iqbal Signed-off-by: Jack Wang Link: https://lore.kernel.org/r/20210419073722.15351-10-gi-oh.kim@ionos.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 9d1c4c2ff48370c2924d2f948890a732bc10a5a0 Author: Peter Zijlstra Date: Thu Mar 25 13:44:46 2021 +0100 sched,fair: Alternative sched_slice() [ Upstream commit 0c2de3f054a59f15e01804b75a04355c48de628c ] The current sched_slice() seems to have issues; there's two possible things that could be improved: - the 'nr_running' used for __sched_period() is daft when cgroups are considered. Using the RQ wide h_nr_running seems like a much more consistent number. - (esp) cgroups can slice it real fine, which makes for easy over-scheduling, ensure min_gran is what the name says. Signed-off-by: Peter Zijlstra (Intel) Tested-by: Valentin Schneider Link: https://lkml.kernel.org/r/20210412102001.611897312@infradead.org Signed-off-by: Sasha Levin commit 76ccefa1b3f8da3750b6548317c116ab8aeccb71 Author: Peter Zijlstra Date: Thu Apr 8 12:35:56 2021 +0200 perf: Rework perf_event_exit_event() [ Upstream commit ef54c1a476aef7eef26fe13ea10dc090952c00f8 ] Make perf_event_exit_event() more robust, such that we can use it from other contexts. Specifically the up and coming remove_on_exec. For this to work we need to address a few issues. Remove_on_exec will not destroy the entire context, so we cannot rely on TASK_TOMBSTONE to disable event_function_call() and we thus have to use perf_remove_from_context(). When using perf_remove_from_context(), there's two races to consider. The first is against close(), where we can have concurrent tear-down of the event. The second is against child_list iteration, which should not find a half baked event. To address this, teach perf_remove_from_context() to special case !ctx->is_active and about DETACH_CHILD. [ elver@google.com: fix racing parent/child exit in sync_child_event(). ] Signed-off-by: Marco Elver Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20210408103605.1676875-2-elver@google.com Signed-off-by: Sasha Levin commit 76282eddf6aced0be26010a637205129bc070e98 Author: Bart Van Assche Date: Thu Apr 15 15:08:13 2021 -0700 scsi: libfc: Fix a format specifier [ Upstream commit 90d6697810f06aceea9de71ad836a8c7669789cd ] Since the 'mfs' member has been declared as 'u32' in include/scsi/libfc.h, use the %u format specifier instead of %hu. This patch fixes the following clang compiler warning: warning: format specifies type 'unsigned short' but the argument has type 'u32' (aka 'unsigned int') [-Wformat] "lport->mfs:%hu\n", mfs, lport->mfs); ~~~ ^~~~~~~~~~ %u Link: https://lore.kernel.org/r/20210415220826.29438-8-bvanassche@acm.org Cc: Hannes Reinecke Signed-off-by: Bart Van Assche Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 0e0fb68c253823bdd1e76558cdfaefbc445b1eeb Author: Dinghao Liu Date: Wed Apr 7 13:11:49 2021 +0800 mfd: arizona: Fix rumtime PM imbalance on error [ Upstream commit fe6df2b48043bbe1e852b2320501d3b169363c35 ] pm_runtime_get_sync() will increase the rumtime PM counter even it returns an error. Thus a pairing decrement is needed to prevent refcount leak. Fix this by replacing this API with pm_runtime_resume_and_get(), which will not change the runtime PM counter on error. Signed-off-by: Dinghao Liu Acked-by: Charles Keepax Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 2030567b0e204dccfcc67eb1e6432df9d88eb605 Author: Hubert Streidl Date: Tue Mar 16 17:22:37 2021 +0100 mfd: da9063: Support SMBus and I2C mode [ Upstream commit 586478bfc9f7e16504d6f64cf18bcbdf6fd0cbc9 ] By default the PMIC DA9063 2-wire interface is SMBus compliant. This means the PMIC will automatically reset the interface when the clock signal ceases for more than the SMBus timeout of 35 ms. If the I2C driver / device is not capable of creating atomic I2C transactions, a context change can cause a ceasing of the clock signal. This can happen if for example a real-time thread is scheduled. Then the DA9063 in SMBus mode will reset the 2-wire interface. Subsequently a write message could end up in the wrong register. This could cause unpredictable system behavior. The DA9063 PMIC also supports an I2C compliant mode for the 2-wire interface. This mode does not reset the interface when the clock signal ceases. Thus the problem depicted above does not occur. This patch tests for the bus functionality "I2C_FUNC_I2C". It can reasonably be assumed that the bus cannot obey SMBus timings if this functionality is set. SMBus commands most probably are emulated in this case which is prone to the latency issue described above. This patch enables the I2C bus mode if I2C_FUNC_I2C is set or otherwise keeps the default SMBus mode. Signed-off-by: Hubert Streidl Signed-off-by: Mark Jonas Reviewed-by: Wolfram Sang Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit f14b8dae97dbc462c974c7b0b76c0abd419ffdea Author: Xu Yilun Date: Wed Mar 10 23:55:45 2021 +0800 mfd: intel-m10-bmc: Fix the register access range [ Upstream commit d9b326b2c3673f939941806146aee38e5c635fd0 ] This patch fixes the max register address of MAX 10 BMC. The range 0x20000000 ~ 0x200000fc are for control registers of the QSPI flash controller, which are not accessible to host. Signed-off-by: Xu Yilun Reviewed-by: Tom Rix Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit e2c075537107f9be3413c997e1b842e3f84cc545 Author: James Smart Date: Sun Apr 11 18:31:22 2021 -0700 scsi: lpfc: Remove unsupported mbox PORT_CAPABILITIES logic [ Upstream commit b62232ba8caccaf1954e197058104a6478fac1af ] SLI-4 does not contain a PORT_CAPABILITIES mailbox command (only SLI-3 does, and SLI-3 doesn't use it), yet there are SLI-4 code paths that have code to issue the command. The command will always fail. Remove the code for the mailbox command and leave only the resulting "failure path" logic. Link: https://lore.kernel.org/r/20210412013127.2387-12-jsmart2021@gmail.com Co-developed-by: Justin Tee Signed-off-by: Justin Tee Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 49bff90dd104d6bfe6d76c3ddaef0e8033fc4613 Author: James Smart Date: Sun Apr 11 18:31:17 2021 -0700 scsi: lpfc: Fix error handling for mailboxes completed in MBX_POLL mode [ Upstream commit 304ee43238fed517faa123e034b593905b8679f8 ] In SLI-4, when performing a mailbox command with MBX_POLL, the driver uses the BMBX register to send the command rather than the MQ. A flag is set indicating the BMBX register is active and saves the mailbox job struct (mboxq) in the mbox_active element of the adapter. The routine then waits for completion or timeout. The mailbox job struct is not freed by the routine. In cases of timeout, the adapter will be reset. The lpfc_sli_mbox_sys_flush() routine will clean up the mbox in preparation for the reset. It clears the BMBX active flag and marks the job structure as MBX_NOT_FINISHED. But, it never frees the mboxq job structure. Expectation in both normal completion and timeout cases is that the issuer of the mbx command will free the structure. Unfortunately, not all calling paths are freeing the memory in cases of error. All calling paths were looked at and updated, if missing, to free the mboxq memory regardless of completion status. Link: https://lore.kernel.org/r/20210412013127.2387-7-jsmart2021@gmail.com Co-developed-by: Justin Tee Signed-off-by: Justin Tee Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit d30a8a240c520776a222b48edb930d6acc56c9b2 Author: James Smart Date: Sun Apr 11 18:31:14 2021 -0700 scsi: lpfc: Fix reference counting errors in lpfc_cmpl_els_rsp() [ Upstream commit f866eb06c087125619457b53e9211a9e758f64f7 ] Call traces are being seen that result from a nodelist structure ref counting error. They are typically seen after transmission of an LS_RJT ELS response. Aged code in lpfc_cmpl_els_rsp() calls lpfc_nlp_not_used() which, if the ndlp reference count is exactly 1, will decrement the reference count. Previously lpfc_nlp_put() was within lpfc_els_free_iocb(), and the 'put' within the free would only be invoked if cmdiocb->context1 was not NULL. Since the nodelist structure reference count is decremented when exiting lpfc_cmpl_els_rsp() the lpfc_nlp_not_used() calls are no longer required. Calling them is causing the reference count issue. Fix by removing the lpfc_nlp_not_used() calls. Link: https://lore.kernel.org/r/20210412013127.2387-4-jsmart2021@gmail.com Co-developed-by: Justin Tee Signed-off-by: Justin Tee Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 9465bf9804c028deb6b53a90a3811cd83fb66bea Author: James Smart Date: Sun Apr 11 18:31:13 2021 -0700 scsi: lpfc: Fix crash when a REG_RPI mailbox fails triggering a LOGO response [ Upstream commit fffd18ec6579c2d9c72b212169259062fe747888 ] Fix a crash caused by a double put on the node when the driver completed an ACC for an unsolicted abort on the same node. The second put was executed by lpfc_nlp_not_used() and is wrong because the completion routine executes the nlp_put when the iocbq was released. Additionally, the driver is issuing a LOGO then immediately calls lpfc_nlp_set_state to put the node into NPR. This call does nothing. Remove the lpfc_nlp_not_used call and additional set_state in the completion routine. Remove the lpfc_nlp_set_state post issue_logo. Isn't necessary. Link: https://lore.kernel.org/r/20210412013127.2387-3-jsmart2021@gmail.com Co-developed-by: Justin Tee Signed-off-by: Justin Tee Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit a8655bfe7ba6d1a289ce7252af4919937ddbfc0a Author: Gustavo A. R. Silva Date: Thu Apr 1 11:20:54 2021 -0500 scsi: mpt3sas: Fix out-of-bounds warnings in _ctl_addnl_diag_query [ Upstream commit 16660db3fc2af8664af5e0a3cac69c4a54bfb794 ] Fix the following out-of-bounds warnings by embedding existing struct htb_rel_query into struct mpt3_addnl_diag_query, instead of duplicating its members: include/linux/fortify-string.h:20:29: warning: '__builtin_memcpy' offset [19, 32] from the object at 'karg' is out of the bounds of referenced subobject 'buffer_rel_condition' with type 'short unsigned int' at offset 16 [-Warray-bounds] include/linux/fortify-string.h:22:29: warning: '__builtin_memset' offset [19, 32] from the object at 'karg' is out of the bounds of referenced subobject 'buffer_rel_condition' with type 'short unsigned int' at offset 16 [-Warray-bounds] The problem is that the original code is trying to copy data into a bunch of struct members adjacent to each other in a single call to memcpy(). All those members are exactly the same contained in struct htb_rel_query, so instead of duplicating them into struct mpt3_addnl_diag_query, replace them with new member rel_query of type struct htb_rel_query. So, now that this new object is introduced, memcpy() doesn't overrun the length of &karg.buffer_rel_condition, because the address of the new struct object _rel_query_ is used as destination, instead. The same issue is present when calling memset(), and it is fixed with this same approach. Below is a comparison of struct mpt3_addnl_diag_query, before and after this change (the size and cachelines remain the same): $ pahole -C mpt3_addnl_diag_query drivers/scsi/mpt3sas/mpt3sas_ctl.o struct mpt3_addnl_diag_query { struct mpt3_ioctl_header hdr; /* 0 12 */ uint32_t unique_id; /* 12 4 */ uint16_t buffer_rel_condition; /* 16 2 */ uint16_t reserved1; /* 18 2 */ uint32_t trigger_type; /* 20 4 */ uint32_t trigger_info_dwords[2]; /* 24 8 */ uint32_t reserved2[2]; /* 32 8 */ /* size: 40, cachelines: 1, members: 7 */ /* last cacheline: 40 bytes */ }; $ pahole -C mpt3_addnl_diag_query drivers/scsi/mpt3sas/mpt3sas_ctl.o struct mpt3_addnl_diag_query { struct mpt3_ioctl_header hdr; /* 0 12 */ uint32_t unique_id; /* 12 4 */ struct htb_rel_query rel_query; /* 16 16 */ uint32_t reserved2[2]; /* 32 8 */ /* size: 40, cachelines: 1, members: 4 */ /* last cacheline: 40 bytes */ }; Also, this helps with the ongoing efforts to globally enable -Warray-bounds and get us closer to being able to tighten the FORTIFY_SOURCE routines on memcpy(). Link: https://github.com/KSPP/linux/issues/109 Link: https://lore.kernel.org/lkml/60659889.bJJILx2THu3hlpxW%25lkp@intel.com/ Link: https://lore.kernel.org/r/20210401162054.GA397186@embeddedor Build-tested-by: kernel test robot Reported-by: kernel test robot Signed-off-by: Gustavo A. R. Silva Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 1fa8aea88a39ee22c7d962bbd56eb545667fcc3e Author: Joshua Aberback Date: Tue Apr 6 17:21:50 2021 -0400 drm/amd/display: Update DCN302 SR Exit Latency [ Upstream commit 79f02534810c9557fb3217b538616dc42a1de3b9 ] [Why&How] Update SR Exit Latency to fix screen flickering caused due to OTG underflow. This is the recommended value given by the hardware IP team. Signed-off-by: Joshua Aberback Acked-by: Aurabindo Pillai Reviewed-by: Harry Wentland Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 7ebfbe221e114a41903aadb0dc7c68dd555ce85c Author: Guchun Chen Date: Tue Mar 30 17:52:18 2021 +0800 drm/amdgpu: fix NULL pointer dereference [ Upstream commit 3c3dc654333f6389803cdcaf03912e94173ae510 ] ttm->sg needs to be checked before accessing its child member. Call Trace: amdgpu_ttm_backend_destroy+0x12/0x70 [amdgpu] ttm_bo_cleanup_memtype_use+0x3a/0x60 [ttm] ttm_bo_release+0x17d/0x300 [ttm] amdgpu_bo_unref+0x1a/0x30 [amdgpu] amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0x78b/0x8b0 [amdgpu] kfd_ioctl_alloc_memory_of_gpu+0x118/0x220 [amdgpu] kfd_ioctl+0x222/0x400 [amdgpu] ? kfd_dev_is_large_bar+0x90/0x90 [amdgpu] __x64_sys_ioctl+0x8e/0xd0 ? __context_tracking_exit+0x52/0x90 do_syscall_64+0x33/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f97f264d317 Code: b3 66 90 48 8b 05 71 4b 2d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 41 4b 2d 00 f7 d8 64 89 01 48 RSP: 002b:00007ffdb402c338 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007f97f3cc63a0 RCX: 00007f97f264d317 RDX: 00007ffdb402c380 RSI: 00000000c0284b16 RDI: 0000000000000003 RBP: 00007ffdb402c380 R08: 00007ffdb402c428 R09: 00000000c4000004 R10: 00000000c4000004 R11: 0000000000000246 R12: 00000000c0284b16 R13: 0000000000000003 R14: 00007f97f3cc63a0 R15: 00007f8836200000 Signed-off-by: Guchun Chen Acked-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit b47f594a65f935cf21b4ac62760b40d2ae4ceda2 Author: Werner Sembach Date: Wed Mar 17 16:13:48 2021 +0100 drm/amd/display: Try YCbCr420 color when YCbCr444 fails [ Upstream commit 68eb3ae3c63708f823aeeb63bb15197c727bd9bf ] When encoder validation of a display mode fails, retry with less bandwidth heavy YCbCr420 color mode, if available. This enables some HDMI 1.4 setups to support 4k60Hz output, which previously failed silently. On some setups, while the monitor and the gpu support display modes with pixel clocks of up to 600MHz, the link encoder might not. This prevents YCbCr444 and RGB encoding for 4k60Hz, but YCbCr420 encoding might still be possible. However, which color mode is used is decided before the link encoder capabilities are checked. This patch fixes the problem by retrying to find a display mode with YCbCr420 enforced and using it, if it is valid. Reviewed-by: Harry Wentland Signed-off-by: Werner Sembach Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 89d6e69c87b3ba5eda68c8570926d2dee4c1f18a Author: Alex Deucher Date: Tue Mar 23 12:59:26 2021 -0400 drm/amdgpu/display: fix memory leak for dimgrey cavefish [ Upstream commit 42b599732ee1d4ac742760050603fb6046789011 ] We need to clean up the dcn3 clk_mgr. Acked-by: Nirmoy Das Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit fc56fb4e57fac73827960f6f73850b1890e3c35a Author: Arnd Bergmann Date: Mon Mar 22 12:54:42 2021 +0100 amdgpu: avoid incorrect %hu format string [ Upstream commit 7d98d416c2cc1c1f7d9508e887de4630e521d797 ] clang points out that the %hu format string does not match the type of the variables here: drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c:263:7: warning: format specifies type 'unsigned short' but the argument has type 'unsigned int' [-Wformat] version_major, version_minor); ^~~~~~~~~~~~~ include/drm/drm_print.h:498:19: note: expanded from macro 'DRM_ERROR' __drm_err(fmt, ##__VA_ARGS__) ~~~ ^~~~~~~~~~~ Change it to a regular %u, the same way a previous patch did for another instance of the same warning. Reviewed-by: Christian König Reviewed-by: Tom Rix Signed-off-by: Arnd Bergmann Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit d99753e15536ca8557b8460c5b08b3deb31be607 Author: Qu Huang Date: Sun Mar 21 16:28:18 2021 +0800 drm/amdkfd: Fix cat debugfs hang_hws file causes system crash bug [ Upstream commit d73610211eec8aa027850982b1a48980aa1bc96e ] Here is the system crash log: [ 1272.884438] BUG: unable to handle kernel NULL pointer dereference at (null) [ 1272.884444] IP: [< (null)>] (null) [ 1272.884447] PGD 825b09067 PUD 8267c8067 PMD 0 [ 1272.884452] Oops: 0010 [#1] SMP [ 1272.884509] CPU: 13 PID: 3485 Comm: cat Kdump: loaded Tainted: G [ 1272.884515] task: ffff9a38dbd4d140 ti: ffff9a37cd3b8000 task.ti: ffff9a37cd3b8000 [ 1272.884517] RIP: 0010:[<0000000000000000>] [< (null)>] (null) [ 1272.884520] RSP: 0018:ffff9a37cd3bbe68 EFLAGS: 00010203 [ 1272.884522] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000014d5f [ 1272.884524] RDX: fffffffffffffff4 RSI: 0000000000000001 RDI: ffff9a38aca4d200 [ 1272.884526] RBP: ffff9a37cd3bbed0 R08: ffff9a38dcd5f1a0 R09: ffff9a31ffc07300 [ 1272.884527] R10: ffff9a31ffc07300 R11: ffffffffaddd5e9d R12: ffff9a38b4e0fb00 [ 1272.884529] R13: 0000000000000001 R14: ffff9a37cd3bbf18 R15: ffff9a38aca4d200 [ 1272.884532] FS: 00007feccaa67740(0000) GS:ffff9a38dcd40000(0000) knlGS:0000000000000000 [ 1272.884534] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1272.884536] CR2: 0000000000000000 CR3: 00000008267c0000 CR4: 00000000003407e0 [ 1272.884537] Call Trace: [ 1272.884544] [] ? seq_read+0x130/0x440 [ 1272.884548] [] vfs_read+0x9f/0x170 [ 1272.884552] [] SyS_read+0x7f/0xf0 [ 1272.884557] [] system_call_fastpath+0x22/0x27 [ 1272.884558] Code: Bad RIP value. [ 1272.884562] RIP [< (null)>] (null) [ 1272.884564] RSP [ 1272.884566] CR2: 0000000000000000 Signed-off-by: Qu Huang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 819dc7e3ace8741054d5fbe361275009840f6a8f Author: Tong Zhang Date: Sun Mar 21 11:19:07 2021 -0400 drm/radeon: don't evict if not initialized [ Upstream commit 05eacc0f8f6c7e27f1841343611f4bed9ee178c1 ] TTM_PL_VRAM may not initialized at all when calling radeon_bo_evict_vram(). We need to check before doing eviction. [ 2.160837] BUG: kernel NULL pointer dereference, address: 0000000000000020 [ 2.161212] #PF: supervisor read access in kernel mode [ 2.161490] #PF: error_code(0x0000) - not-present page [ 2.161767] PGD 0 P4D 0 [ 2.163088] RIP: 0010:ttm_resource_manager_evict_all+0x70/0x1c0 [ttm] [ 2.168506] Call Trace: [ 2.168641] radeon_bo_evict_vram+0x1c/0x20 [radeon] [ 2.168936] radeon_device_fini+0x28/0xf9 [radeon] [ 2.169224] radeon_driver_unload_kms+0x44/0xa0 [radeon] [ 2.169534] radeon_driver_load_kms+0x174/0x210 [radeon] [ 2.169843] drm_dev_register+0xd9/0x1c0 [drm] [ 2.170104] radeon_pci_probe+0x117/0x1a0 [radeon] Reviewed-by: Christian König Suggested-by: Christian König Signed-off-by: Tong Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 15433cb854784199587ca11493a5e16ea1baf5b1 Author: Anson Jacob Date: Mon Mar 1 14:25:44 2021 -0500 drm/amd/display: Fix UBSAN: shift-out-of-bounds warning [ Upstream commit 54718747a6e1037317a8b3610c3be40621b2b75e ] [Why] On NAVI14 CONFIG_UBSAN reported shift-out-of-bounds at display_rq_dlg_calc_20v2.c:304:38 rq_param->misc.rq_c.blk256_height is 0 when chroma(*_c) is invalid. dml_log2 returns -1023 for log2(0), although log2(0) is undefined. Which ended up as: rq_param->dlg.rq_c.swath_height = 1 << -1023 [How] Fix applied on all dml versions. 1. Ensure dml_log2 is only called if the argument is greater than 0. 2. Subtract req128_l/req128_c from log2_swath_height_l/log2_swath_height_c only when it is greater than 0. Tested-by: Daniel Wheeler Signed-off-by: Anson Jacob Reviewed-by: Dmytro Laktyushkin Reviewed-by: Jun Lei Acked-by: Solomon Chiu Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit c86e38aae2e28179ce5ecdd1d9e7aa29a842c7fa Author: Fangzhi Zuo Date: Tue Mar 9 11:22:36 2021 -0500 drm/amd/display: Fix debugfs link_settings entry [ Upstream commit c006a1c00de29e8cdcde1d0254ac23433ed3fee9 ] 1. Catch invalid link_rate and link_count settings 2. Call dc interface to overwrite preferred link settings, and wait until next stream update to apply the new settings. Tested-by: Daniel Wheeler Signed-off-by: Fangzhi Zuo Reviewed-by: Nicholas Kazlauskas Acked-by: Solomon Chiu Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit fc3393e6ec5bfba320966ea3e7796893a2a2a998 Author: Daniel Gomez Date: Thu Mar 18 09:32:36 2021 +0100 drm/radeon/ttm: Fix memory leak userptr pages [ Upstream commit 5aeaa43e0ef1006320c077cbc49f4a8229ca3460 ] If userptr pages have been pinned but not bounded, they remain uncleared. Reviewed-by: Christian König Signed-off-by: Daniel Gomez Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit d272c7074661b3176e8ff9f91bfbfbb85f832d37 Author: Daniel Gomez Date: Wed Mar 17 17:08:37 2021 +0100 drm/amdgpu/ttm: Fix memory leak userptr pages [ Upstream commit 0f6f9dd490d524930081a6ef1d60171ce39220b9 ] If userptr pages have been pinned but not bounded, they remain uncleared. Reviewed-by: Christian König Signed-off-by: Daniel Gomez Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 318e8c3434fd9de21395b31c99f620df292c4c51 Author: Marijn Suijten Date: Tue Apr 6 23:47:25 2021 +0200 drm/msm/mdp5: Do not multiply vclk line count by 100 [ Upstream commit 377569f82ea8228c421cef4da33e056a900b58ca ] Neither vtotal nor drm_mode_vrefresh contain a value that is premultiplied by 100 making the x100 variable name incorrect and resulting in vclks_line to become 100 times larger than it is supposed to be. The hardware counts 100 clockticks too many before tearcheck, leading to severe panel issues on at least the Sony Xperia lineup. This is likely an artifact from the original MDSS DSI panel driver where the calculation [1] corrected for a premultiplied reference framerate by 100 [2]. It does not appear that the above values were ever premultiplied in the history of the DRM MDP5 driver. With this change applied the value written to the SYNC_CONFIG_VSYNC register is now identical to downstream kernels. [1]: https://source.codeaurora.org/quic/la/kernel/msm-3.18/tree/drivers/video/msm/mdss/mdss_mdp_intf_cmd.c?h=LA.UM.8.6.c26-02400-89xx.0#n288 [2]: https://source.codeaurora.org/quic/la/kernel/msm-3.18/tree/drivers/video/msm/mdss/mdss_dsi_panel.c?h=LA.UM.8.6.c26-02400-89xx.0#n1648 Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Marijn Suijten Link: https://lore.kernel.org/r/20210406214726.131534-3-marijn.suijten@somainline.org Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 9d105eefb786fb7f90e8045a2d5551d1faad5e23 Author: Marijn Suijten Date: Tue Apr 6 23:47:24 2021 +0200 drm/msm/mdp5: Configure PP_SYNC_HEIGHT to double the vtotal [ Upstream commit 2ad52bdb220de5ab348098e3482b01235d15a842 ] Leaving this at a close-to-maximum register value 0xFFF0 means it takes very long for the MDSS to generate a software vsync interrupt when the hardware TE interrupt doesn't arrive. Configuring this to double the vtotal (like some downstream kernels) leads to a frame to take at most twice before the vsync signal, until hardware TE comes up. In this case the hardware interrupt responsible for providing this signal - "disp-te" gpio - is not hooked up to the mdp5 vsync/pp logic at all. This solves severe panel update issues observed on at least the Xperia Loire and Tone series, until said gpio is properly hooked up to an irq. Suggested-by: AngeloGioacchino Del Regno Signed-off-by: Marijn Suijten Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20210406214726.131534-2-marijn.suijten@somainline.org Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit ce0da003ae3d04f3ffc59cc7685beaab1bd55a1d Author: Lingutla Chandrasekhar Date: Wed Apr 7 23:06:26 2021 +0100 sched/fair: Ignore percpu threads for imbalance pulls [ Upstream commit 9bcb959d05eeb564dfc9cac13a59843a4fb2edf2 ] During load balance, LBF_SOME_PINNED will be set if any candidate task cannot be detached due to CPU affinity constraints. This can result in setting env->sd->parent->sgc->group_imbalance, which can lead to a group being classified as group_imbalanced (rather than any of the other, lower group_type) when balancing at a higher level. In workloads involving a single task per CPU, LBF_SOME_PINNED can often be set due to per-CPU kthreads being the only other runnable tasks on any given rq. This results in changing the group classification during load-balance at higher levels when in reality there is nothing that can be done for this affinity constraint: per-CPU kthreads, as the name implies, don't get to move around (modulo hotplug shenanigans). It's not as clear for userspace tasks - a task could be in an N-CPU cpuset with N-1 offline CPUs, making it an "accidental" per-CPU task rather than an intended one. KTHREAD_IS_PER_CPU gives us an indisputable signal which we can leverage here to not set LBF_SOME_PINNED. Note that the aforementioned classification to group_imbalance (when nothing can be done) is especially problematic on big.LITTLE systems, which have a topology the likes of: DIE [ ] MC [ ][ ] 0 1 2 3 L L B B arch_scale_cpu_capacity(L) < arch_scale_cpu_capacity(B) Here, setting LBF_SOME_PINNED due to a per-CPU kthread when balancing at MC level on CPUs [0-1] will subsequently prevent CPUs [2-3] from classifying the [0-1] group as group_misfit_task when balancing at DIE level. Thus, if CPUs [0-1] are running CPU-bound (misfit) tasks, ill-timed per-CPU kthreads can significantly delay the upgmigration of said misfit tasks. Systems relying on ASYM_PACKING are likely to face similar issues. Signed-off-by: Lingutla Chandrasekhar [Use kthread_is_per_cpu() rather than p->nr_cpus_allowed] [Reword changelog] Signed-off-by: Valentin Schneider Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Dietmar Eggemann Reviewed-by: Vincent Guittot Link: https://lkml.kernel.org/r/20210407220628.3798191-2-valentin.schneider@arm.com Signed-off-by: Sasha Levin commit 91ef133ec62d658375d1e829a06627330336cabc Author: Rik van Riel Date: Fri Mar 26 15:19:32 2021 -0400 sched/fair: Bring back select_idle_smt(), but differently [ Upstream commit c722f35b513f807629603bbf24640b1a48be21b5 ] Mel Gorman did some nice work in 9fe1f127b913 ("sched/fair: Merge select_idle_core/cpu()"), resulting in the kernel being more efficient at finding an idle CPU, and in tasks spending less time waiting to be run, both according to the schedstats run_delay numbers, and according to measured application latencies. Yay. The flip side of this is that we see more task migrations (about 30% more), higher cache misses, higher memory bandwidth utilization, and higher CPU use, for the same number of requests/second. This is most pronounced on a memcache type workload, which saw a consistent 1-3% increase in total CPU use on the system, due to those increased task migrations leading to higher L2 cache miss numbers, and higher memory utilization. The exclusive L3 cache on Skylake does us no favors there. On our web serving workload, that effect is usually negligible. It appears that the increased number of CPU migrations is generally a good thing, since it leads to lower cpu_delay numbers, reflecting the fact that tasks get to run faster. However, the reduced locality and the corresponding increase in L2 cache misses hurts a little. The patch below appears to fix the regression, while keeping the benefit of the lower cpu_delay numbers, by reintroducing select_idle_smt with a twist: when a socket has no idle cores, check to see if the sibling of "prev" is idle, before searching all the other CPUs. This fixes both the occasional 9% regression on the web serving workload, and the continuous 2% CPU use regression on the memcache type workload. With Mel's patches and this patch together, task migrations are still high, but L2 cache misses, memory bandwidth, and CPU time used are back down to what they were before. The p95 and p99 response times for the memcache type application improve by about 10% over what they were before Mel's patches got merged. Signed-off-by: Rik van Riel Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Mel Gorman Acked-by: Vincent Guittot Link: https://lkml.kernel.org/r/20210326151932.2c187840@imladris.surriel.com Signed-off-by: Sasha Levin commit 36a2d6da4c2f072e788867410d01b3f647cb85f6 Author: Hans Verkuil Date: Thu Apr 8 12:31:20 2021 +0200 media: gscpa/stv06xx: fix memory leak [ Upstream commit 4f4e6644cd876c844cdb3bea2dd7051787d5ae25 ] For two of the supported sensors the stv06xx driver allocates memory which is stored in sd->sensor_priv. This memory is freed on a disconnect, but if the probe() fails, then it isn't freed and so this leaks memory. Add a new probe_error() op that drivers can use to free any allocated memory in case there was a probe failure. Thanks to Pavel Skripkin for discovering the cause of the memory leak. Reported-and-tested-by: syzbot+e7f4c64a4248a0340c37@syzkaller.appspotmail.com Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit d72fa22777207fa5d796c36776dd44161337a203 Author: Pavel Skripkin Date: Sun Mar 28 21:32:19 2021 +0200 media: dvb-usb: fix memory leak in dvb_usb_adapter_init [ Upstream commit b7cd0da982e3043f2eec7235ac5530cb18d6af1d ] syzbot reported memory leak in dvb-usb. The problem was in invalid error handling in dvb_usb_adapter_init(). for (n = 0; n < d->props.num_adapters; n++) { .... if ((ret = dvb_usb_adapter_stream_init(adap)) || (ret = dvb_usb_adapter_dvb_init(adap, adapter_nrs)) || (ret = dvb_usb_adapter_frontend_init(adap))) { return ret; } ... d->num_adapters_initialized++; ... } In case of error in dvb_usb_adapter_dvb_init() or dvb_usb_adapter_dvb_init() d->num_adapters_initialized won't be incremented, but dvb_usb_adapter_exit() relies on it: for (n = 0; n < d->num_adapters_initialized; n++) So, allocated objects won't be freed. Signed-off-by: Pavel Skripkin Reported-by: syzbot+3c2be7424cea3b932b0e@syzkaller.appspotmail.com Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit bdc41f736b41d26fbb1c9be2a3e1ede02f1ad888 Author: Dinghao Liu Date: Wed Apr 7 07:46:06 2021 +0200 media: sun8i-di: Fix runtime PM imbalance in deinterlace_start_streaming [ Upstream commit f1995d5e43cf897f63b4d7a7f84a252d891ae820 ] pm_runtime_get_sync() will increase the runtime PM counter even it returns an error. Thus a pairing decrement is needed to prevent refcount leak. Fix this by replacing this API with pm_runtime_resume_and_get(), which will not change the runtime PM counter on error. Signed-off-by: Dinghao Liu Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit c9c8b61f30dd7816a8a58724efbaaf2196692844 Author: Dinghao Liu Date: Wed Apr 7 07:43:13 2021 +0200 media: platform: sti: Fix runtime PM imbalance in regs_show [ Upstream commit 69306a947b3ae21e0d1cbfc9508f00fec86c7297 ] pm_runtime_get_sync() will increase the runtime PM counter even it returns an error. Thus a pairing decrement is needed to prevent refcount leak. Fix this by replacing this API with pm_runtime_resume_and_get(), which will not change the runtime PM counter on error. Signed-off-by: Dinghao Liu Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 21b50a6ac98f350910d02b54499fe720a8b3f522 Author: Yang Yingliang Date: Tue Apr 6 15:50:53 2021 +0200 media: i2c: adv7842: fix possible use-after-free in adv7842_remove() [ Upstream commit 4a15275b6a18597079f18241c87511406575179a ] This driver's remove path calls cancel_delayed_work(). However, that function does not wait until the work function finishes. This means that the callback function may still be running after the driver's remove function has finished, which would result in a use-after-free. Fix by calling cancel_delayed_work_sync(), which ensures that the work is properly cancelled, no longer running, and unable to re-schedule itself. Reported-by: Hulk Robot Signed-off-by: Yang Yingliang Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 98e887fc93fea317365c8a89f0cd64a70e994443 Author: Yang Yingliang Date: Tue Apr 6 15:49:45 2021 +0200 media: i2c: tda1997: Fix possible use-after-free in tda1997x_remove() [ Upstream commit 7f820ab5d4eebfe2d970d32a76ae496a6c286f0f ] This driver's remove path calls cancel_delayed_work(). However, that function does not wait until the work function finishes. This means that the callback function may still be running after the driver's remove function has finished, which would result in a use-after-free. Fix by calling cancel_delayed_work_sync(), which ensures that the work is properly cancelled, no longer running, and unable to re-schedule itself. Reported-by: Hulk Robot Signed-off-by: Yang Yingliang Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 8d57011b838e6bb36463fe98284e522c679801d3 Author: Yang Yingliang Date: Tue Apr 6 15:48:12 2021 +0200 media: i2c: adv7511-v4l2: fix possible use-after-free in adv7511_remove() [ Upstream commit 2c9541720c66899adf6f3600984cf3ef151295ad ] This driver's remove path calls cancel_delayed_work(). However, that function does not wait until the work function finishes. This means that the callback function may still be running after the driver's remove function has finished, which would result in a use-after-free. Fix by calling cancel_delayed_work_sync(), which ensures that the work is properly cancelled, no longer running, and unable to re-schedule itself. Reported-by: Hulk Robot Signed-off-by: Yang Yingliang Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 2a52254ccae1d3ddebd7771f09576814f73ba619 Author: Yang Yingliang Date: Tue Apr 6 15:42:46 2021 +0200 media: adv7604: fix possible use-after-free in adv76xx_remove() [ Upstream commit fa56f5f1fe31c2050675fa63b84963ebd504a5b3 ] This driver's remove path calls cancel_delayed_work(). However, that function does not wait until the work function finishes. This means that the callback function may still be running after the driver's remove function has finished, which would result in a use-after-free. Fix by calling cancel_delayed_work_sync(), which ensures that the work is properly cancelled, no longer running, and unable to re-schedule itself. Reported-by: Hulk Robot Signed-off-by: Yang Yingliang Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 1fcbb1432a7514525ffa44c08a7d3768a1e35f18 Author: Yang Yingliang Date: Tue Apr 6 15:39:29 2021 +0200 media: tc358743: fix possible use-after-free in tc358743_remove() [ Upstream commit 6107a4fdf8554a7aa9488bdc835bb010062fa8a9 ] This driver's remove path calls cancel_delayed_work(). However, that function does not wait until the work function finishes. This means that the callback function may still be running after the driver's remove function has finished, which would result in a use-after-free. Fix by calling cancel_delayed_work_sync(), which ensures that the work is properly cancelled, no longer running, and unable to re-schedule itself. Reported-by: Hulk Robot Signed-off-by: Yang Yingliang Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 3a8aa84ad5c6092eaf598f5e174ad1c46bcbe501 Author: Yang Yingliang Date: Wed Apr 7 17:19:03 2021 +0800 power: supply: s3c_adc_battery: fix possible use-after-free in s3c_adc_bat_remove() [ Upstream commit 68ae256945d2abe9036a7b68af4cc65aff79d5b7 ] This driver's remove path calls cancel_delayed_work(). However, that function does not wait until the work function finishes. This means that the callback function may still be running after the driver's remove function has finished, which would result in a use-after-free. Fix by calling cancel_delayed_work_sync(), which ensures that the work is properly cancelled, no longer running, and unable to re-schedule itself. Reported-by: Hulk Robot Signed-off-by: Yang Yingliang Reviewed-by: Krzysztof Kozlowski Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 15efbbe7674bfcd34adc90151ca5a50e9cb22417 Author: Yang Yingliang Date: Wed Apr 7 17:17:06 2021 +0800 power: supply: generic-adc-battery: fix possible use-after-free in gab_remove() [ Upstream commit b6cfa007b3b229771d9588970adb4ab3e0487f49 ] This driver's remove path calls cancel_delayed_work(). However, that function does not wait until the work function finishes. This means that the callback function may still be running after the driver's remove function has finished, which would result in a use-after-free. Fix by calling cancel_delayed_work_sync(), which ensures that the work is properly cancelled, no longer running, and unable to re-schedule itself. Reported-by: Hulk Robot Signed-off-by: Yang Yingliang Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit ce1e481865a7f2f2e1049790fb4acbc0f9472b8f Author: Colin Ian King Date: Tue Apr 6 18:01:15 2021 +0100 clk: socfpga: arria10: Fix memory leak of socfpga_clk on error return [ Upstream commit 657d4d1934f75a2d978c3cf2086495eaa542e7a9 ] There is an error return path that is not kfree'ing socfpga_clk leading to a memory leak. Fix this by adding in the missing kfree call. Addresses-Coverity: ("Resource leak") Signed-off-by: Colin Ian King Link: https://lore.kernel.org/r/20210406170115.430990-1-colin.king@canonical.com Acked-by: Dinh Nguyen Reviewed-by: Krzysztof Kozlowski Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 1cf96e59da60551b45f58f77e5b582b0cae30775 Author: Abhinav Kumar Date: Fri Mar 5 11:17:18 2021 -0800 drm/msm/dp: Fix incorrect NULL check kbot warnings in DP driver [ Upstream commit 7d649cfe0314aad2ba18042885ab9de2f13ad809 ] Fix an incorrect NULL check reported by kbot in the MSM DP driver smatch warnings: drivers/gpu/drm/msm/dp/dp_hpd.c:37 dp_hpd_connect() error: we previously assumed 'hpd_priv->dp_cb' could be null (see line 37) Reported-by: kernel test robot Reported-by: Dan Carpenter Signed-off-by: Abhinav Kumar Reviewed-by: Stephen Boyd Link: https://lore.kernel.org/r/1614971839-2686-2-git-send-email-abhinavk@codeaurora.org Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 6281cd9e34b3a2aa0ea01e3645c8bab8ad60134b Author: Akhil P Oommen Date: Mon Apr 5 19:17:12 2021 +0530 drm/msm/a6xx: Fix perfcounter oob timeout [ Upstream commit 2fc8a92e0a22c483e749232d4f13c77a92139aa7 ] We were not programing the correct bit while clearing the perfcounter oob. So, clear it correctly using the new 'clear' bit. This fixes the below error: [drm:a6xx_gmu_set_oob] *ERROR* Timeout waiting for GMU OOB set PERFCOUNTER: 0x80000000 Signed-off-by: Akhil P Oommen Link: https://lore.kernel.org/r/1617630433-36506-1-git-send-email-akhilpo@codeaurora.org Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 4af165214d95c84ef0625692111f8025d6eb8e63 Author: Laurent Pinchart Date: Mon Mar 8 11:31:28 2021 +0100 media: uvcvideo: Support devices that report an OT as an entity source [ Upstream commit 4ca052b4ea621d0002a5e5feace51f60ad5e6b23 ] Some devices reference an output terminal as the source of extension units. This is incorrect, as output terminals only have an input pin, and thus can't be connected to any entity in the forward direction. The resulting topology would cause issues when registering the media controller graph. To avoid this problem, connect the extension unit to the source of the output terminal instead. While at it, and while no device has been reported to be affected by this issue, also handle forward scans where two output terminals would be connected together, and skip the terminals found through such an invalid connection. Reported-and-tested-by: John Nealy Signed-off-by: Laurent Pinchart Signed-off-by: Hans de Goede Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 7de578c084c93b4e28922c270b2760de5c1f12d6 Author: Laurent Pinchart Date: Sun Feb 21 22:11:50 2021 +0100 media: uvcvideo: Fix XU id print in forward scan [ Upstream commit 3293448632ff2ae8c7cde4c3475da96138e24ca7 ] An error message in the forward scan code incorrectly prints the ID of the source entity instead of the XU entity being scanned. Fix it. Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit dd06898725d5f3069d8ed406e0a5b2208acb0575 Author: Hans Verkuil Date: Thu Mar 25 08:48:21 2021 +0100 media: vivid: update EDID [ Upstream commit 443ec4bbc6116f6f492a7a1282bfd8422c862158 ] The EDID had a few mistakes as reported by edid-decode: Block 1, CTA-861 Extension Block: Video Data Block: For improved preferred timing interoperability, set 'Native detailed modes' to 1. Video Capability Data Block: S_PT is equal to S_IT and S_CE, so should be set to 0 instead. Fixed those. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 56fd1aa2322ae5486c278f10a22997ae55361c24 Author: Muhammad Usama Anjum Date: Wed Mar 24 19:07:53 2021 +0100 media: em28xx: fix memory leak [ Upstream commit 0ae10a7dc8992ee682ff0b1752ff7c83d472eef1 ] If some error occurs, URB buffers should also be freed. If they aren't freed with the dvb here, the em28xx_dvb_fini call doesn't frees the URB buffers as dvb is set to NULL. The function in which error occurs should do all the cleanup for the allocations it had done. Tested the patch with the reproducer provided by syzbot. This patch fixes the memleak. Reported-by: syzbot+889397c820fa56adf25d@syzkaller.appspotmail.com Signed-off-by: Muhammad Usama Anjum Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 82fa26b929758a7d98edf157a2d4046aa74940f5 Author: Ewan D. Milne Date: Wed Mar 31 16:11:54 2021 -0400 scsi: scsi_dh_alua: Remove check for ASC 24h in alua_rtpg() [ Upstream commit bc3f2b42b70eb1b8576e753e7d0e117bbb674496 ] Some arrays return ILLEGAL_REQUEST with ASC 00h if they don't support the RTPG extended header so remove the check for INVALID FIELD IN CDB. Link: https://lore.kernel.org/r/20210331201154.20348-1-emilne@redhat.com Reviewed-by: Hannes Reinecke Signed-off-by: Ewan D. Milne Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit ae8c6ad672ce55c398bc6054ae01f2f27f673893 Author: Kevin Barnett Date: Thu Mar 11 14:17:48 2021 -0600 scsi: smartpqi: Add new PCI IDs [ Upstream commit 75fbeacca3ad30835e903002dba98dd909b4dfff ] Add support for newer hardware. Link: https://lore.kernel.org/r/161549386882.25025.2594251735886014958.stgit@brunhilda Reviewed-by: Scott Benesh Reviewed-by: Scott Teel Acked-by: Martin Wilck Signed-off-by: Kevin Barnett Signed-off-by: Don Brace Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 30a5371d870cb66d83b867167b6d86d198e8f905 Author: Murthy Bhat Date: Thu Mar 11 14:15:03 2021 -0600 scsi: smartpqi: Correct request leakage during reset operations [ Upstream commit b622a601a13ae5974c5b0aeecb990c224b8db0d9 ] While failing queued I/Os in TMF path, there was a request leak and hence stale entries in request pool with ref count being non-zero. In shutdown path we have a BUG_ON to catch stuck I/O either in firmware or in the driver. The stale requests caused a system crash. The I/O request pool leakage also lead to a significant performance drop. Link: https://lore.kernel.org/r/161549370379.25025.12793264112620796062.stgit@brunhilda Reviewed-by: Scott Teel Reviewed-by: Scott Benesh Reviewed-by: Kevin Barnett Signed-off-by: Murthy Bhat Signed-off-by: Don Brace Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit d218413a98865b52402395e5612e39b39549bf7c Author: Don Brace Date: Thu Mar 11 14:14:57 2021 -0600 scsi: smartpqi: Use host-wide tag space [ Upstream commit c6d3ee209b9e863c6251f72101511340451ca324 ] Correct SCSI midlayer sending more requests than exposed host queue depth causing firmware ASSERT and lockup issues by enabling host-wide tags. Note: This also results in better performance. Link: https://lore.kernel.org/r/161549369787.25025.8975999483518581619.stgit@brunhilda Suggested-by: Ming Lei Suggested-by: John Garry Reviewed-by: Scott Benesh Reviewed-by: Scott Teel Reviewed-by: Mike McGowen Reviewed-by: Kevin Barnett Signed-off-by: Don Brace Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit b494d1b2791c7b33493ba1ef5044babfb509bf3b Author: Carl Philipp Klemm Date: Sun Jan 17 22:48:53 2021 +0100 power: supply: cpcap-charger: Add usleep to cpcap charger to avoid usb plug bounce [ Upstream commit 751faedf06e895a17e985a88ef5b6364ffd797ed ] Adds 80000 us sleep when the usb cable is plugged in to hopefully avoid bouncing contacts. Upon pluging in the usb cable vbus will bounce for some time, causing cpcap to dissconnect charging due to detecting an undervoltage condition. This is a scope of vbus on xt894 while quickly inserting the usb cable with firm force, probed at the far side of the usb socket and vbus loaded with approx 1k: http://uvos.xyz/maserati/usbplug.jpg. As can clearly be seen, vbus is all over the place for the first 15 ms or so with a small blip at ~40 ms this causes the cpcap to trip up and disable charging again. The delay helps cpcap_usb_detect avoid the worst of this. It is, however, still not ideal as strong vibrations can cause the issue to reapear any time during charging. I have however not been able to cause the device to stop charging due to this in practice as it is hard to vibrate the device such that the vbus pins start bouncing again but cpcap_usb_detect is not called again due to a detected disconnect/reconnect event. Signed-off-by: Carl Philipp Klemm Tested-by: Tony Lindgren Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 7d8463c8acc9a566262beb714c38909091bcaceb Author: Carl Philipp Klemm Date: Sun Jan 17 22:47:45 2021 +0100 power: supply: cpcap-charger: fix small mistake in current to register conversion [ Upstream commit 8a5a0cc13aa927eac7a9eb3ca82dfc1f82cfc28d ] Signed-off-by: Carl Philipp Klemm Acked-by: Tony Lindgren Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 3a200c6b7bd5aa3e4649e059d7dd448716419568 Author: Fenghua Yu Date: Wed Mar 17 02:22:54 2021 +0000 selftests/resctrl: Fix checking for < 0 for unsigned values [ Upstream commit 1205b688c92558a04d8dd4cbc2b213e0fceba5db ] Dan reported following static checker warnings tools/testing/selftests/resctrl/resctrl_val.c:545 measure_vals() warn: 'bw_imc' unsigned <= 0 tools/testing/selftests/resctrl/resctrl_val.c:549 measure_vals() warn: 'bw_resc_end' unsigned <= 0 These warnings are reported because 1. measure_vals() declares 'bw_imc' and 'bw_resc_end' as unsigned long variables 2. Return value of get_mem_bw_imc() and get_mem_bw_resctrl() are assigned to 'bw_imc' and 'bw_resc_end' respectively 3. The returned values are checked for <= 0 to see if the calls failed Checking for < 0 for an unsigned value doesn't make any sense. Fix this issue by changing the implementation of get_mem_bw_imc() and get_mem_bw_resctrl() such that they now accept reference to a variable and set the variable appropriately upon success and return 0, else return < 0 on error. Reported-by: Dan Carpenter Tested-by: Babu Moger Signed-off-by: Fenghua Yu Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit bf81fc260e2569ad18a3d783245c726373120fed Author: Fenghua Yu Date: Wed Mar 17 02:22:53 2021 +0000 selftests/resctrl: Fix incorrect parsing of iMC counters [ Upstream commit d81343b5eedf84be71a4313e8fd073d0c510afcf ] iMC (Integrated Memory Controller) counters are usually at "/sys/bus/event_source/devices/" and are named as "uncore_imc_". num_of_imcs() function tries to count number of such iMC counters so that it could appropriately initialize required number of perf_attr structures that could be used to read these iMC counters. num_of_imcs() function assumes that all the directories under this path that start with "uncore_imc" are iMC counters. But, on some systems there could be directories named as "uncore_imc_free_running" which aren't iMC counters. Trying to read from such directories will result in "not found file" errors and MBM/MBA tests will fail. Hence, fix the logic in num_of_imcs() such that it looks at the first character after "uncore_imc_" to check if it's a numerical digit or not. If it's a digit then the directory represents an iMC counter, else, skip the directory. Reported-by: Reinette Chatre Tested-by: Babu Moger Signed-off-by: Fenghua Yu Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 477c43592fb66d01619c73df004b64b95bf7f52d Author: Fenghua Yu Date: Wed Mar 17 02:22:47 2021 +0000 selftests/resctrl: Use resctrl/info for feature detection [ Upstream commit ee0415681eb661efa1eb2db7acc263f2c7df1e23 ] Resctrl test suite before running any unit test (like cmt, cat, mbm and mba) should first check if the feature is enabled (by kernel and not just supported by H/W) on the platform or not. validate_resctrl_feature_request() is supposed to do that. This function intends to grep for relevant flags in /proc/cpuinfo but there are several issues here 1. validate_resctrl_feature_request() calls fgrep() to get flags from /proc/cpuinfo. But, fgrep() can only return a string with maximum of 255 characters and hence the complete cpu flags are never returned. 2. The substring search logic is also busted. If strstr() finds requested resctrl feature in the cpu flags, it returns pointer to the first occurrence. But, the logic negates the return value of strstr() and hence validate_resctrl_feature_request() returns false if the feature is present in the cpu flags and returns true if the feature is not present. 3. validate_resctrl_feature_request() checks if a resctrl feature is reported in /proc/cpuinfo flags or not. Having a cpu flag means that the H/W supports the feature, but it doesn't mean that the kernel enabled it. A user could selectively enable only a subset of resctrl features using kernel command line arguments. Hence, /proc/cpuinfo isn't a reliable source to check if a feature is enabled or not. The 3rd issue being the major one and fixing it requires changing the way validate_resctrl_feature_request() works. Since, /proc/cpuinfo isn't the right place to check if a resctrl feature is enabled or not, a more appropriate place is /sys/fs/resctrl/info directory. Change validate_resctrl_feature_request() such that, 1. For cat, check if /sys/fs/resctrl/info/L3 directory is present or not 2. For mba, check if /sys/fs/resctrl/info/MB directory is present or not 3. For cmt, check if /sys/fs/resctrl/info/L3_MON directory is present and check if /sys/fs/resctrl/info/L3_MON/mon_features has llc_occupancy 4. For mbm, check if /sys/fs/resctrl/info/L3_MON directory is present and check if /sys/fs/resctrl/info/L3_MON/mon_features has mbm__bytes Please note that only L3_CAT, L3_CMT, MBA and MBM are supported. CDP and L2 variants can be added later. Reported-by: Reinette Chatre Tested-by: Babu Moger Signed-off-by: Fenghua Yu Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit aa177a5215c2d89d610dd6039a02bf7ac1072466 Author: Fenghua Yu Date: Wed Mar 17 02:22:40 2021 +0000 selftests/resctrl: Fix missing options "-n" and "-p" [ Upstream commit d7af3d0d515cbdf63b6c3398a3c15ecb1bc2bd38 ] resctrl test suite accepts command line arguments (like -b, -t, -n and -p) as documented in the help. But passing -n and -p throws an invalid option error. This happens because -n and -p are missing in the list of characters that getopt() recognizes as valid arguments. Hence, they are treated as invalid options. Fix this by adding them to the list of characters that getopt() recognizes as valid arguments. Please note that the main() function already has the logic to deal with the values passed as part of these arguments and hence no changes are needed there. Tested-by: Babu Moger Signed-off-by: Fenghua Yu Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit c3b5a2c51833e775092d9e3146912ec264037340 Author: Fenghua Yu Date: Wed Mar 17 02:22:38 2021 +0000 selftests/resctrl: Clean up resctrl features check [ Upstream commit 2428673638ea28fa93d2a38b1c3e8d70122b00ee ] Checking resctrl features call strcmp() to compare feature strings (e.g. "mba", "cat" etc). The checkings are error prone and don't have good coding style. Define the constant strings in macros and call strncmp() to solve the potential issues. Suggested-by: Shuah Khan Tested-by: Babu Moger Signed-off-by: Fenghua Yu Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 6055a8a97449e94cb7a54e272dd654bcdeb18f98 Author: Fenghua Yu Date: Wed Mar 17 02:22:37 2021 +0000 selftests/resctrl: Fix compilation issues for other global variables [ Upstream commit 896016d2ad051811ff9c9c087393adc063322fbc ] Reinette reported following compilation issue on Fedora 32, gcc version 10.1.1 /usr/bin/ld: resctrl_tests.o:/resctrl.h:65: multiple definition of `bm_pid'; cache.o:/resctrl.h:65: first defined here Other variables are ppid, tests_run, llc_occup_path, is_amd. Compiler isn't happy because these variables are defined globally in two .c files but are not declared as extern. To fix issues for the global variables, declare them as extern. Chang Log: - Split this patch from v4's patch 1 (Shuah). Reported-by: Reinette Chatre Tested-by: Babu Moger Signed-off-by: Fenghua Yu Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 1afd4311c06278dca56db79d773ceb73470731a7 Author: Fenghua Yu Date: Wed Mar 17 02:22:36 2021 +0000 selftests/resctrl: Fix compilation issues for global variables [ Upstream commit 8236c51d85a64643588505a6791e022cc8d84864 ] Reinette reported following compilation issue on Fedora 32, gcc version 10.1.1 /usr/bin/ld: cqm_test.o:/cqm_test.c:22: multiple definition of `cache_size'; cat_test.o:/cat_test.c:23: first defined here The same issue is reported for long_mask, cbm_mask, count_of_bits etc variables as well. Compiler isn't happy because these variables are defined globally in two .c files namely cqm_test.c and cat_test.c and the compiler during compilation finds that the variable is already defined (multiple definition error). Taking a closer look at the usage of these variables reveals that these variables are used only locally in functions such as cqm_resctrl_val() (defined in cqm_test.c) and cat_perf_miss_val() (defined in cat_test.c). These variables are not shared between those functions. So, there is no need for these variables to be global. Hence, fix this issue by making them static variables. Reported-by: Reinette Chatre Tested-by: Babu Moger Signed-off-by: Fenghua Yu Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit fa74403444c6be658eeef87c799d8486963d85fb Author: Fenghua Yu Date: Wed Mar 17 02:22:35 2021 +0000 selftests/resctrl: Enable gcc checks to detect buffer overflows [ Upstream commit a9d26a302dea29eb84f491b1340a57e56c631a71 ] David reported a buffer overflow error in the check_results() function of the cmt unit test and he suggested enabling _FORTIFY_SOURCE gcc compiler option to automatically detect any such errors. Feature Test Macros man page describes_FORTIFY_SOURCE as below "Defining this macro causes some lightweight checks to be performed to detect some buffer overflow errors when employing various string and memory manipulation functions (for example, memcpy, memset, stpcpy, strcpy, strncpy, strcat, strncat, sprintf, snprintf, vsprintf, vsnprintf, gets, and wide character variants thereof). For some functions, argument consistency is checked; for example, a check is made that open has been supplied with a mode argument when the specified flags include O_CREAT. Not all problems are detected, just some common cases. If _FORTIFY_SOURCE is set to 1, with compiler optimization level 1 (gcc -O1) and above, checks that shouldn't change the behavior of conforming programs are performed. With _FORTIFY_SOURCE set to 2, some more checking is added, but some conforming programs might fail. Some of the checks can be performed at compile time (via macros logic implemented in header files), and result in compiler warnings; other checks take place at run time, and result in a run-time error if the check fails. Use of this macro requires compiler support, available with gcc since version 4.0." Fix the buffer overflow error in the check_results() function of the cmt unit test and enable _FORTIFY_SOURCE gcc check to catch any future buffer overflow errors. Reported-by: David Binderman Suggested-by: David Binderman Tested-by: Babu Moger Signed-off-by: Fenghua Yu Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 20eac5036476bf5b303c9c5284f95bf6ee5d9c6a Author: Hou Pu Date: Wed Mar 31 14:52:39 2021 +0800 nvmet: return proper error code from discovery ctrl [ Upstream commit 79695dcd9ad4463a82def7f42960e6d7baa76f0b ] Return NVME_SC_INVALID_FIELD from discovery controller like normal controller when executing identify or get log page command. Signed-off-by: Hou Pu Reviewed-by: Chaitanya Kulkarni Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit b70e92f2b19999a1acce4cb177e924336baa6aa3 Author: Carsten Haitzler Date: Thu Feb 4 13:11:02 2021 +0000 drm/komeda: Fix bit check to import to value of proper type [ Upstream commit a1c3be890440a1769ed6f822376a3e3ab0d42994 ] Another issue found by KASAN. The bit finding is buried inside the dp_for_each_set_bit() macro (that passes on to for_each_set_bit() that calls the bit stuff. These bit functions want an unsigned long pointer as input and just dumbly casting leads to out-of-bounds accesses. This fixes that. Signed-off-by: Carsten Haitzler Reviewed-by: Steven Price Reviewed-by: James Qian Wang Signed-off-by: Liviu Dudau Link: https://patchwork.freedesktop.org/patch/msgid/20210204131102.68658-1-carsten.haitzler@foss.arm.com Signed-off-by: Sasha Levin commit 0ec9e97d2109158ae2d5836ce946776ce5348600 Author: Xingui Yang Date: Fri Mar 12 18:24:36 2021 +0800 ata: ahci: Disable SXS for Hisilicon Kunpeng920 [ Upstream commit 234e6d2c18f5b080cde874483c4c361f3ae7cffe ] On Hisilicon Kunpeng920, ESP is set to 1 by default for all ports of SATA controller. In some scenarios, some ports are not external SATA ports, and it cause disks connected to these ports to be identified as removable disks. So disable the SXS capability on the software side to prevent users from mistakenly considering non-removable disks as removable disks and performing related operations. Signed-off-by: Xingui Yang Signed-off-by: Luo Jiaxing Reviewed-by: John Garry Link: https://lore.kernel.org/r/1615544676-61926-1-git-send-email-luojiaxing@huawei.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit e67ddebf1ffcd463bc145c7e9fe947cb741bf3df Author: Al Cooper Date: Thu Mar 25 15:28:34 2021 -0400 mmc: sdhci-brcmstb: Remove CQE quirk [ Upstream commit f0bdf98fab058efe7bf49732f70a0f26d1143154 ] Remove the CQHCI_QUIRK_SHORT_TXFR_DESC_SZ quirk because the latest chips have this fixed and earlier chips have other CQE problems that prevent the feature from being enabled. Signed-off-by: Al Cooper Acked-by: Florian Fainelli Link: https://lore.kernel.org/r/20210325192834.42955-1-alcooperx@gmail.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit e5ffc70d2ac5f303262b91878cec6e9dc24039b5 Author: Adrian Hunter Date: Mon Mar 22 07:53:56 2021 +0200 mmc: sdhci-pci: Add PCI IDs for Intel LKF [ Upstream commit ee629112be8b4eff71d4d3d108a28bc7dc877e13 ] Add PCI IDs for Intel LKF eMMC and SD card host controllers. Signed-off-by: Adrian Hunter Link: https://lore.kernel.org/r/20210322055356.24923-1-adrian.hunter@intel.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit fc1077b4995ef234bb0b0ee3be416f7b2426a2dc Author: Peng Fan Date: Thu Feb 25 11:10:04 2021 +0800 mmc: sdhci-esdhc-imx: validate pinctrl before use it [ Upstream commit f410ee0aa2df050a9505f5c261953e9b18e21206 ] When imx_data->pinctrl is not a valid pointer, pinctrl_lookup_state will trigger kernel panic. When we boot Dual OS on Jailhouse hypervisor, we let the 1st Linux to configure pinmux ready for the 2nd OS, so the 2nd OS not have pinctrl settings. Similar to this commit b62eee9f804e ("mmc: sdhci-esdhc-imx: no fail when no pinctrl available"). Reviewed-by: Bough Chen Reviewed-by: Alice Guo Signed-off-by: Peng Fan Link: https://lore.kernel.org/r/1614222604-27066-6-git-send-email-peng.fan@oss.nxp.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 1bb697e54e784bc6cb329a743f1659e9b0971855 Author: Quinn Tran Date: Mon Mar 29 01:52:22 2021 -0700 scsi: qla2xxx: Fix use after free in bsg [ Upstream commit 2ce35c0821afc2acd5ee1c3f60d149f8b2520ce8 ] On bsg command completion, bsg_job_done() was called while qla driver continued to access the bsg_job buffer. bsg_job_done() would free up resources that ended up being reused by other task while the driver continued to access the buffers. As a result, driver was reading garbage data. localhost kernel: BUG: KASAN: use-after-free in sg_next+0x64/0x80 localhost kernel: Read of size 8 at addr ffff8883228a3330 by task swapper/26/0 localhost kernel: localhost kernel: CPU: 26 PID: 0 Comm: swapper/26 Kdump: loaded Tainted: G OE --------- - - 4.18.0-193.el8.x86_64+debug #1 localhost kernel: Hardware name: HP ProLiant DL360 Gen9/ProLiant DL360 Gen9, BIOS P89 08/12/2016 localhost kernel: Call Trace: localhost kernel: localhost kernel: dump_stack+0x9a/0xf0 localhost kernel: print_address_description.cold.3+0x9/0x23b localhost kernel: kasan_report.cold.4+0x65/0x95 localhost kernel: debug_dma_unmap_sg.part.12+0x10d/0x2d0 localhost kernel: qla2x00_bsg_sp_free+0xaf6/0x1010 [qla2xxx] Link: https://lore.kernel.org/r/20210329085229.4367-6-njavali@marvell.com Reviewed-by: Himanshu Madhani Signed-off-by: Quinn Tran Signed-off-by: Saurav Kashyap Signed-off-by: Nilesh Javali Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 6d1689fadd78fa37ef086aca251f6bd1e9255918 Author: Paolo Valente Date: Thu Mar 4 18:46:25 2021 +0100 block, bfq: fix weight-raising resume with !low_latency [ Upstream commit 8c544770092a3d7532d01903b75721e537d87001 ] When the io_latency heuristic is off, bfq_queues must not start to be weight-raised. Unfortunately, by mistake, this may happen when the state of a previously weight-raised bfq_queue is resumed after a queue split. This commit fixes this error. Tested-by: Jan Kara Signed-off-by: Paolo Valente Tested-by: Oleksandr Natalenko Link: https://lore.kernel.org/r/20210304174627.161-5-paolo.valente@linaro.org Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 15966e6a3338aaae784da203ee748f4c907489df Author: Dmitry Vyukov Date: Sat Mar 20 14:28:40 2021 +0100 drm/vkms: fix misuse of WARN_ON [ Upstream commit b4142fc4d52d051d4d8df1fb6c569e5b445d369e ] vkms_vblank_simulate() uses WARN_ON for timing-dependent condition (timer overrun). This is a mis-use of WARN_ON, WARN_ON must be used to denote kernel bugs. Use pr_warn() instead. Signed-off-by: Dmitry Vyukov Reported-by: syzbot+4fc21a003c8332eb0bdd@syzkaller.appspotmail.com Cc: Rodrigo Siqueira Cc: Melissa Wen Cc: Haneen Mohammed Cc: Daniel Vetter Cc: David Airlie Cc: dri-devel@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Acked-by: Melissa Wen Signed-off-by: Melissa Wen Link: https://patchwork.freedesktop.org/patch/msgid/20210320132840.1315853-1-dvyukov@google.com Signed-off-by: Sasha Levin commit bc1434f7da172e041d006e595d4f700fc159c2e4 Author: Bart Van Assche Date: Sat Mar 20 16:23:58 2021 -0700 scsi: qla2xxx: Always check the return value of qla24xx_get_isp_stats() [ Upstream commit a2b2cc660822cae08c351c7f6b452bfd1330a4f7 ] This patch fixes the following Coverity warning: CID 361199 (#1 of 1): Unchecked return value (CHECKED_RETURN) 3. check_return: Calling qla24xx_get_isp_stats without checking return value (as is done elsewhere 4 out of 5 times). Link: https://lore.kernel.org/r/20210320232359.941-7-bvanassche@acm.org Cc: Quinn Tran Cc: Mike Christie Cc: Himanshu Madhani Cc: Daniel Wagner Cc: Lee Duncan Reviewed-by: Daniel Wagner Reviewed-by: Himanshu Madhani Signed-off-by: Bart Van Assche Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit b45476240f7e1154423464ec070907181bb87595 Author: Qingqing Zhuo Date: Tue Mar 9 15:10:24 2021 -0500 drm/amd/display: Fix potential memory leak [ Upstream commit 51ba691206e35464fd7ec33dd519d141c80b5dff ] [Why] vblank_workqueue is never released. [How] Free it upon dm finish. Tested-by: Daniel Wheeler Signed-off-by: Qingqing Zhuo Reviewed-by: Nicholas Kazlauskas Acked-by: Solomon Chiu Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 563ac6261e28cf21be99cf0f31613266610fd9da Author: Dmytro Laktyushkin Date: Thu Mar 4 11:04:26 2021 -0500 drm/amd/display: fix dml prefetch validation [ Upstream commit 8ee0fea4baf90e43efe2275de208a7809f9985bc ] Incorrect variable used, missing initialization during validation. Tested-by: Daniel Wheeler Signed-off-by: Dmytro Laktyushkin Reviewed-by: Eric Bernstein Acked-by: Solomon Chiu Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 4a3fc4596395cfec24a710e33159194805ca3cf3 Author: Aric Cyr Date: Mon Mar 8 15:43:34 2021 -0500 drm/amd/display: DCHUB underflow counter increasing in some scenarios [ Upstream commit 4710430a779e6077d81218ac768787545bff8c49 ] [Why] When unplugging a display, the underflow counter can be seen to increase because PSTATE switch is allowed even when some planes are not blanked. [How] Check that all planes are not active instead of all streams before allowing PSTATE change. Tested-by: Daniel Wheeler Signed-off-by: Aric Cyr Acked-by: Solomon Chiu Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 0d2d95716fdc9fe5df9ec043f509f64595b5cd89 Author: Anson Jacob Date: Tue Mar 2 16:16:36 2021 -0500 drm/amd/display: Fix UBSAN warning for not a valid value for type '_Bool' [ Upstream commit 6a30a92997eee49554f72b462dce90abe54a496f ] [Why] dc_cursor_position do not initialise position.translate_by_source when crtc or plane->state->fb is NULL. UBSAN caught this error in dce110_set_cursor_position, as the value was garbage. [How] Initialise dc_cursor_position structure elements to 0 in handle_cursor_update before calling get_cursor_position. Tested-by: Daniel Wheeler Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1471 Reported-by: Lyude Paul Signed-off-by: Anson Jacob Reviewed-by: Aurabindo Jayamohanan Pillai Acked-by: Solomon Chiu Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit f48cd93fec94f90afbdd1b14c34104e3cf22543a Author: Kenneth Feng Date: Tue Mar 16 10:28:00 2021 +0800 drm/amd/pm: fix workload mismatch on vega10 [ Upstream commit 0979d43259e13846d86ba17e451e17fec185d240 ] Workload number mapped to the correct one. This issue is only on vega10. Signed-off-by: Kenneth Feng Reviewed-by: Kevin Wang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 02cdf707babc19efee0d41def5aad3e5f2f908a1 Author: shaoyunl Date: Tue Mar 9 10:30:15 2021 -0500 drm/amdgpu : Fix asic reset regression issue introduce by 8f211fe8ac7c4f [ Upstream commit c8941550aa66b2a90f4b32c45d59e8571e33336e ] This recent change introduce SDMA interrupt info printing with irq->process function. These functions do not require a set function to enable/disable the irq Signed-off-by: shaoyunl Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 7a12075948ef7e939c447cdede7b208da44ec359 Author: Joshua Aberback Date: Fri Feb 26 19:44:24 2021 -0500 drm/amd/display: Align cursor cache address to 2KB [ Upstream commit 554ba183b135ef09250b61a202d88512b5bbd03a ] [Why] The registers for the address of the cursor are aligned to 2KB, so all cursor surfaces also need to be aligned to 2KB. Currently, the provided cursor cache surface is not aligned, so we need a workaround until alignment is enforced by the surface provider. [How] - round up surface address to nearest multiple of 2048 - current policy is to provide a much bigger cache size than necessary,so this operation is safe Tested-by: Daniel Wheeler Signed-off-by: Joshua Aberback Reviewed-by: Jun Lei Acked-by: Eryk Brol Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 9069b1b542de8f3bbffef868aff41521b21485cf Author: Anson Jacob Date: Wed Mar 3 12:33:15 2021 -0500 drm/amdkfd: Fix UBSAN shift-out-of-bounds warning [ Upstream commit 50e2fc36e72d4ad672032ebf646cecb48656efe0 ] If get_num_sdma_queues or get_num_xgmi_sdma_queues is 0, we end up doing a shift operation where the number of bits shifted equals number of bits in the operand. This behaviour is undefined. Set num_sdma_queues or num_xgmi_sdma_queues to ULLONG_MAX, if the count is >= number of bits in the operand. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1472 Reported-by: Lyude Paul Signed-off-by: Anson Jacob Reviewed-by: Alex Deucher Reviewed-by: Felix Kuehling Tested-by: Lyude Paul Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 41db62bc06eec528e8bd423e4edeb4d35eb874b5 Author: Jonathan Kim Date: Wed Jan 27 15:24:59 2021 -0500 drm/amdgpu: mask the xgmi number of hops reported from psp to kfd [ Upstream commit 4ac5617c4b7d0f0a8f879997f8ceaa14636d7554 ] The psp supplies the link type in the upper 2 bits of the psp xgmi node information num_hops field. With a new link type, Aldebaran has these bits set to a non-zero value (1 = xGMI3) so the KFD topology will report the incorrect IO link weights without proper masking. The actual number of hops is located in the 3 least significant bits of this field so mask if off accordingly before passing it to the KFD. Signed-off-by: Jonathan Kim Reviewed-by: Amber Lin Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit e58dd0a4f199ab68fe694b87010d1dbc4591a8f8 Author: Alex Sierra Date: Fri Jan 15 17:03:18 2021 -0600 drm/amdgpu: enable 48-bit IH timestamp counter [ Upstream commit 9a9c59a8f4f4478d5951eb0bded1d17b936aad6e ] By default this timestamp is 32 bit counter. It gets overflowed in around 10 minutes. Signed-off-by: Alex Sierra Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 39ba18abd37af60233f5ea60d87edbce110f9399 Author: Philip Yang Date: Tue Sep 22 13:09:33 2020 -0400 drm/amdgpu: enable retry fault wptr overflow [ Upstream commit b672cb1eee59efe6ca5bb2a2ce90060a22860558 ] If xnack is on, VM retry fault interrupt send to IH ring1, and ring1 will be full quickly. IH cannot receive other interrupts, this causes deadlock if migrating buffer using sdma and waiting for sdma done while handling retry fault. Remove VMC from IH storm client, enable ring1 write pointer overflow, then IH will drop retry fault interrupts and be able to receive other interrupts while driver is handling retry fault. IH ring1 write pointer doesn't writeback to memory by IH, and ring1 write pointer recorded by self-irq is not updated, so always read the latest ring1 write pointer from register. Signed-off-by: Philip Yang Signed-off-by: Felix Kuehling Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit d736c4fc59a8d5e43756b6b0bed79ddae35b1964 Author: Kiran Gunda Date: Thu Mar 18 18:09:39 2021 +0530 backlight: qcom-wled: Fix FSC update issue for WLED5 [ Upstream commit 4d6e9cdff7fbb6bef3e5559596fab3eeffaf95ca ] Currently, for WLED5, the FSC (Full scale current) setting is not updated properly due to driver toggling the wrong register after an FSC update. On WLED5 we should only toggle the MOD_SYNC bit after a brightness update. For an FSC update we need to toggle the SYNC bits instead. Fix it by adopting the common wled3_sync_toggle() for WLED5 and introducing new code to the brightness update path to compensate. Signed-off-by: Kiran Gunda Reviewed-by: Daniel Thompson Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 219db950ae5a3d542d78f23085f76609c7f362ac Author: Obeida Shamoun Date: Sun Mar 14 11:11:10 2021 +0100 backlight: qcom-wled: Use sink_addr for sync toggle [ Upstream commit cdfd4c689e2a52c313b35ddfc1852ff274f91acb ] WLED3_SINK_REG_SYNC is, as the name implies, a sink register offset. Therefore, use the sink address as base instead of the ctrl address. This fixes the sync toggle on wled4, which can be observed by the fact that adjusting brightness now works. It has no effect on wled3 because sink and ctrl base addresses are the same. This allows adjusting the brightness without having to disable then reenable the module. Signed-off-by: Obeida Shamoun Signed-off-by: Konrad Dybcio Signed-off-by: Marijn Suijten Reviewed-by: Daniel Thompson Acked-by: Kiran Gunda Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 599edbf276f43493c5b54b66553831bdf4a317f0 Author: dongjian Date: Mon Mar 22 19:21:33 2021 +0800 power: supply: Use IRQF_ONESHOT [ Upstream commit 2469b836fa835c67648acad17d62bc805236a6ea ] Fixes coccicheck error: drivers/power/supply/pm2301_charger.c:1089:7-27: ERROR: drivers/power/supply/lp8788-charger.c:502:8-28: ERROR: drivers/power/supply/tps65217_charger.c:239:8-33: ERROR: drivers/power/supply/tps65090-charger.c:303:8-33: ERROR: Threaded IRQ with no primary handler requested without IRQF_ONESHOT Signed-off-by: dongjian Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 889cb8bec2c53738412157cef5b0420c71e96304 Author: Hans Verkuil Date: Fri Mar 12 09:49:55 2021 +0100 media: v4l2-ctrls.c: initialize flags field of p_fwht_params [ Upstream commit ea1611ba3a544b34f89ffa3d1e833caab30a3f09 ] The V4L2_CID_STATELESS_FWHT_PARAMS compound control was missing a proper initialization of the flags field, so after loading the vicodec module for the first time, running v4l2-compliance for the stateless decoder would fail on this control because the initial control value was considered invalid by the vicodec driver. Initializing the flags field to sane values fixes this. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit b8d7e79dd4847762a381bd763d9cb0b2a130a569 Author: Hans Verkuil Date: Thu Mar 11 15:46:40 2021 +0100 media: gspca/sq905.c: fix uninitialized variable [ Upstream commit eaaea4681984c79d2b2b160387b297477f0c1aab ] act_len can be uninitialized if usb_bulk_msg() returns an error. Set it to 0 to avoid a KMSAN error. Signed-off-by: Hans Verkuil Reported-by: syzbot+a4e309017a5f3a24c7b3@syzkaller.appspotmail.com Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit b13bc773eea302bbe76c9acd3c4117501a1a7dd1 Author: Daniel Niv Date: Thu Mar 11 03:53:00 2021 +0100 media: media/saa7164: fix saa7164_encoder_register() memory leak bugs [ Upstream commit c759b2970c561e3b56aa030deb13db104262adfe ] Add a fix for the memory leak bugs that can occur when the saa7164_encoder_register() function fails. The function allocates memory without explicitly freeing it when errors occur. Add a better error handling that deallocate the unused buffers before the function exits during a fail. Signed-off-by: Daniel Niv Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 2b17e0eb9bb51381294cd5dcae694a8ccc3e1ad0 Author: Julian Wiedmann Date: Sat Jan 30 14:56:20 2021 +0100 s390/qdio: let driver manage the QAOB [ Upstream commit 396c100472dd63bb1a5389d9dfb25a94943c41c9 ] We are spending way too much effort on qdio-internal bookkeeping for QAOB management & caching, and it's still not robust. Once qdio's TX path has detached the QAOB from a PENDING buffer, we lost all track of it until it shows up in a CQ notification again. So if the device is torn down before that notification arrives, we leak the QAOB. Just have the driver take care of it, and simply pass down a QAOB if they want a TX with async-completion capability. For a buffer in PENDING state that requires the QAOB for final completion, qeth can now also try to recycle the buffer's QAOB rather than unconditionally freeing it. This also eliminates the qdio_outbuf_state array, which was only needed to transfer the aob->user1 tag from the driver to the qdio layer. Signed-off-by: Julian Wiedmann Acked-by: Benjamin Block Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin commit 54f1727a0956bcbed3a88540577c5e7dbab93aec Author: Bryan O'Donoghue Date: Fri Feb 5 19:11:49 2021 +0100 media: venus: core, venc, vdec: Fix probe dependency error [ Upstream commit 08b1cf474b7f72750adebe0f0a35f8e9a3eb75f6 ] Commit aaaa93eda64b ("media] media: venus: venc: add video encoder files") is the last in a series of three commits to add core.c vdec.c and venc.c adding core, encoder and decoder. The encoder and decoder check for core drvdata as set and return -EPROBE_DEFER if it has not been set, however both the encoder and decoder rely on core.v4l2_dev as valid. core.v4l2_dev will not be valid until v4l2_device_register() has completed in core.c's probe(). Normally this is never seen however, Dmitry reported the following backtrace when compiling drivers and firmware directly into a kernel image. [ 5.259968] Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT) [ 5.269850] sd 0:0:0:3: [sdd] Optimal transfer size 524288 bytes [ 5.275505] Workqueue: events deferred_probe_work_func [ 5.275513] pstate: 60400005 (nZCv daif +PAN -UAO -TCO BTYPE=--) [ 5.441211] usb 2-1: new SuperSpeedPlus Gen 2 USB device number 2 using xhci-hcd [ 5.442486] pc : refcount_warn_saturate+0x140/0x148 [ 5.493756] hub 2-1:1.0: USB hub found [ 5.496266] lr : refcount_warn_saturate+0x140/0x148 [ 5.500982] hub 2-1:1.0: 4 ports detected [ 5.503440] sp : ffff80001067b730 [ 5.503442] x29: ffff80001067b730 [ 5.592660] usb 1-1: new high-speed USB device number 2 using xhci-hcd [ 5.598478] x28: ffff6c6bc1c379b8 [ 5.598480] x27: ffffa5c673852960 x26: ffffa5c673852000 [ 5.598484] x25: ffff6c6bc1c37800 x24: 0000000000000001 [ 5.810652] x23: 0000000000000000 x22: ffffa5c673bc7118 [ 5.813777] hub 1-1:1.0: USB hub found [ 5.816108] x21: ffffa5c674440000 x20: 0000000000000001 [ 5.820846] hub 1-1:1.0: 4 ports detected [ 5.825415] x19: ffffa5c6744f4000 x18: ffffffffffffffff [ 5.825418] x17: 0000000000000000 x16: 0000000000000000 [ 5.825421] x15: 00000a4810c193ba x14: 0000000000000000 [ 5.825424] x13: 00000000000002b8 x12: 000000000000f20a [ 5.825427] x11: 000000000000f20a x10: 0000000000000038 [ 5.845447] usb 2-1.1: new SuperSpeed Gen 1 USB device number 3 using xhci-hcd [ 5.845904] [ 5.845905] x9 : 0000000000000000 x8 : ffff6c6d36fae780 [ 5.871208] x7 : ffff6c6d36faf240 x6 : 0000000000000000 [ 5.876664] x5 : 0000000000000004 x4 : 0000000000000085 [ 5.882121] x3 : 0000000000000119 x2 : ffffa5c6741ef478 [ 5.887578] x1 : 3acbb3926faf5f00 x0 : 0000000000000000 [ 5.893036] Call trace: [ 5.895551] refcount_warn_saturate+0x140/0x148 [ 5.900202] __video_register_device+0x64c/0xd10 [ 5.904944] venc_probe+0xc4/0x148 [ 5.908444] platform_probe+0x68/0xe0 [ 5.912210] really_probe+0x118/0x3e0 [ 5.915977] driver_probe_device+0x5c/0xc0 [ 5.920187] __device_attach_driver+0x98/0xb8 [ 5.924661] bus_for_each_drv+0x68/0xd0 [ 5.928604] __device_attach+0xec/0x148 [ 5.932547] device_initial_probe+0x14/0x20 [ 5.936845] bus_probe_device+0x9c/0xa8 [ 5.940788] device_add+0x3e8/0x7c8 [ 5.944376] of_device_add+0x4c/0x60 [ 5.948056] of_platform_device_create_pdata+0xbc/0x140 [ 5.953425] of_platform_bus_create+0x17c/0x3c0 [ 5.958078] of_platform_populate+0x80/0x110 [ 5.962463] venus_probe+0x2ec/0x4d8 [ 5.966143] platform_probe+0x68/0xe0 [ 5.969907] really_probe+0x118/0x3e0 [ 5.973674] driver_probe_device+0x5c/0xc0 [ 5.977882] __device_attach_driver+0x98/0xb8 [ 5.982356] bus_for_each_drv+0x68/0xd0 [ 5.986298] __device_attach+0xec/0x148 [ 5.990242] device_initial_probe+0x14/0x20 [ 5.994539] bus_probe_device+0x9c/0xa8 [ 5.998481] deferred_probe_work_func+0x74/0xb0 [ 6.003132] process_one_work+0x1e8/0x360 [ 6.007254] worker_thread+0x208/0x478 [ 6.011106] kthread+0x150/0x158 [ 6.014431] ret_from_fork+0x10/0x30 [ 6.018111] ---[ end trace f074246b1ecdb466 ]--- This patch fixes by - Only setting drvdata after v4l2_device_register() completes - Moving v4l2_device_register() so that suspend/reume in core::probe() stays as-is - Changes pm_ops->core_function() to take struct venus_core not struct device - Minimal rework of v4l2_device_*register in probe/remove Reported-by: Dmitry Baryshkov Signed-off-by: Bryan O'Donoghue Signed-off-by: Stanimir Varbanov Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 0e5d8d321fb8da26b63ee4c03e44467e43eaffe1 Author: Hans de Goede Date: Sun Mar 7 16:17:57 2021 +0100 extcon: arizona: Fix various races on driver unbind [ Upstream commit e5b499f6fb17bc95a813e85d0796522280203806 ] We must free/disable all interrupts and cancel all pending works before doing further cleanup. Before this commit arizona_extcon_remove() was doing several register writes to shut things down before disabling the IRQs and it was cancelling only 1 of the 3 different works used. Move all the register-writes shutting things down to after the disabling of the IRQs and add the 2 missing cancel_delayed_work_sync() calls. This fixes various possible races on driver unbind. One of which would always trigger on devices using the mic-clamp feature for jack detection. The ARIZONA_MICD_CLAMP_MODE_MASK update was done before disabling the IRQs, causing: 1. arizona_jackdet() to run 2. detect a jack being inserted (clamp disabled means jack inserted) 3. call arizona_start_mic() which: 3.1 Enables the MICVDD regulator 3.2 takes a pm_runtime_reference And this was all happening after the ARIZONA_MICD_ENA bit clearing, which would undo 3.1 and 3.2 because the ARIZONA_MICD_CLAMP_MODE_MASK update was being done after the ARIZONA_MICD_ENA bit clearing. So this means that arizona_extcon_remove() would exit with 1. MICVDD enabled and 2. The pm_runtime_reference being unbalanced. MICVDD still being enabled caused the following oops when the regulator is released by the devm framework: [ 2850.745757] ------------[ cut here ]------------ [ 2850.745827] WARNING: CPU: 2 PID: 2098 at drivers/regulator/core.c:2123 _regulator_put.part.0+0x19f/0x1b0 [ 2850.745835] Modules linked in: extcon_arizona ... ... [ 2850.746909] Call Trace: [ 2850.746932] regulator_put+0x2d/0x40 [ 2850.746946] release_nodes+0x22a/0x260 [ 2850.746984] __device_release_driver+0x190/0x240 [ 2850.747002] driver_detach+0xd4/0x120 ... [ 2850.747337] ---[ end trace f455dfd7abd9781f ]--- Note this oops is just one of various theoretically possible races caused by the wrong ordering inside arizona_extcon_remove(), this fixes the ordering fixing all possible races, including the reported oops. Signed-off-by: Hans de Goede Reviewed-by: Andy Shevchenko Acked-by: Charles Keepax Tested-by: Charles Keepax Acked-by: Chanwoo Choi Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 381d0d20ea7b432102ca0f043974f7c2d2dae59f Author: Hans de Goede Date: Sun Mar 7 16:17:56 2021 +0100 extcon: arizona: Fix some issues when HPDET IRQ fires after the jack has been unplugged [ Upstream commit c309a3e8793f7e01c4a4ec7960658380572cb576 ] When the jack is partially inserted and then removed again it may be removed while the hpdet code is running. In this case the following may happen: 1. The "JACKDET rise" or ""JACKDET fall" IRQ triggers 2. arizona_jackdet runs and takes info->lock 3. The "HPDET" IRQ triggers 4. arizona_hpdet_irq runs, blocks on info->lock 5. arizona_jackdet calls arizona_stop_mic() and clears info->hpdet_done 6. arizona_jackdet releases info->lock 7. arizona_hpdet_irq now can continue running and: 7.1 Calls arizona_start_mic() (if a mic was detected) 7.2 sets info->hpdet_done Step 7 is undesirable / a bug: 7.1 causes the device to stay in a high power-state (with MICVDD enabled) 7.2 causes hpdet to not run on the next jack insertion, which in turn causes the EXTCON_JACK_HEADPHONE state to never get set This fixes both issues by skipping these 2 steps when arizona_hpdet_irq runs after the jack has been unplugged. Signed-off-by: Hans de Goede Reviewed-by: Andy Shevchenko Acked-by: Charles Keepax Tested-by: Charles Keepax Acked-by: Chanwoo Choi Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 348c35a21bf1c13fe0968623161ae39b29783bdf Author: Matthias Schiffer Date: Wed Mar 3 10:54:19 2021 +0100 power: supply: bq27xxx: fix power_avg for newer ICs [ Upstream commit c4d57c22ac65bd503716062a06fad55a01569cac ] On all newer bq27xxx ICs, the AveragePower register contains a signed value; in addition to handling the raw value as unsigned, the driver code also didn't convert it to µW as expected. At least for the BQ28Z610, the reference manual incorrectly states that the value is in units of 1mW and not 10mW. I have no way of knowing whether the manuals of other supported ICs contain the same error, or if there are models that actually use 1mW. At least, the new code shouldn't be *less* correct than the old version for any device. power_avg is removed from the cache structure, se we don't have to extend it to store both a signed value and an error code. Always getting an up-to-date value may be desirable anyways, as it avoids inconsistent current and power readings when switching between charging and discharging. Signed-off-by: Matthias Schiffer Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit c8baf9979daec8410c5b701eec5074941a27bb8f Author: Mauro Carvalho Chehab Date: Fri Mar 12 08:16:03 2021 +0100 atomisp: don't let it go past pipes array [ Upstream commit 1f6c45ac5fd70ab59136ab5babc7def269f3f509 ] In practice, IA_CSS_PIPE_ID_NUM should never be used when calling atomisp_q_video_buffers_to_css(), as the driver should discover the right pipe before calling it. Yet, if some pipe parsing issue happens, it could end using it. So, add a WARN_ON() to prevent such case. Reported-by: Dan Carpenter Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 115a5769d710d60da4cfb4507c68029d5c55bc29 Author: Laurent Pinchart Date: Mon Feb 15 05:26:47 2021 +0100 media: imx: capture: Return -EPIPE from __capture_legacy_try_fmt() [ Upstream commit cc271b6754691af74d710b761eaf027e3743e243 ] The correct return code to report an invalid pipeline configuration is -EPIPE. Return it instead of -EINVAL from __capture_legacy_try_fmt() when the capture format doesn't match the media bus format of the connected subdev. Signed-off-by: Laurent Pinchart Reviewed-by: Rui Miguel Silva Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit a6b47637955cfdf2fd628d6fd3bb5413013d2623 Author: Brad Love Date: Tue Jan 26 05:52:05 2021 +0100 media: cx23885: add more quirks for reset DMA on some AMD IOMMU [ Upstream commit 5f864cfbf59bfed2057bd214ce7fbf6ad420d54b ] The folowing AMD IOMMU are affected by the RiSC engine stall, requiring a reset to maintain continual operation. After being added to the broken_dev_id list the systems are functional long term. 0x1481 is the PCI ID for the IOMMU found on Starship/Matisse 0x1419 is the PCI ID for the IOMMU found on 15h (Models 10h-1fh) family 0x5a23 is the PCI ID for the IOMMU found on RD890S/RD990 Signed-off-by: Brad Love Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 08acc7769692c1769be96b2a90e21b042bb4382d Author: Pavel Skripkin Date: Mon Mar 1 21:38:26 2021 +0100 media: drivers/media/usb: fix memory leak in zr364xx_probe [ Upstream commit 9c39be40c0155c43343f53e3a439290c0fec5542 ] syzbot reported memory leak in zr364xx_probe()[1]. The problem was in invalid error handling order. All error conditions rigth after v4l2_ctrl_handler_init() must call v4l2_ctrl_handler_free(). Reported-by: syzbot+efe9aefc31ae1e6f7675@syzkaller.appspotmail.com Signed-off-by: Pavel Skripkin Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 6802047d607edfc0c40be9f99dcfddeb7b23152c Author: Julian Braha Date: Thu Feb 25 09:06:58 2021 +0100 media: drivers: media: pci: sta2x11: fix Kconfig dependency on GPIOLIB [ Upstream commit 24df8b74c8b2fb42c49ffe8585562da0c96446ff ] When STA2X11_VIP is enabled, and GPIOLIB is disabled, Kbuild gives the following warning: WARNING: unmet direct dependencies detected for VIDEO_ADV7180 Depends on [n]: MEDIA_SUPPORT [=y] && GPIOLIB [=n] && VIDEO_V4L2 [=y] && I2C [=y] Selected by [y]: - STA2X11_VIP [=y] && MEDIA_SUPPORT [=y] && MEDIA_PCI_SUPPORT [=y] && MEDIA_CAMERA_SUPPORT [=y] && PCI [=y] && VIDEO_V4L2 [=y] && VIRT_TO_BUS [=y] && I2C [=y] && (STA2X11 [=n] || COMPILE_TEST [=y]) && MEDIA_SUBDRV_AUTOSELECT [=y] This is because STA2X11_VIP selects VIDEO_ADV7180 without selecting or depending on GPIOLIB, despite VIDEO_ADV7180 depending on GPIOLIB. Signed-off-by: Julian Braha Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 2eeccff0ba79b86ca81de5185dbbf5411b068c2b Author: Sean Young Date: Mon Feb 22 09:08:35 2021 +0100 media: ite-cir: check for receive overflow [ Upstream commit 28c7afb07ccfc0a939bb06ac1e7afe669901c65a ] It's best if this condition is reported. Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 4f8058c23b2b8d7a0cd9efbd94d13aebceb88592 Author: Chaitanya Kulkarni Date: Sat Feb 27 21:56:26 2021 -0800 scsi: target: pscsi: Fix warning in pscsi_complete_cmd() [ Upstream commit fd48c056a32ed6e7754c7c475490f3bed54ed378 ] This fixes a compilation warning in pscsi_complete_cmd(): drivers/target/target_core_pscsi.c: In function ‘pscsi_complete_cmd’: drivers/target/target_core_pscsi.c:624:5: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body] ; /* XXX: TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE */ Link: https://lore.kernel.org/r/20210228055645.22253-5-chaitanya.kulkarni@wdc.com Reviewed-by: Mike Christie Reviewed-by: Johannes Thumshirn Signed-off-by: Chaitanya Kulkarni Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 1016c0f62f73d5d2c3a5d1ad1e1fb0cdce1993ae Author: xndcn Date: Fri Mar 5 23:18:19 2021 +0800 drm/virtio: fix possible leak/unlock virtio_gpu_object_array [ Upstream commit 377f8331d0565e6f71ba081c894029a92d0c7e77 ] virtio_gpu_object array is not freed or unlocked in some failed cases. Signed-off-by: xndcn Link: http://patchwork.freedesktop.org/patch/msgid/20210305151819.14330-1-xndchn@gmail.com Signed-off-by: Gerd Hoffmann Signed-off-by: Sasha Levin commit 3f926066e967f6e86aa94d5fb1e9f69f6a651d53 Author: Uladzislau Rezki (Sony) Date: Fri Jan 29 21:05:05 2021 +0100 kvfree_rcu: Use same set of GFP flags as does single-argument [ Upstream commit ee6ddf58475cce8a3d3697614679cd8cb4a6f583 ] Running an rcuscale stress-suite can lead to "Out of memory" of a system. This can happen under high memory pressure with a small amount of physical memory. For example, a KVM test configuration with 64 CPUs and 512 megabytes can result in OOM when running rcuscale with below parameters: ../kvm.sh --torture rcuscale --allcpus --duration 10 --kconfig CONFIG_NR_CPUS=64 \ --bootargs "rcuscale.kfree_rcu_test=1 rcuscale.kfree_nthreads=16 rcuscale.holdoff=20 \ rcuscale.kfree_loops=10000 torture.disable_onoff_at_boot" --trust-make [ 12.054448] kworker/1:1H invoked oom-killer: gfp_mask=0x2cc0(GFP_KERNEL|__GFP_NOWARN), order=0, oom_score_adj=0 [ 12.055303] CPU: 1 PID: 377 Comm: kworker/1:1H Not tainted 5.11.0-rc3+ #510 [ 12.055416] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.12.0-1 04/01/2014 [ 12.056485] Workqueue: events_highpri fill_page_cache_func [ 12.056485] Call Trace: [ 12.056485] dump_stack+0x57/0x6a [ 12.056485] dump_header+0x4c/0x30a [ 12.056485] ? del_timer_sync+0x20/0x30 [ 12.056485] out_of_memory.cold.47+0xa/0x7e [ 12.056485] __alloc_pages_slowpath.constprop.123+0x82f/0xc00 [ 12.056485] __alloc_pages_nodemask+0x289/0x2c0 [ 12.056485] __get_free_pages+0x8/0x30 [ 12.056485] fill_page_cache_func+0x39/0xb0 [ 12.056485] process_one_work+0x1ed/0x3b0 [ 12.056485] ? process_one_work+0x3b0/0x3b0 [ 12.060485] worker_thread+0x28/0x3c0 [ 12.060485] ? process_one_work+0x3b0/0x3b0 [ 12.060485] kthread+0x138/0x160 [ 12.060485] ? kthread_park+0x80/0x80 [ 12.060485] ret_from_fork+0x22/0x30 [ 12.062156] Mem-Info: [ 12.062350] active_anon:0 inactive_anon:0 isolated_anon:0 [ 12.062350] active_file:0 inactive_file:0 isolated_file:0 [ 12.062350] unevictable:0 dirty:0 writeback:0 [ 12.062350] slab_reclaimable:2797 slab_unreclaimable:80920 [ 12.062350] mapped:1 shmem:2 pagetables:8 bounce:0 [ 12.062350] free:10488 free_pcp:1227 free_cma:0 ... [ 12.101610] Out of memory and no killable processes... [ 12.102042] Kernel panic - not syncing: System is deadlocked on memory [ 12.102583] CPU: 1 PID: 377 Comm: kworker/1:1H Not tainted 5.11.0-rc3+ #510 [ 12.102600] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.12.0-1 04/01/2014 Because kvfree_rcu() has a fallback path, memory allocation failure is not the end of the world. Furthermore, the added overhead of aggressive GFP settings must be balanced against the overhead of the fallback path, which is a cache miss for double-argument kvfree_rcu() and a call to synchronize_rcu() for single-argument kvfree_rcu(). The current choice of GFP_KERNEL|__GFP_NOWARN can result in longer latencies than a call to synchronize_rcu(), so less-tenacious GFP flags would be helpful. Here is the tradeoff that must be balanced: a) Minimize use of the fallback path, b) Avoid pushing the system into OOM, c) Bound allocation latency to that of synchronize_rcu(), and d) Leave the emergency reserves to use cases lacking fallbacks. This commit therefore changes GFP flags from GFP_KERNEL|__GFP_NOWARN to GFP_KERNEL|__GFP_NORETRY|__GFP_NOMEMALLOC|__GFP_NOWARN. This combination leaves the emergency reserves alone and can initiate reclaim, but will not invoke the OOM killer. Signed-off-by: Uladzislau Rezki (Sony) Signed-off-by: Paul E. McKenney Signed-off-by: Sasha Levin commit cc69d5a314b10ad21a917343fd1e16b3e026d52e Author: Barry Song Date: Wed Feb 24 16:09:44 2021 +1300 sched/topology: fix the issue groups don't span domain->span for NUMA diameter > 2 [ Upstream commit 585b6d2723dc927ebc4ad884c4e879e4da8bc21f ] As long as NUMA diameter > 2, building sched_domain by sibling's child domain will definitely create a sched_domain with sched_group which will span out of the sched_domain: +------+ +------+ +-------+ +------+ | node | 12 |node | 20 | node | 12 |node | | 0 +---------+1 +--------+ 2 +-------+3 | +------+ +------+ +-------+ +------+ domain0 node0 node1 node2 node3 domain1 node0+1 node0+1 node2+3 node2+3 + domain2 node0+1+2 | group: node0+1 | group:node2+3 <-------------------+ when node2 is added into the domain2 of node0, kernel is using the child domain of node2's domain2, which is domain1(node2+3). Node 3 is outside the span of the domain including node0+1+2. This will make load_balance() run based on screwed avg_load and group_type in the sched_group spanning out of the sched_domain, and it also makes select_task_rq_fair() pick an idle CPU outside the sched_domain. Real servers which suffer from this problem include Kunpeng920 and 8-node Sun Fire X4600-M2, at least. Here we move to use the *child* domain of the *child* domain of node2's domain2 as the new added sched_group. At the same, we re-use the lower level sgc directly. +------+ +------+ +-------+ +------+ | node | 12 |node | 20 | node | 12 |node | | 0 +---------+1 +--------+ 2 +-------+3 | +------+ +------+ +-------+ +------+ domain0 node0 node1 +- node2 node3 | domain1 node0+1 node0+1 | node2+3 node2+3 | domain2 node0+1+2 | group: node0+1 | group:node2 <-------------------+ While the lower level sgc is re-used, this patch only changes the remote sched_groups for those sched_domains playing grandchild trick, therefore, sgc->next_update is still safe since it's only touched by CPUs that have the group span as local group. And sgc->imbalance is also safe because sd_parent remains the same in load_balance and LB only tries other CPUs from the local group. Moreover, since local groups are not touched, they are still getting roughly equal size in a TL. And should_we_balance() only matters with local groups, so the pull probability of those groups are still roughly equal. Tested by the below topology: qemu-system-aarch64 -M virt -nographic \ -smp cpus=8 \ -numa node,cpus=0-1,nodeid=0 \ -numa node,cpus=2-3,nodeid=1 \ -numa node,cpus=4-5,nodeid=2 \ -numa node,cpus=6-7,nodeid=3 \ -numa dist,src=0,dst=1,val=12 \ -numa dist,src=0,dst=2,val=20 \ -numa dist,src=0,dst=3,val=22 \ -numa dist,src=1,dst=2,val=22 \ -numa dist,src=2,dst=3,val=12 \ -numa dist,src=1,dst=3,val=24 \ -m 4G -cpu cortex-a57 -kernel arch/arm64/boot/Image w/o patch, we get lots of "groups don't span domain->span": [ 0.802139] CPU0 attaching sched-domain(s): [ 0.802193] domain-0: span=0-1 level=MC [ 0.802443] groups: 0:{ span=0 cap=1013 }, 1:{ span=1 cap=979 } [ 0.802693] domain-1: span=0-3 level=NUMA [ 0.802731] groups: 0:{ span=0-1 cap=1992 }, 2:{ span=2-3 cap=1943 } [ 0.802811] domain-2: span=0-5 level=NUMA [ 0.802829] groups: 0:{ span=0-3 cap=3935 }, 4:{ span=4-7 cap=3937 } [ 0.802881] ERROR: groups don't span domain->span [ 0.803058] domain-3: span=0-7 level=NUMA [ 0.803080] groups: 0:{ span=0-5 mask=0-1 cap=5843 }, 6:{ span=4-7 mask=6-7 cap=4077 } [ 0.804055] CPU1 attaching sched-domain(s): [ 0.804072] domain-0: span=0-1 level=MC [ 0.804096] groups: 1:{ span=1 cap=979 }, 0:{ span=0 cap=1013 } [ 0.804152] domain-1: span=0-3 level=NUMA [ 0.804170] groups: 0:{ span=0-1 cap=1992 }, 2:{ span=2-3 cap=1943 } [ 0.804219] domain-2: span=0-5 level=NUMA [ 0.804236] groups: 0:{ span=0-3 cap=3935 }, 4:{ span=4-7 cap=3937 } [ 0.804302] ERROR: groups don't span domain->span [ 0.804520] domain-3: span=0-7 level=NUMA [ 0.804546] groups: 0:{ span=0-5 mask=0-1 cap=5843 }, 6:{ span=4-7 mask=6-7 cap=4077 } [ 0.804677] CPU2 attaching sched-domain(s): [ 0.804687] domain-0: span=2-3 level=MC [ 0.804705] groups: 2:{ span=2 cap=934 }, 3:{ span=3 cap=1009 } [ 0.804754] domain-1: span=0-3 level=NUMA [ 0.804772] groups: 2:{ span=2-3 cap=1943 }, 0:{ span=0-1 cap=1992 } [ 0.804820] domain-2: span=0-5 level=NUMA [ 0.804836] groups: 2:{ span=0-3 mask=2-3 cap=3991 }, 4:{ span=0-1,4-7 mask=4-5 cap=5985 } [ 0.804944] ERROR: groups don't span domain->span [ 0.805108] domain-3: span=0-7 level=NUMA [ 0.805134] groups: 2:{ span=0-5 mask=2-3 cap=5899 }, 6:{ span=0-1,4-7 mask=6-7 cap=6125 } [ 0.805223] CPU3 attaching sched-domain(s): [ 0.805232] domain-0: span=2-3 level=MC [ 0.805249] groups: 3:{ span=3 cap=1009 }, 2:{ span=2 cap=934 } [ 0.805319] domain-1: span=0-3 level=NUMA [ 0.805336] groups: 2:{ span=2-3 cap=1943 }, 0:{ span=0-1 cap=1992 } [ 0.805383] domain-2: span=0-5 level=NUMA [ 0.805399] groups: 2:{ span=0-3 mask=2-3 cap=3991 }, 4:{ span=0-1,4-7 mask=4-5 cap=5985 } [ 0.805458] ERROR: groups don't span domain->span [ 0.805605] domain-3: span=0-7 level=NUMA [ 0.805626] groups: 2:{ span=0-5 mask=2-3 cap=5899 }, 6:{ span=0-1,4-7 mask=6-7 cap=6125 } [ 0.805712] CPU4 attaching sched-domain(s): [ 0.805721] domain-0: span=4-5 level=MC [ 0.805738] groups: 4:{ span=4 cap=984 }, 5:{ span=5 cap=924 } [ 0.805787] domain-1: span=4-7 level=NUMA [ 0.805803] groups: 4:{ span=4-5 cap=1908 }, 6:{ span=6-7 cap=2029 } [ 0.805851] domain-2: span=0-1,4-7 level=NUMA [ 0.805867] groups: 4:{ span=4-7 cap=3937 }, 0:{ span=0-3 cap=3935 } [ 0.805915] ERROR: groups don't span domain->span [ 0.806108] domain-3: span=0-7 level=NUMA [ 0.806130] groups: 4:{ span=0-1,4-7 mask=4-5 cap=5985 }, 2:{ span=0-3 mask=2-3 cap=3991 } [ 0.806214] CPU5 attaching sched-domain(s): [ 0.806222] domain-0: span=4-5 level=MC [ 0.806240] groups: 5:{ span=5 cap=924 }, 4:{ span=4 cap=984 } [ 0.806841] domain-1: span=4-7 level=NUMA [ 0.806866] groups: 4:{ span=4-5 cap=1908 }, 6:{ span=6-7 cap=2029 } [ 0.806934] domain-2: span=0-1,4-7 level=NUMA [ 0.806953] groups: 4:{ span=4-7 cap=3937 }, 0:{ span=0-3 cap=3935 } [ 0.807004] ERROR: groups don't span domain->span [ 0.807312] domain-3: span=0-7 level=NUMA [ 0.807386] groups: 4:{ span=0-1,4-7 mask=4-5 cap=5985 }, 2:{ span=0-3 mask=2-3 cap=3991 } [ 0.807686] CPU6 attaching sched-domain(s): [ 0.807710] domain-0: span=6-7 level=MC [ 0.807750] groups: 6:{ span=6 cap=1017 }, 7:{ span=7 cap=1012 } [ 0.807840] domain-1: span=4-7 level=NUMA [ 0.807870] groups: 6:{ span=6-7 cap=2029 }, 4:{ span=4-5 cap=1908 } [ 0.807952] domain-2: span=0-1,4-7 level=NUMA [ 0.807985] groups: 6:{ span=4-7 mask=6-7 cap=4077 }, 0:{ span=0-5 mask=0-1 cap=5843 } [ 0.808045] ERROR: groups don't span domain->span [ 0.808257] domain-3: span=0-7 level=NUMA [ 0.808571] groups: 6:{ span=0-1,4-7 mask=6-7 cap=6125 }, 2:{ span=0-5 mask=2-3 cap=5899 } [ 0.808848] CPU7 attaching sched-domain(s): [ 0.808860] domain-0: span=6-7 level=MC [ 0.808880] groups: 7:{ span=7 cap=1012 }, 6:{ span=6 cap=1017 } [ 0.808953] domain-1: span=4-7 level=NUMA [ 0.808974] groups: 6:{ span=6-7 cap=2029 }, 4:{ span=4-5 cap=1908 } [ 0.809034] domain-2: span=0-1,4-7 level=NUMA [ 0.809055] groups: 6:{ span=4-7 mask=6-7 cap=4077 }, 0:{ span=0-5 mask=0-1 cap=5843 } [ 0.809128] ERROR: groups don't span domain->span [ 0.810361] domain-3: span=0-7 level=NUMA [ 0.810400] groups: 6:{ span=0-1,4-7 mask=6-7 cap=5961 }, 2:{ span=0-5 mask=2-3 cap=5903 } w/ patch, we don't get "groups don't span domain->span" any more: [ 1.486271] CPU0 attaching sched-domain(s): [ 1.486820] domain-0: span=0-1 level=MC [ 1.500924] groups: 0:{ span=0 cap=980 }, 1:{ span=1 cap=994 } [ 1.515717] domain-1: span=0-3 level=NUMA [ 1.515903] groups: 0:{ span=0-1 cap=1974 }, 2:{ span=2-3 cap=1989 } [ 1.516989] domain-2: span=0-5 level=NUMA [ 1.517124] groups: 0:{ span=0-3 cap=3963 }, 4:{ span=4-5 cap=1949 } [ 1.517369] domain-3: span=0-7 level=NUMA [ 1.517423] groups: 0:{ span=0-5 mask=0-1 cap=5912 }, 6:{ span=4-7 mask=6-7 cap=4054 } [ 1.520027] CPU1 attaching sched-domain(s): [ 1.520097] domain-0: span=0-1 level=MC [ 1.520184] groups: 1:{ span=1 cap=994 }, 0:{ span=0 cap=980 } [ 1.520429] domain-1: span=0-3 level=NUMA [ 1.520487] groups: 0:{ span=0-1 cap=1974 }, 2:{ span=2-3 cap=1989 } [ 1.520687] domain-2: span=0-5 level=NUMA [ 1.520744] groups: 0:{ span=0-3 cap=3963 }, 4:{ span=4-5 cap=1949 } [ 1.520948] domain-3: span=0-7 level=NUMA [ 1.521038] groups: 0:{ span=0-5 mask=0-1 cap=5912 }, 6:{ span=4-7 mask=6-7 cap=4054 } [ 1.522068] CPU2 attaching sched-domain(s): [ 1.522348] domain-0: span=2-3 level=MC [ 1.522606] groups: 2:{ span=2 cap=1003 }, 3:{ span=3 cap=986 } [ 1.522832] domain-1: span=0-3 level=NUMA [ 1.522885] groups: 2:{ span=2-3 cap=1989 }, 0:{ span=0-1 cap=1974 } [ 1.523043] domain-2: span=0-5 level=NUMA [ 1.523092] groups: 2:{ span=0-3 mask=2-3 cap=4037 }, 4:{ span=4-5 cap=1949 } [ 1.523302] domain-3: span=0-7 level=NUMA [ 1.523352] groups: 2:{ span=0-5 mask=2-3 cap=5986 }, 6:{ span=0-1,4-7 mask=6-7 cap=6102 } [ 1.523748] CPU3 attaching sched-domain(s): [ 1.523774] domain-0: span=2-3 level=MC [ 1.523825] groups: 3:{ span=3 cap=986 }, 2:{ span=2 cap=1003 } [ 1.524009] domain-1: span=0-3 level=NUMA [ 1.524086] groups: 2:{ span=2-3 cap=1989 }, 0:{ span=0-1 cap=1974 } [ 1.524281] domain-2: span=0-5 level=NUMA [ 1.524331] groups: 2:{ span=0-3 mask=2-3 cap=4037 }, 4:{ span=4-5 cap=1949 } [ 1.524534] domain-3: span=0-7 level=NUMA [ 1.524586] groups: 2:{ span=0-5 mask=2-3 cap=5986 }, 6:{ span=0-1,4-7 mask=6-7 cap=6102 } [ 1.524847] CPU4 attaching sched-domain(s): [ 1.524873] domain-0: span=4-5 level=MC [ 1.524954] groups: 4:{ span=4 cap=958 }, 5:{ span=5 cap=991 } [ 1.525105] domain-1: span=4-7 level=NUMA [ 1.525153] groups: 4:{ span=4-5 cap=1949 }, 6:{ span=6-7 cap=2006 } [ 1.525368] domain-2: span=0-1,4-7 level=NUMA [ 1.525428] groups: 4:{ span=4-7 cap=3955 }, 0:{ span=0-1 cap=1974 } [ 1.532726] domain-3: span=0-7 level=NUMA [ 1.532811] groups: 4:{ span=0-1,4-7 mask=4-5 cap=6003 }, 2:{ span=0-3 mask=2-3 cap=4037 } [ 1.534125] CPU5 attaching sched-domain(s): [ 1.534159] domain-0: span=4-5 level=MC [ 1.534303] groups: 5:{ span=5 cap=991 }, 4:{ span=4 cap=958 } [ 1.534490] domain-1: span=4-7 level=NUMA [ 1.534572] groups: 4:{ span=4-5 cap=1949 }, 6:{ span=6-7 cap=2006 } [ 1.534734] domain-2: span=0-1,4-7 level=NUMA [ 1.534783] groups: 4:{ span=4-7 cap=3955 }, 0:{ span=0-1 cap=1974 } [ 1.536057] domain-3: span=0-7 level=NUMA [ 1.536430] groups: 4:{ span=0-1,4-7 mask=4-5 cap=6003 }, 2:{ span=0-3 mask=2-3 cap=3896 } [ 1.536815] CPU6 attaching sched-domain(s): [ 1.536846] domain-0: span=6-7 level=MC [ 1.536934] groups: 6:{ span=6 cap=1005 }, 7:{ span=7 cap=1001 } [ 1.537144] domain-1: span=4-7 level=NUMA [ 1.537262] groups: 6:{ span=6-7 cap=2006 }, 4:{ span=4-5 cap=1949 } [ 1.537553] domain-2: span=0-1,4-7 level=NUMA [ 1.537613] groups: 6:{ span=4-7 mask=6-7 cap=4054 }, 0:{ span=0-1 cap=1805 } [ 1.537872] domain-3: span=0-7 level=NUMA [ 1.537998] groups: 6:{ span=0-1,4-7 mask=6-7 cap=6102 }, 2:{ span=0-5 mask=2-3 cap=5845 } [ 1.538448] CPU7 attaching sched-domain(s): [ 1.538505] domain-0: span=6-7 level=MC [ 1.538586] groups: 7:{ span=7 cap=1001 }, 6:{ span=6 cap=1005 } [ 1.538746] domain-1: span=4-7 level=NUMA [ 1.538798] groups: 6:{ span=6-7 cap=2006 }, 4:{ span=4-5 cap=1949 } [ 1.539048] domain-2: span=0-1,4-7 level=NUMA [ 1.539111] groups: 6:{ span=4-7 mask=6-7 cap=4054 }, 0:{ span=0-1 cap=1805 } [ 1.539571] domain-3: span=0-7 level=NUMA [ 1.539610] groups: 6:{ span=0-1,4-7 mask=6-7 cap=6102 }, 2:{ span=0-5 mask=2-3 cap=5845 } Signed-off-by: Barry Song Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Reviewed-by: Valentin Schneider Tested-by: Meelis Roos Link: https://lkml.kernel.org/r/20210224030944.15232-1-song.bao.hua@hisilicon.com Signed-off-by: Sasha Levin commit 125cb2c7f8f31408669f44bd882f1c836f4a5f69 Author: Vincent Donnefort Date: Thu Feb 25 16:58:20 2021 +0000 sched/pelt: Fix task util_est update filtering [ Upstream commit b89997aa88f0b07d8a6414c908af75062103b8c9 ] Being called for each dequeue, util_est reduces the number of its updates by filtering out when the EWMA signal is different from the task util_avg by less than 1%. It is a problem for a sudden util_avg ramp-up. Due to the decay from a previous high util_avg, EWMA might now be close enough to the new util_avg. No update would then happen while it would leave ue.enqueued with an out-of-date value. Taking into consideration the two util_est members, EWMA and enqueued for the filtering, ensures, for both, an up-to-date value. This is for now an issue only for the trace probe that might return the stale value. Functional-wise, it isn't a problem, as the value is always accessed through max(enqueued, ewma). This problem has been observed using LISA's UtilConvergence:test_means on the sd845c board. No regression observed with Hackbench on sd845c and Perf-bench sched pipe on hikey/hikey960. Signed-off-by: Vincent Donnefort Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Reviewed-by: Dietmar Eggemann Reviewed-by: Vincent Guittot Link: https://lkml.kernel.org/r/20210225165820.1377125-1-vincent.donnefort@arm.com Signed-off-by: Sasha Levin commit 0feca71f535942c8f3f1cb845efa2f94696e3f82 Author: Vincent Donnefort Date: Thu Feb 25 08:36:11 2021 +0000 sched/fair: Fix task utilization accountability in compute_energy() [ Upstream commit 0372e1cf70c28de6babcba38ef97b6ae3400b101 ] find_energy_efficient_cpu() (feec()) computes for each perf_domain (pd) an energy delta as follows: feec(task) for_each_pd base_energy = compute_energy(task, -1, pd) -> for_each_cpu(pd) -> cpu_util_next(cpu, task, -1) energy_delta = compute_energy(task, dst_cpu, pd) -> for_each_cpu(pd) -> cpu_util_next(cpu, task, dst_cpu) energy_delta -= base_energy Then it picks the best CPU as being the one that minimizes energy_delta. cpu_util_next() estimates the CPU utilization that would happen if the task was placed on dst_cpu as follows: max(cpu_util + task_util, cpu_util_est + _task_util_est) The task contribution to the energy delta can then be either: (1) _task_util_est, on a mostly idle CPU, where cpu_util is close to 0 and _task_util_est > cpu_util. (2) task_util, on a mostly busy CPU, where cpu_util > _task_util_est. (cpu_util_est doesn't appear here. It is 0 when a CPU is idle and otherwise must be small enough so that feec() takes the CPU as a potential target for the task placement) This is problematic for feec(), as cpu_util_next() might give an unfair advantage to a CPU which is mostly busy (2) compared to one which is mostly idle (1). _task_util_est being always bigger than task_util in feec() (as the task is waking up), the task contribution to the energy might look smaller on certain CPUs (2) and this breaks the energy comparison. This issue is, moreover, not sporadic. By starving idle CPUs, it keeps their cpu_util < _task_util_est (1) while others will maintain cpu_util > _task_util_est (2). Fix this problem by always using max(task_util, _task_util_est) as a task contribution to the energy (ENERGY_UTIL). The new estimated CPU utilization for the energy would then be: max(cpu_util, cpu_util_est) + max(task_util, _task_util_est) compute_energy() still needs to know which OPP would be selected if the task would be migrated in the perf_domain (FREQUENCY_UTIL). Hence, cpu_util_next() is still used to estimate the maximum util within the pd. Signed-off-by: Vincent Donnefort Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Reviewed-by: Quentin Perret Reviewed-by: Dietmar Eggemann Link: https://lkml.kernel.org/r/20210225083612.1113823-2-vincent.donnefort@arm.com Signed-off-by: Sasha Levin commit d4be398888b76787e804de50c79f3eee9ef2a852 Author: Emily Deng Date: Thu Mar 4 19:30:51 2021 +0800 drm/amdgpu: Fix some unload driver issues [ Upstream commit bb0cd09be45ea457f25fdcbcb3d6cf2230f26c46 ] When unloading driver after killing some applications, it will hit sdma flush tlb job timeout which is called by ttm_bo_delay_delete. So to avoid the job submit after fence driver fini, call ttm_bo_lock_delayed_workqueue before fence driver fini. And also put drm_sched_fini before waiting fence. Signed-off-by: Emily Deng Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 05395840ae35c4a71c121ed4929e906d9da1dae0 Author: Arunpravin Date: Mon Mar 1 15:45:13 2021 +0530 drm/amd/pm/swsmu: clean up user profile function [ Upstream commit d8cce9306801cfbf709055677f7896905094ff95 ] Remove unnecessary comments, enable restore mode using '|=' operator, fixes the alignment to improve the code readability. v2: Move all restoration flag check to bitwise '&' operator Signed-off-by: Arunpravin Reviewed-by: Evan Quan Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit e085b5916049ba90f6231dfde72bbcbcda8f5380 Author: James Smart Date: Mon Mar 1 09:18:13 2021 -0800 scsi: lpfc: Fix ADISC handling that never frees nodes [ Upstream commit 309b477462df7542355ac984674a6e89c01c89aa ] While testing target port swap test with ADISC enabled, several nodes remain in UNUSED state. These nodes are never freed and rmmod hangs for long time before finising with "0233 Nodelist not empty" error. During PLOGI completion lpfc_plogi_confirm_nport() looks for existing nodes with same WWPN. If found, the existing node is used to continue discovery. The node on which plogi was performed is freed. When ADISC is enabled, an ADISC els request is triggered in response to an RSCN. It's possible that the ADISC may be rejected by the remote port causing the ADISC completion handler to clear the port and node name in the node. If this occurs, if a PLOGI is received it causes a node lookup based on wwpn to now fail, causing the port swap logic to kick in which allocates a new node and swaps to it. This effectively orphans the original node structure. Fix the situation by detecting when the lookup fails and forgo the node swap and node allocation by using the node on which the PLOGI was issued. Link: https://lore.kernel.org/r/20210301171821.3427-15-jsmart2021@gmail.com Co-developed-by: Dick Kennedy Signed-off-by: Dick Kennedy Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit a2dc0640eacdc8ba236cadc792d14a57d1d90fbc Author: James Smart Date: Mon Mar 1 09:18:12 2021 -0800 scsi: lpfc: Fix PLOGI ACC to be transmit after REG_LOGIN [ Upstream commit 143753059b8b957f1cf4355338a3e3a32f3a85bf ] The driver is seeing a scenario where PLOGI response was issued and traffic is arriving while the adapter is still setting up the login context. This is resulting in errors handling the traffic. Change the driver so that PLOGI response is sent after the login context has been setup to avoid the situation. Link: https://lore.kernel.org/r/20210301171821.3427-14-jsmart2021@gmail.com Co-developed-by: Dick Kennedy Signed-off-by: Dick Kennedy Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 823db6f1490e911a2a52bb47de68a06680ec887c Author: James Smart Date: Mon Mar 1 09:18:10 2021 -0800 scsi: lpfc: Fix status returned in lpfc_els_retry() error exit path [ Upstream commit 148bc64d38fe314475a074c4f757ec9d84537d1c ] An unlikely error exit path from lpfc_els_retry() returns incorrect status to a caller, erroneously indicating that a retry has been successfully issued or scheduled. Change error exit path to indicate no retry. Link: https://lore.kernel.org/r/20210301171821.3427-12-jsmart2021@gmail.com Co-developed-by: Dick Kennedy Signed-off-by: Dick Kennedy Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 895d55027f4ba2ecae05fb7529f0061432afe204 Author: James Smart Date: Mon Mar 1 09:18:06 2021 -0800 scsi: lpfc: Fix pt2pt connection does not recover after LOGO [ Upstream commit bd4f5100424d17d4e560d6653902ef8e49b2fc1f ] On a pt2pt setup, between 2 initiators, if one side issues a a LOGO, there is no relogin attempt. The FC specs are grey in this area on which port (higher wwn or not) is to re-login. As there is no spec guidance, unconditionally re-PLOGI after the logout to ensure a login is re-established. Link: https://lore.kernel.org/r/20210301171821.3427-8-jsmart2021@gmail.com Co-developed-by: Dick Kennedy Signed-off-by: Dick Kennedy Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 3224d515e4d9c0a00c1a7a359028b074ee12aad2 Author: James Smart Date: Mon Mar 1 09:18:00 2021 -0800 scsi: lpfc: Fix incorrect dbde assignment when building target abts wqe [ Upstream commit 9302154c07bff4e7f7f43c506a1ac84540303d06 ] The wqe_dbde field indicates whether a Data BDE is present in Words 0:2 and should therefore should be clear in the abts request wqe. By setting the bit we can be misleading fw into error cases. Clear the wqe_dbde field. Link: https://lore.kernel.org/r/20210301171821.3427-2-jsmart2021@gmail.com Co-developed-by: Dick Kennedy Signed-off-by: Dick Kennedy Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit b9694aef9b1acca1fe885628ee1f091779dde211 Author: Lee Jones Date: Wed Mar 3 13:42:36 2021 +0000 drm/amd/display/dc/dce/dce_aux: Remove duplicate line causing 'field overwritten' issue [ Upstream commit 3e3527f5b765c6f479ba55e5a570ee9538589a74 ] Fixes the following W=1 kernel build warning(s): In file included from drivers/gpu/drm/amd/amdgpu/../display/dc/dce112/dce112_resource.c:59: drivers/gpu/drm/amd/amdgpu/../include/asic_reg/dce/dce_11_2_sh_mask.h:10014:58: warning: initialized field overwritten [-Woverride-init] drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.h:214:16: note: in expansion of macro ‘AUX_SW_DATA__AUX_SW_AUTOINCREMENT_DISABLE__SHIFT’ drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.h:127:2: note: in expansion of macro ‘AUX_SF’ drivers/gpu/drm/amd/amdgpu/../display/dc/dce112/dce112_resource.c:177:2: note: in expansion of macro ‘DCE_AUX_MASK_SH_LIST’ drivers/gpu/drm/amd/amdgpu/../include/asic_reg/dce/dce_11_2_sh_mask.h:10014:58: note: (near initialization for ‘aux_shift.AUX_SW_AUTOINCREMENT_DISABLE’) drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.h:214:16: note: in expansion of macro ‘AUX_SW_DATA__AUX_SW_AUTOINCREMENT_DISABLE__SHIFT’ drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.h:127:2: note: in expansion of macro ‘AUX_SF’ drivers/gpu/drm/amd/amdgpu/../display/dc/dce112/dce112_resource.c:177:2: note: in expansion of macro ‘DCE_AUX_MASK_SH_LIST’ drivers/gpu/drm/amd/amdgpu/../include/asic_reg/dce/dce_11_2_sh_mask.h:10013:56: warning: initialized field overwritten [-Woverride-init] drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.h:214:16: note: in expansion of macro ‘AUX_SW_DATA__AUX_SW_AUTOINCREMENT_DISABLE_MASK’ drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.h:127:2: note: in expansion of macro ‘AUX_SF’ drivers/gpu/drm/amd/amdgpu/../display/dc/dce112/dce112_resource.c:181:2: note: in expansion of macro ‘DCE_AUX_MASK_SH_LIST’ drivers/gpu/drm/amd/amdgpu/../include/asic_reg/dce/dce_11_2_sh_mask.h:10013:56: note: (near initialization for ‘aux_mask.AUX_SW_AUTOINCREMENT_DISABLE’) drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.h:214:16: note: in expansion of macro ‘AUX_SW_DATA__AUX_SW_AUTOINCREMENT_DISABLE_MASK’ drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.h:127:2: note: in expansion of macro ‘AUX_SF’ Cc: Harry Wentland Cc: Leo Li Cc: Alex Deucher Cc: "Christian König" Cc: David Airlie Cc: Daniel Vetter Cc: amd-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Lee Jones Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit a586b255e8e9c1c56a2960414a6f2dd328032bfe Author: Xiaogang Chen Date: Thu Feb 25 12:06:34 2021 -0500 drm/amdgpu/display: buffer INTERRUPT_LOW_IRQ_CONTEXT interrupt work [ Upstream commit b6f91fc183f758461b9462cc93e673adbbf95c2d ] amdgpu DM handles INTERRUPT_LOW_IRQ_CONTEXT interrupt(hpd, hpd_rx) by using work queue and uses single work_struct. If new interrupt is recevied before the previous handler finished, new interrupts(same type) will be discarded and driver just sends "amdgpu_dm_irq_schedule_work FAILED" message out. If some important hpd, hpd_rx related interrupts are missed by driver the hot (un)plug devices may cause system hang or instability, such as issues with system resume from S3 sleep with mst device connected. This patch dynamically allocates new amdgpu_dm_irq_handler_data for new interrupts if previous INTERRUPT_LOW_IRQ_CONTEXT interrupt work has not been handled. So the new interrupt works can be queued to the same workqueue_struct, instead of discard the new interrupts. All allocated amdgpu_dm_irq_handler_data are put into a single linked list and will be reused after. Signed-off-by: Xiaogang Chen Reviewed-by: Aurabindo Pillai Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 34ef003c04d38482bc6c8d55b365af77e4a70a85 Author: Wyatt Wood Date: Fri Feb 19 12:21:47 2021 -0500 drm/amd/display: Return invalid state if GPINT times out [ Upstream commit 8039bc7130ef4206a58e4dc288621bc97eba08eb ] [Why] GPINT timeout is causing PSR_STATE_0 to be returned when it shouldn't. We must guarantee that PSR is fully disabled before doing hw programming on driver-side. [How] Return invalid state if GPINT command times out. Let existing retry logic send the GPINT until successful. Tested-by: Daniel Wheeler Signed-off-by: Wyatt Wood Reviewed-by: Anthony Koo Acked-by: Rodrigo Siqueira Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 26a5506faacb65b06ba0d072263f78fef223703d Author: Aric Cyr Date: Fri Feb 12 18:13:59 2021 -0500 drm/amd/display: Don't optimize bandwidth before disabling planes [ Upstream commit 6ad98e8aeb0106f453bb154933e8355849244990 ] [Why] There is a window of time where we optimize bandwidth due to no streams enabled will enable PSTATE changing but HUBPs are not disabled yet. This results in underflow counter increasing in some hotplug scenarios. [How] Set the optimize-bandwidth flag for later processing once all the HUBPs are properly disabled. Signed-off-by: Aric Cyr Acked-by: Bindu Ramamurthy Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit e9b75f1e5ee0fd9a42049da5e3f0738dea014b6a Author: Eryk Brol Date: Tue Feb 9 17:09:52 2021 -0500 drm/amd/display: Check for DSC support instead of ASIC revision [ Upstream commit 349a19b2f1b01e713268c7de9944ad669ccdf369 ] [why] This check for ASIC revision is no longer useful and causes lightup issues after a topology change in MST DSC scenario. In this case, DSC configs should be recalculated for the new topology. This check prevented that from happening on certain ASICs that do, in fact, support DSC. [how] Change the ASIC revision to instead check if DSC is supported. Signed-off-by: Eryk Brol Acked-by: Bindu Ramamurthy Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 2cf0e67da6467533636091760d1a4ab9491bc8a1 Author: Tong Zhang Date: Sun Feb 21 21:33:22 2021 -0500 drm/ast: fix memory leak when unload the driver [ Upstream commit dc739820ff90acccd013f6bb420222978a982791 ] a connector is leaked upon module unload, it seems that we should do similar to sample driver as suggested in drm_drv.c. Adding drm_atomic_helper_shutdown() in ast_pci_remove to prevent leaking. [ 153.822134] WARNING: CPU: 0 PID: 173 at drivers/gpu/drm/drm_mode_config.c:504 drm_mode_config_cle0 [ 153.822698] Modules linked in: ast(-) drm_vram_helper drm_ttm_helper ttm [last unloaded: ttm] [ 153.823197] CPU: 0 PID: 173 Comm: modprobe Tainted: G W 5.11.0-03615-g55f62bc873474 [ 153.823708] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-48-gd9c812dda519-4 [ 153.824333] RIP: 0010:drm_mode_config_cleanup+0x418/0x470 [ 153.824637] Code: 0c 00 00 00 00 48 8b 84 24 a8 00 00 00 65 48 33 04 25 28 00 00 00 75 65 48 81 c0 [ 153.825668] RSP: 0018:ffff888103c9fb70 EFLAGS: 00010212 [ 153.825962] RAX: ffff888102b0d100 RBX: ffff888102b0c298 RCX: ffffffff818d8b2b [ 153.826356] RDX: dffffc0000000000 RSI: 000000007fffffff RDI: ffff888102b0c298 [ 153.826748] RBP: ffff888103c9fba0 R08: 0000000000000001 R09: ffffed1020561857 [ 153.827146] R10: ffff888102b0c2b7 R11: ffffed1020561856 R12: ffff888102b0c000 [ 153.827538] R13: ffff888102b0c2d8 R14: ffff888102b0c2d8 R15: 1ffff11020793f70 [ 153.827935] FS: 00007f24bff456a0(0000) GS:ffff88815b400000(0000) knlGS:0000000000000000 [ 153.828380] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 153.828697] CR2: 0000000001c39018 CR3: 0000000103c90000 CR4: 00000000000006f0 [ 153.829096] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 153.829486] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 153.829883] Call Trace: [ 153.830024] ? drmm_mode_config_init+0x930/0x930 [ 153.830281] ? cpumask_next+0x16/0x20 [ 153.830488] ? mnt_get_count+0x66/0x80 [ 153.830699] ? drm_mode_config_cleanup+0x470/0x470 [ 153.830972] drm_managed_release+0xed/0x1c0 [ 153.831208] drm_dev_release+0x3a/0x50 [ 153.831420] release_nodes+0x39e/0x410 [ 153.831631] ? devres_release+0x40/0x40 [ 153.831852] device_release_driver_internal+0x158/0x270 [ 153.832143] driver_detach+0x76/0xe0 [ 153.832344] bus_remove_driver+0x7e/0x100 [ 153.832568] pci_unregister_driver+0x28/0xf0 [ 153.832821] __x64_sys_delete_module+0x268/0x300 [ 153.833086] ? __ia32_sys_delete_module+0x300/0x300 [ 153.833357] ? call_rcu+0x372/0x4f0 [ 153.833553] ? fpregs_assert_state_consistent+0x4d/0x60 [ 153.833840] ? exit_to_user_mode_prepare+0x2f/0x130 [ 153.834118] do_syscall_64+0x33/0x40 [ 153.834317] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 153.834597] RIP: 0033:0x7f24bfec7cf7 [ 153.834797] Code: 48 89 57 30 48 8b 04 24 48 89 47 38 e9 1d a0 02 00 48 89 f8 48 89 f7 48 89 d6 41 [ 153.835812] RSP: 002b:00007fff72e6cb58 EFLAGS: 00000202 ORIG_RAX: 00000000000000b0 [ 153.836234] RAX: ffffffffffffffda RBX: 00007f24bff45690 RCX: 00007f24bfec7cf7 [ 153.836623] RDX: 00000000ffffffff RSI: 0000000000000080 RDI: 0000000001c2fb10 [ 153.837018] RBP: 0000000001c2fac0 R08: 2f2f2f2f2f2f2f2f R09: 0000000001c2fac0 [ 153.837408] R10: fefefefefefefeff R11: 0000000000000202 R12: 0000000001c2fac0 [ 153.837798] R13: 0000000001c2f9d0 R14: 0000000000000000 R15: 0000000000000001 [ 153.838194] ---[ end trace b92031513bbe596c ]--- [ 153.838441] [drm:drm_mode_config_cleanup] *ERROR* connector VGA-1 leaked! Signed-off-by: Tong Zhang Signed-off-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/20210222023322.984885-1-ztong0001@gmail.com Signed-off-by: Sasha Levin commit b76edf81bf8596ba557636edec7b94f94ea5bac3 Author: Huang Rui Date: Wed Feb 10 12:27:43 2021 +0800 drm/amd/pm: do not issue message while write "r" into pp_od_clk_voltage [ Upstream commit ca1203d7d7295c49e5707d7def457bdc524a8edb ] We should commit the value after restore them back to default as well. $ echo "r" > pp_od_clk_voltage $ echo "c" > pp_od_clk_voltage Signed-off-by: Huang Rui Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 7b1d0b1ddeb99d154a93ce6f9596e1a0b70931ff Author: Nicholas Kazlauskas Date: Wed Feb 3 10:11:30 2021 -0500 drm/amd/display: Fix MPC OGAM power on/off sequence [ Upstream commit 737b2b536a30a467c405d75f2287e17828838a13 ] [Why] Color corruption can occur on bootup into a login manager that applies a non-linear gamma LUT because the LUT may not actually be powered on before writing. It's cleared on the next full pipe reprogramming as we switch to LUTB from LUTA and the pipe accessing the LUT has taken it out of light sleep mode. [How] The MPCC_OGAM_MEM_PWR_FORCE register does not force the current power mode when set to 0. It only forces when set light sleep, deep sleep or shutdown. The register to actually force power on and ignore sleep modes is MPCC_OGAM_MEM_PWR_DIS - a value of 0 will enable power requests and a value of 1 will disable them. When PWR_FORCE!=0 is combined with PWR_DIS=0 then MPCC OGAM memory is forced into the state specified by the force bits. If PWR_FORCE is 0 then it respects the mode specified by MPCC_OGAM_MEM_LOW_PWR_MODE if the RAM LUT is not in use. We set that bit to shutdown on low power, but otherwise it inherits from bootup defaults. So for the fix: 1. Update the sequence to "force" power on when needed We can use MPCC_OGAM_MEM_PWR_DIS for this to turn on the memory even when the block is in bypass and pending to be enabled for the next frame. We need this for both low power enabled or disabled. If we don't set this then we can run into issues when we first program the LUT from bootup. 2. Don't apply FORCE_SEL Once we enable power requests with DIS=0 we run into the issue of the RAM being forced into light sleep and being unusable for display output. Leave this 0 like we used to for DCN20. 3. Rely on MPCC OGAM init to determine light sleep/deep sleep MPC low power debug mode isn't enabled on any ASIC currently but we'll respect the setting determined during init if it is. Lightly tested as working with IGT tests and desktop color adjustment. 4. Change the MPC resource default for DCN30 It was interleaving the dcn20 and dcn30 versions before depending on the sequence. 5. REG_WAIT for it to be on whenever we're powering up the memory Otherwise we can write register values too early and we'll get corruption. Signed-off-by: Nicholas Kazlauskas Reviewed-by: Eric Yang Acked-by: Qingqing Zhuo Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 698b8222e590521b6028639f1a003ca98cba91d3 Author: Martin Leung Date: Tue Feb 2 16:28:05 2021 -0500 drm/amd/display: changing sr exit latency [ Upstream commit efe213e5a57e0cd92fa4f328dc1963d330549982 ] [Why] Hardware team remeasured, need to update timings to increase latency slightly and avoid intermittent underflows. [How] sr exit latency update. Signed-off-by: Martin Leung Reviewed-by: Alvin Lee Acked-by: Qingqing Zhuo Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 6c4e74b56e934cb3077c8935b3567dac8e18179c Author: Thomas Zimmermann Date: Tue Feb 9 14:46:24 2021 +0100 drm/ast: Fix invalid usage of AST_MAX_HWC_WIDTH in cursor atomic_check [ Upstream commit ee4a92d690f30f3793df942939726bec0338e65b ] Use AST_MAX_HWC_HEIGHT for setting offset_y in the cursor plane's atomic_check. The code used AST_MAX_HWC_WIDTH instead. This worked because both constants has the same value. Signed-off-by: Thomas Zimmermann Acked-by: Gerd Hoffmann Link: https://patchwork.freedesktop.org/patch/msgid/20210209134632.12157-3-tzimmermann@suse.de Signed-off-by: Sasha Levin commit 1d3ed1ec0a6b61945d866c778e7e161b8cfc5da9 Author: Gerd Hoffmann Date: Thu Feb 4 15:57:06 2021 +0100 drm/qxl: release shadow on shutdown [ Upstream commit 4ca77c513537700d3fae69030879f781dde1904c ] In case we have a shadow surface on shutdown release it so it doesn't leak. Signed-off-by: Gerd Hoffmann Acked-by: Thomas Zimmermann Link: http://patchwork.freedesktop.org/patch/msgid/20210204145712.1531203-6-kraxel@redhat.com Signed-off-by: Sasha Levin commit e7272a21ef6c5d73d23dbaa8a06aa5860838a187 Author: Tong Zhang Date: Tue Feb 2 23:07:27 2021 -0500 drm/qxl: do not run release if qxl failed to init [ Upstream commit b91907a6241193465ca92e357adf16822242296d ] if qxl_device_init() fail, drm device will not be registered, in this case, do not run qxl_drm_release() [ 5.258534] ================================================================== [ 5.258931] BUG: KASAN: user-memory-access in qxl_destroy_monitors_object+0x42/0xa0 [qxl] [ 5.259388] Write of size 8 at addr 00000000000014dc by task modprobe/95 [ 5.259754] [ 5.259842] CPU: 0 PID: 95 Comm: modprobe Not tainted 5.11.0-rc6-00007-g88bb507a74ea #62 [ 5.260309] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-48-gd9c812dda54 [ 5.260917] Call Trace: [ 5.261056] dump_stack+0x7d/0xa3 [ 5.261245] kasan_report.cold+0x10c/0x10e [ 5.261475] ? qxl_destroy_monitors_object+0x42/0xa0 [qxl] [ 5.261789] check_memory_region+0x17c/0x1e0 [ 5.262029] qxl_destroy_monitors_object+0x42/0xa0 [qxl] [ 5.262332] qxl_modeset_fini+0x9/0x20 [qxl] [ 5.262595] qxl_drm_release+0x22/0x30 [qxl] [ 5.262841] drm_dev_release+0x32/0x50 [ 5.263047] release_nodes+0x39e/0x410 [ 5.263253] ? devres_release+0x40/0x40 [ 5.263462] really_probe+0x2ea/0x420 [ 5.263664] driver_probe_device+0x6d/0xd0 [ 5.263888] device_driver_attach+0x82/0x90 [ 5.264116] ? device_driver_attach+0x90/0x90 [ 5.264353] __driver_attach+0x60/0x100 [ 5.264563] ? device_driver_attach+0x90/0x90 [ 5.264801] bus_for_each_dev+0xe1/0x140 [ 5.265014] ? subsys_dev_iter_exit+0x10/0x10 [ 5.265251] ? klist_node_init+0x61/0x80 [ 5.265464] bus_add_driver+0x254/0x2a0 [ 5.265673] driver_register+0xd3/0x150 [ 5.265882] ? 0xffffffffc0048000 [ 5.266064] do_one_initcall+0x84/0x250 [ 5.266274] ? trace_event_raw_event_initcall_finish+0x150/0x150 [ 5.266596] ? unpoison_range+0xf/0x30 [ 5.266801] ? ____kasan_kmalloc.constprop.0+0x84/0xa0 [ 5.267082] ? unpoison_range+0xf/0x30 [ 5.267287] ? unpoison_range+0xf/0x30 [ 5.267491] do_init_module+0xf8/0x350 [ 5.267697] load_module+0x3fe6/0x4340 [ 5.267902] ? vm_unmap_ram+0x1d0/0x1d0 [ 5.268115] ? module_frob_arch_sections+0x20/0x20 [ 5.268375] ? __do_sys_finit_module+0x108/0x170 [ 5.268624] __do_sys_finit_module+0x108/0x170 [ 5.268865] ? __ia32_sys_init_module+0x40/0x40 [ 5.269111] ? file_open_root+0x200/0x200 [ 5.269330] ? do_sys_open+0x85/0xe0 [ 5.269527] ? filp_open+0x50/0x50 [ 5.269714] ? exit_to_user_mode_prepare+0xfc/0x130 [ 5.269978] do_syscall_64+0x33/0x40 [ 5.270176] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 5.270450] RIP: 0033:0x7fa3f685bcf7 [ 5.270646] Code: 48 89 57 30 48 8b 04 24 48 89 47 38 e9 1d a0 02 00 48 89 f8 48 89 f7 48 89 d1 [ 5.271634] RSP: 002b:00007ffca83048d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [ 5.272037] RAX: ffffffffffffffda RBX: 0000000001e94a70 RCX: 00007fa3f685bcf7 [ 5.272416] RDX: 0000000000000000 RSI: 0000000001e939e0 RDI: 0000000000000003 [ 5.272794] RBP: 0000000000000003 R08: 0000000000000000 R09: 0000000000000001 [ 5.273171] R10: 00007fa3f68bf300 R11: 0000000000000246 R12: 0000000001e939e0 [ 5.273550] R13: 0000000000000000 R14: 0000000001e93bd0 R15: 0000000000000001 [ 5.273928] ================================================================== Signed-off-by: Tong Zhang Link: http://patchwork.freedesktop.org/patch/msgid/20210203040727.868921-1-ztong0001@gmail.com Signed-off-by: Gerd Hoffmann Signed-off-by: Sasha Levin commit 9ca845fb12c6bf586d7e1308ea72b442c90e7ad9 Author: Jared Baldridge Date: Wed Jan 20 12:56:26 2021 -0800 drm: Added orientation quirk for OneGX1 Pro [ Upstream commit 81ad7f9f78e4ff80e95be8282423f511b84f1166 ] The OneGX1 Pro has a fairly unique combination of generic strings, but we additionally match on the BIOS date just to be safe. Signed-off-by: Jared Baldridge Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Link: https://patchwork.freedesktop.org/patch/msgid/41288ccb-1012-486b-81c1-a24c31850c91@www.fastmail.com Signed-off-by: Sasha Levin commit c68956c429cdbc6a25b39585716c2f6a3a3253bc Author: Adam Ward Date: Wed Apr 21 12:03:06 2021 +0000 regulator: da9121: automotive variants identity fix [ Upstream commit 013592be146a10d3567c0062cd1416faab060704 ] This patch fixes identification of DA913x parts by the DA9121 driver, where a lack of clarity lead to implementation on the basis that variant IDs were to be identical to the equivalent rated non-automotive parts. There is a new emphasis on the DT identity to cope with overlap in these ID's - this is not considered to be problematic, because projects would be exclusively using automotive or consumer grade parts. Signed-off-by: Adam Ward Link: https://lore.kernel.org/r/20210421120306.DB5B880007F@slsrvapps-01.diasemi.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 9575200840832d832ddf08ce00cd336e7d218b52 Author: Josef Bacik Date: Fri Mar 12 15:25:21 2021 -0500 btrfs: convert logic BUG_ON()'s in replace_path to ASSERT()'s [ Upstream commit 7a9213a93546e7eaef90e6e153af6b8fc7553f10 ] A few BUG_ON()'s in replace_path are purely to keep us from making logical mistakes, so replace them with ASSERT()'s. Reviewed-by: Qu Wenruo Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 4cb0aea2e250eee35ccfac5f5395cd8f3238a9e5 Author: Josef Bacik Date: Fri Mar 12 15:25:20 2021 -0500 btrfs: do proper error handling in btrfs_update_reloc_root [ Upstream commit 592fbcd50c99b8adf999a2a54f9245caff333139 ] We call btrfs_update_root in btrfs_update_reloc_root, which can fail for all sorts of reasons, including IO errors. Instead of panicing the box lets return the error, now that all callers properly handle those errors. Reviewed-by: Qu Wenruo Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit aa7ccc79588b830af610b6d5de95a4a41f91566f Author: Josef Bacik Date: Fri Mar 12 15:25:14 2021 -0500 btrfs: do proper error handling in create_reloc_root [ Upstream commit 84c50ba5214c2f3c1be4a931d521ec19f55dfdc8 ] We do memory allocations here, read blocks from disk, all sorts of operations that could easily fail at any given point. Instead of panicing the box, simply return the error back up the chain, all callers at this point have proper error handling. Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 63d01008da136dc3de36de5852cc29c2b8694249 Author: Filipe Manana Date: Wed Mar 31 11:55:50 2021 +0100 btrfs: fix exhaustion of the system chunk array due to concurrent allocations [ Upstream commit eafa4fd0ad06074da8be4e28ff93b4dca9ffa407 ] When we are running out of space for updating the chunk tree, that is, when we are low on available space in the system space info, if we have many task concurrently allocating block groups, via fallocate for example, many of them can end up all allocating new system chunks when only one is needed. In extreme cases this can lead to exhaustion of the system chunk array, which has a size limit of 2048 bytes, and results in a transaction abort with errno EFBIG, producing a trace in dmesg like the following, which was triggered on a PowerPC machine with a node/leaf size of 64K: [1359.518899] ------------[ cut here ]------------ [1359.518980] BTRFS: Transaction aborted (error -27) [1359.519135] WARNING: CPU: 3 PID: 16463 at ../fs/btrfs/block-group.c:1968 btrfs_create_pending_block_groups+0x340/0x3c0 [btrfs] [1359.519152] Modules linked in: (...) [1359.519239] Supported: Yes, External [1359.519252] CPU: 3 PID: 16463 Comm: stress-ng Tainted: G X 5.3.18-47-default #1 SLE15-SP3 [1359.519274] NIP: c008000000e36fe8 LR: c008000000e36fe4 CTR: 00000000006de8e8 [1359.519293] REGS: c00000056890b700 TRAP: 0700 Tainted: G X (5.3.18-47-default) [1359.519317] MSR: 800000000282b033 CR: 48008222 XER: 00000007 [1359.519356] CFAR: c00000000013e170 IRQMASK: 0 [1359.519356] GPR00: c008000000e36fe4 c00000056890b990 c008000000e83200 0000000000000026 [1359.519356] GPR04: 0000000000000000 0000000000000000 0000d52a3b027651 0000000000000007 [1359.519356] GPR08: 0000000000000003 0000000000000001 0000000000000007 0000000000000000 [1359.519356] GPR12: 0000000000008000 c00000063fe44600 000000001015e028 000000001015dfd0 [1359.519356] GPR16: 000000000000404f 0000000000000001 0000000000010000 0000dd1e287affff [1359.519356] GPR20: 0000000000000001 c000000637c9a000 ffffffffffffffe5 0000000000000000 [1359.519356] GPR24: 0000000000000004 0000000000000000 0000000000000100 ffffffffffffffc0 [1359.519356] GPR28: c000000637c9a000 c000000630e09230 c000000630e091d8 c000000562188b08 [1359.519561] NIP [c008000000e36fe8] btrfs_create_pending_block_groups+0x340/0x3c0 [btrfs] [1359.519613] LR [c008000000e36fe4] btrfs_create_pending_block_groups+0x33c/0x3c0 [btrfs] [1359.519626] Call Trace: [1359.519671] [c00000056890b990] [c008000000e36fe4] btrfs_create_pending_block_groups+0x33c/0x3c0 [btrfs] (unreliable) [1359.519729] [c00000056890ba90] [c008000000d68d44] __btrfs_end_transaction+0xbc/0x2f0 [btrfs] [1359.519782] [c00000056890bae0] [c008000000e309ac] btrfs_alloc_data_chunk_ondemand+0x154/0x610 [btrfs] [1359.519844] [c00000056890bba0] [c008000000d8a0fc] btrfs_fallocate+0xe4/0x10e0 [btrfs] [1359.519891] [c00000056890bd00] [c0000000004a23b4] vfs_fallocate+0x174/0x350 [1359.519929] [c00000056890bd50] [c0000000004a3cf8] ksys_fallocate+0x68/0xf0 [1359.519957] [c00000056890bda0] [c0000000004a3da8] sys_fallocate+0x28/0x40 [1359.519988] [c00000056890bdc0] [c000000000038968] system_call_exception+0xe8/0x170 [1359.520021] [c00000056890be20] [c00000000000cb70] system_call_common+0xf0/0x278 [1359.520037] Instruction dump: [1359.520049] 7d0049ad 40c2fff4 7c0004ac 71490004 40820024 2f83fffb 419e0048 3c620000 [1359.520082] e863bcb8 7ec4b378 48010d91 e8410018 <0fe00000> 3c820000 e884bcc8 7ec6b378 [1359.520122] ---[ end trace d6c186e151022e20 ]--- The following steps explain how we can end up in this situation: 1) Task A is at check_system_chunk(), either because it is allocating a new data or metadata block group, at btrfs_chunk_alloc(), or because it is removing a block group or turning a block group RO. It does not matter why; 2) Task A sees that there is not enough free space in the system space_info object, that is 'left' is < 'thresh'. And at this point the system space_info has a value of 0 for its 'bytes_may_use' counter; 3) As a consequence task A calls btrfs_alloc_chunk() in order to allocate a new system block group (chunk) and then reserves 'thresh' bytes in the chunk block reserve with the call to btrfs_block_rsv_add(). This changes the chunk block reserve's 'reserved' and 'size' counters by an amount of 'thresh', and changes the 'bytes_may_use' counter of the system space_info object from 0 to 'thresh'. Also during its call to btrfs_alloc_chunk(), we end up increasing the value of the 'total_bytes' counter of the system space_info object by 8MiB (the size of a system chunk stripe). This happens through the call chain: btrfs_alloc_chunk() create_chunk() btrfs_make_block_group() btrfs_update_space_info() 4) After it finishes the first phase of the block group allocation, at btrfs_chunk_alloc(), task A unlocks the chunk mutex; 5) At this point the new system block group was added to the transaction handle's list of new block groups, but its block group item, device items and chunk item were not yet inserted in the extent, device and chunk trees, respectively. That only happens later when we call btrfs_finish_chunk_alloc() through a call to btrfs_create_pending_block_groups(); Note that only when we update the chunk tree, through the call to btrfs_finish_chunk_alloc(), we decrement the 'reserved' counter of the chunk block reserve as we COW/allocate extent buffers, through: btrfs_alloc_tree_block() btrfs_use_block_rsv() btrfs_block_rsv_use_bytes() And the system space_info's 'bytes_may_use' is decremented everytime we allocate an extent buffer for COW operations on the chunk tree, through: btrfs_alloc_tree_block() btrfs_reserve_extent() find_free_extent() btrfs_add_reserved_bytes() If we end up COWing less chunk btree nodes/leaves than expected, which is the typical case since the amount of space we reserve is always pessimistic to account for the worst possible case, we release the unused space through: btrfs_create_pending_block_groups() btrfs_trans_release_chunk_metadata() btrfs_block_rsv_release() block_rsv_release_bytes() btrfs_space_info_free_bytes_may_use() But before task A gets into btrfs_create_pending_block_groups()... 6) Many other tasks start allocating new block groups through fallocate, each one does the first phase of block group allocation in a serialized way, since btrfs_chunk_alloc() takes the chunk mutex before calling check_system_chunk() and btrfs_alloc_chunk(). However before everyone enters the final phase of the block group allocation, that is, before calling btrfs_create_pending_block_groups(), new tasks keep coming to allocate new block groups and while at check_system_chunk(), the system space_info's 'bytes_may_use' keeps increasing each time a task reserves space in the chunk block reserve. This means that eventually some other task can end up not seeing enough free space in the system space_info and decide to allocate yet another system chunk. This may repeat several times if yet more new tasks keep allocating new block groups before task A, and all the other tasks, finish the creation of the pending block groups, which is when reserved space in excess is released. Eventually this can result in exhaustion of system chunk array in the superblock, with btrfs_add_system_chunk() returning EFBIG, resulting later in a transaction abort. Even when we don't reach the extreme case of exhausting the system array, most, if not all, unnecessarily created system block groups end up being unused since when finishing creation of the first pending system block group, the creation of the following ones end up not needing to COW nodes/leaves of the chunk tree, so we never allocate and deallocate from them, resulting in them never being added to the list of unused block groups - as a consequence they don't get deleted by the cleaner kthread - the only exceptions are if we unmount and mount the filesystem again, which adds any unused block groups to the list of unused block groups, if a scrub is run, which also adds unused block groups to the unused list, and under some circumstances when using a zoned filesystem or async discard, which may also add unused block groups to the unused list. So fix this by: *) Tracking the number of reserved bytes for the chunk tree per transaction, which is the sum of reserved chunk bytes by each transaction handle currently being used; *) When there is not enough free space in the system space_info, if there are other transaction handles which reserved chunk space, wait for some of them to complete in order to have enough excess reserved space released, and then try again. Otherwise proceed with the creation of a new system chunk. Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 7c124584b3c0b2eb7802482a44d4981210fa7a96 Author: Filipe Manana Date: Tue Feb 23 12:08:48 2021 +0000 btrfs: fix race between marking inode needs to be logged and log syncing [ Upstream commit bc0939fcfab0d7efb2ed12896b1af3d819954a14 ] We have a race between marking that an inode needs to be logged, either at btrfs_set_inode_last_trans() or at btrfs_page_mkwrite(), and between btrfs_sync_log(). The following steps describe how the race happens. 1) We are at transaction N; 2) Inode I was previously fsynced in the current transaction so it has: inode->logged_trans set to N; 3) The inode's root currently has: root->log_transid set to 1 root->last_log_commit set to 0 Which means only one log transaction was committed to far, log transaction 0. When a log tree is created we set ->log_transid and ->last_log_commit of its parent root to 0 (at btrfs_add_log_tree()); 4) One more range of pages is dirtied in inode I; 5) Some task A starts an fsync against some other inode J (same root), and so it joins log transaction 1. Before task A calls btrfs_sync_log()... 6) Task B starts an fsync against inode I, which currently has the full sync flag set, so it starts delalloc and waits for the ordered extent to complete before calling btrfs_inode_in_log() at btrfs_sync_file(); 7) During ordered extent completion we have btrfs_update_inode() called against inode I, which in turn calls btrfs_set_inode_last_trans(), which does the following: spin_lock(&inode->lock); inode->last_trans = trans->transaction->transid; inode->last_sub_trans = inode->root->log_transid; inode->last_log_commit = inode->root->last_log_commit; spin_unlock(&inode->lock); So ->last_trans is set to N and ->last_sub_trans set to 1. But before setting ->last_log_commit... 8) Task A is at btrfs_sync_log(): - it increments root->log_transid to 2 - starts writeback for all log tree extent buffers - waits for the writeback to complete - writes the super blocks - updates root->last_log_commit to 1 It's a lot of slow steps between updating root->log_transid and root->last_log_commit; 9) The task doing the ordered extent completion, currently at btrfs_set_inode_last_trans(), then finally runs: inode->last_log_commit = inode->root->last_log_commit; spin_unlock(&inode->lock); Which results in inode->last_log_commit being set to 1. The ordered extent completes; 10) Task B is resumed, and it calls btrfs_inode_in_log() which returns true because we have all the following conditions met: inode->logged_trans == N which matches fs_info->generation && inode->last_subtrans (1) <= inode->last_log_commit (1) && inode->last_subtrans (1) <= root->last_log_commit (1) && list inode->extent_tree.modified_extents is empty And as a consequence we return without logging the inode, so the existing logged version of the inode does not point to the extent that was written after the previous fsync. It should be impossible in practice for one task be able to do so much progress in btrfs_sync_log() while another task is at btrfs_set_inode_last_trans() right after it reads root->log_transid and before it reads root->last_log_commit. Even if kernel preemption is enabled we know the task at btrfs_set_inode_last_trans() can not be preempted because it is holding the inode's spinlock. However there is another place where we do the same without holding the spinlock, which is in the memory mapped write path at: vm_fault_t btrfs_page_mkwrite(struct vm_fault *vmf) { (...) BTRFS_I(inode)->last_trans = fs_info->generation; BTRFS_I(inode)->last_sub_trans = BTRFS_I(inode)->root->log_transid; BTRFS_I(inode)->last_log_commit = BTRFS_I(inode)->root->last_log_commit; (...) So with preemption happening after setting ->last_sub_trans and before setting ->last_log_commit, it is less of a stretch to have another task do enough progress at btrfs_sync_log() such that the task doing the memory mapped write ends up with ->last_sub_trans and ->last_log_commit set to the same value. It is still a big stretch to get there, as the task doing btrfs_sync_log() has to start writeback, wait for its completion and write the super blocks. So fix this in two different ways: 1) For btrfs_set_inode_last_trans(), simply set ->last_log_commit to the value of ->last_sub_trans minus 1; 2) For btrfs_page_mkwrite() only set the inode's ->last_sub_trans, just like we do for buffered and direct writes at btrfs_file_write_iter(), which is all we need to make sure multiple writes and fsyncs to an inode in the same transaction never result in an fsync missing that the inode changed and needs to be logged. Turn this into a helper function and use it both at btrfs_page_mkwrite() and at btrfs_file_write_iter() - this also fixes the problem that at btrfs_page_mkwrite() we were setting those fields without the protection of the inode's spinlock. This is an extremely unlikely race to happen in practice. Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 7bc617ca21ed7089adf1045c1c02a5493d6859ad Author: Josef Bacik Date: Wed Feb 10 17:14:34 2021 -0500 btrfs: use btrfs_inode_lock/btrfs_inode_unlock inode lock helpers [ Upstream commit 64708539cd23b31d0f235a2c12a0cf782f95908a ] A few places we intermix btrfs_inode_lock with a inode_unlock, and some places we just use inode_lock/inode_unlock instead of btrfs_inode_lock. None of these places are using this incorrectly, but as we adjust some of these callers it would be nice to keep everything consistent, so convert everybody to use btrfs_inode_lock/btrfs_inode_unlock. Reviewed-by: Filipe Manana Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 4f2fee1e17efc63e5cd60bb40f6134d45eada6f9 Author: David Bauer Date: Fri Apr 16 21:59:56 2021 +0200 spi: sync up initial chipselect state [ Upstream commit d347b4aaa1a042ea528e385d9070b74c77a14321 ] When initially probing the SPI slave device, the call for disabling an SPI device without the SPI_CS_HIGH flag is not applied, as the condition for checking whether or not the state to be applied equals the one currently set evaluates to true. This however might not necessarily be the case, as the chipselect might be active. Add a force flag to spi_set_cs which allows to override this early exit condition. Set it to false everywhere except when called from spi_setup to sync up the initial CS state. Fixes commit d40f0b6f2e21 ("spi: Avoid setting the chip select if we don't need to") Signed-off-by: David Bauer Link: https://lore.kernel.org/r/20210416195956.121811-1-mail@david-bauer.net Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit aa7ce33cb69143eaaea1a4f9631468d050926240 Author: David E. Box Date: Fri Apr 16 20:12:44 2021 -0700 platform/x86: intel_pmc_core: Don't use global pmcdev in quirks [ Upstream commit c9f86d6ca6b5e23d30d16ade4b9fff5b922a610a ] The DMI callbacks, used for quirks, currently access the PMC by getting the address a global pmc_dev struct. Instead, have the callbacks set a global quirk specific variable. In probe, after calling dmi_check_system(), pass pmc_dev to a function that will handle each quirk if its variable condition is met. This allows removing the global pmc_dev later. Signed-off-by: David E. Box Reviewed-by: Hans de Goede Reviewed-by: Rajneesh Bhardwaj Link: https://lore.kernel.org/r/20210417031252.3020837-2-david.e.box@linux.intel.com Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit 58f2c4df081f1f0b443e8373698b4eb357aa23b6 Author: Shixin Liu Date: Thu Apr 8 15:18:39 2021 +0800 crypto: omap-aes - Fix PM reference leak on omap-aes.c [ Upstream commit 1f34cc4a8da34fbb250efb928f9b8c6fe7ee0642 ] pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in reference leak here. Fix it by replacing it with pm_runtime_resume_and_get to keep usage counter balanced. Signed-off-by: Shixin Liu Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 728936b641fcb43b494b63f22b0fbac94229c5f3 Author: Shixin Liu Date: Thu Apr 8 15:18:37 2021 +0800 crypto: sa2ul - Fix PM reference leak in sa_ul_probe() [ Upstream commit 13343badae093977295341d5a050f51ef128821c ] pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in reference leak here. Fix it by replacing it with pm_runtime_resume_and_get to keep usage counter balanced. Signed-off-by: Shixin Liu Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit ef8b29f1e948e5eee9581d7ab96cd0732f06cfc5 Author: Shixin Liu Date: Thu Apr 8 15:18:36 2021 +0800 crypto: stm32/cryp - Fix PM reference leak on stm32-cryp.c [ Upstream commit 747bf30fd944f02f341b5f3bc7d97a13f2ae2fbe ] pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in reference leak here. Fix it by replacing it with pm_runtime_resume_and_get to keep usage counter balanced. Signed-off-by: Shixin Liu Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 994169b0d7bff44320ae808e08456bbb5fa97b05 Author: Shixin Liu Date: Thu Apr 8 15:18:35 2021 +0800 crypto: stm32/hash - Fix PM reference leak on stm32-hash.c [ Upstream commit 1cb3ad701970e68f18a9e5d090baf2b1b703d729 ] pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in reference leak here. Fix it by replacing it with pm_runtime_resume_and_get to keep usage counter balanced. Signed-off-by: Shixin Liu Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 3de2b604df544151249f8cb0d439f7a555f04e8f Author: Shixin Liu Date: Thu Apr 8 15:18:33 2021 +0800 crypto: sun8i-ce - Fix PM reference leak in sun8i_ce_probe() [ Upstream commit cc987ae9150c255352660d235ab27c834aa527be ] pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in reference leak here. Fix it by replacing it with pm_runtime_resume_and_get to keep usage counter balanced. Signed-off-by: Shixin Liu Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 06871eb9a326d6041920a0338512e9746c878afc Author: Shixin Liu Date: Thu Apr 8 15:18:32 2021 +0800 crypto: sun8i-ss - Fix PM reference leak when pm_runtime_get_sync() fails [ Upstream commit 06cd7423cf451d68bfab289278d7890c9ae01a14 ] pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in reference leak here. Fix it by replacing it with pm_runtime_resume_and_get to keep usage counter balanced. Signed-off-by: Shixin Liu Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 077a90e774c15f037bcda73f30e679c779d64e2f Author: Shixin Liu Date: Thu Apr 8 15:18:31 2021 +0800 crypto: sun4i-ss - Fix PM reference leak when pm_runtime_get_sync() fails [ Upstream commit ac98fc5e1c321112dab9ccac9df892c154540f5d ] pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in reference leak here. Fix it by replacing it with pm_runtime_resume_and_get to keep usage counter balanced. Signed-off-by: Shixin Liu Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit fae3d0a14dfe6030685d2069614ef4084678176c Author: Yang Yingliang Date: Wed Apr 7 17:27:16 2021 +0800 phy: phy-twl4030-usb: Fix possible use-after-free in twl4030_usb_remove() [ Upstream commit e1723d8b87b73ab363256e7ca3af3ddb75855680 ] This driver's remove path calls cancel_delayed_work(). However, that function does not wait until the work function finishes. This means that the callback function may still be running after the driver's remove function has finished, which would result in a use-after-free. Fix by calling cancel_delayed_work_sync(), which ensures that the work is properly cancelled, no longer running, and unable to re-schedule itself. Reported-by: Hulk Robot Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20210407092716.3270248-1-yangyingliang@huawei.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 99ef43fde005d752c46ae826b9ad9ef3accdc6cf Author: Pavel Machek Date: Wed Apr 14 20:12:49 2021 +0300 intel_th: Consistency and off-by-one fix [ Upstream commit 18ffbc47d45a1489b664dd68fb3a7610a6e1dea3 ] Consistently use "< ... +1" in for loops. Fix of-by-one in for_each_set_bit(). Signed-off-by: Pavel Machek Signed-off-by: Alexander Shishkin Link: https://lore.kernel.org/lkml/20190724095841.GA6952@amd/ Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210414171251.14672-6-alexander.shishkin@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 8293c3d6032083a5ef12b0686688b7901dd95b9b Author: Hillf Danton Date: Mon Apr 12 11:57:58 2021 +0800 tty: n_gsm: check error while registering tty devices [ Upstream commit 0a360e8b65d62fe1a994f0a8da4f8d20877b2100 ] Add the error path for registering tty devices and roll back in case of error in bid to avoid the UAF like the below one reported. Plus syzbot reported general protection fault in cdev_del() on Sep 24, 2020 and both cases are down to the kobject_put() in tty_cdev_add(). ------------[ cut here ]------------ refcount_t: underflow; use-after-free. WARNING: CPU: 1 PID: 8923 at lib/refcount.c:28 refcount_warn_saturate+0x1cf/0x210 -origin/lib/refcount.c:28 Modules linked in: CPU: 1 PID: 8923 Comm: executor Not tainted 5.12.0-rc5+ #8 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:refcount_warn_saturate+0x1cf/0x210 -origin/lib/refcount.c:28 Code: 4f ff ff ff e8 32 fa b5 fe 48 c7 c7 3d f8 f6 86 e8 d6 ab c6 fe c6 05 7c 34 67 04 01 48 c7 c7 68 f8 6d 86 31 c0 e8 81 2e 9d fe <0f> 0b e9 22 ff ff ff e8 05 fa b5 fe 48 c7 c7 3e f8 f6 86 e8 a9 ab RSP: 0018:ffffc90001633c60 EFLAGS: 00010246 RAX: 15d08b2e34b77800 RBX: 0000000000000003 RCX: ffff88804c056c80 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000003 R08: ffffffff813767aa R09: 0001ffffffffffff R10: 0001ffffffffffff R11: ffff88804c056c80 R12: ffff888040b7d000 R13: ffff88804c206938 R14: ffff88804c206900 R15: ffff888041b18488 FS: 00000000022c9940(0000) GS:ffff88807ec00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f9f9b122008 CR3: 0000000044b4b000 CR4: 0000000000750ee0 PKRU: 55555554 Call Trace: __refcount_sub_and_test -origin/./include/linux/refcount.h:283 [inline] __refcount_dec_and_test -origin/./include/linux/refcount.h:315 [inline] refcount_dec_and_test -origin/./include/linux/refcount.h:333 [inline] kref_put -origin/./include/linux/kref.h:64 [inline] kobject_put+0x17b/0x180 -origin/lib/kobject.c:753 cdev_del+0x4b/0x50 -origin/fs/char_dev.c:597 tty_unregister_device+0x99/0xd0 -origin/drivers/tty/tty_io.c:3343 gsmld_detach_gsm -origin/drivers/tty/n_gsm.c:2409 [inline] gsmld_close+0x6c/0x140 -origin/drivers/tty/n_gsm.c:2478 tty_ldisc_close -origin/drivers/tty/tty_ldisc.c:488 [inline] tty_ldisc_kill -origin/drivers/tty/tty_ldisc.c:636 [inline] tty_ldisc_release+0x1b6/0x400 -origin/drivers/tty/tty_ldisc.c:809 tty_release_struct+0x19/0xb0 -origin/drivers/tty/tty_io.c:1714 tty_release+0x9ad/0xa00 -origin/drivers/tty/tty_io.c:1885 __fput+0x260/0x4e0 -origin/fs/file_table.c:280 ____fput+0x11/0x20 -origin/fs/file_table.c:313 task_work_run+0x8e/0x110 -origin/kernel/task_work.c:140 tracehook_notify_resume -origin/./include/linux/tracehook.h:189 [inline] exit_to_user_mode_loop -origin/kernel/entry/common.c:174 [inline] exit_to_user_mode_prepare+0x16b/0x1a0 -origin/kernel/entry/common.c:208 __syscall_exit_to_user_mode_work -origin/kernel/entry/common.c:290 [inline] syscall_exit_to_user_mode+0x20/0x40 -origin/kernel/entry/common.c:301 do_syscall_64+0x45/0x80 -origin/arch/x86/entry/common.c:56 entry_SYSCALL_64_after_hwframe+0x44/0xae Reported-by: syzbot+c49fe6089f295a05e6f8@syzkaller.appspotmail.com Reported-and-tested-by: Hao Sun Signed-off-by: Hillf Danton Link: https://lore.kernel.org/r/20210412035758.1974-1-hdanton@sina.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ad9f7e48c5e06fb18d1cbccabed0c5ae078a2713 Author: Thinh Nguyen Date: Tue Apr 13 19:13:18 2021 -0700 usb: dwc3: gadget: Check for disabled LPM quirk [ Upstream commit 475e8be53d0496f9bc6159f4abb3ff5f9b90e8de ] If the device doesn't support LPM, make sure to disable the LPM capability and don't advertise to the host that it supports it. Acked-by: Felipe Balbi Signed-off-by: Thinh Nguyen Link: https://lore.kernel.org/r/9e68527ff932b1646f92a7593d4092a903754666.1618366071.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 26f4ea0e0ca4ff532d256fc5f09bb2f4c5e87a5c Author: Bixuan Cui Date: Thu Apr 8 21:08:31 2021 +0800 usb: core: hub: Fix PM reference leak in usb_port_resume() [ Upstream commit 025f97d188006eeee4417bb475a6878d1e0eed3f ] pm_runtime_get_sync will increment pm usage counter even it failed. thus a pairing decrement is needed. Fix it by replacing it with pm_runtime_resume_and_get to keep usage counter balanced. Reported-by: Hulk Robot Signed-off-by: Bixuan Cui Link: https://lore.kernel.org/r/20210408130831.56239-1-cuibixuan@huawei.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e63746548f840638b692ae00265fb5e605dc6508 Author: Bixuan Cui Date: Thu Apr 8 17:18:36 2021 +0800 usb: musb: fix PM reference leak in musb_irq_work() [ Upstream commit 9535b99533904e9bc1607575aa8e9539a55435d7 ] pm_runtime_get_sync will increment pm usage counter even it failed. thus a pairing decrement is needed. Fix it by replacing it with pm_runtime_resume_and_get to keep usage counter balanced. Reported-by: Hulk Robot Signed-off-by: Bixuan Cui Link: https://lore.kernel.org/r/20210408091836.55227-1-cuibixuan@huawei.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 02798f0cb9b342bdabc4965f2ce3d6a6de6afec5 Author: Yang Yingliang Date: Wed Apr 7 17:29:47 2021 +0800 usb: gadget: tegra-xudc: Fix possible use-after-free in tegra_xudc_remove() [ Upstream commit a932ee40c276767cd55fadec9e38829bf441db41 ] This driver's remove path calls cancel_delayed_work(). However, that function does not wait until the work function finishes. This means that the callback function may still be running after the driver's remove function has finished, which would result in a use-after-free. Fix by calling cancel_delayed_work_sync(), which ensures that the work is properly cancelled, no longer running, and unable to re-schedule itself. Reported-by: Hulk Robot Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20210407092947.3271507-1-yangyingliang@huawei.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 1b0f64df77d0a1016e3bdf5a1d43993ea63856fc Author: Heikki Krogerus Date: Thu Apr 8 11:31:44 2021 +0300 usb: dwc3: pci: add support for the Intel Alder Lake-M [ Upstream commit 782de5e7190de0a773417708e17d9461d9109bf9 ] This patch adds the necessary PCI ID for Intel Alder Lake-M devices. Signed-off-by: Heikki Krogerus Link: https://lore.kernel.org/r/20210408083144.69350-1-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 32565a0616f984a85ccb4ed5067e6415d3dd1109 Author: Wang Li Date: Fri Apr 9 09:54:58 2021 +0000 spi: qup: fix PM reference leak in spi_qup_remove() [ Upstream commit cec77e0a249892ceb10061bf17b63f9fb111d870 ] pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in reference leak here. Fix it by replacing it with pm_runtime_resume_and_get to keep usage counter balanced. Reported-by: Hulk Robot Signed-off-by: Wang Li Reviewed-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20210409095458.29921-1-wangli74@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 18fe30ff2692a290afa7de010ed40c5061a92b0e Author: Wei Yongjun Date: Fri Apr 9 08:29:54 2021 +0000 spi: omap-100k: Fix reference leak to master [ Upstream commit a23faea76d4cf5f75decb574491e66f9ecd707e7 ] Call spi_master_get() holds the reference count to master device, thus we need an additional spi_master_put() call to reduce the reference count, otherwise we will leak a reference to master. This commit fix it by removing the unnecessary spi_master_get(). Reported-by: Hulk Robot Signed-off-by: Wei Yongjun Link: https://lore.kernel.org/r/20210409082954.2906933-1-weiyongjun1@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a505edce0bdd485e8469b454eb19dddc1faf7d6e Author: Wei Yongjun Date: Fri Apr 9 08:29:55 2021 +0000 spi: dln2: Fix reference leak to master [ Upstream commit 9b844b087124c1538d05f40fda8a4fec75af55be ] Call spi_master_get() holds the reference count to master device, thus we need an additional spi_master_put() call to reduce the reference count, otherwise we will leak a reference to master. This commit fix it by removing the unnecessary spi_master_get(). Reported-by: Hulk Robot Signed-off-by: Wei Yongjun Link: https://lore.kernel.org/r/20210409082955.2907950-1-weiyongjun1@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 840872c2aed21e82579292c09ccef8f5e34b0eba Author: Angela Czubak Date: Thu Apr 8 12:37:59 2021 +0200 resource: Prevent irqresource_disabled() from erasing flags [ Upstream commit d08a745729646f407277e904b02991458f20d261 ] Some Chromebooks use hard-coded interrupts in their ACPI tables. This is an excerpt as dumped on Relm: ... Name (_HID, "ELAN0001") // _HID: Hardware ID Name (_DDN, "Elan Touchscreen ") // _DDN: DOS Device Name Name (_UID, 0x05) // _UID: Unique ID Name (ISTP, Zero) Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings { Name (BUF0, ResourceTemplate () { I2cSerialBusV2 (0x0010, ControllerInitiated, 0x00061A80, AddressingMode7Bit, "\\_SB.I2C1", 0x00, ResourceConsumer, , Exclusive, ) Interrupt (ResourceConsumer, Edge, ActiveLow, Exclusive, ,, ) { 0x000000B8, } }) Return (BUF0) /* \_SB_.I2C1.ETSA._CRS.BUF0 */ } ... This interrupt is hard-coded to 0xB8 = 184 which is too high to be mapped to IO-APIC, so no triggering information is propagated as acpi_register_gsi() fails and irqresource_disabled() is issued, which leads to erasing triggering and polarity information. Do not overwrite flags as it leads to erasing triggering and polarity information which might be useful in case of hard-coded interrupts. This way the information can be read later on even though mapping to APIC domain failed. Signed-off-by: Angela Czubak [ rjw: Changelog rearrangement ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit f938233fe9a668268182aad387ddb39cbcfa4940 Author: Dinh Nguyen Date: Mon Mar 22 07:18:44 2021 -0500 clocksource/drivers/dw_apb_timer_of: Add handling for potential memory leak [ Upstream commit 397dc6f7ca3c858dc95800f299357311ccf679e6 ] Add calls to disable the clock and unmap the timer base address in case of any failures. Reported-by: kernel test robot Reported-by: Dan Carpenter Signed-off-by: Dinh Nguyen Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20210322121844.2271041-1-dinguyen@kernel.org Signed-off-by: Sasha Levin commit 43f27251c576fcb84118528e404ee8271d09c539 Author: Srinivas Pandruvada Date: Tue Mar 30 15:08:40 2021 -0700 platform/x86: ISST: Account for increased timeout in some cases [ Upstream commit 5c782817a981981917ec3c647cf521022ee07143 ] In some cases when firmware is busy or updating, some mailbox commands still timeout on some newer CPUs. To fix this issue, change how we process timeout. With this change, replaced timeout from using simple count with real timeout in micro-seconds using ktime. When the command response takes more than average processing time, yield to other tasks. The worst case timeout is extended upto 1 milli-second. Signed-off-by: Srinivas Pandruvada Link: https://lore.kernel.org/r/20210330220840.3113959-1-srinivas.pandruvada@linux.intel.com Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit 5226917d0f470e9f0714a878bb7fa8a2d2c0f9ce Author: Srinivas Pandruvada Date: Thu Mar 4 17:31:49 2021 -0800 tools/power/x86/intel-speed-select: Increase string size [ Upstream commit 2e70b710f36c80b6e78cf32a5c30b46dbb72213c ] The current string size to print cpulist can accommodate upto 80 logical CPUs per package. But this limit is not enough. So increase the string size. Also prevent buffer overflow, if the string size reaches limit. Signed-off-by: Srinivas Pandruvada Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit b605b652887e76beddf4307cf9dd7bdcacd1eba4 Author: Ludovic Desroches Date: Fri Apr 2 15:02:27 2021 +0200 ARM: dts: at91: change the key code of the gpio key [ Upstream commit ca7a049ad1a72ec5f03d1330b53575237fcb727c ] Having a button code and not a key code causes issues with libinput. udev won't set ID_INPUT_KEY. If it is forced, then it causes a bug within libinput. Signed-off-by: Ludovic Desroches Signed-off-by: Nicolas Ferre Link: https://lore.kernel.org/r/20210402130227.21478-1-nicolas.ferre@microchip.com Signed-off-by: Sasha Levin commit cf641232176d457db08a63338a20ac1a27cb8133 Author: Loic Poulain Date: Fri Mar 19 16:50:37 2021 +0100 bus: mhi: pci_generic: Implement PCI shutdown callback [ Upstream commit 757072abe1c0b67cb226936c709291889658a222 ] Deinit the device on shutdown to halt MHI/PCI operation on device side. This change fixes floating device state with some hosts that do not fully shutdown PCIe device when rebooting. Signed-off-by: Loic Poulain Reviewed-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/1616169037-7969-1-git-send-email-loic.poulain@linaro.org Signed-off-by: Manivannan Sadhasivam Signed-off-by: Sasha Levin commit 29792079690913fdc28ec68271cd82ac5c5a0b62 Author: Bhaumik Bhatt Date: Thu Apr 1 14:16:11 2021 -0700 bus: mhi: core: Clear context for stopped channels from remove() [ Upstream commit 4e44ae3d6d9c2c2a6d9356dd279c925532d5cd8c ] If a channel was explicitly stopped but not reset and a driver remove is issued, clean up the channel context such that it is reflected on the device. This move is useful if a client driver module is unloaded or a device crash occurs with the host having placed the channel in a stopped state. Signed-off-by: Bhaumik Bhatt Reviewed-by: Hemant Kumar Reviewed-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/1617311778-1254-3-git-send-email-bbhatt@codeaurora.org Signed-off-by: Manivannan Sadhasivam Signed-off-by: Sasha Levin commit 80380148c46d96f21840df1b02dd9db76a4bacfa Author: Mathias Nyman Date: Tue Apr 6 10:02:08 2021 +0300 xhci: prevent double-fetch of transfer and transfer event TRBs [ Upstream commit e9fcb07704fcef6fa6d0333fd2b3a62442eaf45b ] The same values are parsed several times from transfer and event TRBs by different functions in the same call path, all while processing one transfer event. As the TRBs are in DMA memory and can be accessed by the xHC host we want to avoid this to prevent double-fetch issues. To resolve this pass the already parsed values to the different functions in the path of parsing a transfer event Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20210406070208.3406266-5-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit f47c7ace4acdc335f70e71c26397c278ee46b78b Author: Mathias Nyman Date: Tue Apr 6 10:02:07 2021 +0300 xhci: fix potential array out of bounds with several interrupters [ Upstream commit 286fd02fd54b6acab65809549cf5fb3f2a886696 ] The Max Interrupters supported by the controller is given in a 10bit wide bitfield, but the driver uses a fixed 128 size array to index these interrupters. Klockwork reports a possible array out of bounds case which in theory is possible. In practice this hasn't been hit as a common number of Max Interrupters for new controllers is 8, not even close to 128. This needs to be fixed anyway Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20210406070208.3406266-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit bf6c351709a98dc8bdc19e59015b050d55838caa Author: Mathias Nyman Date: Tue Apr 6 10:02:06 2021 +0300 xhci: check control context is valid before dereferencing it. [ Upstream commit 597899d2f7c5619c87185ee7953d004bd37fd0eb ] Don't dereference ctrl_ctx before checking it's valid. Issue reported by Klockwork Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20210406070208.3406266-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 396481ce3f12ee047308eca49501e5dcc320cc80 Author: Mathias Nyman Date: Tue Apr 6 10:02:05 2021 +0300 xhci: check port array allocation was successful before dereferencing it [ Upstream commit 8a157d2ff104d2849c58226a1fd02365d7d60150 ] return if rhub->ports is null after rhub->ports = kcalloc_node() Klockwork reported issue Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20210406070208.3406266-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 5598b0a7efdee2509dde9bcb8fcc1c050ebf5672 Author: Russ Weight Date: Mon Apr 5 16:52:59 2021 -0700 fpga: dfl: pci: add DID for D5005 PAC cards [ Upstream commit a78a51a851ed3edc83264a67e2ba77a34f27965f ] This patch adds the approved PCI Express Device IDs for the PF and VF for the card for D5005 PAC cards. Signed-off-by: Russ Weight Signed-off-by: Matthew Gerlach Signed-off-by: Moritz Fischer Signed-off-by: Sasha Levin commit 04cd7a2b0ae785dd099b813934e1402db746d627 Author: Chunfeng Yun Date: Wed Mar 31 17:05:53 2021 +0800 usb: xhci-mtk: support quirk to disable usb2 lpm [ Upstream commit bee1f89aad2a51cd3339571bc8eadbb0dc88a683 ] The xHCI driver support usb2 HW LPM by default, here add support XHCI_HW_LPM_DISABLE quirk, then we can disable usb2 lpm when need it. Signed-off-by: Chunfeng Yun Link: https://lore.kernel.org/r/1617181553-3503-4-git-send-email-chunfeng.yun@mediatek.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e132d83b2cffa05d3b9afe333975dbb462dbb72b Author: Eric Biggers Date: Sun Mar 21 22:13:47 2021 -0700 random: initialize ChaCha20 constants with correct endianness [ Upstream commit a181e0fdb2164268274453b5b291589edbb9b22d ] On big endian CPUs, the ChaCha20-based CRNG is using the wrong endianness for the ChaCha20 constants. This doesn't matter cryptographically, but technically it means it's not ChaCha20 anymore. Fix it to always use the standard constants. Cc: linux-crypto@vger.kernel.org Cc: Andy Lutomirski Cc: Jann Horn Cc: Theodore Ts'o Acked-by: Ard Biesheuvel Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 16839bc05c83f5de291728594d6712b5cf58e2e5 Author: Robin Murphy Date: Fri Mar 26 16:02:41 2021 +0000 perf/arm_pmu_platform: Fix error handling [ Upstream commit e338cb6bef254821a8c095018fd27254d74bfd6a ] If we're aborting after failing to register the PMU device, we probably don't want to leak the IRQs that we've claimed. Signed-off-by: Robin Murphy Link: https://lore.kernel.org/r/53031a607fc8412a60024bfb3bb8cd7141f998f5.1616774562.git.robin.murphy@arm.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit bf6a8d1b4e4d55ce44319615423726a317601be0 Author: Robin Murphy Date: Fri Mar 26 16:02:40 2021 +0000 perf/arm_pmu_platform: Use dev_err_probe() for IRQ errors [ Upstream commit 11fa1dc8020a2a9e0c59998920092d4df3fb7308 ] By virtue of using platform_irq_get_optional() under the covers, platform_irq_count() needs the target interrupt controller to be available and may return -EPROBE_DEFER if it isn't. Let's use dev_err_probe() to avoid a spurious error log (and help debug any deferral issues) in that case. Reported-by: Paul Menzel Signed-off-by: Robin Murphy Link: https://lore.kernel.org/r/073d5e0d3ed1f040592cb47ca6fe3759f40cc7d1.1616774562.git.robin.murphy@arm.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 65b2f85e7273a44eb626d356ed70bf1e6a2f91b8 Author: Pierre-Louis Bossart Date: Tue Mar 23 09:37:07 2021 +0800 soundwire: cadence: only prepare attached devices on clock stop [ Upstream commit 58ef9356260c291a4321e07ff507f31a1d8212af ] We sometimes see COMMAND_IGNORED responses during the clock stop sequence. It turns out we already have information if devices are present on a link, so we should only prepare those when they are attached. In addition, even when COMMAND_IGNORED are received, we should still proceed with the clock stop. The device will not be prepared but that's not a problem. The only case where the clock stop will fail is if the Cadence IP reports an error (including a timeout), or if the devices throw a COMMAND_FAILED response. BugLink: https://github.com/thesofproject/linux/issues/2621 Signed-off-by: Pierre-Louis Bossart Reviewed-by: Rander Wang Reviewed-by: Guennadi Liakhovetski Signed-off-by: Bard Liao Link: https://lore.kernel.org/r/20210323013707.21455-1-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 464461886367226f1f0c915db9e5a01bb8942289 Author: Jerome Forissier Date: Mon Mar 22 11:40:37 2021 +0100 tee: optee: do not check memref size on return from Secure World [ Upstream commit c650b8dc7a7910eb25af0aac1720f778b29e679d ] When Secure World returns, it may have changed the size attribute of the memory references passed as [in/out] parameters. The GlobalPlatform TEE Internal Core API specification does not restrict the values that this size can take. In particular, Secure World may increase the value to be larger than the size of the input buffer to indicate that it needs more. Therefore, the size check in optee_from_msg_param() is incorrect and needs to be removed. This fixes a number of failed test cases in the GlobalPlatform TEE Initial Configuratiom Test Suite v2_0_0_0-2017_06_09 when OP-TEE is compiled without dynamic shared memory support (CFG_CORE_DYN_SHM=n). Reviewed-by: Sumit Garg Suggested-by: Jens Wiklander Signed-off-by: Jerome Forissier Signed-off-by: Jens Wiklander Signed-off-by: Sasha Levin commit ad42a659f35192c5ad58c2af9ae2634ba8b8e4c7 Author: Sebastian Krzyszkowiak Date: Mon Mar 15 09:35:30 2021 +0100 arm64: dts: imx8mq-librem5-r3: Mark buck3 as always on [ Upstream commit a362b0cc94d476b097ba0ff466958c1d4e27e219 ] Commit 99e71c029213 ("arm64: dts: imx8mq-librem5: Don't mark buck3 as always on") removed always-on marking from GPU regulator, which is great for power saving - however it introduces additional i2c0 traffic which can be deadly for devices from the Dogwood batch. To workaround the i2c0 shutdown issue on Dogwood, this commit marks buck3 as always-on again - but only for Dogwood (r3). Signed-off-by: Sebastian Krzyszkowiak Signed-off-by: Martin Kepplinger Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 2ed7e900e70bee8e80fbbe0acabe5bdbe72e81d6 Author: Dmitry Osipenko Date: Tue Mar 2 15:24:59 2021 +0300 soc/tegra: pmc: Fix completion of power-gate toggling [ Upstream commit c45e66a6b9f40f2e95bc6d97fbf3daa1ebe88c6b ] The SW-initiated power gate toggling is dropped by PMC if there is contention with a HW-initiated toggling, i.e. when one of CPU cores is gated by cpuidle driver. Software should retry the toggling after 10 microseconds on Tegra20/30 SoCs, hence add the retrying. On Tegra114+ the toggling method was changed in hardware, the TOGGLE_START bit indicates whether PMC is busy or could accept the command to toggle, hence handle that bit properly. The problem pops up after enabling dynamic power gating of 3D hardware, where 3D power domain fails to turn on/off "randomly". The programming sequence and quirks are documented in TRMs, but PMC driver obliviously re-used the Tegra20 logic for Tegra30+, which strikes back now. The 10 microseconds and other timeouts aren't documented in TRM, they are taken from downstream kernel. Link: https://nv-tegra.nvidia.com/gitweb/?p=linux-2.6.git;a=commit;h=311dd1c318b70e93bcefec15456a10ff2b9eb0ff Link: https://nv-tegra.nvidia.com/gitweb/?p=linux-3.10.git;a=commit;h=7f36693c47cb23730a6b2822e0975be65fb0c51d Tested-by: Peter Geis # Ouya T30 Tested-by: Nicolas Chauvet # PAZ00 T20 and TK1 T124 Tested-by: Matt Merhar # Ouya T30 Signed-off-by: Dmitry Osipenko Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 85e8bde13e9915fe0efb90c3c44a2cbb3495ec33 Author: Nathan Chancellor Date: Thu Mar 25 17:04:35 2021 -0700 efi/libstub: Add $(CLANG_FLAGS) to x86 flags [ Upstream commit 58d746c119dfa28e72fc35aacaf3d2a3ac625cd0 ] When cross compiling x86 on an ARM machine with clang, there are several errors along the lines of: arch/x86/include/asm/page_64.h:52:7: error: invalid output constraint '=D' in asm This happens because the x86 flags in the EFI stub are not derived from KBUILD_CFLAGS like the other architectures are and the clang flags that set the target architecture ('--target=') and the path to the GNU cross tools ('--prefix=') are not present, meaning that the host architecture is targeted. These flags are available as $(CLANG_FLAGS) from the main Makefile so add them to the cflags for x86 so that cross compiling works as expected. Signed-off-by: Nathan Chancellor Signed-off-by: Borislav Petkov Acked-by: Ard Biesheuvel Link: https://lkml.kernel.org/r/20210326000435.4785-4-nathan@kernel.org Signed-off-by: Sasha Levin commit 50e9a45834f929110b10feb74ba74e798be4e442 Author: Nathan Chancellor Date: Thu Mar 25 17:04:34 2021 -0700 x86/boot: Add $(CLANG_FLAGS) to compressed KBUILD_CFLAGS [ Upstream commit d5cbd80e302dfea59726c44c56ab7957f822409f ] When cross compiling x86 on an ARM machine with clang, there are several errors along the lines of: arch/x86/include/asm/string_64.h:27:10: error: invalid output constraint '=&c' in asm This happens because the compressed boot Makefile reassigns KBUILD_CFLAGS and drops the clang flags that set the target architecture ('--target=') and the path to the GNU cross tools ('--prefix='), meaning that the host architecture is targeted. These flags are available as $(CLANG_FLAGS) from the main Makefile so add them to the compressed boot folder's KBUILD_CFLAGS so that cross compiling works as expected. Signed-off-by: Nathan Chancellor Signed-off-by: Borislav Petkov Acked-by: Ard Biesheuvel Link: https://lkml.kernel.org/r/20210326000435.4785-3-nathan@kernel.org Signed-off-by: Sasha Levin commit 9150f7843b5d0acd415b89f59b6d2dc6b8c68867 Author: John Millikin Date: Thu Mar 25 17:04:33 2021 -0700 x86/build: Propagate $(CLANG_FLAGS) to $(REALMODE_FLAGS) [ Upstream commit 8abe7fc26ad8f28bfdf78adbed56acd1fa93f82d ] When cross-compiling with Clang, the `$(CLANG_FLAGS)' variable contains additional flags needed to build C and assembly sources for the target platform. Normally this variable is automatically included in `$(KBUILD_CFLAGS)' via the top-level Makefile. The x86 real-mode makefile builds `$(REALMODE_CFLAGS)' from a plain assignment and therefore drops the Clang flags. This causes Clang to not recognize x86-specific assembler directives:   arch/x86/realmode/rm/header.S:36:1: error: unknown directive   .type real_mode_header STT_OBJECT ; .size real_mode_header, .-real_mode_header   ^ Explicit propagation of `$(CLANG_FLAGS)' to `$(REALMODE_CFLAGS)', which is inherited by real-mode make rules, fixes cross-compilation with Clang for x86 targets. Relevant flags: * `--target' sets the target architecture when cross-compiling. This   flag must be set for both compilation and assembly (`KBUILD_AFLAGS')   to support architecture-specific assembler directives. * `-no-integrated-as' tells clang to assemble with GNU Assembler   instead of its built-in LLVM assembler. This flag is set by default   unless `LLVM_IAS=1' is set, because the LLVM assembler can't yet   parse certain GNU extensions. Signed-off-by: John Millikin Signed-off-by: Nathan Chancellor Signed-off-by: Borislav Petkov Acked-by: Ard Biesheuvel Tested-by: Sedat Dilek Link: https://lkml.kernel.org/r/20210326000435.4785-2-nathan@kernel.org Signed-off-by: Sasha Levin commit ae4a4ca270c506ff22453833869a18c7004bc394 Author: Linus Walleij Date: Fri Mar 26 10:19:11 2021 +0100 ARM: dts: ux500: Fix up TVK R3 sensors [ Upstream commit aeceecd40d94ed3c00bfe1cfe59dd1bfac2fc6fe ] The TVK1281618 R3 sensors are different from the R2 board, some incorrectness is fixed and some new sensors added, we also rename the nodes appropriately with accelerometer@ etc. Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit a2ecc3aa10671658542dc7d58cbcd21aca646561 Author: Rafał Miłecki Date: Tue Mar 9 13:55:00 2021 +0100 ARM: dts: BCM5301X: fix "reg" formatting in /memory node [ Upstream commit 43986f38818278bb71a7fef6de689637bb734afe ] This fixes warnings/errors like: arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dt.yaml: /: memory@0:reg:0: [0, 134217728, 2281701376, 402653184] is too long From schema: /lib/python3.6/site-packages/dtschema/schemas/reg.yaml Signed-off-by: Rafał Miłecki Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin commit 52a7c20bfb4b3319db540a62d89a9ef77e38fa22 Author: Andre Przywara Date: Fri Mar 19 16:53:29 2021 +0000 kselftest/arm64: mte: Fix MTE feature detection [ Upstream commit 592432862cc4019075a7196d9961562c49507d6f ] To check whether the CPU and kernel support the MTE features we want to test, we use an (emulated) CPU ID register read. However we only check against a very particular feature version (0b0010), even though the ARM ARM promises ID register features to be backwards compatible. While this could be fixed by using ">=" instead of "==", we should actually use the explicit HWCAP2_MTE hardware capability, exposed by the kernel via the ELF auxiliary vectors. That moves this responsibility to the kernel, and fixes running the tests on machines with FEAT_MTE3 capability. Signed-off-by: Andre Przywara Reviewed-by: Mark Brown Link: https://lore.kernel.org/r/20210319165334.29213-7-andre.przywara@arm.com Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 236da04d3bc4ff80e75a43dc93ba7de42a0fd325 Author: Rafael J. Wysocki Date: Tue Mar 16 16:51:40 2021 +0100 PCI: PM: Do not read power state in pci_enable_device_flags() [ Upstream commit 4514d991d99211f225d83b7e640285f29f0755d0 ] It should not be necessary to update the current_state field of struct pci_dev in pci_enable_device_flags() before calling do_pci_enable_device() for the device, because none of the code between that point and the pci_set_power_state() call in do_pci_enable_device() invoked later depends on it. Moreover, doing that is actively harmful in some cases. For example, if the given PCI device depends on an ACPI power resource whose _STA method initially returns 0 ("off"), but the config space of the PCI device is accessible and the power state retrieved from the PCI_PM_CTRL register is D0, the current_state field in the struct pci_dev representing that device will get out of sync with the power.state of its ACPI companion object and that will lead to power management issues going forward. To avoid such issues it is better to leave the current_state value as is until it is changed to PCI_D0 by do_pci_enable_device() as appropriate. However, the power state of the device is not changed to PCI_D0 if it is already enabled when pci_enable_device_flags() gets called for it, so update its current_state in that case, but use pci_update_current_state() covering platform PM too for that. Link: https://lore.kernel.org/lkml/20210314000439.3138941-1-luzmaximilian@gmail.com/ Reported-by: Maximilian Luz Tested-by: Maximilian Luz Signed-off-by: Rafael J. Wysocki Reviewed-by: Mika Westerberg Signed-off-by: Sasha Levin commit 2c22c855b2ab3a086443744767d8ce9707d2345e Author: Dmitry Osipenko Date: Tue Mar 2 15:09:58 2021 +0300 ARM: tegra: acer-a500: Rename avdd to vdda of touchscreen node [ Upstream commit b27b9689e1f3278919c6183c565d837d0aef6fc1 ] Rename avdd supply to vdda of the touchscreen node. The old supply name was incorrect. Signed-off-by: Dmitry Osipenko Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit e83a6878a1687209385a9e4ac82f96bf53dece8d Author: Andre Przywara Date: Fri Mar 19 16:53:24 2021 +0000 kselftest/arm64: mte: Fix compilation with native compiler [ Upstream commit 4a423645bc2690376a7a94b4bb7b2f74bc6206ff ] The mte selftest Makefile contains a check for GCC, to add the memtag -march flag to the compiler options. This check fails if the compiler is not explicitly specified, so reverts to the standard "cc", in which case --version doesn't mention the "gcc" string we match against: $ cc --version | head -n 1 cc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0 This will not add the -march switch to the command line, so compilation fails: mte_helper.S: Assembler messages: mte_helper.S:25: Error: selected processor does not support `irg x0,x0,xzr' mte_helper.S:38: Error: selected processor does not support `gmi x1,x0,xzr' ... Actually clang accepts the same -march option as well, so we can just drop this check and add this unconditionally to the command line, to avoid any future issues with this check altogether (gcc actually prints basename(argv[0]) when called with --version). Signed-off-by: Andre Przywara Reviewed-by: Nick Desaulniers Reviewed-by: Mark Brown Link: https://lore.kernel.org/r/20210319165334.29213-2-andre.przywara@arm.com Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 8815109c15efcb190270b891ed575b366e72cca9 Author: Thinh Nguyen Date: Wed Mar 10 19:43:21 2021 -0800 usb: xhci: Fix port minor revision [ Upstream commit 64364bc912c01b33bba6c22e3ccb849bfca96398 ] Some hosts incorrectly use sub-minor version for minor version (i.e. 0x02 instead of 0x20 for bcdUSB 0x320 and 0x01 for bcdUSB 0x310). Currently the xHCI driver works around this by just checking for minor revision > 0x01 for USB 3.1 everywhere. With the addition of USB 3.2, checking this gets a bit cumbersome. Since there is no USB release with bcdUSB 0x301 to 0x309, we can assume that sub-minor version 01 to 09 is incorrect. Let's try to fix this and use the minor revision that matches with the USB/xHCI spec to help with the version checking within the driver. Acked-by: Mathias Nyman Signed-off-by: Thinh Nguyen Link: https://lore.kernel.org/r/ed330e95a19dc367819c5b4d78bf7a541c35aa0a.1615432770.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9777200246f92bb86e9d7d7dbbb06cd5c8a26943 Author: Wesley Cheng Date: Fri Mar 19 02:31:25 2021 -0700 usb: dwc3: gadget: Ignore EP queue requests during bus reset [ Upstream commit 71ca43f30df9c642970f9dc9b2d6f463f4967e7b ] The current dwc3_gadget_reset_interrupt() will stop any active transfers, but only addresses blocking of EP queuing for while we are coming from a disconnected scenario, i.e. after receiving the disconnect event. If the host decides to issue a bus reset on the device, the connected parameter will still be set to true, allowing for EP queuing to continue while we are disabling the functions. To avoid this, set the connected flag to false until the stop active transfers is complete. Signed-off-by: Wesley Cheng Link: https://lore.kernel.org/r/1616146285-19149-3-git-send-email-wcheng@codeaurora.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 7f66ca5efe7c14aab6d3325cc776f90a0b8f827e Author: Ruslan Bilovol Date: Mon Mar 1 13:49:34 2021 +0200 usb: gadget: f_uac1: validate input parameters [ Upstream commit a59c68a6a3d1b18e2494f526eb19893a34fa6ec6 ] Currently user can configure UAC1 function with parameters that violate UAC1 spec or are not supported by UAC1 gadget implementation. This can lead to incorrect behavior if such gadget is connected to the host - like enumeration failure or other issues depending on host's UAC1 driver implementation, bringing user to a long hours of debugging the issue. Instead of silently accept these parameters, throw an error if they are not valid. Signed-off-by: Ruslan Bilovol Link: https://lore.kernel.org/r/1614599375-8803-5-git-send-email-ruslan.bilovol@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d15e57bb5bf284b336bae865136165959c116a81 Author: Ruslan Bilovol Date: Mon Mar 1 13:49:33 2021 +0200 usb: gadget: f_uac2: validate input parameters [ Upstream commit 3713d5ceb04d5ab6a5e2b86dfca49170053f3a5e ] Currently user can configure UAC2 function with parameters that violate UAC2 spec or are not supported by UAC2 gadget implementation. This can lead to incorrect behavior if such gadget is connected to the host - like enumeration failure or other issues depending on host's UAC2 driver implementation, bringing user to a long hours of debugging the issue. Instead of silently accept these parameters, throw an error if they are not valid. Signed-off-by: Ruslan Bilovol Link: https://lore.kernel.org/r/1614599375-8803-4-git-send-email-ruslan.bilovol@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 79c4569e2492d170874d993ea71714a007eb4f59 Author: Vitaly Kuznetsov Date: Fri Mar 19 12:18:23 2021 +0100 genirq/matrix: Prevent allocation counter corruption [ Upstream commit c93a5e20c3c2dabef8ea360a3d3f18c6f68233ab ] When irq_matrix_free() is called for an unallocated vector the managed_allocated and total_allocated counters get out of sync with the real state of the matrix. Later, when the last interrupt is freed, these counters will underflow resulting in UINTMAX because the counters are unsigned. While this is certainly a problem of the calling code, this can be catched in the allocator by checking the allocation bit for the to be freed vector which simplifies debugging. An example of the problem described above: https://lore.kernel.org/lkml/20210318192819.636943062@linutronix.de/ Add the missing sanity check and emit a warning when it triggers. Suggested-by: Thomas Gleixner Signed-off-by: Vitaly Kuznetsov Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/r/20210319111823.1105248-1-vkuznets@redhat.com Signed-off-by: Sasha Levin commit 6cb737a99abed908bc5c54fa14d0f02f74231406 Author: Longfang Liu Date: Sat Mar 13 15:28:23 2021 +0800 crypto: hisilicon/sec - fixes a printing error [ Upstream commit 4b7aef0230418345be1fb77abbb1592801869901 ] When the log is output here, the device has not been initialized yet. Signed-off-by: Longfang Liu Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit e0c552b91c7d2de5951f880dbc28e92cab271d8a Author: Joerg Roedel Date: Fri Mar 12 13:38:18 2021 +0100 x86/sev: Do not require Hypervisor CPUID bit for SEV guests [ Upstream commit eab696d8e8b9c9d600be6fad8dd8dfdfaca6ca7c ] A malicious hypervisor could disable the CPUID intercept for an SEV or SEV-ES guest and trick it into the no-SEV boot path, where it could potentially reveal secrets. This is not an issue for SEV-SNP guests, as the CPUID intercept can't be disabled for those. Remove the Hypervisor CPUID bit check from the SEV detection code to protect against this kind of attack and add a Hypervisor bit equals zero check to the SME detection path to prevent non-encrypted guests from trying to enable SME. This handles the following cases: 1) SEV(-ES) guest where CPUID intercept is disabled. The guest will still see leaf 0x8000001f and the SEV bit. It can retrieve the C-bit and boot normally. 2) Non-encrypted guests with intercepted CPUID will check the SEV_STATUS MSR and find it 0 and will try to enable SME. This will fail when the guest finds MSR_K8_SYSCFG to be zero, as it is emulated by KVM. But we can't rely on that, as there might be other hypervisors which return this MSR with bit 23 set. The Hypervisor bit check will prevent that the guest tries to enable SME in this case. 3) Non-encrypted guests on SEV capable hosts with CPUID intercept disabled (by a malicious hypervisor) will try to boot into the SME path. This will fail, but it is also not considered a problem because non-encrypted guests have no protection against the hypervisor anyway. [ bp: s/non-SEV/non-encrypted/g ] Signed-off-by: Joerg Roedel Signed-off-by: Borislav Petkov Acked-by: Tom Lendacky Link: https://lkml.kernel.org/r/20210312123824.306-3-joro@8bytes.org Signed-off-by: Sasha Levin commit 014379ef6849f0e70c2b32095ff4579cd10c1536 Author: Pawel Laszczak Date: Mon Mar 15 08:17:48 2021 +0100 usb: webcam: Invalid size of Processing Unit Descriptor [ Upstream commit 6a154ec9ef6762c774cd2b50215c7a8f0f08a862 ] According with USB Device Class Definition for Video Device the Processing Unit Descriptor bLength should be 12 (10 + bmControlSize), but it has 11. Invalid length caused that Processing Unit Descriptor Test Video form CV tool failed. To fix this issue patch adds bmVideoStandards into uvc_processing_unit_descriptor structure. The bmVideoStandards field was added in UVC 1.1 and it wasn't part of UVC 1.0a. Reviewed-by: Laurent Pinchart Signed-off-by: Pawel Laszczak Reviewed-by: Peter Chen Link: https://lore.kernel.org/r/20210315071748.29706-1-pawell@gli-login.cadence.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit f1fbce00b98f00694251086ecbb4335c51c206c9 Author: Pawel Laszczak Date: Mon Mar 8 13:53:38 2021 +0100 usb: gadget: uvc: add bInterval checking for HS mode [ Upstream commit 26adde04acdff14a1f28d4a5dce46a8513a3038b ] Patch adds extra checking for bInterval passed by configfs. The 5.6.4 chapter of USB Specification (rev. 2.0) say: "A high-bandwidth endpoint must specify a period of 1x125 µs (i.e., a bInterval value of 1)." The issue was observed during testing UVC class on CV. I treat this change as improvement because we can control bInterval by configfs. Reviewed-by: Peter Chen Reviewed-by: Laurent Pinchart Signed-off-by: Pawel Laszczak Link: https://lore.kernel.org/r/20210308125338.4824-1-pawell@gli-login.cadence.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 4e58e2fd84f18e4206f9f7600af041965d67d12d Author: Hui Tang Date: Fri Mar 5 14:35:01 2021 +0800 crypto: qat - fix unmap invalid dma address [ Upstream commit 792b32fad548281e1b7fe14df9063a96c54b32a2 ] 'dma_mapping_error' return a negative value if 'dma_addr' is equal to 'DMA_MAPPING_ERROR' not zero, so fix initialization of 'dma_addr'. Signed-off-by: Hui Tang Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit d7b89a167daa861d5c00cc996630abe5502f50c1 Author: Ard Biesheuvel Date: Tue Mar 2 21:33:03 2021 +0100 crypto: api - check for ERR pointers in crypto_destroy_tfm() [ Upstream commit 83681f2bebb34dbb3f03fecd8f570308ab8b7c2c ] Given that crypto_alloc_tfm() may return ERR pointers, and to avoid crashes on obscure error paths where such pointers are presented to crypto_destroy_tfm() (such as [0]), add an ERR_PTR check there before dereferencing the second argument as a struct crypto_tfm pointer. [0] https://lore.kernel.org/linux-crypto/000000000000de949705bc59e0f6@google.com/ Reported-by: syzbot+12cf5fbfdeba210a89dd@syzkaller.appspotmail.com Reviewed-by: Eric Biggers Signed-off-by: Ard Biesheuvel Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 29b9829718c5e9bd68fc1c652f5e0ba9b9a64fed Author: Bhaumik Bhatt Date: Wed Feb 24 15:23:04 2021 -0800 bus: mhi: core: Process execution environment changes serially [ Upstream commit ef2126c4e2ea2b92f543fae00a2a0332e4573c48 ] In current design, whenever the BHI interrupt is fired, the execution environment is updated. This can cause race conditions and impede ongoing power up/down processing. For example, if a power down is in progress, MHI host updates to a local "disabled" execution environment. If a BHI interrupt fires later, that value gets replaced with one from the BHI EE register. This impacts the controller as it does not expect multiple RDDM execution environment change status callbacks as an example. Another issue would be that the device can enter mission mode and the execution environment is updated, while device creation for SBL channels is still going on due to slower PM state worker thread run, leading to multiple attempts at opening the same channel. Ensure that EE changes are handled only from appropriate places and occur one after another and handle only PBL modes or RDDM EE changes as critical events directly from the interrupt handler. Simplify handling by waiting for SYS ERROR before handling RDDM. This also makes sure that we use the correct execution environment to notify the controller driver when the device resets to one of the PBL execution environments. Signed-off-by: Bhaumik Bhatt Reviewed-by: Loic Poulain Reviewed-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/1614208985-20851-4-git-send-email-bbhatt@codeaurora.org Signed-off-by: Manivannan Sadhasivam Signed-off-by: Sasha Levin commit 3ec3ac3b08e7f0d7fb00487b6030c1afcc17e4fb Author: Bhaumik Bhatt Date: Wed Feb 24 15:23:02 2021 -0800 bus: mhi: core: Destroy SBL devices when moving to mission mode [ Upstream commit 925089c1900f588615db5bf4e1d9064a5f2c18c7 ] Currently, client devices are created in SBL or AMSS (mission mode) and only destroyed after power down or SYS ERROR. When moving between certain execution environments, such as from SBL to AMSS, no clean-up is required. This presents an issue where SBL-specific channels are left open and client drivers now run in an execution environment where they cannot operate. Fix this by expanding the mhi_destroy_device() to do an execution environment specific clean-up if one is requested. Close the gap and destroy devices in such scenarios that allow SBL client drivers to clean up once device enters mission mode. Signed-off-by: Bhaumik Bhatt Reviewed-by: Loic Poulain Reviewed-by: Hemant Kumar Reviewed-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/1614208985-20851-2-git-send-email-bbhatt@codeaurora.org Signed-off-by: Manivannan Sadhasivam Signed-off-by: Sasha Levin commit 936cfae514c7b8857b22a67a9c5b7da0fbe672dd Author: Loic Poulain Date: Fri Mar 5 20:16:46 2021 +0100 bus: mhi: pci_generic: No-Op for device_wake operations [ Upstream commit e3e5e6508fc1c0e98a5a264853713dd30a60e5e5 ] The wake_db register presence is highly speculative and can fuze MHI devices. Indeed, currently the wake_db register address is defined at entry 127 of the 'Channel doorbell array', thus writing to this address is equivalent to ringing the doorbell for channel 127, causing trouble with some devics (e.g. SDX24 based modems) that get an unexpected channel 127 doorbell interrupt. This change fixes that issue by setting wake get/put as no-op for pci_generic devices. The wake device sideband mechanism seems really specific to each device, and is AFAIK not defined by the MHI spec. It also removes zeroing initialization of wake_db register during MMIO initialization, the register being set via wake_get/put accessors few cycles later during M0 transition. Signed-off-by: Loic Poulain Reviewed-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/1614971808-22156-4-git-send-email-loic.poulain@linaro.org Signed-off-by: Manivannan Sadhasivam Signed-off-by: Sasha Levin commit 43bcf55a67077478ee11ca41925c3a553e0b41a1 Author: David Bauer Date: Wed Mar 3 17:08:37 2021 +0100 spi: ath79: remove spi-master setup and cleanup assignment [ Upstream commit ffb597b2bd3cd78b9bfb68f536743cd46dbb2cc4 ] This removes the assignment of setup and cleanup functions for the ath79 target. Assigning the setup-method will lead to 'setup_transfer' not being assigned in spi_bitbang_init. Because of this, performing any TX/RX operation will lead to a kernel oops. Also drop the redundant cleanup assignment, as it's also assigned in spi_bitbang_init. Signed-off-by: David Bauer Link: https://lore.kernel.org/r/20210303160837.165771-2-mail@david-bauer.net Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 548b144b5f83d95914fd118a54130e054f954f86 Author: David Bauer Date: Wed Mar 3 17:08:36 2021 +0100 spi: ath79: always call chipselect function [ Upstream commit 19e2132174583beb90c1bd3e9c842bc6d5c944d1 ] spi-bitbang has to call the chipselect function on the ath79 SPI driver in order to communicate with the SPI slave device, as the ath79 SPI driver has three dedicated chipselect lines but can also be used with GPIOs for the CS lines. Fixes commit 4a07b8bcd503 ("spi: bitbang: Make chipselect callback optional") Signed-off-by: David Bauer Link: https://lore.kernel.org/r/20210303160837.165771-1-mail@david-bauer.net Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 40a66f6f4b6632067dbb2df8fc6b37dc66fed14c Author: karthik alapati Date: Sun Feb 21 21:01:05 2021 +0530 staging: wimax/i2400m: fix byte-order issue [ Upstream commit 0c37baae130df39b19979bba88bde2ee70a33355 ] fix sparse byte-order warnings by converting host byte-order type to __le16 byte-order types before assigning to hdr.length Signed-off-by: karthik alapati Link: https://lore.kernel.org/r/0ae5c5c4c646506d8be871e7be5705542671a1d5.1613921277.git.mail@karthek.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 37e7b52281ebc8a364391faac82977b77757fb03 Author: Tony Lindgren Date: Mon Mar 8 11:35:07 2021 +0200 bus: ti-sysc: Probe for l4_wkup and l4_cfg interconnect devices first [ Upstream commit 4700a00755fb5a4bb5109128297d6fd2d1272ee6 ] We want to probe l4_wkup and l4_cfg interconnect devices first to avoid issues with missing resources. Otherwise we attempt to probe l4_per devices first causing pointless deferred probe and also annoyingh renumbering of the MMC devices for example. Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit fbe76e9f4fbe84cc3347198d24913ab68736a641 Author: Dmitry Osipenko Date: Tue Mar 2 12:54:04 2021 +0300 cpuidle: tegra: Fix C7 idling state on Tegra114 commit 32c8c34d8132b5fe8497c2538597445a0d65c29d upstream. Trusted Foundation firmware doesn't implement the do_idle call and in this case suspending should fall back to the common suspend path. In order to fix this issue we will unconditionally set the NOFLUSH_L2 mode via firmware call, which is a NO-OP on Tegra30/124, and then proceed to the C7 idling, like it was done by the older Tegra114 cpuidle driver. Fixes: 14e086baca50 ("cpuidle: tegra: Squash Tegra114 driver into the common driver") Cc: stable@vger.kernel.org # 5.7+ Reported-by: Anton Bambura # TF701 T114 Tested-by: Anton Bambura # TF701 T114 Tested-by: Matt Merhar # Ouya T30 Tested-by: Peter Geis # Ouya T30 Signed-off-by: Dmitry Osipenko Reviewed-by: Daniel Lezcano Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20210302095405.28453-1-digetx@gmail.com Signed-off-by: Greg Kroah-Hartman commit 3d40985b100da97b2e6777fade7aa7964580468b Author: Phillip Potter Date: Wed Mar 31 23:07:19 2021 +0100 fbdev: zero-fill colormap in fbcmap.c commit 19ab233989d0f7ab1de19a036e247afa4a0a1e9c upstream. Use kzalloc() rather than kmalloc() for the dynamically allocated parts of the colormap in fb_alloc_cmap_gfp, to prevent a leak of random kernel data to userspace under certain circumstances. Fixes a KMSAN-found infoleak bug reported by syzbot at: https://syzkaller.appspot.com/bug?id=741578659feabd108ad9e06696f0c1f2e69c4b6e Reported-by: syzbot+47fa9c9c648b765305b9@syzkaller.appspotmail.com Cc: stable Reviewed-by: Geert Uytterhoeven Signed-off-by: Phillip Potter Link: https://lore.kernel.org/r/20210331220719.1499743-1-phil@philpotter.co.uk Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 2cf62247f25903afe560f3acee7f590908fec171 Author: Chen Jun Date: Wed Apr 14 03:04:49 2021 +0000 posix-timers: Preserve return value in clock_adjtime32() commit 2d036dfa5f10df9782f5278fc591d79d283c1fad upstream. The return value on success (>= 0) is overwritten by the return value of put_old_timex32(). That works correct in the fault case, but is wrong for the success case where put_old_timex32() returns 0. Just check the return value of put_old_timex32() and return -EFAULT in case it is not zero. [ tglx: Massage changelog ] Fixes: 3a4d44b61625 ("ntp: Move adjtimex related compat syscalls to native counterparts") Signed-off-by: Chen Jun Signed-off-by: Thomas Gleixner Reviewed-by: Richard Cochran Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210414030449.90692-1-chenjun102@huawei.com Signed-off-by: Greg Kroah-Hartman commit a06b40880153a2360b313e19b9ccf16c6b1a311b Author: Johannes Thumshirn Date: Fri Apr 16 12:05:27 2021 +0900 btrfs: zoned: fail mount if the device does not support zone append commit 1d68128c107a0b8c0c9125cb05d4771ddc438369 upstream. For zoned btrfs, zone append is mandatory to write to a sequential write only zone, otherwise parallel writes to the same zone could result in unaligned write errors. If a zoned block device does not support zone append (e.g. a dm-crypt zoned device using a non-NULL IV cypher), fail to mount. CC: stable@vger.kernel.org # 5.12 Signed-off-by: Johannes Thumshirn Signed-off-by: Damien Le Moal Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 688ddc93faf4ad65517471ef01d950db9cc8f6a7 Author: Filipe Manana Date: Wed Apr 14 14:05:26 2021 +0100 btrfs: zoned: fix unpaired block group unfreeze during device replace commit 0dc16ef4f6c2708407fab6d141908d46a3b737bc upstream. When doing a device replace on a zoned filesystem, if we find a block group with ->to_copy == 0, we jump to the label 'done', which will result in later calling btrfs_unfreeze_block_group(), even though at this point we never called btrfs_freeze_block_group(). Since at this point we have neither turned the block group to RO mode nor made any progress, we don't need to jump to the label 'done'. So fix this by jumping instead to the label 'skip' and dropping our reference on the block group before the jump. Fixes: 78ce9fc269af6e ("btrfs: zoned: mark block groups to copy for device-replace") CC: stable@vger.kernel.org # 5.12 Reviewed-by: Johannes Thumshirn Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit e2da98788369bfba1138bada72765c47989a4338 Author: Filipe Manana Date: Mon Apr 5 12:32:16 2021 +0100 btrfs: fix race between transaction aborts and fsyncs leading to use-after-free commit 061dde8245356d8864d29e25207aa4daa0be4d3c upstream. There is a race between a task aborting a transaction during a commit, a task doing an fsync and the transaction kthread, which leads to an use-after-free of the log root tree. When this happens, it results in a stack trace like the following: BTRFS info (device dm-0): forced readonly BTRFS warning (device dm-0): Skipping commit of aborted transaction. BTRFS: error (device dm-0) in cleanup_transaction:1958: errno=-5 IO failure BTRFS warning (device dm-0): lost page write due to IO error on /dev/mapper/error-test (-5) BTRFS warning (device dm-0): Skipping commit of aborted transaction. BTRFS warning (device dm-0): direct IO failed ino 261 rw 0,0 sector 0xa4e8 len 4096 err no 10 BTRFS error (device dm-0): error writing primary super block to device 1 BTRFS warning (device dm-0): direct IO failed ino 261 rw 0,0 sector 0x12e000 len 4096 err no 10 BTRFS warning (device dm-0): direct IO failed ino 261 rw 0,0 sector 0x12e008 len 4096 err no 10 BTRFS warning (device dm-0): direct IO failed ino 261 rw 0,0 sector 0x12e010 len 4096 err no 10 BTRFS: error (device dm-0) in write_all_supers:4110: errno=-5 IO failure (1 errors while writing supers) BTRFS: error (device dm-0) in btrfs_sync_log:3308: errno=-5 IO failure general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b68: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI CPU: 2 PID: 2458471 Comm: fsstress Not tainted 5.12.0-rc5-btrfs-next-84 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 RIP: 0010:__mutex_lock+0x139/0xa40 Code: c0 74 19 (...) RSP: 0018:ffff9f18830d7b00 EFLAGS: 00010202 RAX: 6b6b6b6b6b6b6b68 RBX: 0000000000000001 RCX: 0000000000000002 RDX: ffffffffb9c54d13 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff9f18830d7bc0 R08: 0000000000000000 R09: 0000000000000000 R10: ffff9f18830d7be0 R11: 0000000000000001 R12: ffff8c6cd199c040 R13: ffff8c6c95821358 R14: 00000000fffffffb R15: ffff8c6cbcf01358 FS: 00007fa9140c2b80(0000) GS:ffff8c6fac600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa913d52000 CR3: 000000013d2b4003 CR4: 0000000000370ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __btrfs_handle_fs_error+0xde/0x146 [btrfs] ? btrfs_sync_log+0x7c1/0xf20 [btrfs] ? btrfs_sync_log+0x7c1/0xf20 [btrfs] btrfs_sync_log+0x7c1/0xf20 [btrfs] btrfs_sync_file+0x40c/0x580 [btrfs] do_fsync+0x38/0x70 __x64_sys_fsync+0x10/0x20 do_syscall_64+0x33/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7fa9142a55c3 Code: 8b 15 09 (...) RSP: 002b:00007fff26278d48 EFLAGS: 00000246 ORIG_RAX: 000000000000004a RAX: ffffffffffffffda RBX: 0000563c83cb4560 RCX: 00007fa9142a55c3 RDX: 00007fff26278cb0 RSI: 00007fff26278cb0 RDI: 0000000000000005 RBP: 0000000000000005 R08: 0000000000000001 R09: 00007fff26278d5c R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000340 R13: 00007fff26278de0 R14: 00007fff26278d96 R15: 0000563c83ca57c0 Modules linked in: btrfs dm_zero dm_snapshot dm_thin_pool (...) ---[ end trace ee2f1b19327d791d ]--- The steps that lead to this crash are the following: 1) We are at transaction N; 2) We have two tasks with a transaction handle attached to transaction N. Task A and Task B. Task B is doing an fsync; 3) Task B is at btrfs_sync_log(), and has saved fs_info->log_root_tree into a local variable named 'log_root_tree' at the top of btrfs_sync_log(). Task B is about to call write_all_supers(), but before that... 4) Task A calls btrfs_commit_transaction(), and after it sets the transaction state to TRANS_STATE_COMMIT_START, an error happens before it waits for the transaction's 'num_writers' counter to reach a value of 1 (no one else attached to the transaction), so it jumps to the label "cleanup_transaction"; 5) Task A then calls cleanup_transaction(), where it aborts the transaction, setting BTRFS_FS_STATE_TRANS_ABORTED on fs_info->fs_state, setting the ->aborted field of the transaction and the handle to an errno value and also setting BTRFS_FS_STATE_ERROR on fs_info->fs_state. After that, at cleanup_transaction(), it deletes the transaction from the list of transactions (fs_info->trans_list), sets the transaction to the state TRANS_STATE_COMMIT_DOING and then waits for the number of writers to go down to 1, as it's currently 2 (1 for task A and 1 for task B); 6) The transaction kthread is running and sees that BTRFS_FS_STATE_ERROR is set in fs_info->fs_state, so it calls btrfs_cleanup_transaction(). There it sees the list fs_info->trans_list is empty, and then proceeds into calling btrfs_drop_all_logs(), which frees the log root tree with a call to btrfs_free_log_root_tree(); 7) Task B calls write_all_supers() and, shortly after, under the label 'out_wake_log_root', it deferences the pointer stored in 'log_root_tree', which was already freed in the previous step by the transaction kthread. This results in a use-after-free leading to a crash. Fix this by deleting the transaction from the list of transactions at cleanup_transaction() only after setting the transaction state to TRANS_STATE_COMMIT_DOING and waiting for all existing tasks that are attached to the transaction to release their transaction handles. This makes the transaction kthread wait for all the tasks attached to the transaction to be done with the transaction before dropping the log roots and doing other cleanups. Fixes: ef67963dac255b ("btrfs: drop logs when we've aborted a transaction") CC: stable@vger.kernel.org # 5.10+ Reviewed-by: Josef Bacik Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit ae4cd897367582905e5e883d6a062bd5385936d3 Author: Alexander Shishkin Date: Wed Apr 14 20:12:50 2021 +0300 intel_th: pci: Add Rocket Lake CPU support commit 9f7f2a5e01ab4ee56b6d9c0572536fe5fd56e376 upstream. This adds support for the Trace Hub in Rocket Lake CPUs. Signed-off-by: Alexander Shishkin Reviewed-by: Andy Shevchenko Cc: stable # v4.14+ Link: https://lore.kernel.org/r/20210414171251.14672-7-alexander.shishkin@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit e0d49e44953f0205d7ec49e140f8515af9f1fbdc Author: Filipe Manana Date: Tue Apr 20 10:55:12 2021 +0100 btrfs: fix metadata extent leak after failure to create subvolume commit 67addf29004c5be9fa0383c82a364bb59afc7f84 upstream. When creating a subvolume we allocate an extent buffer for its root node after starting a transaction. We setup a root item for the subvolume that points to that extent buffer and then attempt to insert the root item into the root tree - however if that fails, due to ENOMEM for example, we do not free the extent buffer previously allocated and we do not abort the transaction (as at that point we did nothing that can not be undone). This means that we effectively do not return the metadata extent back to the free space cache/tree and we leave a delayed reference for it which causes a metadata extent item to be added to the extent tree, in the next transaction commit, without having backreferences. When this happens 'btrfs check' reports the following: $ btrfs check /dev/sdi Opening filesystem to check... Checking filesystem on /dev/sdi UUID: dce2cb9d-025f-4b05-a4bf-cee0ad3785eb [1/7] checking root items [2/7] checking extents ref mismatch on [30425088 16384] extent item 1, found 0 backref 30425088 root 256 not referenced back 0x564a91c23d70 incorrect global backref count on 30425088 found 1 wanted 0 backpointer mismatch on [30425088 16384] owner ref check failed [30425088 16384] ERROR: errors found in extent allocation tree or chunk allocation [3/7] checking free space cache [4/7] checking fs roots [5/7] checking only csums items (without verifying data) [6/7] checking root refs [7/7] checking quota groups skipped (not enabled on this FS) found 212992 bytes used, error(s) found total csum bytes: 0 total tree bytes: 131072 total fs tree bytes: 32768 total extent tree bytes: 16384 btree space waste bytes: 124669 file data blocks allocated: 65536 referenced 65536 So fix this by freeing the metadata extent if btrfs_insert_root() returns an error. CC: stable@vger.kernel.org # 4.4+ Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 6adafbbb03a11ab7f5725c0b79b1bf90272ca242 Author: Maciej W. Rozycki Date: Wed Apr 14 12:38:28 2021 +0200 x86/build: Disable HIGHMEM64G selection for M486SX commit 0ef3439cd80ba7770723edb0470d15815914bb62 upstream. Fix a regression caused by making the 486SX separately selectable in Kconfig, for which the HIGHMEM64G setting has not been updated and therefore has become exposed as a user-selectable option for the M486SX configuration setting unlike with original M486 and all the other settings that choose non-PAE-enabled processors: High Memory Support > 1. off (NOHIGHMEM) 2. 4GB (HIGHMEM4G) 3. 64GB (HIGHMEM64G) choice[1-3?]: With the fix in place the setting is now correctly removed: High Memory Support > 1. off (NOHIGHMEM) 2. 4GB (HIGHMEM4G) choice[1-2?]: [ bp: Massage commit message. ] Fixes: 87d6021b8143 ("x86/math-emu: Limit MATH_EMULATION to 486SX compatibles") Signed-off-by: Maciej W. Rozycki Signed-off-by: Borislav Petkov Cc: stable@vger.kernel.org # v5.5+ Link: https://lkml.kernel.org/r/alpine.DEB.2.21.2104141221340.44318@angie.orcam.me.uk Signed-off-by: Greg Kroah-Hartman commit 3a736de3271abdd5aadafc4ad01009ce335286a3 Author: Qu Wenruo Date: Tue Aug 4 15:25:47 2020 +0800 btrfs: handle remount to no compress during compression commit 1d8ba9e7e785b6625f4d8e978e8a284b144a7077 upstream. [BUG] When running btrfs/071 with inode_need_compress() removed from compress_file_range(), we got the following crash: BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page Workqueue: btrfs-delalloc btrfs_work_helper [btrfs] RIP: 0010:compress_file_range+0x476/0x7b0 [btrfs] Call Trace: ? submit_compressed_extents+0x450/0x450 [btrfs] async_cow_start+0x16/0x40 [btrfs] btrfs_work_helper+0xf2/0x3e0 [btrfs] process_one_work+0x278/0x5e0 worker_thread+0x55/0x400 ? process_one_work+0x5e0/0x5e0 kthread+0x168/0x190 ? kthread_create_worker_on_cpu+0x70/0x70 ret_from_fork+0x22/0x30 ---[ end trace 65faf4eae941fa7d ]--- This is already after the patch "btrfs: inode: fix NULL pointer dereference if inode doesn't need compression." [CAUSE] @pages is firstly created by kcalloc() in compress_file_extent(): pages = kcalloc(nr_pages, sizeof(struct page *), GFP_NOFS); Then passed to btrfs_compress_pages() to be utilized there: ret = btrfs_compress_pages(... pages, &nr_pages, ...); btrfs_compress_pages() will initialize each page as output, in zlib_compress_pages() we have: pages[nr_pages] = out_page; nr_pages++; Normally this is completely fine, but there is a special case which is in btrfs_compress_pages() itself: switch (type) { default: return -E2BIG; } In this case, we didn't modify @pages nor @out_pages, leaving them untouched, then when we cleanup pages, the we can hit NULL pointer dereference again: if (pages) { for (i = 0; i < nr_pages; i++) { WARN_ON(pages[i]->mapping); put_page(pages[i]); } ... } Since pages[i] are all initialized to zero, and btrfs_compress_pages() doesn't change them at all, accessing pages[i]->mapping would lead to NULL pointer dereference. This is not possible for current kernel, as we check inode_need_compress() before doing pages allocation. But if we're going to remove that inode_need_compress() in compress_file_extent(), then it's going to be a problem. [FIX] When btrfs_compress_pages() hits its default case, modify @out_pages to 0 to prevent such problem from happening. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=212331 CC: stable@vger.kernel.org # 5.10+ Reviewed-by: Josef Bacik Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit bb7d42ee6cd5822afc1e6c77c2c0d78fc000ad8f Author: Aurelien Aptel Date: Fri Apr 9 15:47:01 2021 +0200 smb2: fix use-after-free in smb2_ioctl_query_info() commit ccd48ec3d4a6cc595b2d9c5146e63b6c23546701 upstream. * rqst[1,2,3] is allocated in vars * each rqst->rq_iov is also allocated in vars or using pooled memory SMB2_open_free, SMB2_ioctl_free, SMB2_query_info_free are iterating on each rqst after vars has been freed (use-after-free), and they are freeing the kvec a second time (double-free). How to trigger: * compile with KASAN * mount a share $ smbinfo quota /mnt/foo Segmentation fault $ dmesg ================================================================== BUG: KASAN: use-after-free in SMB2_open_free+0x1c/0xa0 Read of size 8 at addr ffff888007b10c00 by task python3/1200 CPU: 2 PID: 1200 Comm: python3 Not tainted 5.12.0-rc6+ #107 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.14.0-0-g155821a-rebuilt.opensuse.org 04/01/2014 Call Trace: dump_stack+0x93/0xc2 print_address_description.constprop.0+0x18/0x130 ? SMB2_open_free+0x1c/0xa0 ? SMB2_open_free+0x1c/0xa0 kasan_report.cold+0x7f/0x111 ? smb2_ioctl_query_info+0x240/0x990 ? SMB2_open_free+0x1c/0xa0 SMB2_open_free+0x1c/0xa0 smb2_ioctl_query_info+0x2bf/0x990 ? smb2_query_reparse_tag+0x600/0x600 ? cifs_mapchar+0x250/0x250 ? rcu_read_lock_sched_held+0x3f/0x70 ? cifs_strndup_to_utf16+0x12c/0x1c0 ? rwlock_bug.part.0+0x60/0x60 ? rcu_read_lock_sched_held+0x3f/0x70 ? cifs_convert_path_to_utf16+0xf8/0x140 ? smb2_check_message+0x6f0/0x6f0 cifs_ioctl+0xf18/0x16b0 ? smb2_query_reparse_tag+0x600/0x600 ? cifs_readdir+0x1800/0x1800 ? selinux_bprm_creds_for_exec+0x4d0/0x4d0 ? do_user_addr_fault+0x30b/0x950 ? __x64_sys_openat+0xce/0x140 __x64_sys_ioctl+0xb9/0xf0 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7fdcf1f4ba87 Code: b3 66 90 48 8b 05 11 14 2c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e1 13 2c 00 f7 d8 64 89 01 48 RSP: 002b:00007ffef1ce7748 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00000000c018cf07 RCX: 00007fdcf1f4ba87 RDX: 0000564c467c5590 RSI: 00000000c018cf07 RDI: 0000000000000003 RBP: 00007ffef1ce7770 R08: 00007ffef1ce7420 R09: 00007fdcf0e0562b R10: 0000000000000100 R11: 0000000000000246 R12: 0000000000004018 R13: 0000000000000001 R14: 0000000000000003 R15: 0000564c467c5590 Allocated by task 1200: kasan_save_stack+0x1b/0x40 __kasan_kmalloc+0x7a/0x90 smb2_ioctl_query_info+0x10e/0x990 cifs_ioctl+0xf18/0x16b0 __x64_sys_ioctl+0xb9/0xf0 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae Freed by task 1200: kasan_save_stack+0x1b/0x40 kasan_set_track+0x1c/0x30 kasan_set_free_info+0x20/0x30 __kasan_slab_free+0xe5/0x110 slab_free_freelist_hook+0x53/0x130 kfree+0xcc/0x320 smb2_ioctl_query_info+0x2ad/0x990 cifs_ioctl+0xf18/0x16b0 __x64_sys_ioctl+0xb9/0xf0 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae The buggy address belongs to the object at ffff888007b10c00 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 0 bytes inside of 512-byte region [ffff888007b10c00, ffff888007b10e00) The buggy address belongs to the page: page:0000000044e14b75 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x7b10 head:0000000044e14b75 order:2 compound_mapcount:0 compound_pincount:0 flags: 0x100000000010200(slab|head) raw: 0100000000010200 ffffea000015f500 0000000400000004 ffff888001042c80 raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888007b10b00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff888007b10b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff888007b10c00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888007b10c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888007b10d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== Signed-off-by: Aurelien Aptel CC: Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit ee3b051cd948f3cc3e049f3b5049c3b0b7fc4b88 Author: Paulo Alcantara Date: Mon May 3 11:55:26 2021 -0300 cifs: fix regression when mounting shares with prefix paths commit 5c1acf3fe05ce443edba5e2110c9e581765f66a8 upstream. The commit 315db9a05b7a ("cifs: fix leak in cifs_smb3_do_mount() ctx") revealed an existing bug when mounting shares that contain a prefix path or DFS links. cifs_setup_volume_info() requires the @devname to contain the full path (UNC + prefix) to update the fs context with the new UNC and prepath values, however we were passing only the UNC path (old_ctx->UNC) in @device thus discarding any prefix paths. Instead of concatenating both old_ctx->{UNC,prepath} and pass it in @devname, just keep the dup'ed values of UNC and prepath in cifs_sb->ctx after calling smb3_fs_context_dup(), and fix smb3_parse_devname() to correctly parse and not leak the new UNC and prefix paths. Cc: # v5.11+ Fixes: 315db9a05b7a ("cifs: fix leak in cifs_smb3_do_mount() ctx") Signed-off-by: Paulo Alcantara (SUSE) Acked-by: David Disseldorp Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit eb877963081ca7fb1ccc37ff60c5716fa658d82f Author: Shyam Prasad N Date: Thu Apr 29 07:53:18 2021 +0000 cifs: detect dead connections only when echoes are enabled. commit f4916649f98e2c7bdba38c6597a98c456c17317d upstream. We can detect server unresponsiveness only if echoes are enabled. Echoes can be disabled under two scenarios: 1. The connection is low on credits, so we've disabled echoes/oplocks. 2. The connection has not seen any request till now (other than negotiate/sess-setup), which is when we enable these two, based on the credits available. So this fix will check for dead connection, only when echo is enabled. Signed-off-by: Shyam Prasad N CC: # v5.8+ Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 0049109550011245df45d4a2abf60960f3eac6af Author: David Disseldorp Date: Fri Apr 23 00:14:03 2021 +0200 cifs: fix leak in cifs_smb3_do_mount() ctx commit 315db9a05b7a56810728589baa930864107e4634 upstream. cifs_smb3_do_mount() calls smb3_fs_context_dup() and then cifs_setup_volume_info(). The latter's subsequent smb3_parse_devname() call overwrites the cifs_sb->ctx->UNC string already dup'ed by smb3_fs_context_dup(), resulting in a leak. E.g. unreferenced object 0xffff888002980420 (size 32): comm "mount", pid 160, jiffies 4294892541 (age 30.416s) hex dump (first 32 bytes): 5c 5c 31 39 32 2e 31 36 38 2e 31 37 34 2e 31 30 \\192.168.174.10 34 5c 72 61 70 69 64 6f 2d 73 68 61 72 65 00 00 4\rapido-share.. backtrace: [<00000000069e12f6>] kstrdup+0x28/0x50 [<00000000b61f4032>] smb3_fs_context_dup+0x127/0x1d0 [cifs] [<00000000c6e3e3bf>] cifs_smb3_do_mount+0x77/0x660 [cifs] [<0000000063467a6b>] smb3_get_tree+0xdf/0x220 [cifs] [<00000000716f731e>] vfs_get_tree+0x1b/0x90 [<00000000491d3892>] path_mount+0x62a/0x910 [<0000000046b2e774>] do_mount+0x50/0x70 [<00000000ca7b64dd>] __x64_sys_mount+0x81/0xd0 [<00000000b5122496>] do_syscall_64+0x33/0x40 [<000000002dd397af>] entry_SYSCALL_64_after_hwframe+0x44/0xae This change is a bandaid until the cifs_setup_volume_info() TODO and error handling issues are resolved. Signed-off-by: David Disseldorp Acked-by: Ronnie Sahlberg Reviewed-by: Paulo Alcantara (SUSE) CC: # v5.11+ Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit e9ac929c3ec9223535745b1df8764426af6b73a5 Author: Eugene Korenevsky Date: Fri Apr 16 10:35:30 2021 +0300 cifs: fix out-of-bound memory access when calling smb3_notify() at mount point commit a637f4ae037e1e0604ac008564934d63261a8fd1 upstream. If smb3_notify() is called at mount point of CIFS, build_path_from_dentry() returns the pointer to kmalloc-ed memory with terminating zero (this is empty FileName to be passed to SMB2 CREATE request). This pointer is assigned to the `path` variable. Then `path + 1` (to skip first backslash symbol) is passed to cifs_convert_path_to_utf16(). This is incorrect for empty path and causes out-of-bound memory access. Get rid of this "increase by one". cifs_convert_path_to_utf16() already contains the check for leading backslash in the path. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=212693 CC: # v5.6+ Signed-off-by: Eugene Korenevsky Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit b399c1a3ea0b9d10047ff266d65533df7f15532f Author: Paul Aurich Date: Tue Apr 13 14:25:27 2021 -0700 cifs: Return correct error code from smb2_get_enc_key commit 83728cbf366e334301091d5b808add468ab46b27 upstream. Avoid a warning if the error percolates back up: [440700.376476] CIFS VFS: \\otters.example.com crypt_message: Could not get encryption key [440700.386947] ------------[ cut here ]------------ [440700.386948] err = 1 [440700.386977] WARNING: CPU: 11 PID: 2733 at /build/linux-hwe-5.4-p6lk6L/linux-hwe-5.4-5.4.0/lib/errseq.c:74 errseq_set+0x5c/0x70 ... [440700.397304] CPU: 11 PID: 2733 Comm: tar Tainted: G OE 5.4.0-70-generic #78~18.04.1-Ubuntu ... [440700.397334] Call Trace: [440700.397346] __filemap_set_wb_err+0x1a/0x70 [440700.397419] cifs_writepages+0x9c7/0xb30 [cifs] [440700.397426] do_writepages+0x4b/0xe0 [440700.397444] __filemap_fdatawrite_range+0xcb/0x100 [440700.397455] filemap_write_and_wait+0x42/0xa0 [440700.397486] cifs_setattr+0x68b/0xf30 [cifs] [440700.397493] notify_change+0x358/0x4a0 [440700.397500] utimes_common+0xe9/0x1c0 [440700.397510] do_utimes+0xc5/0x150 [440700.397520] __x64_sys_utimensat+0x88/0xd0 Fixes: 61cfac6f267d ("CIFS: Fix possible use after free in demultiplex thread") Signed-off-by: Paul Aurich CC: stable@vger.kernel.org Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 3f72d3709f53af72835af7dc8b15ba61611a0e36 Author: He Ying Date: Fri Apr 23 04:35:16 2021 -0400 irqchip/gic-v3: Do not enable irqs when handling spurious interrups commit a97709f563a078e259bf0861cd259aa60332890a upstream. We triggered the following error while running our 4.19 kernel with the pseudo-NMI patches backported to it: [ 14.816231] ------------[ cut here ]------------ [ 14.816231] kernel BUG at irq.c:99! [ 14.816232] Internal error: Oops - BUG: 0 [#1] SMP [ 14.816232] Process swapper/0 (pid: 0, stack limit = 0x(____ptrval____)) [ 14.816233] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O 4.19.95.aarch64 #14 [ 14.816233] Hardware name: evb (DT) [ 14.816234] pstate: 80400085 (Nzcv daIf +PAN -UAO) [ 14.816234] pc : asm_nmi_enter+0x94/0x98 [ 14.816235] lr : asm_nmi_enter+0x18/0x98 [ 14.816235] sp : ffff000008003c50 [ 14.816235] pmr_save: 00000070 [ 14.816237] x29: ffff000008003c50 x28: ffff0000095f56c0 [ 14.816238] x27: 0000000000000000 x26: ffff000008004000 [ 14.816239] x25: 00000000015e0000 x24: ffff8008fb916000 [ 14.816240] x23: 0000000020400005 x22: ffff0000080817cc [ 14.816241] x21: ffff000008003da0 x20: 0000000000000060 [ 14.816242] x19: 00000000000003ff x18: ffffffffffffffff [ 14.816243] x17: 0000000000000008 x16: 003d090000000000 [ 14.816244] x15: ffff0000095ea6c8 x14: ffff8008fff5ab40 [ 14.816244] x13: ffff8008fff58b9d x12: 0000000000000000 [ 14.816245] x11: ffff000008c8a200 x10: 000000008e31fca5 [ 14.816246] x9 : ffff000008c8a208 x8 : 000000000000000f [ 14.816247] x7 : 0000000000000004 x6 : ffff8008fff58b9e [ 14.816248] x5 : 0000000000000000 x4 : 0000000080000000 [ 14.816249] x3 : 0000000000000000 x2 : 0000000080000000 [ 14.816250] x1 : 0000000000120000 x0 : ffff0000095f56c0 [ 14.816251] Call trace: [ 14.816251] asm_nmi_enter+0x94/0x98 [ 14.816251] el1_irq+0x8c/0x180 (IRQ C) [ 14.816252] gic_handle_irq+0xbc/0x2e4 [ 14.816252] el1_irq+0xcc/0x180 (IRQ B) [ 14.816253] arch_timer_handler_virt+0x38/0x58 [ 14.816253] handle_percpu_devid_irq+0x90/0x240 [ 14.816253] generic_handle_irq+0x34/0x50 [ 14.816254] __handle_domain_irq+0x68/0xc0 [ 14.816254] gic_handle_irq+0xf8/0x2e4 [ 14.816255] el1_irq+0xcc/0x180 (IRQ A) [ 14.816255] arch_cpu_idle+0x34/0x1c8 [ 14.816255] default_idle_call+0x24/0x44 [ 14.816256] do_idle+0x1d0/0x2c8 [ 14.816256] cpu_startup_entry+0x28/0x30 [ 14.816256] rest_init+0xb8/0xc8 [ 14.816257] start_kernel+0x4c8/0x4f4 [ 14.816257] Code: 940587f1 d5384100 b9401001 36a7fd01 (d4210000) [ 14.816258] Modules linked in: start_dp(O) smeth(O) [ 15.103092] ---[ end trace 701753956cb14aa8 ]--- [ 15.103093] Kernel panic - not syncing: Fatal exception in interrupt [ 15.103099] SMP: stopping secondary CPUs [ 15.103100] Kernel Offset: disabled [ 15.103100] CPU features: 0x36,a2400218 [ 15.103100] Memory Limit: none which is cause by a 'BUG_ON(in_nmi())' in nmi_enter(). From the call trace, we can find three interrupts (noted A, B, C above): interrupt (A) is preempted by (B), which is further interrupted by (C). Subsequent investigations show that (B) results in nmi_enter() being called, but that it actually is a spurious interrupt. Furthermore, interrupts are reenabled in the context of (B), and (C) fires with NMI priority. We end-up with a nested NMI situation, something we definitely do not want to (and cannot) handle. The bug here is that spurious interrupts should never result in any state change, and we should just return to the interrupted context. Moving the handling of spurious interrupts as early as possible in the GICv3 handler fixes this issue. Fixes: 3f1f3234bc2d ("irqchip/gic-v3: Switch to PMR masking before calling IRQ handler") Acked-by: Mark Rutland Signed-off-by: He Ying [maz: rewrote commit message, corrected Fixes: tag] Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20210423083516.170111-1-heying24@huawei.com Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 9c0affe34c5cfdd8116817f7d0bbd6f0af136c5b Author: Ulf Hansson Date: Wed Mar 10 16:29:00 2021 +0100 mmc: core: Fix hanging on I/O during system suspend for removable cards commit 17a17bf50612e6048a9975450cf1bd30f93815b5 upstream. The mmc core uses a PM notifier to temporarily during system suspend, turn off the card detection mechanism for removal/insertion of (e)MMC/SD/SDIO cards. Additionally, the notifier may be used to remove an SDIO card entirely, if a corresponding SDIO functional driver don't have the system suspend/resume callbacks assigned. This behaviour has been around for a very long time. However, a recent bug report tells us there are problems with this approach. More precisely, when receiving the PM_SUSPEND_PREPARE notification, we may end up hanging on I/O to be completed, thus also preventing the system from getting suspended. In the end what happens, is that the cancel_delayed_work_sync() in mmc_pm_notify() ends up waiting for mmc_rescan() to complete - and since mmc_rescan() wants to claim the host, it needs to wait for the I/O to be completed first. Typically, this problem is triggered in Android, if there is ongoing I/O while the user decides to suspend, resume and then suspend the system again. This due to that after the resume, an mmc_rescan() work gets punted to the workqueue, which job is to verify that the card remains inserted after the system has resumed. To fix this problem, userspace needs to become frozen to suspend the I/O, prior to turning off the card detection mechanism. Therefore, let's drop the PM notifiers for mmc subsystem altogether and rely on the card detection to be turned off/on as a part of the system_freezable_wq, that we are already using. Moreover, to allow and SDIO card to be removed during system suspend, let's manage this from a ->prepare() callback, assigned at the mmc_host_class level. In this way, we can use the parent device (the mmc_host_class device), to remove the card device that is the child, in the device_prepare() phase. Reported-by: Kiwoong Kim Cc: stable@vger.kernel.org # v4.5+ Signed-off-by: Ulf Hansson Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20210310152900.149380-1-ulf.hansson@linaro.org Reviewed-by: Kiwoong Kim Signed-off-by: Greg Kroah-Hartman commit 79c081d27cc7f9ebb181de6093ad87a7af5ab1ab Author: Seunghui Lee Date: Mon Feb 22 17:31:56 2021 +0900 mmc: core: Set read only for SD cards with permanent write protect bit commit 917a5336f2c27928be270226ab374ed0cbf3805d upstream. Some of SD cards sets permanent write protection bit in their CSD register, due to lifespan or internal problem. To avoid unnecessary I/O write operations, let's parse the bits in the CSD during initialization and mark the card as read only for this case. Signed-off-by: Seunghui Lee Link: https://lore.kernel.org/r/20210222083156.19158-1-sh043.lee@samsung.com Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 0549d960b0c7563be4a3eae62dac8d39ae0563a9 Author: DooHyun Hwang Date: Wed Feb 10 13:59:36 2021 +0900 mmc: core: Do a power cycle when the CMD11 fails commit 147186f531ae49c18b7a9091a2c40e83b3d95649 upstream. A CMD11 is sent to the SD/SDIO card to start the voltage switch procedure into 1.8V I/O. According to the SD spec a power cycle is needed of the card, if it turns out that the CMD11 fails. Let's fix this, to allow a retry of the initialization without the voltage switch, to succeed. Note that, whether it makes sense to also retry with the voltage switch after the power cycle is a bit more difficult to know. At this point, we treat it like the CMD11 isn't supported and therefore we skip it when retrying. Signed-off-by: DooHyun Hwang Link: https://lore.kernel.org/r/20210210045936.7809-1-dh0421.hwang@samsung.com Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 615bdc0dd81043d17e3492f09e116c6eb0b2577f Author: Avri Altman Date: Sun Apr 25 09:02:06 2021 +0300 mmc: block: Issue a cache flush only when it's enabled commit 97fce126e279690105ee15be652b465fd96f9997 upstream. In command queueing mode, the cache isn't flushed via the mmc_flush_cache() function, but instead by issuing a CMDQ_TASK_MGMT (CMD48) with a FLUSH_CACHE opcode. In this path, we need to check if cache has been enabled, before deciding to flush the cache, along the lines of what's being done in mmc_flush_cache(). To fix this problem, let's add a new bus ops callback ->cache_enabled() and implement it for the mmc bus type. In this way, the mmc block device driver can call it to know whether cache flushing should be done. Fixes: 1e8e55b67030 (mmc: block: Add CQE support) Cc: stable@vger.kernel.org Reported-by: Brendan Peter Signed-off-by: Avri Altman Tested-by: Brendan Peter Acked-by: Adrian Hunter Link: https://lore.kernel.org/r/20210425060207.2591-2-avri.altman@wdc.com Link: https://lore.kernel.org/r/20210425060207.2591-3-avri.altman@wdc.com [Ulf: Squashed the two patches and made some minor updates] Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 6d19fc6d44da37854f75661d41367abc78b3fa75 Author: Avri Altman Date: Tue Apr 20 16:46:41 2021 +0300 mmc: block: Update ext_csd.cache_ctrl if it was written commit aea0440ad023ab0662299326f941214b0d7480bd upstream. The cache function can be turned ON and OFF by writing to the CACHE_CTRL byte (EXT_CSD byte [33]). However, card->ext_csd.cache_ctrl is only set on init if cache size > 0. Fix that by explicitly setting ext_csd.cache_ctrl on ext-csd write. Signed-off-by: Avri Altman Acked-by: Adrian Hunter Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210420134641.57343-3-avri.altman@wdc.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit df2c44c9b41010189cbc8253465ba5c1f8301a5b Author: Aniruddha Tvs Rao Date: Wed Apr 7 10:46:17 2021 +0100 mmc: sdhci-tegra: Add required callbacks to set/clear CQE_EN bit commit 5ec6fa5a6dc5e42a4aa782f3a81d5f08b0fac1e6 upstream. CMD8 is not supported with Command Queue Enabled. Add required callback to clear CQE_EN and CQE_INTR fields in the host controller register before sending CMD8. Add corresponding callback in the CQHCI resume path to re-enable CQE_EN and CQE_INTR fields. Reported-by: Kamal Mostafa Tested-by: Kamal Mostafa Signed-off-by: Aniruddha Tvs Rao Signed-off-by: Jon Hunter Acked-by: Adrian Hunter Acked-by: Thierry Reding Link: https://lore.kernel.org/r/20210407094617.770495-1-jonathanh@nvidia.com Cc: stable@vger.kernel.org # v5.10+ Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit afc09d03bfaf1a9daf540255a971b3f235e80c0d Author: Adrian Hunter Date: Wed Mar 31 11:17:52 2021 +0300 mmc: sdhci-pci: Fix initialization of some SD cards for Intel BYT-based controllers commit 2970134b927834e9249659a70aac48e62dff804a upstream. Bus power may control card power, but the full reset done by SDHCI at initialization still may not reset the power, whereas a direct write to SDHCI_POWER_CONTROL can. That might be needed to initialize correctly, if the card was left powered on previously. Signed-off-by: Adrian Hunter Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210331081752.23621-1-adrian.hunter@intel.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 9ef5cb5025d1e11960a9b79d66694e91db5e3209 Author: Pradeep P V K Date: Wed Mar 3 14:02:11 2021 +0530 mmc: sdhci: Check for reset prior to DMA address unmap commit 21e35e898aa9ef7781632959db8613a5380f2eae upstream. For data read commands, SDHC may initiate data transfers even before it completely process the command response. In case command itself fails, driver un-maps the memory associated with data transfer but this memory can still be accessed by SDHC for the already initiated data transfer. This scenario can lead to un-mapped memory access error. To avoid this scenario, reset SDHC (when command fails) prior to un-mapping memory. Resetting SDHC ensures that all in-flight data transfers are either aborted or completed. So we don't run into this scenario. Swap the reset, un-map steps sequence in sdhci_request_done(). Suggested-by: Veerabhadrarao Badiganti Signed-off-by: Pradeep P V K Acked-by: Adrian Hunter Link: https://lore.kernel.org/r/1614760331-43499-1-git-send-email-pragalla@qti.qualcomm.com Cc: stable@vger.kernel.org # v4.9+ Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit d6e7fda496978f2763413b5523557b38dc2bf6c2 Author: Christophe JAILLET Date: Sat Feb 20 15:29:53 2021 +0100 mmc: uniphier-sd: Fix a resource leak in the remove function commit e29c84857e2d51aa017ce04284b962742fb97d9e upstream. A 'tmio_mmc_host_free()' call is missing in the remove function, in order to balance a 'tmio_mmc_host_alloc()' call in the probe. This is done in the error handling path of the probe, but not in the remove function. Add the missing call. Fixes: 3fd784f745dd ("mmc: uniphier-sd: add UniPhier SD/eMMC controller driver") Signed-off-by: Christophe JAILLET Reviewed-by: Masahiro Yamada Link: https://lore.kernel.org/r/20210220142953.918608-1-christophe.jaillet@wanadoo.fr Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 4b75f8a3b21b11f6b0655d8675c870799e5d4ed1 Author: Christophe JAILLET Date: Sat Feb 20 15:29:35 2021 +0100 mmc: uniphier-sd: Fix an error handling path in uniphier_sd_probe() commit b03aec1c1f337dfdae44cdb0645ecac34208ae0a upstream. A 'uniphier_sd_clk_enable()' call should be balanced by a corresponding 'uniphier_sd_clk_disable()' call. This is done in the remove function, but not in the error handling path of the probe. Add the missing call. Fixes: 3fd784f745dd ("mmc: uniphier-sd: add UniPhier SD/eMMC controller driver") Signed-off-by: Christophe JAILLET Reviewed-by: Masahiro Yamada Link: https://lore.kernel.org/r/20210220142935.918554-1-christophe.jaillet@wanadoo.fr Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit c8b5286c2154f847e63016bdad7800368378c726 Author: Sreekanth Reddy Date: Tue Mar 30 16:21:37 2021 +0530 scsi: mpt3sas: Block PCI config access from userspace during reset commit 3c8604691d2acc7b7d4795d9695070de9eaa5828 upstream. While diag reset is in progress there is short duration where all access to controller's PCI config space from the host needs to be blocked. This is due to a hardware limitation of the IOC controllers. Block all access to controller's config space from userland applications by calling pci_cfg_access_lock() while diag reset is in progress and unlocking it again after the controller comes back to ready state. Link: https://lore.kernel.org/r/20210330105137.20728-1-sreekanth.reddy@broadcom.com Cc: stable@vger.kernel.org #v5.4.108+ Signed-off-by: Sreekanth Reddy Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit e90e844c5b2b66ad17a7383f120778b1b31a06c9 Author: Sreekanth Reddy Date: Tue Mar 30 16:20:04 2021 +0530 scsi: mpt3sas: Only one vSES is present even when IOC has multi vSES commit 4c51f956965120b3441cdd39c358b87daba13e19 upstream. Whenever the driver is adding a vSES to virtual-phys list it is reinitializing the list head. Hence those vSES devices which were added previously are lost. Stop reinitializing the list every time a new vSES device is added. Link: https://lore.kernel.org/r/20210330105004.20413-1-sreekanth.reddy@broadcom.com Cc: stable@vger.kernel.org #v5.11.10+ Signed-off-by: Sreekanth Reddy Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit a73208e3244127ef9f2cdf24e4adb947aaa32053 Author: Arun Easi Date: Mon Mar 29 01:52:23 2021 -0700 scsi: qla2xxx: Fix crash in qla2xxx_mqueuecommand() commit 6641df81ab799f28a5d564f860233dd26cca0d93 upstream. RIP: 0010:kmem_cache_free+0xfa/0x1b0 Call Trace: qla2xxx_mqueuecommand+0x2b5/0x2c0 [qla2xxx] scsi_queue_rq+0x5e2/0xa40 __blk_mq_try_issue_directly+0x128/0x1d0 blk_mq_request_issue_directly+0x4e/0xb0 Fix incorrect call to free srb in qla2xxx_mqueuecommand(), as srb is now allocated by upper layers. This fixes smatch warning of srb unintended free. Link: https://lore.kernel.org/r/20210329085229.4367-7-njavali@marvell.com Fixes: af2a0c51b120 ("scsi: qla2xxx: Fix SRB leak on switch command timeout") Cc: stable@vger.kernel.org # 5.5 Reported-by: Laurence Oberman Reported-by: Dan Carpenter Reviewed-by: Himanshu Madhani Signed-off-by: Arun Easi Signed-off-by: Nilesh Javali Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit b86203bb433cba7c7c64b504d6f9d5fba2b3e73a Author: James Smart Date: Sun Apr 11 18:31:12 2021 -0700 scsi: lpfc: Fix rmmod crash due to bad ring pointers to abort_iotag commit 078c68b87a717b9fcd8e0f2109f73456fbc55490 upstream. Rmmod on SLI-4 adapters is sometimes hitting a bad ptr dereference in lpfc_els_free_iocb(). A prior patch refactored the lpfc_sli_abort_iocb() routine. One of the changes was to convert from building/sending an abort within the routine to using a common routine. The reworked routine passes, without modification, the pring ptr to the new common routine. The older routine had logic to check SLI-3 vs SLI-4 and adapt the pring ptr if necessary as callers were passing SLI-3 pointers even when not on an SLI-4 adapter. The new routine is missing this check and adapt, so the SLI-3 ring pointers are being used in SLI-4 paths. Fix by cleaning up the calling routines. In review, there is no need to pass the ring ptr argument to abort_iocb at all. The routine can look at the adapter type itself and reference the proper ring. Link: https://lore.kernel.org/r/20210412013127.2387-2-jsmart2021@gmail.com Fixes: db7531d2b377 ("scsi: lpfc: Convert abort handling to SLI-3 and SLI-4 handlers") Cc: # v5.11+ Co-developed-by: Justin Tee Signed-off-by: Justin Tee Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 0f86d66b38501e3ac66cf2d9f9f8ad6838bad0e6 Author: Roman Bolshakov Date: Mon Apr 12 19:57:40 2021 +0300 scsi: qla2xxx: Reserve extra IRQ vectors commit f02d4086a8f36a0e1aaebf559b54cf24a177a486 upstream. Commit a6dcfe08487e ("scsi: qla2xxx: Limit interrupt vectors to number of CPUs") lowers the number of allocated MSI-X vectors to the number of CPUs. That breaks vector allocation assumptions in qla83xx_iospace_config(), qla24xx_enable_msix() and qla2x00_iospace_config(). Either of the functions computes maximum number of qpairs as: ha->max_qpairs = ha->msix_count - 1 (MB interrupt) - 1 (default response queue) - 1 (ATIO, in dual or pure target mode) max_qpairs is set to zero in case of two CPUs and initiator mode. The number is then used to allocate ha->queue_pair_map inside qla2x00_alloc_queues(). No allocation happens and ha->queue_pair_map is left NULL but the driver thinks there are queue pairs available. qla2xxx_queuecommand() tries to find a qpair in the map and crashes: if (ha->mqenable) { uint32_t tag; uint16_t hwq; struct qla_qpair *qpair = NULL; tag = blk_mq_unique_tag(cmd->request); hwq = blk_mq_unique_tag_to_hwq(tag); qpair = ha->queue_pair_map[hwq]; # <- HERE if (qpair) return qla2xxx_mqueuecommand(host, cmd, qpair); } BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI CPU: 0 PID: 72 Comm: kworker/u4:3 Tainted: G W 5.10.0-rc1+ #25 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014 Workqueue: scsi_wq_7 fc_scsi_scan_rport [scsi_transport_fc] RIP: 0010:qla2xxx_queuecommand+0x16b/0x3f0 [qla2xxx] Call Trace: scsi_queue_rq+0x58c/0xa60 blk_mq_dispatch_rq_list+0x2b7/0x6f0 ? __sbitmap_get_word+0x2a/0x80 __blk_mq_sched_dispatch_requests+0xb8/0x170 blk_mq_sched_dispatch_requests+0x2b/0x50 __blk_mq_run_hw_queue+0x49/0xb0 __blk_mq_delay_run_hw_queue+0xfb/0x150 blk_mq_sched_insert_request+0xbe/0x110 blk_execute_rq+0x45/0x70 __scsi_execute+0x10e/0x250 scsi_probe_and_add_lun+0x228/0xda0 __scsi_scan_target+0xf4/0x620 ? __pm_runtime_resume+0x4f/0x70 scsi_scan_target+0x100/0x110 fc_scsi_scan_rport+0xa1/0xb0 [scsi_transport_fc] process_one_work+0x1ea/0x3b0 worker_thread+0x28/0x3b0 ? process_one_work+0x3b0/0x3b0 kthread+0x112/0x130 ? kthread_park+0x80/0x80 ret_from_fork+0x22/0x30 The driver should allocate enough vectors to provide every CPU it's own HW queue and still handle reserved (MB, RSP, ATIO) interrupts. The change fixes the crash on dual core VM and prevents unbalanced QP allocation where nr_hw_queues is two less than the number of CPUs. Link: https://lore.kernel.org/r/20210412165740.39318-1-r.bolshakov@yadro.com Fixes: a6dcfe08487e ("scsi: qla2xxx: Limit interrupt vectors to number of CPUs") Cc: Daniel Wagner Cc: Himanshu Madhani Cc: Quinn Tran Cc: Nilesh Javali Cc: Martin K. Petersen Cc: stable@vger.kernel.org # 5.11+ Reported-by: Aleksandr Volkov Reported-by: Aleksandr Miloserdov Reviewed-by: Daniel Wagner Reviewed-by: Himanshu Madhani Signed-off-by: Roman Bolshakov Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit e77fbc250f30e68fd8fb231b71f5084c0baf39f4 Author: Ilya Dryomov Date: Mon May 3 17:09:01 2021 +0200 libceph: allow addrvecs with a single NONE/blank address commit 3f1c6f2122fc780560f09735b6d1dbf39b44eb0f upstream. Normally, an unused OSD id/slot is represented by an empty addrvec. However, it also appears to be possible to generate an osdmap where an unused OSD id/slot has an addrvec with a single blank address of type NONE. Allow such addrvecs and make the end result be exactly the same as for the empty addrvec case -- leave addr intact. Cc: stable@vger.kernel.org # 5.11+ Signed-off-by: Ilya Dryomov Reviewed-by: Jeff Layton Signed-off-by: Greg Kroah-Hartman commit 6ce58cbf68808433ba30b0905d2f58aff219166f Author: Ilya Dryomov Date: Wed Apr 14 10:38:40 2021 +0200 libceph: bump CephXAuthenticate encoding version commit 7807dafda21a549403d922da98dde0ddfeb70d08 upstream. A dummy v3 encoding (exactly the same as v2) was introduced so that the monitors can distinguish broken clients that may not include their auth ticket in CEPHX_GET_AUTH_SESSION_KEY request on reconnects, thus failing to prove previous possession of their global_id (one part of CVE-2021-20288). The kernel client has always included its auth ticket, so it is compatible with enforcing mode as is. However we want to bump the encoding version to avoid having to authenticate twice on the initial connect -- all legacy (CephXAuthenticate < v3) are now forced do so in order to expose insecure global_id reclaim. Marking for stable since at least for 5.11 and 5.12 it is trivial (v2 -> v3). Cc: stable@vger.kernel.org # 5.11+ URL: https://tracker.ceph.com/issues/50452 Signed-off-by: Ilya Dryomov Reviewed-by: Sage Weil Signed-off-by: Greg Kroah-Hartman commit 77b96633f972a46e28c8fa0a74e5f835962a0780 Author: Tudor Ambarus Date: Thu Feb 18 15:09:50 2021 +0200 spi: spi-ti-qspi: Free DMA resources commit 1d309cd688a76fb733f0089d36dc630327b32d59 upstream. Release the RX channel and free the dma coherent memory when devm_spi_register_master() fails. Fixes: 5720ec0a6d26 ("spi: spi-ti-qspi: Add DMA support for QSPI mmap read") Cc: stable@vger.kernel.org Signed-off-by: Tudor Ambarus Link: https://lore.kernel.org/r/20210218130950.90155-1-tudor.ambarus@microchip.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit e312452b9570e0a186c692da9516aea0f7c094cf Author: Christophe Kerello Date: Mon Apr 19 14:15:39 2021 +0200 spi: stm32-qspi: fix pm_runtime usage_count counter commit 102e9d1936569d43f55dd1ea89be355ad207143c upstream. pm_runtime usage_count counter is not well managed. pm_runtime_put_autosuspend callback drops the usage_counter but this one has never been increased. Add pm_runtime_get_sync callback to bump up the usage counter. It is also needed to use pm_runtime_force_suspend and pm_runtime_force_resume APIs to handle properly the clock. Fixes: 9d282c17b023 ("spi: stm32-qspi: Add pm_runtime support") Signed-off-by: Christophe Kerello Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210419121541.11617-2-patrice.chotard@foss.st.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit aebbc29301b13436a599744b4834a07d9f53ba1d Author: Gao Xiang Date: Mon Mar 29 08:36:14 2021 +0800 erofs: add unsupported inode i_format check commit 24a806d849c0b0c1d0cd6a6b93ba4ae4c0ec9f08 upstream. If any unknown i_format fields are set (may be of some new incompat inode features), mark such inode as unsupported. Just in case of any new incompat i_format fields added in the future. Link: https://lore.kernel.org/r/20210329003614.6583-1-hsiangkao@aol.com Fixes: 431339ba9042 ("staging: erofs: add inode operations") Cc: # 4.19+ Signed-off-by: Gao Xiang Signed-off-by: Greg Kroah-Hartman commit 4d786870e3262ec098a3b4ed10b895176bc66ecb Author: Gustavo A. R. Silva Date: Fri Feb 12 04:40:22 2021 -0600 mtd: physmap: physmap-bt1-rom: Fix unintentional stack access commit 683313993dbe1651c7aa00bb42a041d70e914925 upstream. Cast &data to (char *) in order to avoid unintentionally accessing the stack. Notice that data is of type u32, so any increment to &data will be in the order of 4-byte chunks, and this piece of code is actually intended to be a byte offset. Fixes: b3e79e7682e0 ("mtd: physmap: Add Baikal-T1 physically mapped ROM support") Addresses-Coverity-ID: 1497765 ("Out-of-bounds access") Cc: stable@vger.kernel.org Signed-off-by: Gustavo A. R. Silva Acked-by: Serge Semin Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210212104022.GA242669@embeddedor Signed-off-by: Greg Kroah-Hartman commit 676c4cd75307ca5b4cb15d840a497acc630643f7 Author: Kai Stuhlemmer (ebee Engineering) Date: Mon Mar 22 17:07:14 2021 +0200 mtd: rawnand: atmel: Update ecc_stats.corrected counter commit 33cebf701e98dd12b01d39d1c644387b27c1a627 upstream. Update MTD ECC statistics with the number of corrected bits. Fixes: f88fc122cc34 ("mtd: nand: Cleanup/rework the atmel_nand driver") Cc: stable@vger.kernel.org Signed-off-by: Kai Stuhlemmer (ebee Engineering) Signed-off-by: Tudor Ambarus Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210322150714.101585-1-tudor.ambarus@microchip.com Signed-off-by: Greg Kroah-Hartman commit 60015c2e48bf044fee0057d3728a4f5438e8b2c5 Author: Alexander Lobakin Date: Tue Mar 23 17:37:19 2021 +0000 mtd: spinand: core: add missing MODULE_DEVICE_TABLE() commit 25fefc88c71f47db0466570335e3f75f10952e7a upstream. The module misses MODULE_DEVICE_TABLE() for both SPI and OF ID tables and thus never autoloads on ID matches. Add the missing declarations. Present since day-0 of spinand framework introduction. Fixes: 7529df465248 ("mtd: nand: Add core infrastructure to support SPI NANDs") Cc: stable@vger.kernel.org # 4.19+ Signed-off-by: Alexander Lobakin Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210323173714.317884-1-alobakin@pm.me Signed-off-by: Greg Kroah-Hartman commit d08fcd5794ecfd39aeeacd66790180432ab85b15 Author: Tudor Ambarus Date: Fri Apr 2 11:20:30 2021 +0300 Revert "mtd: spi-nor: macronix: Add support for mx25l51245g" commit 46094049a49be777f12a9589798f7c70b90cd03f upstream. This reverts commit 04b8edad262eec0d153005973dfbdd83423c0dcb. mx25l51245g and mx66l51235l have the same flash ID. The flash detection returns the first entry in the flash_info array that matches the flash ID that was read, thus for the 0xc2201a ID, mx25l51245g was always hit, introducing a regression for mx66l51235l. If one wants to differentiate the flash names, a better fix would be to differentiate between the two at run-time, depending on SFDP, and choose the correct name from a list of flash names, depending on the SFDP differentiator. Fixes: 04b8edad262e ("mtd: spi-nor: macronix: Add support for mx25l51245g") Signed-off-by: Tudor Ambarus Acked-by: Pratyush Yadav Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210402082031.19055-2-tudor.ambarus@microchip.com Signed-off-by: Greg Kroah-Hartman commit e87cc955ca86af0c1e788d21e42f544fef2d06dd Author: Xiang Chen Date: Thu Apr 1 15:34:46 2021 +0800 mtd: spi-nor: core: Fix an issue of releasing resources during read/write commit be94215be1ab19e5d38f50962f611c88d4bfc83a upstream. If rmmod the driver during read or write, the driver will release the resources which are used during read or write, so it is possible to refer to NULL pointer. Use the testcase "mtd_debug read /dev/mtd0 0xc00000 0x400000 dest_file & sleep 0.5;rmmod spi_hisi_sfc_v3xx.ko", the issue can be reproduced in hisi_sfc_v3xx driver. To avoid the issue, fill the interface _get_device and _put_device of mtd_info to grab the reference to the spi controller driver module, so the request of rmmod the driver is rejected before read/write is finished. Fixes: b199489d37b2 ("mtd: spi-nor: add the framework for SPI NOR") Signed-off-by: Xiang Chen Signed-off-by: Yicong Yang Signed-off-by: Tudor Ambarus Tested-by: Michael Walle Tested-by: Tudor Ambarus Reviewed-by: Michael Walle Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/1617262486-4223-1-git-send-email-yangyicong@hisilicon.com Signed-off-by: Greg Kroah-Hartman commit 704550d124f7b135ea6690968390b00db04d6872 Author: Jim Quinlan Date: Fri Apr 30 11:21:54 2021 -0400 reset: add missing empty function reset_control_rearm() commit 48582b2e3b87b794a9845d488af2c76ce055502b upstream. All other functions are defined for when CONFIG_RESET_CONTROLLER is not set. Fixes: 557acb3d2cd9 ("reset: make shared pulsed reset controls re-triggerable") Link: https://lore.kernel.org/r/20210430152156.21162-2-jim2101024@gmail.com Signed-off-by: Jim Quinlan Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org # v5.11+ Signed-off-by: Greg Kroah-Hartman commit f84f08617825b0033809a417b6a8d01b16387888 Author: Davidlohr Bueso Date: Thu May 6 18:04:07 2021 -0700 fs/epoll: restore waking from ep_done_scan() commit 7fab29e356309ff93a4b30ecc466129682ec190b upstream. Commit 339ddb53d373 ("fs/epoll: remove unnecessary wakeups of nested epoll") changed the userspace visible behavior of exclusive waiters blocked on a common epoll descriptor upon a single event becoming ready. Previously, all tasks doing epoll_wait would awake, and now only one is awoken, potentially causing missed wakeups on applications that rely on this behavior, such as Apache Qpid. While the aforementioned commit aims at having only a wakeup single path in ep_poll_callback (with the exceptions of epoll_ctl cases), we need to restore the wakeup in what was the old ep_scan_ready_list() such that the next thread can be awoken, in a cascading style, after the waker's corresponding ep_send_events(). Link: https://lkml.kernel.org/r/20210405231025.33829-3-dave@stgolabs.net Fixes: 339ddb53d373 ("fs/epoll: remove unnecessary wakeups of nested epoll") Signed-off-by: Davidlohr Bueso Cc: Al Viro Cc: Jason Baron Cc: Roman Penyaev Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 3d5e1c964b6bdc3f4a6994a2f8ca6067f38be86b Author: Jeffrey Mitchell Date: Fri Feb 26 15:00:23 2021 -0600 ecryptfs: fix kernel panic with null dev_name commit 9046625511ad8dfbc8c6c2de16b3532c43d68d48 upstream. When mounting eCryptfs, a null "dev_name" argument to ecryptfs_mount() causes a kernel panic if the parsed options are valid. The easiest way to reproduce this is to call mount() from userspace with an existing eCryptfs mount's options and a "source" argument of 0. Error out if "dev_name" is null in ecryptfs_mount() Fixes: 237fead61998 ("[PATCH] ecryptfs: fs/Makefile and fs/Kconfig") Cc: stable@vger.kernel.org Signed-off-by: Jeffrey Mitchell Signed-off-by: Tyler Hicks Signed-off-by: Greg Kroah-Hartman commit 8f1999299af7c6c14b018ea81a82a429c5b67893 Author: Chunfeng Yun Date: Tue Mar 16 17:22:24 2021 +0800 arm64: dts: mt8173: fix property typo of 'phys' in dsi node commit e4e5d030bd779fb8321d3b8bd65406fbe0827037 upstream. Use 'phys' instead of 'phy'. Fixes: 81ad4dbaf7af ("arm64: dts: mt8173: Add display subsystem related nodes") Signed-off-by: Chunfeng Yun Reviewed-by: Chun-Kuang Hu Cc: stable Link: https://lore.kernel.org/r/20210316092232.9806-5-chunfeng.yun@mediatek.com Signed-off-by: Matthias Brugger Signed-off-by: Greg Kroah-Hartman commit 93dbb4f3911087e586827d6c7fc338fcb731769f Author: Marek Behún Date: Thu Jan 14 13:40:23 2021 +0100 arm64: dts: marvell: armada-37xx: add syscon compatible to NB clk node commit 1d88358a89dbac9c7d4559548b9a44840456e6fb upstream. Add "syscon" compatible to the North Bridge clocks node to allow the cpufreq driver to access these registers via syscon API. This is needed for a fix of cpufreq driver. Signed-off-by: Marek Behún Fixes: e8d66e7927b2 ("arm64: dts: marvell: armada-37xx: add nodes...") Cc: stable@vger.kernel.org Cc: Gregory CLEMENT Cc: Miquel Raynal Signed-off-by: Gregory CLEMENT Signed-off-by: Greg Kroah-Hartman commit 578f7183fd1d4d0e2c2a0915ab7a208b0bb38567 Author: Ard Biesheuvel Date: Fri Feb 5 19:23:00 2021 +0100 ARM: 9056/1: decompressor: fix BSS size calculation for LLVM ld.lld commit c4e792d1acce31c2eb7b9193ab06ab94de05bf42 upstream. The LLVM ld.lld linker uses a different symbol type for __bss_start, resulting in the calculation of KBSS_SZ to be thrown off. Up until now, this has gone unnoticed as it only affects the appended DTB case, but pending changes for ARM in the way the decompressed kernel is cleaned from the caches has uncovered this problem. On a ld.lld build: $ nm vmlinux |grep bss_ c1c22034 D __bss_start c1c86e98 B __bss_stop resulting in $ readelf -s arch/arm/boot/compressed/vmlinux | grep bss_size 433: c1c86e98 0 NOTYPE GLOBAL DEFAULT ABS _kernel_bss_size which is obviously incorrect, and may cause the cache clean to access unmapped memory, or cause the size calculation to wrap, resulting in no cache clean to be performed at all. Fix this by updating the sed regex to take D type symbols into account. Link: https://lore.kernel.org/linux-arm-kernel/6c65bcef-d4e7-25fa-43cf-2c435bb61bb9@collabora.com/ Link: https://lore.kernel.org/linux-arm-kernel/20210205085220.31232-1-ardb@kernel.org/ Cc: # v4.19+ Reviewed-by: Nick Desaulniers Tested-by: Nick Desaulniers Reported-by: Guillaume Tucker Reported-by: "kernelci.org bot" Signed-off-by: Ard Biesheuvel Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit cdd107d7f18158d966c2bc136204fe826dac445c Author: Steven Rostedt (VMware) Date: Wed May 5 10:38:24 2021 -0400 ftrace: Handle commands when closing set_ftrace_filter file commit 8c9af478c06bb1ab1422f90d8ecbc53defd44bc3 upstream. # echo switch_mm:traceoff > /sys/kernel/tracing/set_ftrace_filter will cause switch_mm to stop tracing by the traceoff command. # echo -n switch_mm:traceoff > /sys/kernel/tracing/set_ftrace_filter does nothing. The reason is that the parsing in the write function only processes commands if it finished parsing (there is white space written after the command). That's to handle: write(fd, "switch_mm:", 10); write(fd, "traceoff", 8); cases, where the command is broken over multiple writes. The problem is if the file descriptor is closed, then the write call is not processed, and the command needs to be processed in the release code. The release code can handle matching of functions, but does not handle commands. Cc: stable@vger.kernel.org Fixes: eda1e32855656 ("tracing: handle broken names in ftrace filter") Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit b5e5faf8f60709c7032d9e51c9806330a8536c65 Author: Mark Langsdorf Date: Tue Apr 27 13:54:33 2021 -0500 ACPI: custom_method: fix a possible memory leak commit 1cfd8956437f842836e8a066b40d1ec2fc01f13e upstream. In cm_write(), if the 'buf' is allocated memory but not fully consumed, it is possible to reallocate the buffer without freeing it by passing '*ppos' as 0 on a subsequent call. Add an explicit kfree() before kzalloc() to prevent the possible memory leak. Fixes: 526b4af47f44 ("ACPI: Split out custom_method functionality into an own driver") Signed-off-by: Mark Langsdorf Cc: 5.4+ # 5.4+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit b7a5baaae212a686ceb812c32fceed79c03c0234 Author: Mark Langsdorf Date: Fri Apr 23 10:28:17 2021 -0500 ACPI: custom_method: fix potential use-after-free issue commit e483bb9a991bdae29a0caa4b3a6d002c968f94aa upstream. In cm_write(), buf is always freed when reaching the end of the function. If the requested count is less than table.length, the allocated buffer will be freed but subsequent calls to cm_write() will still try to access it. Remove the unconditional kfree(buf) at the end of the function and set the buf to NULL in the -EINVAL error path to match the rest of function. Fixes: 03d1571d9513 ("ACPI: custom_method: fix memory leaks") Signed-off-by: Mark Langsdorf Cc: 5.4+ # 5.4+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit a9571131d8899438095c88940b69601ced7c7df1 Author: Stefan Berger Date: Wed Mar 10 17:19:15 2021 -0500 tpm: acpi: Check eventlog signature before using it commit 3dcd15665aca80197333500a4be3900948afccc1 upstream. Check the eventlog signature before using it. This avoids using an empty log, as may be the case when QEMU created the ACPI tables, rather than probing the EFI log next. This resolves an issue where the EFI log was empty since an empty ACPI log was used. Cc: stable@vger.kernel.org Fixes: 85467f63a05c ("tpm: Add support for event log pointer found in TPM2 ACPI table") Signed-off-by: Stefan Berger Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit 93dbbf20e3ffad14f04227a0b7105f6e6f0387ce Author: Jason Wang Date: Tue Apr 13 17:15:57 2021 +0800 vhost-vdpa: fix vm_flags for virtqueue doorbell mapping commit 3a3e0fad16d40a2aa68ddf7eea4acdf48b22dd44 upstream. The virtqueue doorbell is usually implemented via registeres but we don't provide the necessary vma->flags like VM_PFNMAP. This may cause several issues e.g when userspace tries to map the doorbell via vhost IOTLB, kernel may panic due to the page is not backed by page structure. This patch fixes this by setting the necessary vm_flags. With this patch, try to map doorbell via IOTLB will fail with bad address. Cc: stable@vger.kernel.org Fixes: ddd89d0a059d ("vhost_vdpa: support doorbell mapping via mmap") Signed-off-by: Jason Wang Link: https://lore.kernel.org/r/20210413091557.29008-1-jasowang@redhat.com Signed-off-by: Michael S. Tsirkin Signed-off-by: Greg Kroah-Hartman commit 5b6e6498e9b9e3605d5eeb83307f04197d0bd936 Author: Vineeth Vijayan Date: Fri Apr 23 12:08:43 2021 +0200 s390/cio: remove invalid condition on IO_SCH_UNREG commit 2f7484fd73729f89085fe08d683f5a8d9e17fe99 upstream. The condition to check the cdev pointer validity on css_sch_device_unregister() is a leftover from the 'commit 8cc0dcfdc1c0 ("s390/cio: remove pm support from ccw bus driver")'. This could lead to a situation, where detaching the device is not happening completely. Remove this invalid condition in the IO_SCH_UNREG case. Link: https://lore.kernel.org/r/20210423100843.2230969-1-vneethv@linux.ibm.com Fixes: 8cc0dcfdc1c0 ("s390/cio: remove pm support from ccw bus driver") Reported-by: Christian Ehrhardt Suggested-by: Christian Ehrhardt Cc: Signed-off-by: Vineeth Vijayan Tested-by: Julian Wiedmann Reviewed-by: Peter Oberparleiter Tested-by: Christian Ehrhardt Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit 32bff908a7c15b075510be580e598a9a83babd05 Author: Tony Krowiak Date: Thu Mar 25 08:46:40 2021 -0400 s390/vfio-ap: fix circular lockdep when setting/clearing crypto masks commit 0cc00c8d40500c4c8fe058dc014bdaf44a82f4f7 upstream. This patch fixes a lockdep splat introduced by commit f21916ec4826 ("s390/vfio-ap: clean up vfio_ap resources when KVM pointer invalidated"). The lockdep splat only occurs when starting a Secure Execution guest. Crypto virtualization (vfio_ap) is not yet supported for SE guests; however, in order to avoid this problem when support becomes available, this fix is being provided. The circular locking dependency was introduced when the setting of the masks in the guest's APCB was executed while holding the matrix_dev->lock. While the lock is definitely needed to protect the setting/unsetting of the matrix_mdev->kvm pointer, it is not necessarily critical for setting the masks; so, the matrix_dev->lock will be released while the masks are being set or cleared. Keep in mind, however, that another process that takes the matrix_dev->lock can get control while the masks in the guest's APCB are being set or cleared as a result of the driver being notified that the KVM pointer has been set or unset. This could result in invalid access to the matrix_mdev->kvm pointer by the intervening process. To avoid this scenario, two new fields are being added to the ap_matrix_mdev struct: struct ap_matrix_mdev { ... bool kvm_busy; wait_queue_head_t wait_for_kvm; ... }; The functions that handle notification that the KVM pointer value has been set or cleared will set the kvm_busy flag to true until they are done processing at which time they will set it to false and wake up the tasks on the matrix_mdev->wait_for_kvm wait queue. Functions that require access to matrix_mdev->kvm will sleep on the wait queue until they are awakened at which time they can safely access the matrix_mdev->kvm field. Fixes: f21916ec4826 ("s390/vfio-ap: clean up vfio_ap resources when KVM pointer invalidated") Cc: stable@vger.kernel.org Signed-off-by: Tony Krowiak Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit 971dc8706cee47393d393905d294ea47e39503d3 Author: Harald Freudenberger Date: Thu Apr 15 11:22:03 2021 +0200 s390/zcrypt: fix zcard and zqueue hot-unplug memleak commit 70fac8088cfad9f3b379c9082832b4d7532c16c2 upstream. Tests with kvm and a kmemdebug kernel showed, that on hot unplug the zcard and zqueue structs for the unplugged card or queue are not properly freed because of a mismatch with get/put for the embedded kref counter. This fix now adjusts the handling of the kref counters. With init the kref counter starts with 1. This initial value needs to drop to zero with the unregister of the card or queue to trigger the release and free the object. Fixes: 29c2680fd2bf ("s390/ap: fix ap devices reference counting") Reported-by: Marc Hartmayer Signed-off-by: Harald Freudenberger Cc: stable@vger.kernel.org Reviewed-by: Julian Wiedmann Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit aa34d125b8d241faf292a722f04ef289de7ce192 Author: Vasily Gorbik Date: Tue Apr 20 11:04:10 2021 +0200 s390/disassembler: increase ebpf disasm buffer size commit 6f3353c2d2b3eb4de52e9704cb962712033db181 upstream. Current ebpf disassembly buffer size of 64 is too small. E.g. this line takes 65 bytes: 01fffff8005822e: ec8100ed8065\tclgrj\t%r8,%r1,8,001fffff80058408\n\0 Double the buffer size like it is done for the kernel disassembly buffer. Fixes the following KASAN finding: UG: KASAN: stack-out-of-bounds in print_fn_code+0x34c/0x380 Write of size 1 at addr 001fff800ad5f970 by task test_progs/853 CPU: 53 PID: 853 Comm: test_progs Not tainted 5.12.0-rc7-23786-g23457d86b1f0-dirty #19 Hardware name: IBM 3906 M04 704 (LPAR) Call Trace: [<0000000cd8e0538a>] show_stack+0x17a/0x1668 [<0000000cd8e2a5d8>] dump_stack+0x140/0x1b8 [<0000000cd8e16e74>] print_address_description.constprop.0+0x54/0x260 [<0000000cd75a8698>] kasan_report+0xc8/0x130 [<0000000cd6e26da4>] print_fn_code+0x34c/0x380 [<0000000cd6ea0f4e>] bpf_int_jit_compile+0xe3e/0xe58 [<0000000cd72c4c88>] bpf_prog_select_runtime+0x5b8/0x9c0 [<0000000cd72d1bf8>] bpf_prog_load+0xa78/0x19c0 [<0000000cd72d7ad6>] __do_sys_bpf.part.0+0x18e/0x768 [<0000000cd6e0f392>] do_syscall+0x12a/0x220 [<0000000cd8e333f8>] __do_syscall+0x98/0xc8 [<0000000cd8e54834>] system_call+0x6c/0x94 1 lock held by test_progs/853: #0: 0000000cd9bf7460 (report_lock){....}-{2:2}, at: kasan_report+0x96/0x130 addr 001fff800ad5f970 is located in stack of task test_progs/853 at offset 96 in frame: print_fn_code+0x0/0x380 this frame has 1 object: [32, 96) 'buffer' Memory state around the buggy address: 001fff800ad5f800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 001fff800ad5f880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >001fff800ad5f900: 00 00 f1 f1 f1 f1 00 00 00 00 00 00 00 00 f3 f3 ^ 001fff800ad5f980: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 001fff800ad5fa00: 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00 00 Cc: Reviewed-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit bea198f467262884f9fa320e1b325181d04144c2 Author: Shuo Chen Date: Wed Apr 14 14:24:00 2021 -0700 dyndbg: fix parsing file query without a line-range suffix commit 7b1ae248279bea33af9e797a93c35f49601cb8a0 upstream. Query like 'file tcp_input.c line 1234 +p' was broken by commit aaebe329bff0 ("dyndbg: accept 'file foo.c:func1' and 'file foo.c:10-100'") because a file name without a ':' now makes the loop in ddebug_parse_query() exits early before parsing the 'line 1234' part. As a result, all pr_debug() in tcp_input.c will be enabled, instead of only the one on line 1234. Changing 'break' to 'continue' fixes this. Fixes: aaebe329bff0 ("dyndbg: accept 'file foo.c:func1' and 'file foo.c:10-100'") Cc: stable Reviewed-by: Eric Dumazet Signed-off-by: Shuo Chen Acked-by: Jason Baron Link: https://lore.kernel.org/r/20210414212400.2927281-1-giantchen@gmail.com Signed-off-by: Greg Kroah-Hartman commit 3494c68d79cbb7ddff88fd35e0796343ef736606 Author: Mathias Krause Date: Thu Apr 29 19:59:41 2021 +0300 nitro_enclaves: Fix stale file descriptors on failed usercopy commit f1ce3986baa62cffc3c5be156994de87524bab99 upstream. A failing usercopy of the slot uid will lead to a stale entry in the file descriptor table as put_unused_fd() won't release it. This enables userland to refer to a dangling 'file' object through that still valid file descriptor, leading to all kinds of use-after-free exploitation scenarios. Exchanging put_unused_fd() for close_fd(), ksys_close() or alike won't solve the underlying issue, as the file descriptor might have been replaced in the meantime, e.g. via userland calling close() on it (leading to a NULL pointer dereference in the error handling code as 'fget(enclave_fd)' will return a NULL pointer) or by dup2()'ing a completely different file object to that very file descriptor, leading to the same situation: a dangling file descriptor pointing to a freed object -- just in this case to a file object of user's choosing. Generally speaking, after the call to fd_install() the file descriptor is live and userland is free to do whatever with it. We cannot rely on it to still refer to our enclave object afterwards. In fact, by abusing userfaultfd() userland can hit the condition without any racing and abuse the error handling in the nitro code as it pleases. To fix the above issues, defer the call to fd_install() until all possible errors are handled. In this case it's just the usercopy, so do it directly in ne_create_vm_ioctl() itself. Signed-off-by: Mathias Krause Signed-off-by: Andra Paraschiv Cc: stable Link: https://lore.kernel.org/r/20210429165941.27020-2-andraprs@amazon.com Signed-off-by: Greg Kroah-Hartman commit a99b661c3187365f81026d89b1133a76cd2652b3 Author: Loic Poulain Date: Fri Feb 26 11:53:02 2021 +0100 bus: mhi: core: Fix invalid error returning in mhi_queue commit 0ecc1c70dcd32c0f081b173a1a5d89952686f271 upstream. mhi_queue returns an error when the doorbell is not accessible in the current state. This can happen when the device is in non M0 state, like M3, and needs to be waken-up prior ringing the DB. This case is managed earlier by triggering an asynchronous M3 exit via controller resume/suspend callbacks, that in turn will cause M0 transition and DB update. So, since it's not an error but just delaying of doorbell update, there is no reason to return an error. This also fixes a use after free error for skb case, indeed a caller queuing skb will try to free the skb if the queueing fails, but in that case queueing has been done. Fixes: a8f75cb348fd ("mhi: core: Factorize mhi queuing") Signed-off-by: Loic Poulain Reviewed-by: Jeffrey Hugo Reviewed-by: Bhaumik Bhatt Reviewed-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/1614336782-5809-1-git-send-email-loic.poulain@linaro.org Signed-off-by: Manivannan Sadhasivam Signed-off-by: Greg Kroah-Hartman commit 1c1b5a437fc7d0f0d7a4e0dee53d998fece4986a Author: Loic Poulain Date: Tue Apr 6 11:11:54 2021 +0200 bus: mhi: core: Fix MHI runtime_pm behavior commit 4547a749be997eb12ea7edcf361ec2a5329f7aec upstream. This change ensures that PM reference is always get during packet queueing and released either after queuing completion (RX) or once the buffer has been consumed (TX). This guarantees proper update for underlying MHI controller runtime status (e.g. last_busy timestamp) and prevents suspend to be triggered while TX packets are flying, or before we completed update of the RX ring. Signed-off-by: Loic Poulain Reviewed-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/1617700315-12492-1-git-send-email-loic.poulain@linaro.org Signed-off-by: Manivannan Sadhasivam Signed-off-by: Greg Kroah-Hartman commit ed541cff35cbdb695f0c98ef506dd7218883fc07 Author: Loic Poulain Date: Wed Feb 24 11:18:50 2021 +0100 bus: mhi: pci_generic: Remove WQ_MEM_RECLAIM flag from state workqueue commit 0fccbf0a3b690b162f53b13ed8bc442ea33437dc upstream. A recent change created a dedicated workqueue for the state-change work with WQ_HIGHPRI (no strong reason for that) and WQ_MEM_RECLAIM flags, but the state-change work (mhi_pm_st_worker) does not guarantee forward progress under memory pressure, and will even wait on various memory allocations when e.g. creating devices, loading firmware, etc... The work is then not part of a memory reclaim path... Moreover, this causes a warning in check_flush_dependency() since we end up in code that flushes a non-reclaim workqueue: [ 40.969601] workqueue: WQ_MEM_RECLAIM mhi_hiprio_wq:mhi_pm_st_worker [mhi] is flushing !WQ_MEM_RECLAIM events_highpri:flush_backlog [ 40.969612] WARNING: CPU: 4 PID: 158 at kernel/workqueue.c:2607 check_flush_dependency+0x11c/0x140 [ 40.969733] Call Trace: [ 40.969740] __flush_work+0x97/0x1d0 [ 40.969745] ? wake_up_process+0x15/0x20 [ 40.969749] ? insert_work+0x70/0x80 [ 40.969750] ? __queue_work+0x14a/0x3e0 [ 40.969753] flush_work+0x10/0x20 [ 40.969756] rollback_registered_many+0x1c9/0x510 [ 40.969759] unregister_netdevice_queue+0x94/0x120 [ 40.969761] unregister_netdev+0x1d/0x30 [ 40.969765] mhi_net_remove+0x1a/0x40 [mhi_net] [ 40.969770] mhi_driver_remove+0x124/0x250 [mhi] [ 40.969776] device_release_driver_internal+0xf0/0x1d0 [ 40.969778] device_release_driver+0x12/0x20 [ 40.969782] bus_remove_device+0xe1/0x150 [ 40.969786] device_del+0x17b/0x3e0 [ 40.969791] mhi_destroy_device+0x9a/0x100 [mhi] [ 40.969796] ? mhi_unmap_single_use_bb+0x50/0x50 [mhi] [ 40.969799] device_for_each_child+0x5e/0xa0 [ 40.969804] mhi_pm_st_worker+0x921/0xf50 [mhi] Fixes: 8f7039787687 ("bus: mhi: core: Move to using high priority workqueue") Signed-off-by: Loic Poulain Reviewed-by: Bhaumik Bhatt Reviewed-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/1614161930-8513-1-git-send-email-loic.poulain@linaro.org Signed-off-by: Manivannan Sadhasivam Signed-off-by: Greg Kroah-Hartman commit 1ec103ea8684e5ae632ed5dce878332987f7475c Author: Bhaumik Bhatt Date: Tue Mar 9 10:44:50 2021 -0800 bus: mhi: core: Add missing checks for MMIO register entries commit 8de5ad99414347ad08e6ebc2260be1d2e009cb9a upstream. As per documentation, fields marked as (required) in an MHI controller structure need to be populated by the controller driver before calling mhi_register_controller(). Ensure all required pointers and non-zero fields are present in the controller before proceeding with the registration. Signed-off-by: Bhaumik Bhatt Reviewed-by: Jeffrey Hugo Reviewed-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/1615315490-36017-1-git-send-email-bbhatt@codeaurora.org Signed-off-by: Manivannan Sadhasivam Signed-off-by: Greg Kroah-Hartman commit 76879a980cd5ede4cb9a638999fb80d37bc09db5 Author: Jeffrey Hugo Date: Wed Mar 10 14:30:55 2021 -0700 bus: mhi: core: Sanity check values from remote device before use commit ec32332df7645e0ba463a08d483fe97665167071 upstream. When parsing the structures in the shared memory, there are values which come from the remote device. For example, a transfer completion event will have a pointer to the tre in the relevant channel's transfer ring. As another example, event ring elements may specify a channel in which the event occurred, however the specified channel value may not be valid as no channel is defined at that index even though the index may be less than the maximum allowed index. Such values should be considered to be untrusted, and validated before use. If we blindly use such values, we may access invalid data or crash if the values are corrupted. If validation fails, drop the relevant event. Signed-off-by: Jeffrey Hugo Reviewed-by: Manivannan Sadhasivam Reviewed-by: Hemant Kumar Link: https://lore.kernel.org/r/1615411855-15053-1-git-send-email-jhugo@codeaurora.org Signed-off-by: Manivannan Sadhasivam Signed-off-by: Greg Kroah-Hartman commit 1b43b43170c7b24e9249c2ba2db7214a2f6b1f2f Author: Bhaumik Bhatt Date: Thu Apr 1 14:16:15 2021 -0700 bus: mhi: core: Clear configuration from channel context during reset commit 47705c08465931923e2f2b506986ca0bdf80380d upstream. When clearing up the channel context after client drivers are done using channels, the configuration is currently not being reset entirely. Ensure this is done to appropriately handle issues where clients unaware of the context state end up calling functions which expect a context. Signed-off-by: Bhaumik Bhatt Reviewed-by: Hemant Kumar Reviewed-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/1617311778-1254-7-git-send-email-bbhatt@codeaurora.org Signed-off-by: Manivannan Sadhasivam Signed-off-by: Greg Kroah-Hartman commit 99b8f10d0216c6006cab3b24811f9e96936ce549 Author: Jeffrey Hugo Date: Fri Feb 12 14:27:23 2021 -0700 bus: mhi: core: Fix check for syserr at power_up commit 6403298c58d4858d93648f553abf0bcbd2dfaca2 upstream. The check to see if we have reset the device after detecting syserr at power_up is inverted. wait_for_event_timeout() returns 0 on failure, and a positive value on success. The check is looking for non-zero as a failure, which is likely to incorrectly cause a device init failure if syserr was detected at power_up. Fix this. Fixes: e18d4e9fa79b ("bus: mhi: core: Handle syserr during power_up") Signed-off-by: Jeffrey Hugo Reviewed-by: Loic Poulain Reviewed-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/1613165243-23359-1-git-send-email-jhugo@codeaurora.org Signed-off-by: Manivannan Sadhasivam Signed-off-by: Greg Kroah-Hartman