commit 560ed1386571c54598065fb9e80ff54855e2236d Author: Greg Kroah-Hartman Date: Wed Sep 4 13:30:16 2024 +0200 Linux 6.10.8 Link: https://lore.kernel.org/r/20240901160817.461957599@linuxfoundation.org Tested-by: Ronald Warsow Tested-by: Pavel Machek (CIP) Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Jon Hunter Tested-by: Mark Brown Tested-by: Florian Fainelli Tested-by: Salvatore Bonaccorso Signed-off-by: Greg Kroah-Hartman commit 1b46a871e980e3daa16fd5e77539966492e8910a Author: NeilBrown Date: Thu Aug 29 09:06:28 2024 +1000 nfsd: fix nfsd4_deleg_getattr_conflict in presence of third party lease [ Upstream commit 40927f3d0972bf86357a32a5749be71a551241b6 ] It is not safe to dereference fl->c.flc_owner without first confirming fl->fl_lmops is the expected manager. nfsd4_deleg_getattr_conflict() tests fl_lmops but largely ignores the result and assumes that flc_owner is an nfs4_delegation anyway. This is wrong. With this patch we restore the "!= &nfsd_lease_mng_ops" case to behave as it did before the change mentioned below. This is the same as the current code, but without any reference to a possible delegation. Fixes: c5967721e106 ("NFSD: handle GETATTR conflict with write delegation") Signed-off-by: NeilBrown Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit dbec7640c80cbc59fe3a1d7f075ce364f93ea9d4 Author: Guenter Roeck Date: Thu Aug 8 08:50:03 2024 -0700 apparmor: fix policy_unpack_test on big endian systems [ Upstream commit 98c0cc48e27e9d269a3e4db2acd72b486c88ec77 ] policy_unpack_test fails on big endian systems because data byte order is expected to be little endian but is generated in host byte order. This results in test failures such as: # policy_unpack_test_unpack_array_with_null_name: EXPECTATION FAILED at security/apparmor/policy_unpack_test.c:150 Expected array_size == (u16)16, but array_size == 4096 (0x1000) (u16)16 == 16 (0x10) # policy_unpack_test_unpack_array_with_null_name: pass:0 fail:1 skip:0 total:1 not ok 3 policy_unpack_test_unpack_array_with_null_name # policy_unpack_test_unpack_array_with_name: EXPECTATION FAILED at security/apparmor/policy_unpack_test.c:164 Expected array_size == (u16)16, but array_size == 4096 (0x1000) (u16)16 == 16 (0x10) # policy_unpack_test_unpack_array_with_name: pass:0 fail:1 skip:0 total:1 Add the missing endianness conversions when generating test data. Fixes: 4d944bcd4e73 ("apparmor: add AppArmor KUnit tests for policy unpack") Cc: Brendan Higgins Cc: Kees Cook Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 4b540ec7c0045c2d01c4e479f34bbc8f147afa4c Author: Ben Hutchings Date: Thu Aug 22 00:51:42 2024 +0200 scsi: aacraid: Fix double-free on probe failure [ Upstream commit 919ddf8336f0b84c0453bac583808c9f165a85c2 ] aac_probe_one() calls hardware-specific init functions through the aac_driver_ident::init pointer, all of which eventually call down to aac_init_adapter(). If aac_init_adapter() fails after allocating memory for aac_dev::queues, it frees the memory but does not clear that member. After the hardware-specific init function returns an error, aac_probe_one() goes down an error path that frees the memory pointed to by aac_dev::queues, resulting.in a double-free. Reported-by: Michael Gordon Link: https://bugs.debian.org/1075855 Fixes: 8e0c5ebde82b ("[SCSI] aacraid: Newer adapter communication iterface support") Signed-off-by: Ben Hutchings Link: https://lore.kernel.org/r/ZsZvfqlQMveoL5KQ@decadent.org.uk Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit c9bcc056ec11f53985a6111f078bf7c0d5f66752 Author: Steve Wilkins Date: Fri Aug 9 14:47:44 2024 +0100 firmware: microchip: fix incorrect error report of programming:timeout on success [ Upstream commit 591940e22e287fb64ac07be275e343d860cb72d6 ] After successfully programming the SPI flash with an MFPS auto update image, the error sysfs attribute reports programming:timeout. This is caused by an incorrect check on the return value from wait_for_completion_timeout() in mpfs_auto_update_poll_complete(). Fixes: ec5b0f1193ad ("firmware: microchip: add PolarFire SoC Auto Update support") Signed-off-by: Steve Wilkins Signed-off-by: Conor Dooley Signed-off-by: Sasha Levin commit ac36a8178b6b67aeef6933b6e5f7be5f20625804 Author: Markus Niebel Date: Wed Jul 24 14:58:52 2024 +0200 arm64: dts: freescale: imx93-tqma9352-mba93xxla: fix typo [ Upstream commit 5f0a894bfa3c26ce61deda4c52b12e8ec84d876a ] Fix typo in assignment of SD-Card cd-gpios. Fixes: c982ecfa7992 ("arm64: dts: freescale: add initial device tree for MBa93xxLA SBC board") Signed-off-by: Markus Niebel Signed-off-by: Alexander Stein Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 823c2fe4bc318d9ad77df4f61cbea590ddf254e3 Author: Markus Niebel Date: Wed Jul 24 14:58:48 2024 +0200 arm64: dts: freescale: imx93-tqma9352: fix CMA alloc-ranges [ Upstream commit cd0c6872aab4d2c556a5e953e6926a1b4485e543 ] DRAM starts at 0x80000000. Fixes: c982ecfa7992 ("arm64: dts: freescale: add initial device tree for MBa93xxLA SBC board") Signed-off-by: Markus Niebel Signed-off-by: Alexander Stein Reviewed-by: Peng Fan Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 518581361fbb85f7cfc7e4accf07405719846d3d Author: Shenwei Wang Date: Mon Jul 15 08:17:22 2024 -0500 arm64: dts: imx93: update default value for snps,clk-csr [ Upstream commit 109f256285dd6a5f8c3bd0d80d39b2ccd4fe314e ] For the i.MX93 SoC, the default clock rate for the IP of STMMAC EQOS is 312.5 MHz. According to the following mapping table from the i.MX93 reference manual, this clock rate corresponds to a CSR value of 6. 0000: CSR clock = 60-100 MHz; MDC clock = CSR clock/42 0001: CSR clock = 100-150 MHz; MDC clock = CSR clock/62 0010: CSR clock = 20-35 MHz; MDC clock = CSR clock/16 0011: CSR clock = 35-60 MHz; MDC clock = CSR clock/26 0100: CSR clock = 150-250 MHz; MDC clock = CSR clock/102 0101: CSR clock = 250-300 MHz; MDC clock = CSR clock/124 0110: CSR clock = 300-500 MHz; MDC clock = CSR clock/204 0111: CSR clock = 500-800 MHz; MDC clock = CSR clock/324 Fixes: f2d03ba997cb ("arm64: dts: imx93: reorder device nodes") Signed-off-by: Shenwei Wang Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit ee0eb25a344e3f03d8036490cbcef1432f9a2ad5 Author: Adam Ford Date: Sun Jul 14 12:20:17 2024 -0500 arm64: dts: imx8mp-beacon-kit: Fix Stereo Audio on WM8962 [ Upstream commit 4e69cd835a2d5c3915838491f59a68ee697a87d0 ] The L/R clock needs to be controlled by the SAI3 instead of the CODEC to properly achieve stereo sound. Doing this allows removes the need for unnecessary clock manipulation to try to get the CODEC's clock in sync with the SAI3 clock, since the CODEC can cope with a wide variety of clock inputs. Fixes: 161af16c18f3 ("arm64: dts: imx8mp-beacon-kit: Fix audio_pll2 clock") Fixes: 69e2f37a6ddc ("arm64: dts: imx8mp-beacon-kit: Enable WM8962 Audio CODEC") Signed-off-by: Adam Ford Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 954534c39b7772d8b5c3441935c554b6a359f4b5 Author: Sicelo A. Mhlongo Date: Mon Jul 22 13:31:11 2024 +0200 ARM: dts: omap3-n900: correct the accelerometer orientation [ Upstream commit 5062d9c0cbbc202e495e9b20f147f64ef5cc2897 ] Negate the values reported for the accelerometer z-axis in order to match Documentation/devicetree/bindings/iio/mount-matrix.txt. Fixes: 14a213dcb004 ("ARM: dts: n900: use iio driver for accelerometer") Signed-off-by: Sicelo A. Mhlongo Reviewed-By: Andreas Kemnade Link: https://lore.kernel.org/r/20240722113137.3240847-1-absicsz@gmail.com Signed-off-by: Kevin Hilman Signed-off-by: Sasha Levin commit 610466d175c5c94874d0f5a691cc01f34849ad68 Author: Varadarajan Narayanan Date: Tue Jul 23 15:31:51 2024 +0530 arm64: dts: qcom: ipq5332: Fix interrupt trigger type for usb [ Upstream commit 60a76f7826b88ebf7697a56fdcd9596b23c2b616 ] Trigger type is incorrectly specified as IRQ_TYPE_EDGE_BOTH instead of IRQ_TYPE_LEVEL_HIGH. This trigger type is not supported for SPIs and results in probe failure with -EINVAL. Reviewed-by: Konrad Dybcio Fixes: 927173bf8a0e ("arm64: dts: qcom: Add missing interrupts for qcs404/ipq5332") Signed-off-by: Varadarajan Narayanan Link: https://lore.kernel.org/r/20240723100151.402300-3-quic_varada@quicinc.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 095b0001aefddcd9361097c971b7debc84e72714 Author: Bjorn Andersson Date: Tue Aug 20 13:29:31 2024 -0700 usb: typec: ucsi: Move unregister out of atomic section commit 11bb2ffb679399f99041540cf662409905179e3a upstream. Commit '9329933699b3 ("soc: qcom: pmic_glink: Make client-lock non-sleeping")' moved the pmic_glink client list under a spinlock, as it is accessed by the rpmsg/glink callback, which in turn is invoked from IRQ context. This means that ucsi_unregister() is now called from atomic context, which isn't feasible as it's expecting a sleepable context. An effort is under way to get GLINK to invoke its callbacks in a sleepable context, but until then lets schedule the unregistration. A side effect of this is that ucsi_unregister() can now happen after the remote processor, and thereby the communication link with it, is gone. pmic_glink_send() is amended with a check to avoid the resulting NULL pointer dereference. This does however result in the user being informed about this error by the following entry in the kernel log: ucsi_glink.pmic_glink_ucsi pmic_glink.ucsi.0: failed to send UCSI write request: -5 Fixes: 9329933699b3 ("soc: qcom: pmic_glink: Make client-lock non-sleeping") Cc: stable@vger.kernel.org Reviewed-by: Heikki Krogerus Reviewed-by: Neil Armstrong Reviewed-by: Dmitry Baryshkov Tested-by: Amit Pundir Reviewed-by: Johan Hovold Tested-by: Johan Hovold Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20240820-pmic-glink-v6-11-races-v3-2-eec53c750a04@quicinc.com Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit 7b17e37345e88b51d38e4d925226a40048c6fd4e Author: Pawel Laszczak Date: Wed Aug 21 06:07:42 2024 +0000 usb: cdnsp: fix for Link TRB with TC commit 740f2e2791b98e47288b3814c83a3f566518fed2 upstream. Stop Endpoint command on LINK TRB with TC bit set to 1 causes that internal cycle bit can have incorrect state after command complete. In consequence empty transfer ring can be incorrectly detected when EP is resumed. NOP TRB before LINK TRB avoid such scenario. Stop Endpoint command is then on NOP TRB and internal cycle bit is not changed and have correct value. Fixes: 3d82904559f4 ("usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD Driver") cc: Signed-off-by: Pawel Laszczak Reviewed-by: Peter Chen Link: https://lore.kernel.org/r/PH7PR07MB953878279F375CCCE6C6F40FDD8E2@PH7PR07MB9538.namprd07.prod.outlook.com Signed-off-by: Greg Kroah-Hartman commit c26d0f772cdb08be4f221fd496340181ec717e17 Author: Pawel Laszczak Date: Tue Aug 20 08:21:19 2024 +0000 usb: cdnsp: fix incorrect index in cdnsp_get_hw_deq function commit 0497a356d3c498221eb0c1edc1e8985816092f12 upstream. Patch fixes the incorrect "stream_id" table index instead of "ep_index" used in cdnsp_get_hw_deq function. Fixes: 3d82904559f4 ("usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD Driver") cc: stable@vger.kernel.org Signed-off-by: Pawel Laszczak Reviewed-by: Peter Chen Link: https://lore.kernel.org/r/PH7PR07MB95381F2182688811D5C711CEDD8D2@PH7PR07MB9538.namprd07.prod.outlook.com Signed-off-by: Greg Kroah-Hartman commit f6ce7ffadd74755d3be3be75d5b2aa506289efa1 Author: Zijun Hu Date: Tue Aug 20 19:01:27 2024 +0800 usb: core: sysfs: Unmerge @usb3_hardware_lpm_attr_group in remove_power_attributes() commit 3a8839bbb86da7968a792123ed2296d063871a52 upstream. Device attribute group @usb3_hardware_lpm_attr_group is merged by add_power_attributes(), but it is not unmerged explicitly, fixed by unmerging it in remove_power_attributes(). Fixes: 655fe4effe0f ("usbcore: add sysfs support to xHCI usb3 hardware LPM") Cc: stable@vger.kernel.org Signed-off-by: Zijun Hu Link: https://lore.kernel.org/r/20240820-sysfs_fix-v2-1-a9441487077e@quicinc.com Signed-off-by: Greg Kroah-Hartman commit 9b7fc7da7fac2eae1b73b5cdfdc93cbd4bc75f82 Author: Krzysztof Kozlowski Date: Wed Aug 14 11:39:57 2024 +0200 usb: dwc3: st: add missing depopulate in probe error path commit cd4897bfd14f6a5388b21ba45a066541a0425199 upstream. Depopulate device in probe error paths to fix leak of children resources. Fixes: f83fca0707c6 ("usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC") Cc: stable@vger.kernel.org Signed-off-by: Krzysztof Kozlowski Reviewed-by: Patrice Chotard Acked-by: Thinh Nguyen Link: https://lore.kernel.org/r/20240814093957.37940-2-krzysztof.kozlowski@linaro.org Signed-off-by: Greg Kroah-Hartman commit 1de989668708ce5875efc9d669d227212aeb9a90 Author: Krzysztof Kozlowski Date: Wed Aug 14 11:39:56 2024 +0200 usb: dwc3: st: fix probed platform device ref count on probe error path commit ddfcfeba891064b88bb844208b43bef2ef970f0c upstream. The probe function never performs any paltform device allocation, thus error path "undo_platform_dev_alloc" is entirely bogus. It drops the reference count from the platform device being probed. If error path is triggered, this will lead to unbalanced device reference counts and premature release of device resources, thus possible use-after-free when releasing remaining devm-managed resources. Fixes: f83fca0707c6 ("usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC") Cc: stable@vger.kernel.org Signed-off-by: Krzysztof Kozlowski Acked-by: Thinh Nguyen Reviewed-by: Patrice Chotard Link: https://lore.kernel.org/r/20240814093957.37940-1-krzysztof.kozlowski@linaro.org Signed-off-by: Greg Kroah-Hartman commit e23f6ad8d110bf632f7471482e10b43dc174fb72 Author: Selvarasu Ganesan Date: Thu Aug 15 12:18:31 2024 +0530 usb: dwc3: core: Prevent USB core invalid event buffer address access commit 14e497183df28c006603cc67fd3797a537eef7b9 upstream. This commit addresses an issue where the USB core could access an invalid event buffer address during runtime suspend, potentially causing SMMU faults and other memory issues in Exynos platforms. The problem arises from the following sequence. 1. In dwc3_gadget_suspend, there is a chance of a timeout when moving the USB core to the halt state after clearing the run/stop bit by software. 2. In dwc3_core_exit, the event buffer is cleared regardless of the USB core's status, which may lead to an SMMU faults and other memory issues. if the USB core tries to access the event buffer address. To prevent this hardware quirk on Exynos platforms, this commit ensures that the event buffer address is not cleared by software when the USB core is active during runtime suspend by checking its status before clearing the buffer address. Cc: stable Signed-off-by: Selvarasu Ganesan Acked-by: Thinh Nguyen Link: https://lore.kernel.org/r/20240815064836.1491-1-selvarasu.g@samsung.com Signed-off-by: Greg Kroah-Hartman commit 839ab67f60e46e9e9593f44652fea5ec7a7cec6b Author: Krzysztof Kozlowski Date: Fri Aug 16 09:54:08 2024 +0200 usb: dwc3: omap: add missing depopulate in probe error path commit 2aa765a43817ec8add990f83c8e54a9a5d87aa9c upstream. Depopulate device in probe error paths to fix leak of children resources. Fixes: ee249b455494 ("usb: dwc3: omap: remove IRQ_NOAUTOEN used with shared irq") Cc: stable@vger.kernel.org Acked-by: Thinh Nguyen Signed-off-by: Krzysztof Kozlowski Reviewed-by: Radhey Shyam Pandey Link: https://lore.kernel.org/r/20240816075409.23080-1-krzysztof.kozlowski@linaro.org Signed-off-by: Greg Kroah-Hartman commit e49fae2bfda2a064e0245945ac6487a77d9e9ecc Author: Krzysztof Kozlowski Date: Fri Aug 16 09:54:09 2024 +0200 usb: dwc3: xilinx: add missing depopulate in probe error path commit 16f2a21d9d7e48e1af02654fe3d926c0ce6cb3e5 upstream. Depopulate device in probe error paths to fix leak of children resources. Fixes: 53b5ff83d893 ("usb: dwc3: xilinx: improve error handling for PM APIs") Cc: stable@vger.kernel.org Reviewed-by: Radhey Shyam Pandey Signed-off-by: Krzysztof Kozlowski Acked-by: Thinh Nguyen Link: https://lore.kernel.org/r/20240816075409.23080-2-krzysztof.kozlowski@linaro.org Signed-off-by: Greg Kroah-Hartman commit 87670ba8d4cac7d8eb6633a89757e273fa2822b8 Author: Michael Grzeschik Date: Thu Aug 15 08:40:29 2024 +0200 usb: dwc3: ep0: Don't reset resource alloc flag (including ep0) commit 72fca8371f205d654f95b09cd023a71fd5307041 upstream. The DWC3_EP_RESOURCE_ALLOCATED flag ensures that the resource of an endpoint is only assigned once. Unless the endpoint is reset, don't clear this flag. Otherwise we may set endpoint resource again, which prevents the driver from initiate transfer after handling a STALL or endpoint halt to the control endpoint. Commit f2e0eee47038 ("usb: dwc3: ep0: Don't reset resource alloc flag") was fixing the initial issue, but did this only for physical ep1. Since the function dwc3_ep0_stall_and_restart is resetting the flags for both physical endpoints, this also has to be done for ep0. Cc: stable@vger.kernel.org Fixes: b311048c174d ("usb: dwc3: gadget: Rewrite endpoint allocation flow") Acked-by: Thinh Nguyen Signed-off-by: Michael Grzeschik Link: https://lore.kernel.org/r/20240814-dwc3hwep0reset-v2-1-29e1d7d923ea@pengutronix.de Signed-off-by: Greg Kroah-Hartman commit 8c92b0a18f8dba8aa9baeedea96427526f7bc1ed Author: Michal Vokáč Date: Tue Jul 23 16:25:19 2024 +0200 ARM: dts: imx6dl-yapp43: Increase LED current to match the yapp4 HW design commit 8512fbb64b0e599412da661412d10d4ba1cb003c upstream. On the imx6dl-yapp4 revision based boards, the RGB LED is not driven directly by the LP5562 driver but through FET transistors. Hence the LED current is not determined by the driver but by the LED series resistors. On the imx6dl-yapp43 revision based boards, we removed the FET transistors to drive the LED directly from the LP5562 but forgot to tune the output current to match the previous HW design. Set the LED current on imx6dl-yapp43 based boards to the same values measured on the imx6dl-yapp4 boards and limit the maximum current to 20mA. Fixes: 7da4734751e0 ("ARM: dts: imx6dl-yapp43: Add support for new HW revision of the IOTA board") Cc: Signed-off-by: Michal Vokáč Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit bed5a508bc8950c7ef3e19cc1f0f40f6509de42d Author: Johan Hovold Date: Mon Jul 22 11:42:43 2024 +0200 arm64: dts: qcom: x1e80100: fix PCIe domain numbers commit f8fa1f2f6412bffa71972f9506b72992d0e6e485 upstream. The current PCIe domain numbers are off by one and do not match the numbers that the UEFI firmware (and Windows) uses. Fixes: 5eb83fc10289 ("arm64: dts: qcom: x1e80100: Add PCIe nodes") Cc: stable@vger.kernel.org # 6.9 Reviewed-by: Konrad Dybcio Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20240722094249.26471-3-johan+linaro@kernel.org Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit f2b87c34d241c8924a8a0fd8633976b49c2ca0b0 Author: Johan Hovold Date: Mon Jul 22 11:42:44 2024 +0200 arm64: dts: qcom: x1e80100: add missing PCIe minimum OPP commit 98abf2fbd179017833c38edc9f3b587c69d07e2a upstream. Add the missing PCIe CX performance level votes to avoid relying on other drivers (e.g. USB) to maintain the nominal performance level required for Gen3 speeds. Fixes: 5eb83fc10289 ("arm64: dts: qcom: x1e80100: Add PCIe nodes") Cc: stable@vger.kernel.org # 6.9 Signed-off-by: Johan Hovold Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20240722094249.26471-4-johan+linaro@kernel.org Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit 1d45e82ebc42915892396bdb6e41ab52b7dd84cf Author: Johan Hovold Date: Mon Jul 22 11:54:48 2024 +0200 arm64: dts: qcom: x1e80100-qcp: fix PCIe4 PHY supply commit f03dd49f884f428ba71efe23383ff842f4f15e0e upstream. The PCIe4 PHY is powered by vreg_l3i (not vreg_l3j) on the CRD so assume the same applies to the QCP. Fixes: f9a9c11471da ("arm64: dts: qcom: x1e80100-qcp: Enable more support") Cc: stable@vger.kernel.org # 6.9 Signed-off-by: Johan Hovold Reviewed-by: Konrad Dybcio Reviewed-by: Abel Vesa Link: https://lore.kernel.org/r/20240722095459.27437-2-johan+linaro@kernel.org Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit 49e8a69a666d06cf018fd605610f3fd8ade20d0a Author: Johan Hovold Date: Mon Jul 22 11:42:42 2024 +0200 arm64: dts: qcom: x1e80100-crd: fix PCIe4 PHY supply commit 30f593fa0088b89f479f7358640687b3cbca93d4 upstream. The PCIe4 PHY is powered by vreg_l3i (not vreg_l3j). Fixes: d7e03cce0400 ("arm64: dts: qcom: x1e80100-crd: Enable more support") Cc: stable@vger.kernel.org # 6.9 Signed-off-by: Johan Hovold Reviewed-by: Abel Vesa Link: https://lore.kernel.org/r/20240722094249.26471-2-johan+linaro@kernel.org Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit 01129c2107abca38b741215210bc9d15add6b04a Author: Xu Yang Date: Wed Aug 14 19:25:37 2024 +0800 usb: gadget: uvc: queue pump work in uvcg_video_enable() commit b52a07e07dead777517af3cbda851bb2cc157c9d upstream. Since commit "6acba0345b68 usb:gadget:uvc Do not use worker thread to pump isoc usb requests", pump work could only be queued in uvc_video_complete() and uvc_v4l2_qbuf(). If VIDIOC_QBUF is executed before VIDIOC_STREAMON, we can only depend on uvc_video_complete() to queue pump work. However, this requires some free requests in req_ready list. If req_ready list is empty all the time, pump work will never be queued and video datas will never be pumped to usb controller. Actually, this situation could happen when run uvc-gadget with static image: $ ./uvc-gadget -i 1080p.jpg uvc.0 When capture image from this device, the user app will always block there. The issue is uvc driver has queued video buffer before streamon, but the req_ready list is empty all the time after streamon. This will queue pump work in uvcg_video_enable() to fill some request to req_ready list so the uvc device could work properly. Fixes: 6acba0345b68 ("usb:gadget:uvc Do not use worker thread to pump isoc usb requests") Cc: stable@vger.kernel.org Signed-off-by: Xu Yang Link: https://lore.kernel.org/r/20240814112537.2608949-1-xu.yang_2@nxp.com Signed-off-by: Greg Kroah-Hartman commit e0d580002310bcc1c35f6fccc750b9225e03f6fb Author: ZHANG Yuntian Date: Sat Aug 3 15:46:07 2024 +0800 USB: serial: option: add MeiG Smart SRM825L commit 9a471de516c35219d1722c13367191ce1f120fe9 upstream. Add support for MeiG Smart SRM825L which is based on Qualcomm 315 chip. T: Bus=04 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=5000 MxCh= 0 D: Ver= 3.20 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs= 1 P: Vendor=2dee ProdID=4d22 Rev= 4.14 S: Manufacturer=MEIG S: Product=LTE-A Module S: SerialNumber=6f345e48 C:* #Ifs= 6 Cfg#= 1 Atr=80 MxPwr=896mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=81(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=82(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=84(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option E: Ad=87(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=86(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none) E: Ad=05(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=88(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan E: Ad=89(I) Atr=03(Int.) MxPS= 8 Ivl=32ms E: Ad=8e(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=0f(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms Signed-off-by: ZHANG Yuntian Link: https://lore.kernel.org/0041DFA5200EFB1B+20240803074619.563116-1-yt@radxa.com/ Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 699ff210c23b6843591c5db2763c43a9f8696cd8 Author: Alexander Stein Date: Thu Aug 15 13:31:31 2024 +0200 dt-bindings: usb: microchip,usb2514: Fix reference USB device schema commit 5b235693ed2a1e4963625717a1598becf97759cc upstream. An USB hub is not a HCD, but an USB device. Fix the referenced schema accordingly. Fixes: bfbf2e4b77e2 ("dt-bindings: usb: Document the Microchip USB2514 hub") Cc: stable@vger.kernel.org Reviewed-by: Krzysztof Kozlowski Signed-off-by: Alexander Stein Link: https://lore.kernel.org/r/20240815113132.372542-1-alexander.stein@ew.tq-group.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 80eca665ca5074fba3fc4eb0717f28c1354943a9 Author: Yihang Li Date: Mon Aug 19 17:09:34 2024 +0800 scsi: sd: Ignore command SYNCHRONIZE CACHE error if format in progress commit 4f9eedfa27ae5806ed10906bcceee7bae49c8941 upstream. If formatting a suspended disk (such as formatting with different DIF type), the disk will be resuming first, and then the format command will submit to the disk through SG_IO ioctl. When the disk is processing the format command, the system does not submit other commands to the disk. Therefore, the system attempts to suspend the disk again and sends the SYNCHRONIZE CACHE command. However, the SYNCHRONIZE CACHE command will fail because the disk is in the formatting process. This will cause the runtime_status of the disk to error and it is difficult for user to recover it. Error info like: [ 669.925325] sd 6:0:6:0: [sdg] Synchronizing SCSI cache [ 670.202371] sd 6:0:6:0: [sdg] Synchronize Cache(10) failed: Result: hostbyte=0x00 driverbyte=DRIVER_OK [ 670.216300] sd 6:0:6:0: [sdg] Sense Key : 0x2 [current] [ 670.221860] sd 6:0:6:0: [sdg] ASC=0x4 ASCQ=0x4 To solve the issue, ignore the error and return success/0 when format is in progress. Cc: stable@vger.kernel.org Signed-off-by: Yihang Li Link: https://lore.kernel.org/r/20240819090934.2130592-1-liyihang9@huawei.com Reviewed-by: Bart Van Assche Reviewed-by: Damien Le Moal Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit e40115c33c0d79c940545b6b12112aace7acd9f5 Author: Murali Nalajala Date: Wed Aug 14 15:32:44 2024 -0700 firmware: qcom: scm: Mark get_wq_ctx() as atomic call commit 9960085a3a82c58d3323c1c20b991db6045063b0 upstream. Currently get_wq_ctx() is wrongly configured as a standard call. When two SMC calls are in sleep and one SMC wakes up, it calls get_wq_ctx() to resume the corresponding sleeping thread. But if get_wq_ctx() is interrupted, goes to sleep and another SMC call is waiting to be allocated a waitq context, it leads to a deadlock. To avoid this get_wq_ctx() must be an atomic call and can't be a standard SMC call. Hence mark get_wq_ctx() as a fast call. Fixes: 6bf325992236 ("firmware: qcom: scm: Add wait-queue handling logic") Cc: stable@vger.kernel.org Signed-off-by: Murali Nalajala Signed-off-by: Unnathi Chalicheemala Reviewed-by: Elliot Berman Link: https://lore.kernel.org/r/20240814223244.40081-1-quic_uchalich@quicinc.com Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit dcc5a83af7bb5495aefe2e4e216bdbc5fc0bc6d1 Author: Luca Weiss Date: Sun Aug 18 22:21:01 2024 +0200 usb: typec: fsa4480: Relax CHIP_ID check commit 4f83cae0edb2b13aabb82e8a4852092844d320aa upstream. Some FSA4480-compatible chips like the OCP96011 used on Fairphone 5 return 0x00 from the CHIP_ID register. Handle that gracefully and only fail probe when the I2C read has failed. With this the dev_dbg will print 0 but otherwise continue working. [ 0.251581] fsa4480 1-0042: Found FSA4480 v0.0 (Vendor ID = 0) Cc: stable@vger.kernel.org Fixes: e885f5f1f2b4 ("usb: typec: fsa4480: Check if the chip is really there") Signed-off-by: Luca Weiss Reviewed-by: Heikki Krogerus Reviewed-by: Neil Armstrong Link: https://lore.kernel.org/r/20240818-fsa4480-chipid-fix-v1-1-17c239435cf7@fairphone.com Signed-off-by: Greg Kroah-Hartman commit 695c0e840b79bf37ae2b52c0ceb6bd65431e05e2 Author: Ian Ray Date: Wed Aug 14 10:29:05 2024 +0300 cdc-acm: Add DISABLE_ECHO quirk for GE HealthCare UI Controller commit 0b00583ecacb0b51712a5ecd34cf7e6684307c67 upstream. USB_DEVICE(0x1901, 0x0006) may send data before cdc_acm is ready, which may be misinterpreted in the default N_TTY line discipline. Signed-off-by: Ian Ray Acked-by: Oliver Neuku Cc: stable Link: https://lore.kernel.org/r/20240814072905.2501-1-ian.ray@gehealthcare.com Signed-off-by: Greg Kroah-Hartman commit 943b0e7cc646a624bb20a68080f8f1a4a55df41c Author: Bjorn Andersson Date: Tue Aug 20 13:29:30 2024 -0700 soc: qcom: pmic_glink: Fix race during initialization commit 3568affcddd68743e25aa3ec1647d9b82797757b upstream. As pointed out by Stephen Boyd it is possible that during initialization of the pmic_glink child drivers, the protection-domain notifiers fires, and the associated work is scheduled, before the client registration returns and as a result the local "client" pointer has been initialized. The outcome of this is a NULL pointer dereference as the "client" pointer is blindly dereferenced. Timeline provided by Stephen: CPU0 CPU1 ---- ---- ucsi->client = NULL; devm_pmic_glink_register_client() client->pdr_notify(client->priv, pg->client_state) pmic_glink_ucsi_pdr_notify() schedule_work(&ucsi->register_work) pmic_glink_ucsi_register() ucsi_register() pmic_glink_ucsi_read_version() pmic_glink_ucsi_read() pmic_glink_ucsi_read() pmic_glink_send(ucsi->client) ucsi->client = client // Too late! This code is identical across the altmode, battery manager and usci child drivers. Resolve this by splitting the allocation of the "client" object and the registration thereof into two operations. This only happens if the protection domain registry is populated at the time of registration, which by the introduction of commit '1ebcde047c54 ("soc: qcom: add pd-mapper implementation")' became much more likely. Reported-by: Amit Pundir Closes: https://lore.kernel.org/all/CAMi1Hd2_a7TjA7J9ShrAbNOd_CoZ3D87twmO5t+nZxC9sX18tA@mail.gmail.com/ Reported-by: Johan Hovold Closes: https://lore.kernel.org/all/ZqiyLvP0gkBnuekL@hovoldconsulting.com/ Reported-by: Stephen Boyd Closes: https://lore.kernel.org/all/CAE-0n52JgfCBWiFQyQWPji8cq_rCsviBpW-m72YitgNfdaEhQg@mail.gmail.com/ Fixes: 58ef4ece1e41 ("soc: qcom: pmic_glink: Introduce base PMIC GLINK driver") Cc: stable@vger.kernel.org Reviewed-by: Heikki Krogerus Reviewed-by: Neil Armstrong Tested-by: Amit Pundir Reviewed-by: Johan Hovold Acked-by: Sebastian Reichel Tested-by: Johan Hovold Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20240820-pmic-glink-v6-11-races-v3-1-eec53c750a04@quicinc.com Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit bd8f8e7b2bcedcbba32f8b0c49f02c8a97f5d308 Author: Bjorn Andersson Date: Tue Aug 20 13:29:32 2024 -0700 soc: qcom: pmic_glink: Actually communicate when remote goes down commit ad51126037a43c05f5f4af5eb262734e3e88ca59 upstream. When the pmic_glink state is UP and we either receive a protection- domain (PD) notification indicating that the PD is going down, or that the whole remoteproc is going down, it's expected that the pmic_glink client instances are notified that their function has gone DOWN. This is not what the code does, which results in the client state either not updating, or being wrong in many cases. So let's fix the conditions. Fixes: 58ef4ece1e41 ("soc: qcom: pmic_glink: Introduce base PMIC GLINK driver") Cc: stable@vger.kernel.org Reviewed-by: Heikki Krogerus Reviewed-by: Neil Armstrong Reviewed-by: Dmitry Baryshkov Tested-by: Amit Pundir Reviewed-by: Johan Hovold Tested-by: Johan Hovold Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20240820-pmic-glink-v6-11-races-v3-3-eec53c750a04@quicinc.com Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit 62c2d63605ca25b5db78a347ed303c0a0a77d5b4 Author: Volodymyr Babchuk Date: Thu Jul 18 11:33:23 2024 +0530 soc: qcom: cmd-db: Map shared memory as WC, not WB commit f9bb896eab221618927ae6a2f1d566567999839d upstream. Linux does not write into cmd-db region. This region of memory is write protected by XPU. XPU may sometime falsely detect clean cache eviction as "write" into the write protected region leading to secure interrupt which causes an endless loop somewhere in Trust Zone. The only reason it is working right now is because Qualcomm Hypervisor maps the same region as Non-Cacheable memory in Stage 2 translation tables. The issue manifests if we want to use another hypervisor (like Xen or KVM), which does not know anything about those specific mappings. Changing the mapping of cmd-db memory from MEMREMAP_WB to MEMREMAP_WT/WC removes dependency on correct mappings in Stage 2 tables. This patch fixes the issue by updating the mapping to MEMREMAP_WC. I tested this on SA8155P with Xen. Fixes: 312416d9171a ("drivers: qcom: add command DB driver") Cc: stable@vger.kernel.org # 5.4+ Signed-off-by: Volodymyr Babchuk Tested-by: Nikita Travkin # sc7180 WoA in EL2 Signed-off-by: Maulik Shah Tested-by: Pavankumar Kondeti Reviewed-by: Caleb Connolly Link: https://lore.kernel.org/r/20240718-cmd_db_uncached-v2-1-f6cf53164c90@quicinc.com Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit 6bd8144e8f0f3700e99572d5a3a30e9b2cd21174 Author: Jens Axboe Date: Fri Aug 30 10:45:54 2024 -0600 io_uring/kbuf: return correct iovec count from classic buffer peek [ Upstream commit f274495aea7b15225b3d83837121b22ef96e560c ] io_provided_buffers_select() returns 0 to indicate success, but it should be returning 1 to indicate that 1 vec was mapped. This causes peeking to fail with classic provided buffers, and while that's not a use case that anyone should use, it should still work correctly. The end result is that no buffer will be selected, and hence a completion with '0' as the result will be posted, without a buffer attached. Fixes: 35c8711c8fc4 ("io_uring/kbuf: add helpers for getting/peeking multiple buffers") Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 7efb769149401bdfc987da67d491d58273399f91 Author: Karthik Poosa Date: Tue Aug 27 21:23:01 2024 +0530 drm/xe/hwmon: Fix WRITE_I1 param from u32 to u16 [ Upstream commit 59d237c8a241168c7ae34c48244059b7bafaff38 ] WRITE_I1 sub-command of the POWER_SETUP pcode command accepts a u16 parameter instead of u32. This change prevents potential illegal sub-command errors. v2: Mask uval instead of changing the prototype. (Badal) v3: Rephrase commit message. (Badal) Signed-off-by: Karthik Poosa Fixes: 92d44a422d0d ("drm/xe/hwmon: Expose card reactive critical power") Reviewed-by: Badal Nilawar Link: https://patchwork.freedesktop.org/patch/msgid/20240827155301.183383-1-karthik.poosa@intel.com Signed-off-by: Rodrigo Vivi (cherry picked from commit a7f657097e96d8fa745c74bb1a239ebd5a8c971c) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit 64513d0e546a1f19e390f7e5eba3872bfcbdacf5 Author: Aleksandr Mishin Date: Tue Aug 27 11:48:22 2024 +0300 nfc: pn533: Add poll mod list filling check [ Upstream commit febccb39255f9df35527b88c953b2e0deae50e53 ] In case of im_protocols value is 1 and tm_protocols value is 0 this combination successfully passes the check 'if (!im_protocols && !tm_protocols)' in the nfc_start_poll(). But then after pn533_poll_create_mod_list() call in pn533_start_poll() poll mod list will remain empty and dev->poll_mod_count will remain 0 which lead to division by zero. Normally no im protocol has value 1 in the mask, so this combination is not expected by driver. But these protocol values actually come from userspace via Netlink interface (NFC_CMD_START_POLL operation). So a broken or malicious program may pass a message containing a "bad" combination of protocol parameter values so that dev->poll_mod_count is not incremented inside pn533_poll_create_mod_list(), thus leading to division by zero. Call trace looks like: nfc_genl_start_poll() nfc_start_poll() ->start_poll() pn533_start_poll() Add poll mod list filling check. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: dfccd0f58044 ("NFC: pn533: Add some polling entropy") Signed-off-by: Aleksandr Mishin Acked-by: Krzysztof Kozlowski Link: https://patch.msgid.link/20240827084822.18785-1-amishin@t-argos.ru Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 12a366a5d14b878b55a2475e3e3f6eb825fbbce4 Author: Eric Dumazet Date: Tue Aug 27 11:49:16 2024 +0000 net: busy-poll: use ktime_get_ns() instead of local_clock() [ Upstream commit 0870b0d8b393dde53106678a1e2cec9dfa52f9b7 ] Typically, busy-polling durations are below 100 usec. When/if the busy-poller thread migrates to another cpu, local_clock() can be off by +/-2msec or more for small values of HZ, depending on the platform. Use ktimer_get_ns() to ensure deterministic behavior, which is the whole point of busy-polling. Fixes: 060212928670 ("net: add low latency socket poll") Fixes: 9a3c71aa8024 ("net: convert low latency sockets to sched_clock()") Fixes: 37089834528b ("sched, net: Fixup busy_loop_us_clock()") Signed-off-by: Eric Dumazet Cc: Mina Almasry Cc: Willem de Bruijn Reviewed-by: Joe Damato Link: https://patch.msgid.link/20240827114916.223377-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 49e1b214f3239b78967c6ddb8f8ec47ae047b051 Author: Ma Ke Date: Wed Aug 21 12:27:24 2024 +0800 drm/amd/display: avoid using null object of framebuffer [ Upstream commit 3b9a33235c773c7a3768060cf1d2cf8a9153bc37 ] Instead of using state->fb->obj[0] directly, get object from framebuffer by calling drm_gem_fb_get_obj() and return error code when object is null to avoid using null object of framebuffer. Fixes: 5d945cbcd4b1 ("drm/amd/display: Create a file dedicated to planes") Signed-off-by: Ma Ke Signed-off-by: Alex Deucher (cherry picked from commit 73dd0ad9e5dad53766ea3e631303430116f834b3) Signed-off-by: Sasha Levin commit 1fa854f65aaffad39f4505664e02566ccca84b83 Author: Ondrej Mosnacek Date: Mon Aug 26 15:07:11 2024 +0200 sctp: fix association labeling in the duplicate COOKIE-ECHO case [ Upstream commit 3a0504d54b3b57f0d7bf3d9184a00c9f8887f6d7 ] sctp_sf_do_5_2_4_dupcook() currently calls security_sctp_assoc_request() on new_asoc, but as it turns out, this association is always discarded and the LSM labels never get into the final association (asoc). This can be reproduced by having two SCTP endpoints try to initiate an association with each other at approximately the same time and then peel off the association into a new socket, which exposes the unitialized labels and triggers SELinux denials. Fix it by calling security_sctp_assoc_request() on asoc instead of new_asoc. Xin Long also suggested limit calling the hook only to cases A, B, and D, since in cases C and E the COOKIE ECHO chunk is discarded and the association doesn't enter the ESTABLISHED state, so rectify that as well. One related caveat with SELinux and peer labeling: When an SCTP connection is set up simultaneously in this way, we will end up with an association that is initialized with security_sctp_assoc_request() on both sides, so the MLS component of the security context of the association will get swapped between the peers, instead of just one side setting it to the other's MLS component. However, at that point security_sctp_assoc_request() had already been called on both sides in sctp_sf_do_unexpected_init() (on a temporary association) and thus if the exchange didn't fail before due to MLS, it won't fail now either (most likely both endpoints have the same MLS range). Tested by: - reproducer from https://src.fedoraproject.org/tests/selinux/pull-request/530 - selinux-testsuite (https://github.com/SELinuxProject/selinux-testsuite/) - sctp-tests (https://github.com/sctp/sctp-tests) - no tests failed that wouldn't fail also without the patch applied Fixes: c081d53f97a1 ("security: pass asoc to sctp_assoc_request and sctp_sk_clone") Suggested-by: Xin Long Signed-off-by: Ondrej Mosnacek Acked-by: Xin Long Acked-by: Paul Moore (LSM/SELinux) Link: https://patch.msgid.link/20240826130711.141271-1-omosnace@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1c2ea2326afa066e915b489c4114c5f1944155af Author: Xueming Feng Date: Mon Aug 26 18:23:27 2024 +0800 tcp: fix forever orphan socket caused by tcp_abort [ Upstream commit bac76cf89816bff06c4ec2f3df97dc34e150a1c4 ] We have some problem closing zero-window fin-wait-1 tcp sockets in our environment. This patch come from the investigation. Previously tcp_abort only sends out reset and calls tcp_done when the socket is not SOCK_DEAD, aka orphan. For orphan socket, it will only purging the write queue, but not close the socket and left it to the timer. While purging the write queue, tp->packets_out and sk->sk_write_queue is cleared along the way. However tcp_retransmit_timer have early return based on !tp->packets_out and tcp_probe_timer have early return based on !sk->sk_write_queue. This caused ICSK_TIME_RETRANS and ICSK_TIME_PROBE0 not being resched and socket not being killed by the timers, converting a zero-windowed orphan into a forever orphan. This patch removes the SOCK_DEAD check in tcp_abort, making it send reset to peer and close the socket accordingly. Preventing the timer-less orphan from happening. According to Lorenzo's email in the v1 thread, the check was there to prevent force-closing the same socket twice. That situation is handled by testing for TCP_CLOSE inside lock, and returning -ENOENT if it is already closed. The -ENOENT code comes from the associate patch Lorenzo made for iproute2-ss; link attached below, which also conform to RFC 9293. At the end of the patch, tcp_write_queue_purge(sk) is removed because it was already called in tcp_done_with_error(). p.s. This is the same patch with v2. Resent due to mis-labeled "changes requested" on patchwork.kernel.org. Link: https://patchwork.ozlabs.org/project/netdev/patch/1450773094-7978-3-git-send-email-lorenzo@google.com/ Fixes: c1e64e298b8c ("net: diag: Support destroying TCP sockets.") Signed-off-by: Xueming Feng Tested-by: Lorenzo Colitti Reviewed-by: Jason Xing Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20240826102327.1461482-1-kuro@kuroa.me Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 612edd35f2a3910ab1f61c1f2338889d4ba99fa2 Author: Cong Wang Date: Sun Aug 25 12:16:38 2024 -0700 gtp: fix a potential NULL pointer dereference [ Upstream commit defd8b3c37b0f9cb3e0f60f47d3d78d459d57fda ] When sockfd_lookup() fails, gtp_encap_enable_socket() returns a NULL pointer, but its callers only check for error pointers thus miss the NULL pointer case. Fix it by returning an error pointer with the error code carried from sockfd_lookup(). (I found this bug during code inspection.) Fixes: 1e3a3abd8b28 ("gtp: make GTP sockets in gtp_newlink optional") Cc: Andreas Schultz Cc: Harald Welte Signed-off-by: Cong Wang Reviewed-by: Simon Horman Reviewed-by: Pablo Neira Ayuso Link: https://patch.msgid.link/20240825191638.146748-1-xiyou.wangcong@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 56354b0a2c24a7828eeed7de4b4dc9652d9affa3 Author: Jianbo Liu Date: Fri Aug 23 06:10:56 2024 +0300 bonding: change ipsec_lock from spin lock to mutex [ Upstream commit 2aeeef906d5a526dc60cf4af92eda69836c39b1f ] In the cited commit, bond->ipsec_lock is added to protect ipsec_list, hence xdo_dev_state_add and xdo_dev_state_delete are called inside this lock. As ipsec_lock is a spin lock and such xfrmdev ops may sleep, "scheduling while atomic" will be triggered when changing bond's active slave. [ 101.055189] BUG: scheduling while atomic: bash/902/0x00000200 [ 101.055726] Modules linked in: [ 101.058211] CPU: 3 PID: 902 Comm: bash Not tainted 6.9.0-rc4+ #1 [ 101.058760] Hardware name: [ 101.059434] Call Trace: [ 101.059436] [ 101.060873] dump_stack_lvl+0x51/0x60 [ 101.061275] __schedule_bug+0x4e/0x60 [ 101.061682] __schedule+0x612/0x7c0 [ 101.062078] ? __mod_timer+0x25c/0x370 [ 101.062486] schedule+0x25/0xd0 [ 101.062845] schedule_timeout+0x77/0xf0 [ 101.063265] ? asm_common_interrupt+0x22/0x40 [ 101.063724] ? __bpf_trace_itimer_state+0x10/0x10 [ 101.064215] __wait_for_common+0x87/0x190 [ 101.064648] ? usleep_range_state+0x90/0x90 [ 101.065091] cmd_exec+0x437/0xb20 [mlx5_core] [ 101.065569] mlx5_cmd_do+0x1e/0x40 [mlx5_core] [ 101.066051] mlx5_cmd_exec+0x18/0x30 [mlx5_core] [ 101.066552] mlx5_crypto_create_dek_key+0xea/0x120 [mlx5_core] [ 101.067163] ? bonding_sysfs_store_option+0x4d/0x80 [bonding] [ 101.067738] ? kmalloc_trace+0x4d/0x350 [ 101.068156] mlx5_ipsec_create_sa_ctx+0x33/0x100 [mlx5_core] [ 101.068747] mlx5e_xfrm_add_state+0x47b/0xaa0 [mlx5_core] [ 101.069312] bond_change_active_slave+0x392/0x900 [bonding] [ 101.069868] bond_option_active_slave_set+0x1c2/0x240 [bonding] [ 101.070454] __bond_opt_set+0xa6/0x430 [bonding] [ 101.070935] __bond_opt_set_notify+0x2f/0x90 [bonding] [ 101.071453] bond_opt_tryset_rtnl+0x72/0xb0 [bonding] [ 101.071965] bonding_sysfs_store_option+0x4d/0x80 [bonding] [ 101.072567] kernfs_fop_write_iter+0x10c/0x1a0 [ 101.073033] vfs_write+0x2d8/0x400 [ 101.073416] ? alloc_fd+0x48/0x180 [ 101.073798] ksys_write+0x5f/0xe0 [ 101.074175] do_syscall_64+0x52/0x110 [ 101.074576] entry_SYSCALL_64_after_hwframe+0x4b/0x53 As bond_ipsec_add_sa_all and bond_ipsec_del_sa_all are only called from bond_change_active_slave, which requires holding the RTNL lock. And bond_ipsec_add_sa and bond_ipsec_del_sa are xfrm state xdo_dev_state_add and xdo_dev_state_delete APIs, which are in user context. So ipsec_lock doesn't have to be spin lock, change it to mutex, and thus the above issue can be resolved. Fixes: 9a5605505d9c ("bonding: Add struct bond_ipesc to manage SA") Signed-off-by: Jianbo Liu Signed-off-by: Tariq Toukan Reviewed-by: Hangbin Liu Acked-by: Jay Vosburgh Link: https://patch.msgid.link/20240823031056.110999-4-jianbol@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 59405f89f799d59bed4fc5c6abed02d2473fb277 Author: Jianbo Liu Date: Fri Aug 23 06:10:55 2024 +0300 bonding: extract the use of real_device into local variable [ Upstream commit 907ed83a7583e8ffede88c5ac088392701a7d458 ] Add a local variable for slave->dev, to prepare for the lock change in the next patch. There is no functionality change. Fixes: 9a5605505d9c ("bonding: Add struct bond_ipesc to manage SA") Signed-off-by: Jianbo Liu Reviewed-by: Cosmin Ratiu Signed-off-by: Tariq Toukan Reviewed-by: Hangbin Liu Acked-by: Jay Vosburgh Link: https://patch.msgid.link/20240823031056.110999-3-jianbol@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 638dc40ddf0b19c8368a7493581d15dc01f5d304 Author: Jianbo Liu Date: Fri Aug 23 06:10:54 2024 +0300 bonding: implement xdo_dev_state_free and call it after deletion [ Upstream commit ec13009472f4a756288eb4e18e20a7845da98d10 ] Add this implementation for bonding, so hardware resources can be freed from the active slave after xfrm state is deleted. The netdev used to invoke xdo_dev_state_free callback, is saved in the xfrm state (xs->xso.real_dev), which is also the bond's active slave. To prevent it from being freed, acquire netdev reference before leaving RCU read-side critical section, and release it after callback is done. And call it when deleting all SAs from old active real interface while switching current active slave. Fixes: 9a5605505d9c ("bonding: Add struct bond_ipesc to manage SA") Signed-off-by: Jianbo Liu Signed-off-by: Tariq Toukan Reviewed-by: Hangbin Liu Acked-by: Jay Vosburgh Link: https://patch.msgid.link/20240823031056.110999-2-jianbol@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ffe237f5bab9da4a4fb170dd3c3b104c6524c712 Author: Petr Machata Date: Mon Aug 26 19:15:11 2024 +0200 selftests: forwarding: local_termination: Down ports on cleanup [ Upstream commit 65a3cce43d5b4c53cf16b0be1a03991f665a0806 ] This test neglects to put ports down on cleanup. Fix it. Fixes: 90b9566aa5cd ("selftests: forwarding: add a test for local_termination.sh") Signed-off-by: Petr Machata Link: https://patch.msgid.link/bf9b79f45de378f88344d44550f0a5052b386199.1724692132.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a42343c881485c0e4636478ede4ea617efd10eff Author: Petr Machata Date: Fri Aug 23 18:25:37 2024 +0200 selftests: forwarding: no_forwarding: Down ports on cleanup [ Upstream commit e8497d6951ee8541d73784f9aac9942a7f239980 ] This test neglects to put ports down on cleanup. Fix it. Fixes: 476a4f05d9b8 ("selftests: forwarding: add a no_forwarding.sh test") Signed-off-by: Petr Machata Reviewed-by: Simon Horman Link: https://patch.msgid.link/0baf91dc24b95ae0cadfdf5db05b74888e6a228a.1724430120.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2138d574c0a2a38b19e0f28056a7457932abb073 Author: Pablo Neira Ayuso Date: Mon Aug 26 15:03:23 2024 +0200 netfilter: nf_tables_ipv6: consider network offset in netdev/egress validation [ Upstream commit 70c261d500951cf3ea0fcf32651aab9a65a91471 ] From netdev/egress, skb->len can include the ethernet header, therefore, subtract network offset from skb->len when validating IPv6 packet length. Fixes: 42df6e1d221d ("netfilter: Introduce egress hook") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit f0f1ee46939925c6ca545f9b0e0c0191d4f776a5 Author: Eric Dumazet Date: Sat Aug 24 18:19:01 2024 +0000 net_sched: sch_fq: fix incorrect behavior for small weights [ Upstream commit bc21000e99f92a6b5540d7267c6b22806c5c33d3 ] fq_dequeue() has a complex logic to find packets in one of the 3 bands. As Neal found out, it is possible that one band has a deficit smaller than its weight. fq_dequeue() can return NULL while some packets are elligible for immediate transmit. In this case, more than one iteration is needed to refill pband->credit. With default parameters (weights 589824 196608 65536) bug can trigger if large BIG TCP packets are sent to the lowest priority band. Bisected-by: John Sperbeck Diagnosed-by: Neal Cardwell Fixes: 29f834aa326e ("net_sched: sch_fq: add 3 bands and WRR scheduling") Signed-off-by: Eric Dumazet Reviewed-by: Neal Cardwell Link: https://patch.msgid.link/20240824181901.953776-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1e9f22cd56a48b1b831849c32fdf578c14bfa29e Author: Cosmo Chou Date: Mon Aug 19 18:46:30 2024 +0800 hwmon: (pt5161l) Fix invalid temperature reading [ Upstream commit 7bbc079531fc38d401e1c4088d4981435a8828e3 ] The temperature reading function was using a signed long for the ADC code, which could lead to mishandling of invalid codes on 32-bit platforms. This allowed out-of-range ADC codes to be incorrectly interpreted as valid values and used in temperature calculations. Change adc_code to u32 to ensure that invalid ADC codes are correctly identified on all platforms. Fixes: 1b2ca93cd059 ("hwmon: Add driver for Astera Labs PT5161L retimer") Signed-off-by: Cosmo Chou Message-ID: <20240819104630.2375441-1-chou.cosmo@gmail.com> Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 1d6d9b5b1b95bfeccb84386a51b7e6c510ec13b2 Author: Jamie Bainbridge Date: Fri Aug 23 16:26:58 2024 +1000 ethtool: check device is present when getting link settings [ Upstream commit a699781c79ecf6cfe67fb00a0331b4088c7c8466 ] A sysfs reader can race with a device reset or removal, attempting to read device state when the device is not actually present. eg: [exception RIP: qed_get_current_link+17] #8 [ffffb9e4f2907c48] qede_get_link_ksettings at ffffffffc07a994a [qede] #9 [ffffb9e4f2907cd8] __rh_call_get_link_ksettings at ffffffff992b01a3 #10 [ffffb9e4f2907d38] __ethtool_get_link_ksettings at ffffffff992b04e4 #11 [ffffb9e4f2907d90] duplex_show at ffffffff99260300 #12 [ffffb9e4f2907e38] dev_attr_show at ffffffff9905a01c #13 [ffffb9e4f2907e50] sysfs_kf_seq_show at ffffffff98e0145b #14 [ffffb9e4f2907e68] seq_read at ffffffff98d902e3 #15 [ffffb9e4f2907ec8] vfs_read at ffffffff98d657d1 #16 [ffffb9e4f2907f00] ksys_read at ffffffff98d65c3f #17 [ffffb9e4f2907f38] do_syscall_64 at ffffffff98a052fb crash> struct net_device.state ffff9a9d21336000 state = 5, state 5 is __LINK_STATE_START (0b1) and __LINK_STATE_NOCARRIER (0b100). The device is not present, note lack of __LINK_STATE_PRESENT (0b10). This is the same sort of panic as observed in commit 4224cfd7fb65 ("net-sysfs: add check for netdevice being present to speed_show"). There are many other callers of __ethtool_get_link_ksettings() which don't have a device presence check. Move this check into ethtool to protect all callers. Fixes: d519e17e2d01 ("net: export device speed and duplex via sysfs") Fixes: 4224cfd7fb65 ("net-sysfs: add check for netdevice being present to speed_show") Signed-off-by: Jamie Bainbridge Link: https://patch.msgid.link/8bae218864beaa44ed01628140475b9bf641c5b0.1724393671.git.jamie.bainbridge@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3c2f4db462df732ecabd8f28fdf2ae6820fa20df Author: Avraham Stern Date: Sun Aug 25 19:17:12 2024 +0300 wifi: iwlwifi: mvm: allow 6 GHz channels in MLO scan [ Upstream commit 454f6306a31248cf972f5f16d4c145ad5b33bfdc ] MLO internal scan may include 6 GHz channels. Since the 6 GHz scan indication is not set, the channel flags are set incorrectly, which leads to a firmware assert. Since the MLO scan may include 6 GHz and non 6 GHz channels in one request, add support for non-PSC 6 GHz channels (PSC channels are already supported) when the 6 GHz indication is not set. Fixes: 38b3998dfba3 ("wifi: iwlwifi: mvm: Introduce internal MLO passive scan") Signed-off-by: Avraham Stern Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20240825191257.04807f8213b2.Idd09d4366df92a74853649c1a520b7f0f752d1ac@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 654297925d0c2b2246e0e3b4c6a8a841912cdc39 Author: Anjaneyulu Date: Sun Aug 25 19:17:08 2024 +0300 wifi: iwlwifi: fw: fix wgds rev 3 exact size [ Upstream commit 3ee22f07a35b76939c5b8d17d6af292f5fafb509 ] Check size of WGDS revision 3 is equal to 8 entries size with some header, but doesn't depend on the number of used entries. Check that used entries are between min and max but allow more to be present than are used to fix operation with some BIOSes that have such data. Fixes: 97f8a3d1610b ("iwlwifi: ACPI: support revision 3 WGDS tables") Signed-off-by: Anjaneyulu Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20240825191257.cc71dfc67ec3.Ic27ee15ac6128b275c210b6de88f2145bd83ca7b@changeid [edit commit message] Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 68a7894b00ca9ee496716f6ca092b4cafb25d129 Author: Emmanuel Grumbach Date: Sun Aug 25 19:17:07 2024 +0300 wifi: iwlwifi: mvm: take the mutex before running link selection [ Upstream commit cd6f46c2fdb82e80ca248549c1f3ebe08b4a63ab ] iwl_mvm_select_links is called by the link selection worker and it requires the mutex. Take it in the link selection worker. This logic used to run from iwl_mvm_rx_umac_scan_complete_notif which had the mvm->mutex held. This was changed to run in a worker holding the wiphy mutex, but we also need the mvm->mutex. Fixes: 2e194efa3809 ("wifi: iwlwifi: mvm: Fix race in scan completion") Signed-off-by: Emmanuel Grumbach Reviewed-by: Ilan Peer Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20240825191257.0cacecd5db1e.Iaca38a078592b69bdd06549daf63408ccf1810e4@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit ac746de608677d9ba511503a310efbd67a4bd95f Author: Pablo Neira Ayuso Date: Mon Aug 26 12:45:22 2024 +0200 netfilter: nf_tables: restore IP sanity checks for netdev/egress [ Upstream commit 5fd0628918977a0afdc2e6bc562d8751b5d3b8c5 ] Subtract network offset to skb->len before performing IPv4 header sanity checks, then adjust transport offset from offset from mac header. Jorge Ortiz says: When small UDP packets (< 4 bytes payload) are sent from eth0, `meta l4proto udp` condition is not met because `NFT_PKTINFO_L4PROTO` is not set. This happens because there is a comparison that checks if the transport header offset exceeds the total length. This comparison does not take into account the fact that the skb network offset might be non-zero in egress mode (e.g., 14 bytes for Ethernet header). Fixes: 0ae8e4cca787 ("netfilter: nf_tables: set transport offset from mac header for netdev/egress") Reported-by: Jorge Ortiz Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit fc94b79af387321abaccd0899cd8b5fd6fa0783f Author: Jason Gunthorpe Date: Thu Aug 22 11:45:55 2024 -0300 iommu: Do not return 0 from map_pages if it doesn't do anything [ Upstream commit 6093cd582f8e027117a8d4ad5d129a1aacdc53d2 ] These three implementations of map_pages() all succeed if a mapping is requested with no read or write. Since they return back to __iommu_map() leaving the mapped output as 0 it triggers an infinite loop. Therefore nothing is using no-access protection bits. Further, VFIO and iommufd rely on iommu_iova_to_phys() to get back PFNs stored by map, if iommu_map() succeeds but iommu_iova_to_phys() fails that will create serious bugs. Thus remove this never used "nothing to do" concept and just fail map immediately. Fixes: e5fc9753b1a8 ("iommu/io-pgtable: Add ARMv7 short descriptor support") Fixes: e1d3c0fd701d ("iommu: add ARM LPAE page table allocator") Fixes: 745ef1092bcf ("iommu/io-pgtable: Move Apple DART support to its own file") Signed-off-by: Jason Gunthorpe Acked-by: Will Deacon Reviewed-by: Kevin Tian Link: https://lore.kernel.org/r/2-v1-1211e1294c27+4b1-iommu_no_prot_jgg@nvidia.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 77812d9283fee36fa378d459a3d56779f84d0321 Author: Luiz Augusto von Dentz Date: Wed Aug 21 14:41:52 2024 -0400 Bluetooth: hci_core: Fix not handling hibernation actions [ Upstream commit 18b3256db76bd1130965acd99fbd38f87c3e6950 ] This fixes not handling hibernation actions on suspend notifier so they are treated in the same way as regular suspend actions. Fixes: 9952d90ea288 ("Bluetooth: Handle PM_SUSPEND_PREPARE and PM_POST_SUSPEND") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 29a1d9971e38f92c84b363ff50379dd434ddfe1c Author: Neeraj Sanjay Kale Date: Fri Aug 16 15:51:13 2024 +0530 Bluetooth: btnxpuart: Fix random crash seen while removing driver [ Upstream commit 35237475384ab3622f63c3c09bdf6af6dacfe9c3 ] This fixes the random kernel crash seen while removing the driver, when running the load/unload test over multiple iterations. 1) modprobe btnxpuart 2) hciconfig hci0 reset 3) hciconfig (check hci0 interface up with valid BD address) 4) modprobe -r btnxpuart Repeat steps 1 to 4 The ps_wakeup() call in btnxpuart_close() schedules the psdata->work(), which gets scheduled after module is removed, causing a kernel crash. This hidden issue got highlighted after enabling Power Save by default in 4183a7be7700 (Bluetooth: btnxpuart: Enable Power Save feature on startup) The new ps_cleanup() deasserts UART break immediately while closing serdev device, cancels any scheduled ps_work and destroys the ps_lock mutex. [ 85.884604] Unable to handle kernel paging request at virtual address ffffd4a61638f258 [ 85.884624] Mem abort info: [ 85.884625] ESR = 0x0000000086000007 [ 85.884628] EC = 0x21: IABT (current EL), IL = 32 bits [ 85.884633] SET = 0, FnV = 0 [ 85.884636] EA = 0, S1PTW = 0 [ 85.884638] FSC = 0x07: level 3 translation fault [ 85.884642] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000041dd0000 [ 85.884646] [ffffd4a61638f258] pgd=1000000095fff003, p4d=1000000095fff003, pud=100000004823d003, pmd=100000004823e003, pte=0000000000000000 [ 85.884662] Internal error: Oops: 0000000086000007 [#1] PREEMPT SMP [ 85.890932] Modules linked in: algif_hash algif_skcipher af_alg overlay fsl_jr_uio caam_jr caamkeyblob_desc caamhash_desc caamalg_desc crypto_engine authenc libdes crct10dif_ce polyval_ce polyval_generic snd_soc_imx_spdif snd_soc_imx_card snd_soc_ak5558 snd_soc_ak4458 caam secvio error snd_soc_fsl_spdif snd_soc_fsl_micfil snd_soc_fsl_sai snd_soc_fsl_utils gpio_ir_recv rc_core fuse [last unloaded: btnxpuart(O)] [ 85.927297] CPU: 1 PID: 67 Comm: kworker/1:3 Tainted: G O 6.1.36+g937b1be4345a #1 [ 85.936176] Hardware name: FSL i.MX8MM EVK board (DT) [ 85.936182] Workqueue: events 0xffffd4a61638f380 [ 85.936198] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 85.952817] pc : 0xffffd4a61638f258 [ 85.952823] lr : 0xffffd4a61638f258 [ 85.952827] sp : ffff8000084fbd70 [ 85.952829] x29: ffff8000084fbd70 x28: 0000000000000000 x27: 0000000000000000 [ 85.963112] x26: ffffd4a69133f000 x25: ffff4bf1c8540990 x24: ffff4bf215b87305 [ 85.963119] x23: ffff4bf215b87300 x22: ffff4bf1c85409d0 x21: ffff4bf1c8540970 [ 85.977382] x20: 0000000000000000 x19: ffff4bf1c8540880 x18: 0000000000000000 [ 85.977391] x17: 0000000000000000 x16: 0000000000000133 x15: 0000ffffe2217090 [ 85.977399] x14: 0000000000000001 x13: 0000000000000133 x12: 0000000000000139 [ 85.977407] x11: 0000000000000001 x10: 0000000000000a60 x9 : ffff8000084fbc50 [ 85.977417] x8 : ffff4bf215b7d000 x7 : ffff4bf215b83b40 x6 : 00000000000003e8 [ 85.977424] x5 : 00000000410fd030 x4 : 0000000000000000 x3 : 0000000000000000 [ 85.977432] x2 : 0000000000000000 x1 : ffff4bf1c4265880 x0 : 0000000000000000 [ 85.977443] Call trace: [ 85.977446] 0xffffd4a61638f258 [ 85.977451] 0xffffd4a61638f3e8 [ 85.977455] process_one_work+0x1d4/0x330 [ 85.977464] worker_thread+0x6c/0x430 [ 85.977471] kthread+0x108/0x10c [ 85.977476] ret_from_fork+0x10/0x20 [ 85.977488] Code: bad PC value [ 85.977491] ---[ end trace 0000000000000000 ]--- Preset since v6.9.11 Fixes: 86d55f124b52 ("Bluetooth: btnxpuart: Deasset UART break before closing serdev device") Signed-off-by: Neeraj Sanjay Kale Reviewed-by: Paul Menzel Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit fbdfeeb71fa931f1a1c04e96217bd376d6aa223e Author: Neeraj Sanjay Kale Date: Wed May 15 12:36:57 2024 +0530 Bluetooth: btnxpuart: Handle FW Download Abort scenario [ Upstream commit e3c4891098c875a63ab0c3b31d584f6d4f1895fd ] This adds a new flag BTNXPUART_FW_DOWNLOAD_ABORT which handles the situation where driver is removed while firmware download is in progress. logs: modprobe btnxpuart [65239.230431] Bluetooth: hci0: ChipID: 7601, Version: 0 [65239.236670] Bluetooth: hci0: Request Firmware: nxp/uartspi_n61x_v1.bin.se rmmod btnxpuart [65241.425300] Bluetooth: hci0: FW Download Aborted Signed-off-by: Neeraj Sanjay Kale Tested-by: Guillaume Legoupil Signed-off-by: Luiz Augusto von Dentz Stable-dep-of: 35237475384a ("Bluetooth: btnxpuart: Fix random crash seen while removing driver") Signed-off-by: Sasha Levin commit 14abb139a6e587416519333145cca8c288a02510 Author: Mario Limonciello Date: Tue Jul 2 12:15:14 2024 -0500 cpufreq/amd-pstate-ut: Don't check for highest perf matching on prefcore [ Upstream commit 9983a9cd4d429dc9ca01770083c4c1f366214b65 ] If a system is using preferred cores the highest perf will be inconsistent as it can change from system events. Skip the checks for it. Fixes: e571a5e2068e ("cpufreq: amd-pstate: Update amd-pstate preferred core ranking dynamically") Reviewed-by: Gautham R. Shenoy Signed-off-by: Mario Limonciello Signed-off-by: Sasha Levin commit 5f5f7366dda8ae870e8305d6e7b3c0c2686cd2cf Author: Eric Dumazet Date: Wed Aug 21 17:53:39 2024 +0000 pktgen: use cpus_read_lock() in pg_net_init() [ Upstream commit 979b581e4c69257acab1af415ddad6b2d78a2fa5 ] I have seen the WARN_ON(smp_processor_id() != cpu) firing in pktgen_thread_worker() during tests. We must use cpus_read_lock()/cpus_read_unlock() around the for_each_online_cpu(cpu) loop. While we are at it use WARN_ON_ONCE() to avoid a possible syslog flood. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20240821175339.1191779-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0d1064dc06be0b8a5a2198ad10bf200d9a3b3598 Author: Kees Cook Date: Tue Jul 16 14:57:06 2024 -0700 dmaengine: ti: omap-dma: Initialize sglen after allocation [ Upstream commit 5e5c793c7fc47219998465361d94510fdf55d83f ] With the new __counted_by annocation, the "sglen" struct member must be set before accessing the "sg" array. This initialization was done in other places where a new struct omap_desc is allocated, but these cases were missed. Set "sglen" after allocation. Fixes: b85178611c11 ("dmaengine: ti: omap-dma: Annotate struct omap_desc with __counted_by") Signed-off-by: Kees Cook Reviewed-by: Gustavo A. R. Silva Link: https://lore.kernel.org/r/20240716215702.work.802-kees@kernel.org Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit be76aa92319525a684bc083080135419c84c83e8 Author: Serge Semin Date: Fri Aug 2 10:50:47 2024 +0300 dmaengine: dw: Add memory bus width verification [ Upstream commit d04b21bfa1c50a2ade4816cab6fdc91827b346b1 ] Currently in case of the DEV_TO_MEM or MEM_TO_DEV DMA transfers the memory data width (single transfer width) is determined based on the buffer length, buffer base address or DMA master-channel max address width capability. It isn't enough in case of the channel disabling prior the block transfer is finished. Here is what DW AHB DMA IP-core databook says regarding the port suspension (DMA-transfer pause) implementation in the controller: "When CTLx.SRC_TR_WIDTH < CTLx.DST_TR_WIDTH and the CFGx.CH_SUSP bit is high, the CFGx.FIFO_EMPTY is asserted once the contents of the FIFO do not permit a single word of CTLx.DST_TR_WIDTH to be formed. However, there may still be data in the channel FIFO, but not enough to form a single transfer of CTLx.DST_TR_WIDTH. In this scenario, once the channel is disabled, the remaining data in the channel FIFO is not transferred to the destination peripheral." So in case if the port gets to be suspended and then disabled it's possible to have the data silently discarded even though the controller reported that FIFO is empty and the CTLx.BLOCK_TS indicated the dropped data already received from the source device. This looks as if the data somehow got lost on a way from the peripheral device to memory and causes problems for instance in the DW APB UART driver, which pauses and disables the DMA-transfer as soon as the recv data timeout happens. Here is the way it looks: Memory <------- DMA FIFO <------ UART FIFO <---------------- UART DST_TR_WIDTH -+--------| | | | | | | No more data Current lvl -+--------| |---------+- DMA-burst lvl | | |---------+- Leftover data | | |---------+- SRC_TR_WIDTH -+--------+-------+---------+ In the example above: no more data is getting received over the UART port and BLOCK_TS is not even close to be fully received; some data is left in the UART FIFO, but not enough to perform a bursted DMA-xfer to the DMA FIFO; some data is left in the DMA FIFO, but not enough to be passed further to the system memory in a single transfer. In this situation the 8250 UART driver catches the recv timeout interrupt, pauses the DMA-transfer and terminates it completely, after which the IRQ handler manually fetches the leftover data from the UART FIFO into the recv-buffer. But since the DMA-channel has been disabled with the data left in the DMA FIFO, that data will be just discarded and the recv-buffer will have a gap of the "current lvl" size in the recv-buffer at the tail of the lately received data portion. So the data will be lost just due to the misconfigured DMA transfer. Note this is only relevant for the case of the transfer suspension and _disabling_. No problem will happen if the transfer will be re-enabled afterwards or the block transfer is fully completed. In the later case the "FIFO flush mode" will be executed at the transfer final stage in order to push out the data left in the DMA FIFO. In order to fix the denoted problem the DW AHB DMA-engine driver needs to make sure that the _bursted_ source transfer width is greater or equal to the single destination transfer (note the HW databook describes more strict constraint than actually required). Since the peripheral-device side is prescribed by the client driver logic, the memory-side can be only used for that. The solution can be easily implemented for the DEV_TO_MEM transfers just by adjusting the memory-channel address width. Sadly it's not that easy for the MEM_TO_DEV transfers since the mem-to-dma burst size is normally dynamically determined by the controller. So the only thing that can be done is to make sure that memory-side address width is greater than the peripheral device address width. Fixes: a09820043c9e ("dw_dmac: autoconfigure data_width or get it via platform data") Signed-off-by: Serge Semin Acked-by: Andy Shevchenko Link: https://lore.kernel.org/r/20240802075100.6475-3-fancer.lancer@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 93fafe96eaec0bc163f24925dfbf6263b6053c62 Author: Serge Semin Date: Fri Aug 2 10:50:46 2024 +0300 dmaengine: dw: Add peripheral bus width verification [ Upstream commit b336268dde75cb09bd795cb24893d52152a9191f ] Currently the src_addr_width and dst_addr_width fields of the dma_slave_config structure are mapped to the CTLx.SRC_TR_WIDTH and CTLx.DST_TR_WIDTH fields of the peripheral bus side in order to have the properly aligned data passed to the target device. It's done just by converting the passed peripheral bus width to the encoded value using the __ffs() function. This implementation has several problematic sides: 1. __ffs() is undefined if no bit exist in the passed value. Thus if the specified addr-width is DMA_SLAVE_BUSWIDTH_UNDEFINED, __ffs() may return unexpected value depending on the platform-specific implementation. 2. DW AHB DMA-engine permits having the power-of-2 transfer width limited by the DMAH_Mk_HDATA_WIDTH IP-core synthesize parameter. Specifying bus-width out of that constraints scope will definitely cause unexpected result since the destination reg will be only partly touched than the client driver implied. Let's fix all of that by adding the peripheral bus width verification method and calling it in dwc_config() which is supposed to be executed before preparing any transfer. The new method will make sure that the passed source or destination address width is valid and if undefined then the driver will just fallback to the 1-byte width transfer. Fixes: 029a40e97d0d ("dmaengine: dw: provide DMA capabilities") Signed-off-by: Serge Semin Acked-by: Andy Shevchenko Link: https://lore.kernel.org/r/20240802075100.6475-2-fancer.lancer@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit b6c833cf14937fe07be7c0abe220452e52612e2a Author: Piyush Mehta Date: Mon Aug 5 11:29:07 2024 +0530 phy: xilinx: phy-zynqmp: Fix SGMII linkup failure on resume [ Upstream commit 5af9b304bc6010723c02f74de0bfd24ff19b1a10 ] On a few Kria KR260 Robotics Starter Kit the PS-GEM SGMII linkup is not happening after the resume. This is because serdes registers are reset when FPD is off (in suspend state) and needs to be reprogrammed in the resume path with the same default initialization as done in the first stage bootloader psu_init routine. To address the failure introduce a set of serdes registers to be saved in the suspend path and then restore it on resume. Fixes: 4a33bea00314 ("phy: zynqmp: Add PHY driver for the Xilinx ZynqMP Gigabit Transceiver") Signed-off-by: Piyush Mehta Signed-off-by: Radhey Shyam Pandey Link: https://lore.kernel.org/r/1722837547-2578381-1-git-send-email-radhey.shyam.pandey@amd.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 1ece4d9b98bbf547453a16aac3b65d16760ba3a0 Author: Abel Vesa Date: Thu Aug 1 13:40:24 2024 +0300 phy: qcom: qmp-pcie: Fix X1E80100 PCIe Gen4 PHY initialisation [ Upstream commit 0e8a0504da59041e775a95db3ebc1a6211423593 ] Update the PCIe Gen4 PHY init sequence with the latest based on internal Qualcomm documentation. Fixes: 606060ce8fd0 ("phy: qcom-qmp-pcie: Add support for X1E80100 g3x2 and g4x2 PCIE") Signed-off-by: Abel Vesa Link: https://lore.kernel.org/r/20240801-x1e80100-phy-qmp-pcie-fix-config-v2-1-cdc0f22b4169@linaro.org Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 58fe9445704a494174022ed3330d073fb8bc3891 Author: Mrinmay Sarkar Date: Mon Aug 26 17:41:01 2024 +0530 dmaengine: dw-edma: Do not enable watermark interrupts for HDMA commit 9f646ff25c09c52cebe726601db27a60f876f15e upstream. DW_HDMA_V0_LIE and DW_HDMA_V0_RIE are initialized as BIT(3) and BIT(4) respectively in dw_hdma_control enum. But as per HDMA register these bits are corresponds to LWIE and RWIE bit i.e local watermark interrupt enable and remote watermarek interrupt enable. In linked list mode LWIE and RWIE bits only enable the local and remote watermark interrupt. Since the watermark interrupts are not used but enabled, this leads to spurious interrupts getting generated. So remove the code that enables them to avoid generating spurious watermark interrupts. And also rename DW_HDMA_V0_LIE to DW_HDMA_V0_LWIE and DW_HDMA_V0_RIE to DW_HDMA_V0_RWIE as there is no LIE and RIE bits in HDMA and those bits are corresponds to LWIE and RWIE bits. Fixes: e74c39573d35 ("dmaengine: dw-edma: Add support for native HDMA") cc: stable@vger.kernel.org Signed-off-by: Mrinmay Sarkar Reviewed-by: Manivannan Sadhasivam Reviewed-by: Serge Semin Link: https://lore.kernel.org/r/1724674261-3144-3-git-send-email-quic_msarkar@quicinc.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 388abe4a1677a7550bc78d19ebbc374198988034 Author: Mrinmay Sarkar Date: Mon Aug 26 17:41:00 2024 +0530 dmaengine: dw-edma: Fix unmasking STOP and ABORT interrupts for HDMA commit 383baf5c8f062091af34c63f28d37642a8f188ae upstream. The current logic is enabling both STOP_INT_MASK and ABORT_INT_MASK bit. This is apparently masking those particular interrupts rather than unmasking the same. If the interrupts are masked, they would never get triggered. So fix the issue by unmasking the STOP and ABORT interrupts properly. Fixes: e74c39573d35 ("dmaengine: dw-edma: Add support for native HDMA") cc: stable@vger.kernel.org Signed-off-by: Mrinmay Sarkar Reviewed-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/1724674261-3144-2-git-send-email-quic_msarkar@quicinc.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 6fa78e9c41471fe43052cd6feba6eae1b0277ae3 Author: Krzysztof Kozlowski Date: Mon Jul 29 16:01:57 2024 +0200 soundwire: stream: fix programming slave ports for non-continous port maps commit ab8d66d132bc8f1992d3eb6cab8d32dda6733c84 upstream. Two bitmasks in 'struct sdw_slave_prop' - 'source_ports' and 'sink_ports' - define which ports to program in sdw_program_slave_port_params(). The masks are used to get the appropriate data port properties ('struct sdw_get_slave_dpn_prop') from an array. Bitmasks can be non-continuous or can start from index different than 0, thus when looking for matching port property for given port, we must iterate over mask bits, not from 0 up to number of ports. This fixes allocation and programming slave ports, when a source or sink masks start from further index. Fixes: f8101c74aa54 ("soundwire: Add Master and Slave port programming") Cc: stable@vger.kernel.org Signed-off-by: Krzysztof Kozlowski Reviewed-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20240729140157.326450-1-krzysztof.kozlowski@linaro.org Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 462678742842496bd08b1f9f103b8e25b701711a Author: Xu Yang Date: Thu Aug 1 20:46:42 2024 +0800 phy: fsl-imx8mq-usb: fix tuning parameter name commit ce52c2532299c7ccfd34a52db8d071e890a78c59 upstream. According to fsl,imx8mq-usb-phy.yaml, this tuning parameter should be fsl,phy-pcs-tx-deemph-3p5db-attenuation-db. Fixes: 63c85ad0cd81 ("phy: fsl-imx8mp-usb: add support for phy tuning") Cc: stable@vger.kernel.org Signed-off-by: Xu Yang Reviewed-by: Alexander Stein Link: https://lore.kernel.org/r/20240801124642.1152838-1-xu.yang_2@nxp.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 5a8ac1accf72e4b0a8af6d533129a9d9d411cfe1 Author: Jason Gunthorpe Date: Thu Aug 22 11:45:54 2024 -0300 iommufd: Do not allow creating areas without READ or WRITE commit 996dc53ac289b81957aa70d62ccadc6986d26a87 upstream. This results in passing 0 or just IOMMU_CACHE to iommu_map(). Most of the page table formats don't like this: amdv1 - -EINVAL armv7s - returns 0, doesn't update mapped arm-lpae - returns 0 doesn't update mapped dart - returns 0, doesn't update mapped VT-D - returns -EINVAL Unfortunately the three formats that return 0 cause serious problems: - Returning ret = but not uppdating mapped from domain->map_pages() causes an infinite loop in __iommu_map() - Not writing ioptes means that VFIO/iommufd have no way to recover them and we will have memory leaks and worse during unmap Since almost nothing can support this, and it is a useless thing to do, block it early in iommufd. Cc: stable@kernel.org Fixes: aad37e71d5c4 ("iommufd: IOCTLs for the io_pagetable") Signed-off-by: Jason Gunthorpe Reviewed-by: Nicolin Chen Reviewed-by: Kevin Tian Link: https://lore.kernel.org/r/1-v1-1211e1294c27+4b1-iommu_no_prot_jgg@nvidia.com Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit db8443078a8a262de4dde8ec3357ee5e7b37f678 Author: Gautham R. Shenoy Date: Tue Aug 13 15:21:14 2024 +0530 cpufreq/amd-pstate: Use topology_logical_package_id() instead of logical_die_id() commit 0d8584d288a9b4132e945d76bcc04395d158b2e7 upstream. After the commit 63edbaa48a57 ("x86/cpu/topology: Add support for the AMD 0x80000026 leaf"), the topolgy_logical_die_id() function returns the logical Core Chiplet Die (CCD) ID instead of the logical socket ID. Since this is currently used to set MSR_AMD_CPPC_ENABLE, which needs to be set on any one of the threads of the socket, it is prudent to use topology_logical_package_id() in place of topology_logical_die_id(). Fixes: 63edbaa48a57 ("x86/cpu/topology: Add support for the AMD 0x80000026 leaf") cc: stable@vger.kernel.org # 6.10 Signed-off-by: Gautham R. Shenoy Tested-by: Dhananjay Ugwekar Link: https://lore.kernel.org/lkml/20240801124509.3650-1-Dhananjay.Ugwekar@amd.com/ Signed-off-by: Dhananjay Ugwekar Signed-off-by: Mario Limonciello Signed-off-by: Greg Kroah-Hartman commit f71ec019257ba4f7ab198bd948c5902a207bad96 Author: Scott Mayhew Date: Wed Aug 28 15:51:29 2024 -0400 selinux,smack: don't bypass permissions check in inode_setsecctx hook commit 76a0e79bc84f466999fa501fce5bf7a07641b8a7 upstream. Marek Gresko reports that the root user on an NFS client is able to change the security labels on files on an NFS filesystem that is exported with root squashing enabled. The end of the kerneldoc comment for __vfs_setxattr_noperm() states: * This function requires the caller to lock the inode's i_mutex before it * is executed. It also assumes that the caller will make the appropriate * permission checks. nfsd_setattr() does do permissions checking via fh_verify() and nfsd_permission(), but those don't do all the same permissions checks that are done by security_inode_setxattr() and its related LSM hooks do. Since nfsd_setattr() is the only consumer of security_inode_setsecctx(), simplest solution appears to be to replace the call to __vfs_setxattr_noperm() with a call to __vfs_setxattr_locked(). This fixes the above issue and has the added benefit of causing nfsd to recall conflicting delegations on a file when a client tries to change its security label. Cc: stable@kernel.org Reported-by: Marek Gresko Link: https://bugzilla.kernel.org/show_bug.cgi?id=218809 Signed-off-by: Scott Mayhew Tested-by: Stephen Smalley Reviewed-by: Stephen Smalley Reviewed-by: Chuck Lever Reviewed-by: Jeff Layton Acked-by: Casey Schaufler Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit f12424ca2061cc83d89156fd7fc8f80d5501f290 Author: Jeff Layton Date: Mon Aug 26 10:32:34 2024 -0400 fs/nfsd: fix update of inode attrs in CB_GETATTR [ Upstream commit 7e8ae8486e4471513e2111aba6ac29f2357bed2a ] Currently, we copy the mtime and ctime to the in-core inode and then mark the inode dirty. This is fine for certain types of filesystems, but not all. Some require a real setattr to properly change these values (e.g. ceph or reexported NFS). Fix this code to call notify_change() instead, which is the proper way to effect a setattr. There is one problem though: In this case, the client is holding a write delegation and has sent us attributes to update our cache. We don't want to break the delegation for this since that would defeat the purpose. Add a new ATTR_DELEG flag that makes notify_change bypass the try_break_deleg call. Fixes: c5967721e106 ("NFSD: handle GETATTR conflict with write delegation") Reviewed-by: Christian Brauner Signed-off-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit e0b66698a5ae41078f7490e8b3527013f5fccd6c Author: Jeff Layton Date: Fri Aug 23 18:27:39 2024 -0400 nfsd: fix potential UAF in nfsd4_cb_getattr_release [ Upstream commit 1116e0e372eb16dd907ec571ce5d4af325c55c10 ] Once we drop the delegation reference, the fields embedded in it are no longer safe to access. Do that last. Fixes: c5967721e106 ("NFSD: handle GETATTR conflict with write delegation") Signed-off-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 1ca0cfdec3940770a6c45e59e31aec788b8651fe Author: Jeff Layton Date: Fri Aug 23 18:27:38 2024 -0400 nfsd: hold reference to delegation when updating it for cb_getattr [ Upstream commit da05ba23d4c8d3e8a45846b952e53dd76c4b5e36 ] Once we've dropped the flc_lock, there is nothing that ensures that the delegation that was found will still be around later. Take a reference to it while holding the lock and then drop it when we've finished with the delegation. Fixes: c5967721e106 ("NFSD: handle GETATTR conflict with write delegation") Signed-off-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 45eb9b1e91dee256537665d5d9ad45e02f44f74b Author: David Howells Date: Fri Aug 23 14:22:42 2024 +0100 cifs: Fix FALLOC_FL_PUNCH_HOLE support [ Upstream commit 416871f4fb84bc96822562e654941d5625a25bf8 ] The cifs filesystem doesn't quite emulate FALLOC_FL_PUNCH_HOLE correctly (note that due to lack of protocol support, it can't actually implement it directly). Whilst it will (partially) invalidate dirty folios in the pagecache, it doesn't write them back first, and so the EOF marker on the server may be lower than inode->i_size. This presents a problem, however, as if the punched hole invalidates the tail of the locally cached dirty data, writeback won't know it needs to move the EOF over to account for the hole punch (which isn't supposed to move the EOF). We could just write zeroes over the punched out region of the pagecache and write that back - but this is supposed to be a deallocatory operation. Fix this by manually moving the EOF over on the server after the operation if the hole punched would corrupt it. Note that the FSCTL_SET_ZERO_DATA RPC and the setting of the EOF should probably be compounded to stop a third party interfering (or, at least, massively reduce the chance). This was reproducible occasionally by using fsx with the following script: truncate 0x0 0x375e2 0x0 punch_hole 0x2f6d3 0x6ab5 0x375e2 truncate 0x0 0x3a71f 0x375e2 mapread 0xee05 0xcf12 0x3a71f write 0x2078e 0x5604 0x3a71f write 0x3ebdf 0x1421 0x3a71f * punch_hole 0x379d0 0x8630 0x40000 * mapread 0x2aaa2 0x85b 0x40000 fallocate 0x1b401 0x9ada 0x40000 read 0x15f2 0x7d32 0x40000 read 0x32f37 0x7a3b 0x40000 * The second "write" should extend the EOF to 0x40000, and the "punch_hole" should operate inside of that - but that depends on whether the VM gets in and writes back the data first. If it doesn't, the file ends up 0x3a71f in size, not 0x40000. Fixes: 31742c5a3317 ("enable fallocate punch hole ("fallocate -p") for SMB3") Signed-off-by: David Howells cc: Steve French cc: Paulo Alcantara cc: Shyam Prasad N cc: Jeff Layton cc: linux-cifs@vger.kernel.org cc: netfs@lists.linux.dev Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 12a2d1a3dbe7324d56d2c7ea90473eb8cbd4bfe9 Author: Stefan Metzmacher Date: Wed Aug 21 15:59:12 2024 +0200 smb/client: remove unused rq_iter_size from struct smb_rqst [ Upstream commit b608e2c318789aeba49055747166e13bee57df4a ] Reviewed-by: David Howells Fixes: d08089f649a0 ("cifs: Change the I/O paths to use an iterator rather than a page list") Signed-off-by: Stefan Metzmacher Signed-off-by: Steve French Signed-off-by: Sasha Levin commit adbaf41621f7a31e83a8245bd360d4a9ebae8d0d Author: David Howells Date: Sat Aug 24 12:56:53 2024 +0100 netfs: Fix interaction of streaming writes with zero-point tracker [ Upstream commit e00e99ba6c6b8e5239e75cd6684a6827d93c39a2 ] When a folio that is marked for streaming write (dirty, but not uptodate, with partial content specified in the private data) is written back, the folio is effectively switched to the blank state upon completion of the write. This means that if we want to read it in future, we need to reread the whole folio. However, if the folio is above the zero_point position, when it is read back, it will just be cleared and the read skipped, leading to apparent local corruption. Fix this by increasing the zero_point to the end of the dirty data in the folio when clearing the folio state after writeback. This is analogous to the folio having ->release_folio() called upon it. This was causing the config.log generated by configuring a cpython tree on a cifs share to get corrupted because the scripts involved were appending text to the file in small pieces. Fixes: 288ace2f57c9 ("netfs: New writeback implementation") Signed-off-by: David Howells Link: https://lore.kernel.org/r/563286.1724500613@warthog.procyon.org.uk cc: Steve French cc: Paulo Alcantara cc: Jeff Layton cc: linux-cifs@vger.kernel.org cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 4931ce82f0a6945110c76e66a1a6f9970a7fc2d1 Author: David Howells Date: Fri Aug 23 21:08:13 2024 +0100 netfs: Fix missing iterator reset on retry of short read [ Upstream commit 950b03d0f664a54389a555d79215348ed413161f ] Fix netfs_rreq_perform_resubmissions() to reset before retrying a short read, otherwise the wrong part of the output buffer will be used. Fixes: 92b6cc5d1e7c ("netfs: Add iov_iters to (sub)requests to describe various buffers") Signed-off-by: David Howells Link: https://lore.kernel.org/r/20240823200819.532106-6-dhowells@redhat.com cc: Steve French cc: Paulo Alcantara cc: Jeff Layton cc: linux-cifs@vger.kernel.org cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit e2814004138a541110d4b2dc254a8f619c2c4ce0 Author: David Howells Date: Fri Aug 23 21:08:12 2024 +0100 netfs: Fix trimming of streaming-write folios in netfs_inval_folio() [ Upstream commit cce6bfa6ca0e30af9927b0074c97fe6a92f28092 ] When netfslib writes to a folio that it doesn't have data for, but that data exists on the server, it will make a 'streaming write' whereby it stores data in a folio that is marked dirty, but not uptodate. When it does this, it attaches a record to folio->private to track the dirty region. When truncate() or fallocate() wants to invalidate part of such a folio, it will call into ->invalidate_folio(), specifying the part of the folio that is to be invalidated. netfs_invalidate_folio(), on behalf of the filesystem, must then determine how to trim the streaming write record. In a couple of cases, however, it does this incorrectly (the reduce-length and move-start cases are switched over and don't, in any case, calculate the value correctly). Fix this by making the logic tree more obvious and fixing the cases. Fixes: 9ebff83e6481 ("netfs: Prep to use folio->private for write grouping and streaming write") Signed-off-by: David Howells Link: https://lore.kernel.org/r/20240823200819.532106-5-dhowells@redhat.com cc: Matthew Wilcox (Oracle) cc: Pankaj Raghav cc: Jeff Layton cc: Marc Dionne cc: linux-afs@lists.infradead.org cc: netfs@lists.linux.dev cc: linux-mm@kvack.org cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit c7c90666e43e7a991f6ad0ec4b3f406b3c2f91be Author: David Howells Date: Fri Aug 23 21:08:11 2024 +0100 netfs: Fix netfs_release_folio() to say no if folio dirty [ Upstream commit 7dfc8f0c6144c290dbeb01835a67e81b34dda8cd ] Fix netfs_release_folio() to say no (ie. return false) if the folio is dirty (analogous with iomap's behaviour). Without this, it will say yes to the release of a dirty page by split_huge_page_to_list_to_order(), which will result in the loss of untruncated data in the folio. Without this, the generic/075 and generic/112 xfstests (both fsx-based tests) fail with minimum folio size patches applied[1]. Fixes: c1ec4d7c2e13 ("netfs: Provide invalidate_folio and release_folio calls") Signed-off-by: David Howells Link: https://lore.kernel.org/r/20240815090849.972355-1-kernel@pankajraghav.com/ [1] Link: https://lore.kernel.org/r/20240823200819.532106-4-dhowells@redhat.com cc: Matthew Wilcox (Oracle) cc: Pankaj Raghav cc: Jeff Layton cc: Marc Dionne cc: linux-afs@lists.infradead.org cc: netfs@lists.linux.dev cc: linux-mm@kvack.org cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 875458893425cbd508d49326c2aa332b2afb1c83 Author: David Howells Date: Fri Aug 23 21:08:10 2024 +0100 afs: Fix post-setattr file edit to do truncation correctly [ Upstream commit a74ee0e878e262c0276966528d72d4e887174410 ] At the end of an kAFS RPC operation, there is an "edit" phase (originally intended for post-directory modification ops to edit the local image) that the setattr VFS op uses to fix up the pagecache if the RPC that requested truncation of a file was successful. afs_setattr_edit_file() calls truncate_setsize() which sets i_size, expands the pagecache if needed and truncates the pagecache. The first two of those, however, are redundant as they've already been done by afs_setattr_success() under the io_lock and the first is also done under the callback lock (cb_lock). Fix afs_setattr_edit_file() to call truncate_pagecache() instead (which is called by truncate_setsize(), thereby skipping the redundant parts. Fixes: 100ccd18bb41 ("netfs: Optimise away reads above the point at which there can be no data") Signed-off-by: David Howells Link: https://lore.kernel.org/r/20240823200819.532106-3-dhowells@redhat.com cc: Matthew Wilcox (Oracle) cc: Pankaj Raghav cc: Jeff Layton cc: Marc Dionne cc: linux-afs@lists.infradead.org cc: netfs@lists.linux.dev cc: linux-mm@kvack.org cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit f4ad910c4431a5f6ccf1c66edb95e616d6763e23 Author: David Howells Date: Fri Aug 23 21:08:09 2024 +0100 mm: Fix missing folio invalidation calls during truncation [ Upstream commit 0aa2e1b2fb7a75aa4b5b4347055ccfea6f091769 ] When AS_RELEASE_ALWAYS is set on a mapping, the ->release_folio() and ->invalidate_folio() calls should be invoked even if PG_private and PG_private_2 aren't set. This is used by netfslib to keep track of the point above which reads can be skipped in favour of just zeroing pagecache locally. There are a couple of places in truncation in which invalidation is only called when folio_has_private() is true. Fix these to check folio_needs_release() instead. Without this, the generic/075 and generic/112 xfstests (both fsx-based tests) fail with minimum folio size patches applied[1]. Fixes: b4fa966f03b7 ("mm, netfs, fscache: stop read optimisation when folio removed from pagecache") Signed-off-by: David Howells Link: https://lore.kernel.org/r/20240815090849.972355-1-kernel@pankajraghav.com/ [1] Link: https://lore.kernel.org/r/20240823200819.532106-2-dhowells@redhat.com Reviewed-by: Matthew Wilcox (Oracle) cc: Matthew Wilcox (Oracle) cc: Pankaj Raghav cc: Jeff Layton cc: Marc Dionne cc: linux-afs@lists.infradead.org cc: netfs@lists.linux.dev cc: linux-mm@kvack.org cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit ba0b697de298285301c71c258598226e06494236 Author: Olga Kornievskaia Date: Fri Aug 23 11:51:08 2024 -0400 nfsd: prevent panic for nfsv4.0 closed files in nfs4_show_open [ Upstream commit a204501e1743d695ca2930ed25a2be9f8ced96d3 ] Prior to commit 3f29cc82a84c ("nfsd: split sc_status out of sc_type") states_show() relied on sc_type field to be of valid type before calling into a subfunction to show content of a particular stateid. From that commit, we split the validity of the stateid into sc_status and no longer changed sc_type to 0 while unhashing the stateid. This resulted in kernel oopsing for nfsv4.0 opens that stay around and in nfs4_show_open() would derefence sc_file which was NULL. Instead, for closed open stateids forgo displaying information that relies of having a valid sc_file. To reproduce: mount the server with 4.0, read and close a file and then on the server cat /proc/fs/nfsd/clients/2/states [ 513.590804] Call trace: [ 513.590925] _raw_spin_lock+0xcc/0x160 [ 513.591119] nfs4_show_open+0x78/0x2c0 [nfsd] [ 513.591412] states_show+0x44c/0x488 [nfsd] [ 513.591681] seq_read_iter+0x5d8/0x760 [ 513.591896] seq_read+0x188/0x208 [ 513.592075] vfs_read+0x148/0x470 [ 513.592241] ksys_read+0xcc/0x178 Fixes: 3f29cc82a84c ("nfsd: split sc_status out of sc_type") Signed-off-by: Olga Kornievskaia Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 3205c181b99e22d167038312b4794819ac4edd78 Author: Hal Feng Date: Mon Aug 12 15:01:08 2024 +0800 pinctrl: starfive: jh7110: Correct the level trigger configuration of iev register [ Upstream commit 639766ca10d1e218e257ae7eabe76814bae6ab89 ] A mistake was made in level trigger register configuration. Correct it. Fixes: 447976ab62c5 ("pinctrl: starfive: Add StarFive JH7110 sys controller driver") Signed-off-by: Hal Feng Link: https://lore.kernel.org/20240812070108.100923-1-hal.feng@starfivetech.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 0197bf772f657fbdea5e9bdec5eea6e67d82cbde Author: Konrad Dybcio Date: Fri Aug 9 02:22:04 2024 +0200 pinctrl: qcom: x1e80100: Fix special pin offsets [ Upstream commit d3692d95cc4d88114b070ee63cffc976f00f207f ] Remove the erroneus 0x100000 offset to prevent the boards from crashing on pin state setting, as well as for the intended state changes to take effect. Fixes: 05e4941d97ef ("pinctrl: qcom: Add X1E80100 pinctrl driver") Signed-off-by: Konrad Dybcio Reviewed-by: Abel Vesa Reviewed-by: Bjorn Andersson Link: https://lore.kernel.org/20240809-topic-h_sdc-v1-1-bb421532c531@quicinc.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 5443bf58bb56d1c96e7f05ac6b1069ccdadedba0 Author: Nícolas F. R. A. Prado Date: Thu Aug 8 19:27:09 2024 -0400 pinctrl: mediatek: common-v2: Fix broken bias-disable for PULL_PU_PD_RSEL_TYPE [ Upstream commit 166bf8af91225576f85208a31eaedbadd182d1ea ] Despite its name, commit fed74d75277d ("pinctrl: mediatek: common-v2: Fix bias-disable for PULL_PU_PD_RSEL_TYPE") actually broke bias-disable for PULL_PU_PD_RSEL_TYPE. mtk_pinconf_bias_set_combo() tries every bias method supported by the pin until one succeeds. For PULL_PU_PD_RSEL_TYPE pins, before the breaking commit, mtk_pinconf_bias_set_rsel() would be called first to try and set the RSEL value (as well as PU and PD), and if that failed, the only other valid option was that bias-disable was specified, which would then be handled by calling mtk_pinconf_bias_set_pu_pd() and disabling both PU and PD. The breaking commit misunderstood this logic and added an early "return 0" in mtk_pinconf_bias_set_rsel(). The result was that in the bias-disable case, the bias was left unchanged, since by returning success, mtk_pinconf_bias_set_combo() no longer tried calling mtk_pinconf_bias_set_pu_pd() to disable the bias. Since the logic for configuring bias-disable on PULL_PU_PD_RSEL_TYPE pins required mtk_pinconf_bias_set_rsel() to fail first, in that case, an error was printed to the log, eg: mt8195-pinctrl 10005000.pinctrl: Not support rsel value 0 Ohm for pin = 29 (GPIO29) This is what the breaking commit actually got rid of, and likely part of the reason why that commit was thought to be fixing functionality, while in reality it was breaking it. Instead of simply reverting that commit, restore the functionality but in a way that avoids the error from being printed and makes the code less confusing: * Return 0 explicitly if a bias method was successful * Introduce an extra function mtk_pinconf_bias_set_pu_pd_rsel() that calls both mtk_pinconf_bias_set_rsel() (only if needed) and mtk_pinconf_bias_set_pu_pd() * And analogously for the corresponding getters Fixes: fed74d75277d ("pinctrl: mediatek: common-v2: Fix bias-disable for PULL_PU_PD_RSEL_TYPE") Signed-off-by: Nícolas F. R. A. Prado Link: https://lore.kernel.org/20240808-mtk-rsel-bias-disable-fix-v1-1-1b4e85bf596c@collabora.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 0790732a7482764acc183adc2ee7376282dc2c60 Author: Ed Tsai Date: Mon Jul 8 15:22:06 2024 +0800 backing-file: convert to using fops->splice_write [ Upstream commit 996b37da1e0f51314d4186b326742c2a95a9f0dd ] Filesystems may define their own splice write. Therefore, use the file fops instead of invoking iter_file_splice_write() directly. Signed-off-by: Ed Tsai Link: https://lore.kernel.org/r/20240708072208.25244-1-ed.tsai@mediatek.com Fixes: 5ca73468612d ("fuse: implement splice read/write passthrough") Reviewed-by: Amir Goldstein Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit dd65b324174a64558a16ebbf4c3266e5701185d0 Author: Jeff Layton Date: Thu Aug 22 14:47:01 2024 -0400 nfsd: ensure that nfsd4_fattr_args.context is zeroed out [ Upstream commit f58bab6fd4063913bd8321e99874b8239e9ba726 ] If nfsd4_encode_fattr4 ends up doing a "goto out" before we get to checking for the security label, then args.context will be set to uninitialized junk on the stack, which we'll then try to free. Initialize it early. Fixes: f59388a579c6 ("NFSD: Add nfsd4_encode_fattr4_sec_label()") Signed-off-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 2aadeb966cdada68da5694ffe5dc3ffe8224b913 Author: Richard Fitzgerald Date: Thu Aug 22 14:35:44 2024 +0100 ASoC: cs-amp-lib: Ignore empty UEFI calibration entries [ Upstream commit bb4485562f5907708f1c218b5d70dce04165d1e1 ] If the timestamp of a calibration entry is 0 it is an unused entry and must be ignored. Some end-products reserve EFI space for calibration entries by shipping with a zero-filled EFI file. When searching the file for calibration data the driver must skip the empty entries. The timestamp of a valid entry is always non-zero. Signed-off-by: Richard Fitzgerald Fixes: 1cad8725f2b9 ("ASoC: cs-amp-lib: Add helpers for factory calibration data") Link: https://patch.msgid.link/20240822133544.304421-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7c9d049ba64d8906fc25355ee7a8d300b93649e2 Author: Richard Fitzgerald Date: Thu Aug 22 12:57:25 2024 +0100 ASoC: cs-amp-lib-test: Force test calibration blob entries to be valid [ Upstream commit bff980d8d9ca537fd5f3c0e9a99876c1e3713e81 ] For a normal calibration blob the calTarget values must be non-zero and unique, and the calTime values must be non-zero. Don't rely on get_random_bytes() to be random enough to guarantee this. Force the calTarget and calTime values to be valid while retaining randomness in the values. Signed-off-by: Richard Fitzgerald Fixes: 177862317a98 ("ASoC: cs-amp-lib: Add KUnit test for calibration helpers") Link: https://patch.msgid.link/20240822115725.259568-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 294e6490bf3a4d1e6e12b156394ed4580e561d11 Author: Simon Trimmer Date: Wed Aug 21 12:47:11 2024 +0000 ALSA: hda: cs35l56: Don't use the device index as a calibration index [ Upstream commit 91191a6e50a2ff752da244493171037663536768 ] The HDA driver cannot assume that the order that the devices are specified in the cirrus,dev-index matches the order of calibration entries. Only a calibration entry with a matching silicon id will be used. Fixes: cfa43aaa7948 ("ALSA: hda: cs35l56: Apply amp calibration from EFI data") Signed-off-by: Simon Trimmer Link: https://patch.msgid.link/20240821124711.44325-1-simont@opensource.cirrus.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 40ef8748b68e419cd691c7067c9eb6126c5cda7f Author: Vijendar Mukunda Date: Fri Aug 16 12:33:28 2024 +0530 ASoC: SOF: amd: Fix for acp init sequence [ Upstream commit a42db293e5983aa1508d12644f23d73f0553b32c ] When ACP is not powered on by default, acp power on sequence explicitly invoked by programming pgfsm control mask. The existing implementation checks the same PGFSM status mask and programs the same PGFSM control mask in all ACP variants which breaks acp power on sequence for ACP6.0 and ACP6.3 variants. So to fix this issue, update ACP pgfsm control mask and status mask based on acp descriptor rev field, which will vary based on acp variant. Fixes: 846aef1d7cc0 ("ASoC: SOF: amd: Add Renoir ACP HW support") Signed-off-by: Vijendar Mukunda Link: https://patch.msgid.link/20240816070328.610360-1-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a241d8ab8a4ca86221435848a65d8f59ea003e76 Author: Yuntao Liu Date: Thu Aug 15 08:49:23 2024 +0000 ASoC: amd: acp: fix module autoloading [ Upstream commit 164199615ae230ace4519141285f06766d6d8036 ] Add MODULE_DEVICE_TABLE(), so modules could be properly autoloaded based on the alias from platform_device_id table. Fixes: 9d8a7be88b336 ("ASoC: amd: acp: Add legacy sound card support for Chrome audio") Signed-off-by: Yuntao Liu Link: https://patch.msgid.link/20240815084923.756476-1-liuyuntao12@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 833dc4e241a54ce9439022eae4442896aafd4d53 Author: Vijendar Mukunda Date: Tue Aug 13 16:29:44 2024 +0530 ASoC: SOF: amd: Fix for incorrect acp error register offsets [ Upstream commit 897e91e995b338002b00454fd0018af26a098148 ] Addition of 'dsp_intr_base' to ACP error register offsets points to wrong register offsets in irq handler. Correct the acp error register offsets. ACP error status register offset and acp error reason register offset got changed from ACP6.0 onwards. Add 'acp_error_stat' and 'acp_sw0_i2s_err_reason' as descriptor fields in sof_amd_acp_desc structure and update the values based on the ACP variant. >From Rembrandt platform onwards, errors related to SW1 Soundwire manager instance/I2S controller connected on P1 power tile is reported with ACP_SW1_I2S_ERROR_REASON register. Add conditional check for the same. Fixes: 96eb81851012 ("ASoC: SOF: amd: add interrupt handling for SoundWire manager devices") Signed-off-by: Vijendar Mukunda Link: https://patch.msgid.link/20240813105944.3126903-2-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit cbcac50af0406a272d0c3656885cfb66f6ed67a2 Author: Vijendar Mukunda Date: Tue Aug 13 16:29:43 2024 +0530 ASoC: SOF: amd: move iram-dram fence register programming sequence [ Upstream commit c56ba3e44784527fd6efe5eb7a4fa6c9f6969a58 ] The existing code modifies IRAM and DRAM size after sha dma start for vangogh platform. The problem with this sequence is that it might cause sha dma failure when firmware code binary size is greater than the default IRAM size. To fix this issue, Move the iram-dram fence register sequence prior to sha dma start. Fixes: 094d11768f74 ("ASoC: SOF: amd: Skip IRAM/DRAM size modification for Steam Deck OLED") Signed-off-by: Vijendar Mukunda Link: https://patch.msgid.link/20240813105944.3126903-1-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 60dec92867d878d05e8365a865a2bc5394de2ec9 Author: Konrad Dybcio Date: Thu Jul 11 11:37:57 2024 +0200 pinctrl: qcom: x1e80100: Update PDC hwirq map [ Upstream commit b7fd10333713e9984cc9b9c04f3681f80efdc809 ] The current map seems to be out of sync (and includes a duplicate entry for GPIO193..). Replace it with the map present in shipping devices' ACPI tables. This new one seems more complete, as it e.g. contains GPIO145 (PCIE6a WAKE#) Fixes: 05e4941d97ef ("pinctrl: qcom: Add X1E80100 pinctrl driver") Signed-off-by: Konrad Dybcio Reviewed-by: Abel Vesa Reviewed-by: Rajendra Nayak Link: https://lore.kernel.org/20240711-topic-x1e_pdc_tlmm-v1-1-e278b249d793@linaro.org Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit e3e5fed7a3c6fc88fe0d7a6f2bbb8f8e0efdea55 Author: Alex Deucher Date: Mon Aug 19 11:14:29 2024 -0400 drm/amdgpu: fix eGPU hotplug regression [ Upstream commit 9cead81eff635e3b3cbce51b40228f3bdc6f2b8c ] The driver needs to wait for the on board firmware to finish its initialization before probing the card. Commit 959056982a9b ("drm/amdgpu: Fix discovery initialization failure during pci rescan") switched from using msleep() to using usleep_range() which seems to have caused init failures on some navi1x boards. Switch back to msleep(). Fixes: 959056982a9b ("drm/amdgpu: Fix discovery initialization failure during pci rescan") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3559 Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3500 Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Cc: Ma Jun (cherry picked from commit c69b07f7bbc905022491c45097923d3487479529) Cc: stable@vger.kernel.org # 6.10.x Signed-off-by: Sasha Levin commit f7207c5961a04b145f202bf7dc36f747c54967dc Author: Victor Lu Date: Fri May 31 14:59:22 2024 -0400 drm/amdgpu: Do not wait for MP0_C2PMSG_33 IFWI init in SRIOV [ Upstream commit b32563859d6f61265222ec0f27d394964a8f7669 ] SRIOV does not need to wait for IFWI init, and MP0_C2PMSG_33 is blocked for VF access. Signed-off-by: Victor Lu Reviewed-by: Vignesh Chander Signed-off-by: Alex Deucher Stable-dep-of: 9cead81eff63 ("drm/amdgpu: fix eGPU hotplug regression") Signed-off-by: Sasha Levin commit 10081b0b0ed201f53e24bd92deb2e0f3c3e713d4 Author: Matthew Auld Date: Wed Aug 14 12:01:30 2024 +0100 drm/xe: prevent UAF around preempt fence [ Upstream commit 730b72480e29f63fd644f5fa57c9d46109428953 ] The fence lock is part of the queue, therefore in the current design anything locking the fence should then also hold a ref to the queue to prevent the queue from being freed. However, currently it looks like we signal the fence and then drop the queue ref, but if something is waiting on the fence, the waiter is kicked to wake up at some later point, where upon waking up it first grabs the lock before checking the fence state. But if we have already dropped the queue ref, then the lock might already be freed as part of the queue, leading to uaf. To prevent this, move the fence lock into the fence itself so we don't run into lifetime issues. Alternative might be to have device level lock, or only release the queue in the fence release callback, however that might require pushing to another worker to avoid locking issues. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") References: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2454 References: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2342 References: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2020 Signed-off-by: Matthew Auld Cc: Matthew Brost Cc: # v6.8+ Reviewed-by: Matthew Brost Link: https://patchwork.freedesktop.org/patch/msgid/20240814110129.825847-2-matthew.auld@intel.com (cherry picked from commit 7116c35aacedc38be6d15bd21b2fc936eed0008b) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit 8831dcab3b6af9f9de9721511c7968bfdf6d56f6 Author: Francois Dugast Date: Thu Jun 13 19:03:48 2024 +0200 drm/xe/exec_queue: Rename xe_exec_queue::compute to xe_exec_queue::lr [ Upstream commit 731e46c032281601756f08cfa7d8505fe41166a9 ] The properties of this struct are used in long running context so make that clear by renaming it to lr, in alignment with the rest of the code. Cc: Matthew Brost Signed-off-by: Francois Dugast Reviewed-by: Matthew Brost Link: https://patchwork.freedesktop.org/patch/msgid/20240613170348.723245-1-francois.dugast@intel.com Signed-off-by: Rodrigo Vivi Stable-dep-of: 730b72480e29 ("drm/xe: prevent UAF around preempt fence") Signed-off-by: Sasha Levin commit 97f519fdd70b11b99cde372483e4413db08e8d94 Author: Thorsten Blum Date: Mon Jun 3 20:00:07 2024 +0200 drm/xe/vm: Simplify if condition [ Upstream commit b3181f433206a1432bc7093d1896fe36026f7fff ] The if condition !A || A && B can be simplified to !A || B. Fixes the following Coccinelle/coccicheck warning reported by excluded_middle.cocci: WARNING !A || A && B is equivalent to !A || B Compile-tested only. Signed-off-by: Thorsten Blum Reviewed-by: Matthew Brost Signed-off-by: Matthew Brost Link: https://patchwork.freedesktop.org/patch/msgid/20240603180005.191578-1-thorsten.blum@toblux.com Stable-dep-of: 730b72480e29 ("drm/xe: prevent UAF around preempt fence") Signed-off-by: Sasha Levin commit c25458927f7d4035d1366500f13d909be2d2abdf Author: Maarten Lankhorst Date: Tue Aug 6 12:50:44 2024 +0200 drm/xe/display: Make display suspend/resume work on discrete [ Upstream commit ddf6492e0e508b7c2b42c8d5a4ac82bd38ef0dd5 ] We should unpin before evicting all memory, and repin after GT resume. This way, we preserve the contents of the framebuffers, and won't hang on resume due to migration engine not being restored yet. Signed-off-by: Maarten Lankhorst Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: stable@vger.kernel.org # v6.8+ Reviewed-by: Uma Shankar Link: https://patchwork.freedesktop.org/patch/msgid/20240806105044.596842-3-maarten.lankhorst@linux.intel.com Signed-off-by: Maarten Lankhorst,,, (cherry picked from commit cb8f81c1753187995b7a43e79c12959f14eb32d3) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit fcc9d8e2195258bd9638901a72afcf4acd98f5eb Author: Rodrigo Vivi Date: Wed May 22 13:01:03 2024 -0400 drm/xe: Prepare display for D3Cold [ Upstream commit e7b180b22022f52e3f5fca695cc75d63bddc5a1c ] Prepare power-well and DC handling for a full power lost during D3Cold, then sanitize it upon D3->D0. Otherwise we get a bunch of state mismatch. Ideally we could leave DC9 enabled and wouldn't need to move DC9->DC0 on every runtime resume, however, the disable_DC is part of the power-well checks and intrinsic to the dc_off power well. In the future that can be detangled so we can have even bigger power savings. But for now, let's focus on getting a D3Cold, which saves much more power by itself. v2: create new functions to avoid full-suspend-resume path, which would result in a deadlock between xe_gem_fault and the modeset-ioctl. v3: Only avoid the full modeset to avoid the race, for a more robust suspend-resume. Cc: Anshuman Gupta Cc: Uma Shankar Tested-by: Francois Dugast Reviewed-by: Anshuman Gupta Link: https://patchwork.freedesktop.org/patch/msgid/20240522170105.327472-5-rodrigo.vivi@intel.com Signed-off-by: Rodrigo Vivi Stable-dep-of: ddf6492e0e50 ("drm/xe/display: Make display suspend/resume work on discrete") Signed-off-by: Sasha Levin commit 17e78f43de0c6da34204cc858b4cc05671ea9acf Author: Alex Deucher Date: Wed Aug 21 15:11:35 2024 -0400 video/aperture: optionally match the device in sysfb_disable() commit b49420d6a1aeb399e5b107fc6eb8584d0860fbd7 upstream. In aperture_remove_conflicting_pci_devices(), we currently only call sysfb_disable() on vga class devices. This leads to the following problem when the pimary device is not VGA compatible: 1. A PCI device with a non-VGA class is the boot display 2. That device is probed first and it is not a VGA device so sysfb_disable() is not called, but the device resources are freed by aperture_detach_platform_device() 3. Non-primary GPU has a VGA class and it ends up calling sysfb_disable() 4. NULL pointer dereference via sysfb_disable() since the resources have already been freed by aperture_detach_platform_device() when it was called by the other device. Fix this by passing a device pointer to sysfb_disable() and checking the device to determine if we should execute it or not. v2: Fix build when CONFIG_SCREEN_INFO is not set v3: Move device check into the mutex Drop primary variable in aperture_remove_conflicting_pci_devices() Drop __init on pci sysfb_pci_dev_is_enabled() Fixes: 5ae3716cfdcd ("video/aperture: Only remove sysfb on the default vga pci device") Cc: Javier Martinez Canillas Cc: Thomas Zimmermann Cc: Helge Deller Cc: Sam Ravnborg Cc: Daniel Vetter Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Reviewed-by: Javier Martinez Canillas Reviewed-by: Thomas Zimmermann Signed-off-by: Alex Deucher Link: https://patchwork.freedesktop.org/patch/msgid/20240821191135.829765-1-alexander.deucher@amd.com Signed-off-by: Greg Kroah-Hartman commit c45558414b8f2e0b9dc34eb8f9d4e8359b887681 Author: Zack Rusin Date: Fri Aug 16 14:32:07 2024 -0400 drm/vmwgfx: Disable coherent dumb buffers without 3d commit e9fd436bb8fb9b9d31fdf07bbcdba6d30290c5e4 upstream. Coherent surfaces make only sense if the host renders to them using accelerated apis. Without 3d the entire content of dumb buffers stays in the guest making all of the extra work they're doing to synchronize between guest and host useless. Configurations without 3d also tend to run with very low graphics memory limits. The pinned console fb, mob cursors and graphical login manager tend to run out of 16MB graphics memory that those guests use. Fix it by making sure the coherent dumb buffers are only used on configs with 3d enabled. Signed-off-by: Zack Rusin Fixes: d6667f0ddf46 ("drm/vmwgfx: Fix handling of dumb buffers") Reported-by: Christian Heusel Closes: https://lore.kernel.org/all/0d0330f3-2ac0-4cd5-8075-7f1cbaf72a8e@heusel.eu Cc: Broadcom internal kernel review list Cc: dri-devel@lists.freedesktop.org Cc: # v6.9+ Link: https://patchwork.freedesktop.org/patch/msgid/20240816183332.31961-4-zack.rusin@broadcom.com Reviewed-by: Martin Krastev Reviewed-by: Maaz Mombasawala Tested-by: Benjamin Coddington Signed-off-by: Greg Kroah-Hartman commit 5c12391ee1ab59cb2f3be3f1f5e6d0fc0c2dc854 Author: Zack Rusin Date: Fri Aug 16 14:32:06 2024 -0400 drm/vmwgfx: Fix prime with external buffers commit 50f1199250912568606b3778dc56646c10cb7b04 upstream. Make sure that for external buffers mapping goes through the dma_buf interface instead of trying to access pages directly. External buffers might not provide direct access to readable/writable pages so to make sure the bo's created from external dma_bufs can be read dma_buf interface has to be used. Fixes crashes in IGT's kms_prime with vgem. Regular desktop usage won't trigger this due to the fact that virtual machines will not have multiple GPUs but it enables better test coverage in IGT. Signed-off-by: Zack Rusin Fixes: b32233acceff ("drm/vmwgfx: Fix prime import/export") Cc: # v6.6+ Cc: Broadcom internal kernel review list Cc: dri-devel@lists.freedesktop.org Cc: # v6.9+ Link: https://patchwork.freedesktop.org/patch/msgid/20240816183332.31961-3-zack.rusin@broadcom.com Reviewed-by: Martin Krastev Reviewed-by: Maaz Mombasawala Signed-off-by: Greg Kroah-Hartman commit d5228d158e4c0b1663b3983044913c15c3d0135e Author: Zack Rusin Date: Fri Aug 16 14:32:05 2024 -0400 drm/vmwgfx: Prevent unmapping active read buffers commit aba07b9a0587f50e5d3346eaa19019cf3f86c0ea upstream. The kms paths keep a persistent map active to read and compare the cursor buffer. These maps can race with each other in simple scenario where: a) buffer "a" mapped for update b) buffer "a" mapped for compare c) do the compare d) unmap "a" for compare e) update the cursor f) unmap "a" for update At step "e" the buffer has been unmapped and the read contents is bogus. Prevent unmapping of active read buffers by simply keeping a count of how many paths have currently active maps and unmap only when the count reaches 0. Fixes: 485d98d472d5 ("drm/vmwgfx: Add support for CursorMob and CursorBypass 4") Cc: Broadcom internal kernel review list Cc: dri-devel@lists.freedesktop.org Cc: # v5.19+ Signed-off-by: Zack Rusin Link: https://patchwork.freedesktop.org/patch/msgid/20240816183332.31961-2-zack.rusin@broadcom.com Reviewed-by: Martin Krastev Reviewed-by: Maaz Mombasawala Signed-off-by: Greg Kroah-Hartman commit e10d26003c16df40e1666eceef2ada29654e7e7c Author: Alex Deucher Date: Thu Aug 22 21:54:24 2024 -0400 drm/amdgpu/swsmu: always force a state reprogram on init commit d420c857d85777663e8d16adfc24463f5d5c2dbc upstream. Always reprogram the hardware state on init. This ensures the PMFW state is explicitly programmed and we are not relying on the default PMFW state. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3131 Reviewed-by: Kenneth Feng Signed-off-by: Alex Deucher (cherry picked from commit c50fe289ed7207f71df3b5f1720512a9620e84fb) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 306cf40125c758c81ddf557246b3ac3d13468e0a Author: Alex Deucher Date: Wed Aug 21 14:32:02 2024 -0400 drm/amdgpu: align pp_power_profile_mode with kernel docs commit 8f614469de248a4bc55fb07e55d5f4c340c75b11 upstream. The kernel doc says you need to select manual mode to adjust this, but the code only allows you to adjust it when manual mode is not selected. Remove the manual mode check. Reviewed-by: Kenneth Feng Signed-off-by: Alex Deucher (cherry picked from commit bbb05f8a9cd87f5046d05a0c596fddfb714ee457) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit c04665e707bbe1ef2c4c5752e801491dcdd3351b Author: Imre Deak Date: Fri Aug 23 19:29:18 2024 +0300 drm/i915/dp_mst: Fix MST state after a sink reset commit a2ccc33b88e2953a6bf0b309e7e8849cc5320018 upstream. In some cases the sink can reset itself after it was configured into MST mode, without the driver noticing the disconnected state. For instance the reset may happen in the middle of a modeset, or the (long) HPD pulse generated may be not long enough for the encoder detect handler to observe the HPD's deasserted state. In this case the sink's DPCD register programmed to enable MST will be reset, while the driver still assumes MST is still enabled. Detect this condition, which will tear down and recreate/re-enable the MST topology. v2: - Add a code comment about adjusting the expected DP_MSTM_CTRL register value for SST + SideBand. (Suraj, Jani) - Print a debug message about detecting the link reset. (Jani) - Verify the DPCD MST state only if it wasn't already determined that the sink is disconnected. Cc: stable@vger.kernel.org Cc: Jani Nikula Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11195 Reviewed-by: Suraj Kandpal (v1) Signed-off-by: Imre Deak Link: https://patchwork.freedesktop.org/patch/msgid/20240823162918.1211875-1-imre.deak@intel.com (cherry picked from commit 594cf78dc36f31c0c7e0de4567e644f406d46bae) Signed-off-by: Joonas Lahtinen Signed-off-by: Greg Kroah-Hartman commit ad3840fc96795527d8718d41690c6fe677828174 Author: Hans de Goede Date: Fri Aug 23 09:50:55 2024 +0200 drm/i915/dsi: Make Lenovo Yoga Tab 3 X90F DMI match less strict commit 7d058e6bac9afab6a406e34344ebbfd3068bb2d5 upstream. There are 2G and 4G RAM versions of the Lenovo Yoga Tab 3 X90F and it turns out that the 2G version has a DMI product name of "CHERRYVIEW D1 PLATFORM" where as the 4G version has "CHERRYVIEW C0 PLATFORM". The sys-vendor + product-version check are unique enough that the product-name check is not necessary. Drop the product-name check so that the existing DMI match for the 4G RAM version also matches the 2G RAM version. Fixes: f6f4a0862bde ("drm/i915/vlv_dsi: Add DMI quirk for backlight control issues on Lenovo Yoga Tab 3 (v2)") Cc: stable@vger.kernel.org Acked-by: Jani Nikula Signed-off-by: Hans de Goede Link: https://patchwork.freedesktop.org/patch/msgid/20240823075055.17198-1-hdegoede@redhat.com (cherry picked from commit a4dbe45c4c14edc316ae94b9af86a28f8c5d8123) Signed-off-by: Joonas Lahtinen Signed-off-by: Greg Kroah-Hartman commit 1e93467ef20308da5a94cde548ee17d523e8ba7b Author: Tvrtko Ursulin Date: Tue Aug 13 11:25:04 2024 +0100 drm/v3d: Disable preemption while updating GPU stats commit 9d824c7fce58f59982228aa85b0376b113cdfa35 upstream. We forgot to disable preemption around the write_seqcount_begin/end() pair while updating GPU stats: [ ] WARNING: CPU: 2 PID: 12 at include/linux/seqlock.h:221 __seqprop_assert.isra.0+0x128/0x150 [v3d] [ ] Workqueue: v3d_bin drm_sched_run_job_work [gpu_sched] <...snip...> [ ] Call trace: [ ] __seqprop_assert.isra.0+0x128/0x150 [v3d] [ ] v3d_job_start_stats.isra.0+0x90/0x218 [v3d] [ ] v3d_bin_job_run+0x23c/0x388 [v3d] [ ] drm_sched_run_job_work+0x520/0x6d0 [gpu_sched] [ ] process_one_work+0x62c/0xb48 [ ] worker_thread+0x468/0x5b0 [ ] kthread+0x1c4/0x1e0 [ ] ret_from_fork+0x10/0x20 Fix it. Cc: Maíra Canal Cc: stable@vger.kernel.org # v6.10+ Fixes: 6abe93b621ab ("drm/v3d: Fix race-condition between sysfs/fdinfo and interrupt handler") Signed-off-by: Tvrtko Ursulin Acked-by: Maíra Canal Signed-off-by: Maíra Canal Link: https://patchwork.freedesktop.org/patch/msgid/20240813102505.80512-1-tursulin@igalia.com Signed-off-by: Greg Kroah-Hartman commit c507da85e4f80c630deb9e98222ccf4118cbe6f8 Author: Max Filippov Date: Sun Aug 25 20:27:45 2024 -0700 binfmt_elf_fdpic: fix AUXV size calculation when ELF_HWCAP2 is defined commit c6a09e342f8e6d3cac7f7c5c14085236aca284b9 upstream. create_elf_fdpic_tables() does not correctly account the space for the AUX vector when an architecture has ELF_HWCAP2 defined. Prior to the commit 10e29251be0e ("binfmt_elf_fdpic: fix /proc//auxv") it resulted in the last entry of the AUX vector being set to zero, but with that change it results in a kernel BUG. Fix that by adding one to the number of AUXV entries (nitems) when ELF_HWCAP2 is defined. Fixes: 10e29251be0e ("binfmt_elf_fdpic: fix /proc//auxv") Cc: stable@vger.kernel.org Reported-by: Greg Ungerer Closes: https://lore.kernel.org/lkml/5b51975f-6d0b-413c-8b38-39a6a45e8821@westnet.com.au/ Signed-off-by: Max Filippov Tested-by: Greg Ungerer Link: https://lore.kernel.org/r/20240826032745.3423812-1-jcmvbkbc@gmail.com Signed-off-by: Kees Cook Signed-off-by: Greg Kroah-Hartman commit 6297c575fbadb0812f8fecdccd9797b52a86b666 Author: Matthieu Baerts (NGI0) Date: Wed Aug 28 08:14:34 2024 +0200 selftests: mptcp: join: check re-re-adding ID 0 endp commit d397d7246c11ca36c33c932bc36d38e3a79e9aa0 upstream. This test extends "delete and re-add" to validate the previous commit: when the endpoint linked to the initial subflow (ID 0) is re-added multiple times, it was no longer being used, because the internal linked counters are not decremented for this special endpoint: it is not an additional endpoint. Here, the "del/add id 0" steps are done 3 times to unsure this case is validated. The 'Fixes' tag here below is the same as the one from the previous commit: this patch here is not fixing anything wrong in the selftests, but it validates the previous fix for an issue introduced by this commit ID. Fixes: 3ad14f54bd74 ("mptcp: more accurate MPC endpoint tracking") Cc: stable@vger.kernel.org Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 6d631530f49f042820df9f262bca59970d8f7fd7 Author: Matthieu Baerts (NGI0) Date: Wed Aug 28 08:14:31 2024 +0200 selftests: mptcp: join: no extra msg if no counter commit 76a2d8394cc183df872adf04bf636eaf42746449 upstream. The checksum and fail counters might not be available. Then no need to display an extra message with missing info. While at it, fix the indentation around, which is wrong since the same commit. Fixes: 47867f0a7e83 ("selftests: mptcp: join: skip check if MIB counter not supported") Cc: stable@vger.kernel.org Reviewed-by: Geliang Tang Signed-off-by: Matthieu Baerts (NGI0) Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 71263ce6abfa128e73d9368d88bfadc708bda09b Author: Matthieu Baerts (NGI0) Date: Wed Aug 28 08:14:26 2024 +0200 selftests: mptcp: join: check removing ID 0 endpoint commit 5f94b08c001290acda94d9d8868075590931c198 upstream. Removing the endpoint linked to the initial subflow should trigger a RM_ADDR for the right ID, and the removal of the subflow. That's what is now being verified in the "delete and re-add" test. Note that removing the initial subflow will not decrement the 'subflows' counters, which corresponds to the *additional* subflows. On the other hand, when the same endpoint is re-added, it will increment this counter, as it will be seen as an additional subflow this time. The 'Fixes' tag here below is the same as the one from the previous commit: this patch here is not fixing anything wrong in the selftests, but it validates the previous fix for an issue introduced by this commit ID. Fixes: 3ad14f54bd74 ("mptcp: more accurate MPC endpoint tracking") Cc: stable@vger.kernel.org Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit a1545eb4ead0e36a88a08cb4ba13575dc39e3e83 Author: Matthieu Baerts (NGI0) Date: Mon Aug 26 19:11:19 2024 +0200 selftests: mptcp: join: cannot rm sf if closed commit e93681afcb96864ec26c3b2ce94008ce93577373 upstream. Thanks to the previous commit, the MPTCP subflows are now closed on both directions even when only the MPTCP path-manager of one peer asks for their closure. In the two tests modified here -- "userspace pm add & remove address" and "userspace pm create destroy subflow" -- one peer is controlled by the userspace PM, and the other one by the in-kernel PM. When the userspace PM sends a RM_ADDR notification, the in-kernel PM will automatically react by closing all subflows using this address. Now, thanks to the previous commit, the subflows are properly closed on both directions, the userspace PM can then no longer closes the same subflows if they are already closed. Before, it was OK to do that, because the subflows were still half-opened, still OK to send a RM_ADDR. In other words, thanks to the previous commit closing the subflows, an error will be returned to the userspace if it tries to close a subflow that has already been closed. So no need to run this command, which mean that the linked counters will then not be incremented. These tests are then no longer sending both a RM_ADDR, then closing the linked subflow just after. The test with the userspace PM on the server side is now removing one subflow linked to one address, then sending a RM_ADDR for another address. The test with the userspace PM on the client side is now only removing the subflow that was previously created. Fixes: 4369c198e599 ("selftests: mptcp: test userspace pm out of transfer") Cc: stable@vger.kernel.org Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20240826-net-mptcp-close-extra-sf-fin-v1-2-905199fe1172@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit a8496ca157fa98c610051cde1e7105ad6737b9ce Author: Matthieu Baerts (NGI0) Date: Wed Aug 28 08:14:37 2024 +0200 mptcp: pm: ADD_ADDR 0 is not a new address commit 57f86203b41c98b322119dfdbb1ec54ce5e3369b upstream. The ADD_ADDR 0 with the address from the initial subflow should not be considered as a new address: this is not something new. If the host receives it, it simply means that the address is available again. When receiving an ADD_ADDR for the ID 0, the PM already doesn't consider it as new by not incrementing the 'add_addr_accepted' counter. But the 'accept_addr' might not be set if the limit has already been reached: this can be bypassed in this case. But before, it is important to check that this ADD_ADDR for the ID 0 is for the same address as the initial subflow. If not, it is not something that should happen, and the ADD_ADDR can be ignored. Note that if an ADD_ADDR is received while there is already a subflow opened using the same address, this ADD_ADDR is ignored as well. It means that if multiple ADD_ADDR for ID 0 are received, there will not be any duplicated subflows created by the client. Fixes: d0876b2284cf ("mptcp: add the incoming RM_ADDR support") Cc: stable@vger.kernel.org Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit e38f07c3837514502e2752dc703e492fee156885 Author: Matthieu Baerts (NGI0) Date: Wed Aug 28 08:14:35 2024 +0200 mptcp: avoid duplicated SUB_CLOSED events commit d82809b6c5f2676b382f77a5cbeb1a5d91ed2235 upstream. The initial subflow might have already been closed, but still in the connection list. When the worker is instructed to close the subflows that have been marked as closed, it might then try to close the initial subflow again. A consequence of that is that the SUB_CLOSED event can be seen twice: # ip mptcp endpoint 1.1.1.1 id 1 subflow dev eth0 2.2.2.2 id 2 subflow dev eth1 # ip mptcp monitor & [ CREATED] remid=0 locid=0 saddr4=1.1.1.1 daddr4=9.9.9.9 [ ESTABLISHED] remid=0 locid=0 saddr4=1.1.1.1 daddr4=9.9.9.9 [ SF_ESTABLISHED] remid=0 locid=2 saddr4=2.2.2.2 daddr4=9.9.9.9 # ip mptcp endpoint delete id 1 [ SF_CLOSED] remid=0 locid=0 saddr4=1.1.1.1 daddr4=9.9.9.9 [ SF_CLOSED] remid=0 locid=0 saddr4=1.1.1.1 daddr4=9.9.9.9 The first one is coming from mptcp_pm_nl_rm_subflow_received(), and the second one from __mptcp_close_subflow(). To avoid doing the post-closed processing twice, the subflow is now marked as closed the first time. Note that it is not enough to check if we are dealing with the first subflow and check its sk_state: the subflow might have been reset or closed before calling mptcp_close_ssk(). Fixes: b911c97c7dc7 ("mptcp: add netlink event support") Cc: stable@vger.kernel.org Tested-by: Arınç ÜNAL Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 119806ae4e46cf239db8e6ad92bc2fd3daae86dc Author: Matthieu Baerts (NGI0) Date: Wed Aug 28 08:14:33 2024 +0200 mptcp: pm: fix ID 0 endp usage after multiple re-creations commit 9366922adc6a71378ca01f898c41be295309f044 upstream. 'local_addr_used' and 'add_addr_accepted' are decremented for addresses not related to the initial subflow (ID0), because the source and destination addresses of the initial subflows are known from the beginning: they don't count as "additional local address being used" or "ADD_ADDR being accepted". It is then required not to increment them when the entrypoint used by the initial subflow is removed and re-added during a connection. Without this modification, this entrypoint cannot be removed and re-added more than once. Reported-by: Arınç ÜNAL Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/512 Fixes: 3ad14f54bd74 ("mptcp: more accurate MPC endpoint tracking") Reported-by: syzbot+455d38ecd5f655fc45cf@syzkaller.appspotmail.com Closes: https://lore.kernel.org/00000000000049861306209237f4@google.com Cc: stable@vger.kernel.org Tested-by: Arınç ÜNAL Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit dc2af94eca4a4faa2307bc0a7da179425ff4f3e8 Author: Matthieu Baerts (NGI0) Date: Wed Aug 28 08:14:32 2024 +0200 mptcp: pm: do not remove already closed subflows commit 58e1b66b4e4b8a602d3f2843e8eba00a969ecce2 upstream. It is possible to have in the list already closed subflows, e.g. the initial subflow has been already closed, but still in the list. No need to try to close it again, and increments the related counters again. Fixes: 0ee4261a3681 ("mptcp: implement mptcp_pm_remove_subflow") Cc: stable@vger.kernel.org Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 7f73d30923549429ae76ecec6f72ad090e6f3ee9 Author: Matthieu Baerts (NGI0) Date: Wed Aug 28 08:14:25 2024 +0200 mptcp: pm: fix RM_ADDR ID for the initial subflow commit 87b5896f3f7848130095656739b05881904e2697 upstream. The initial subflow has a special local ID: 0. When an endpoint is being deleted, it is then important to check if its address is not linked to the initial subflow to send the right ID. If there was an endpoint linked to the initial subflow, msk's mpc_endpoint_id field will be set. We can then use this info when an endpoint is being removed to see if it is linked to the initial subflow. So now, the correct IDs are passed to mptcp_pm_nl_rm_addr_or_subflow(), it is no longer needed to use mptcp_local_id_match(). Fixes: 3ad14f54bd74 ("mptcp: more accurate MPC endpoint tracking") Cc: stable@vger.kernel.org Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 42e7e0a752a30da33de7befc13ef30bfa0c36c90 Author: Matthieu Baerts (NGI0) Date: Wed Aug 28 08:14:27 2024 +0200 mptcp: pm: send ACK on an active subflow commit c07cc3ed895f9bfe0c53b5ed6be710c133b4271c upstream. Taking the first one on the list doesn't work in some cases, e.g. if the initial subflow is being removed. Pick another one instead of not sending anything. Fixes: 84dfe3677a6f ("mptcp: send out dedicated ADD_ADDR packet") Cc: stable@vger.kernel.org Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 3415a1a67a6a7fb2b836947ba3b471ac68fc68bb Author: Matthieu Baerts (NGI0) Date: Wed Aug 28 08:14:29 2024 +0200 mptcp: pm: reset MPC endp ID when re-added commit dce1c6d1e92535f165219695a826caedcca4e9b9 upstream. The initial subflow has a special local ID: 0. It is specific per connection. When a global endpoint is deleted and re-added later, it can have a different ID -- most services managing the endpoints automatically don't force the ID to be the same as before. It is then important to track these modifications to be consistent with the ID being used for the address used by the initial subflow, not to confuse the other peer or to send the ID 0 for the wrong address. Now when removing an endpoint, msk->mpc_endpoint_id is reset if it corresponds to this endpoint. When adding a new endpoint, the same variable is updated if the address match the one of the initial subflow. Fixes: 3ad14f54bd74 ("mptcp: more accurate MPC endpoint tracking") Cc: stable@vger.kernel.org Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 8f71366795b82ed28d3d057e6fa9f58c8cbcebc4 Author: Matthieu Baerts (NGI0) Date: Wed Aug 28 08:14:28 2024 +0200 mptcp: pm: skip connecting to already established sf commit bc19ff57637ff563d2bdf2b385b48c41e6509e0d upstream. The lookup_subflow_by_daddr() helper checks if there is already a subflow connected to this address. But there could be a subflow that is closing, but taking time due to some reasons: latency, losses, data to process, etc. If an ADD_ADDR is received while the endpoint is being closed, it is better to try connecting to it, instead of rejecting it: the peer which has sent the ADD_ADDR will not be notified that the ADD_ADDR has been rejected for this reason, and the expected subflow will not be created at the end. This helper should then only look for subflows that are established, or going to be, but not the ones being closed. Fixes: d84ad04941c3 ("mptcp: skip connecting the connected address") Cc: stable@vger.kernel.org Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 69911409d2034d26f029949a57551ca455b06a19 Author: Matthieu Baerts (NGI0) Date: Wed Aug 28 08:14:24 2024 +0200 mptcp: pm: reuse ID 0 after delete and re-add commit 8b8ed1b429f8fa7ebd5632555e7b047bc0620075 upstream. When the endpoint used by the initial subflow is removed and re-added later, the PM has to force the ID 0, it is a special case imposed by the MPTCP specs. Note that the endpoint should then need to be re-added reusing the same ID. Fixes: 3ad14f54bd74 ("mptcp: more accurate MPC endpoint tracking") Cc: stable@vger.kernel.org Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 78de3c5ffaf2a92413e42533a360d0fca7f9dcf7 Author: Matthieu Baerts (NGI0) Date: Mon Aug 26 19:11:21 2024 +0200 mptcp: pr_debug: add missing \n at the end commit cb41b195e634d3f1ecfcd845314e64fd4bb3c7aa upstream. pr_debug() have been added in various places in MPTCP code to help developers to debug some situations. With the dynamic debug feature, it is easy to enable all or some of them, and asks users to reproduce issues with extra debug. Many of these pr_debug() don't end with a new line, while no 'pr_cont()' are used in MPTCP code. So the goal was not to display multiple debug messages on one line: they were then not missing the '\n' on purpose. Not having the new line at the end causes these messages to be printed with a delay, when something else needs to be printed. This issue is not visible when many messages need to be printed, but it is annoying and confusing when only specific messages are expected, e.g. # echo "func mptcp_pm_add_addr_echoed +fmp" \ > /sys/kernel/debug/dynamic_debug/control # ./mptcp_join.sh "signal address"; \ echo "$(awk '{print $1}' /proc/uptime) - end"; \ sleep 5s; \ echo "$(awk '{print $1}' /proc/uptime) - restart"; \ ./mptcp_join.sh "signal address" 013 signal address (...) 10.75 - end 15.76 - restart 013 signal address [ 10.367935] mptcp:mptcp_pm_add_addr_echoed: MPTCP: msk=(...) (...) => a delay of 5 seconds: printed with a 10.36 ts, but after 'restart' which was printed at the 15.76 ts. The 'Fixes' tag here below points to the first pr_debug() used without '\n' in net/mptcp. This patch could be split in many small ones, with different Fixes tag, but it doesn't seem worth it, because it is easy to re-generate this patch with this simple 'sed' command: git grep -l pr_debug -- net/mptcp | xargs sed -i "s/\(pr_debug(\".*[^n]\)\(\"[,)]\)/\1\\\n\2/g" So in case of conflicts, simply drop the modifications, and launch this command. Fixes: f870fa0b5768 ("mptcp: Add MPTCP socket stubs") Cc: stable@vger.kernel.org Reviewed-by: Geliang Tang Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20240826-net-mptcp-close-extra-sf-fin-v1-4-905199fe1172@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 8ca5c96a007ea77abf6addf7bd680d4cce5a2b3e Author: Matthieu Baerts (NGI0) Date: Mon Aug 26 19:11:20 2024 +0200 mptcp: sched: check both backup in retrans commit 2a1f596ebb23eadc0f9b95a8012e18ef76295fc8 upstream. The 'mptcp_subflow_context' structure has two items related to the backup flags: - 'backup': the subflow has been marked as backup by the other peer - 'request_bkup': the backup flag has been set by the host Looking only at the 'backup' flag can make sense in some cases, but it is not the behaviour of the default packet scheduler when selecting paths. As explained in the commit b6a66e521a20 ("mptcp: sched: check both directions for backup"), the packet scheduler should look at both flags, because that was the behaviour from the beginning: the 'backup' flag was set by accident instead of the 'request_bkup' one. Now that the latter has been fixed, get_retrans() needs to be adapted as well. Fixes: b6a66e521a20 ("mptcp: sched: check both directions for backup") Cc: stable@vger.kernel.org Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20240826-net-mptcp-close-extra-sf-fin-v1-3-905199fe1172@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 2f3efdc9593f66ae48a423eb76973bbbaae9c456 Author: Matthieu Baerts (NGI0) Date: Mon Aug 26 19:11:18 2024 +0200 mptcp: close subflow when receiving TCP+FIN commit f09b0ad55a1196f5891663f8888463c0541059cb upstream. When a peer decides to close one subflow in the middle of a connection having multiple subflows, the receiver of the first FIN should accept that, and close the subflow on its side as well. If not, the subflow will stay half closed, and would even continue to be used until the end of the MPTCP connection or a reset from the network. The issue has not been seen before, probably because the in-kernel path-manager always sends a RM_ADDR before closing the subflow. Upon the reception of this RM_ADDR, the other peer will initiate the closure on its side as well. On the other hand, if the RM_ADDR is lost, or if the path-manager of the other peer only closes the subflow without sending a RM_ADDR, the subflow would switch to TCP_CLOSE_WAIT, but that's it, leaving the subflow half-closed. So now, when the subflow switches to the TCP_CLOSE_WAIT state, and if the MPTCP connection has not been closed before with a DATA_FIN, the kernel owning the subflow schedules its worker to initiate the closure on its side as well. This issue can be easily reproduced with packetdrill, as visible in [1], by creating an additional subflow, injecting a FIN+ACK before sending the DATA_FIN, and expecting a FIN+ACK in return. Fixes: 40947e13997a ("mptcp: schedule worker when subflow is closed") Cc: stable@vger.kernel.org Link: https://github.com/multipath-tcp/packetdrill/pull/154 [1] Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20240826-net-mptcp-close-extra-sf-fin-v1-1-905199fe1172@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit bdef76aab9f36dc8ff4fb14bba50286d264ba793 Author: Haiyang Zhang Date: Wed Aug 21 13:42:29 2024 -0700 net: mana: Fix race of mana_hwc_post_rx_wqe and new hwc response commit 8af174ea863c72f25ce31cee3baad8a301c0cf0f upstream. The mana_hwc_rx_event_handler() / mana_hwc_handle_resp() calls complete(&ctx->comp_event) before posting the wqe back. It's possible that other callers, like mana_create_txq(), start the next round of mana_hwc_send_request() before the posting of wqe. And if the HW is fast enough to respond, it can hit no_wqe error on the HW channel, then the response message is lost. The mana driver may fail to create queues and open, because of waiting for the HW response and timed out. Sample dmesg: [ 528.610840] mana 39d4:00:02.0: HWC: Request timed out! [ 528.614452] mana 39d4:00:02.0: Failed to send mana message: -110, 0x0 [ 528.618326] mana 39d4:00:02.0 enP14804s2: Failed to create WQ object: -110 To fix it, move posting of rx wqe before complete(&ctx->comp_event). Cc: stable@vger.kernel.org Fixes: ca9c54d2d6a5 ("net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)") Signed-off-by: Haiyang Zhang Reviewed-by: Long Li Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5432afe3a59f2c21c338f4bb11465ce49bb2a562 Author: Sascha Hauer Date: Fri Aug 9 10:11:33 2024 +0200 wifi: mwifiex: duplicate static structs used in driver instances commit 27ec3c57fcadb43c79ed05b2ea31bc18c72d798a upstream. mwifiex_band_2ghz and mwifiex_band_5ghz are statically allocated, but used and modified in driver instances. Duplicate them before using them in driver instances so that different driver instances do not influence each other. This was observed on a board which has one PCIe and one SDIO mwifiex adapter. It blew up in mwifiex_setup_ht_caps(). This was called with the statically allocated struct which is modified in this function. Cc: stable@vger.kernel.org Fixes: d6bffe8bb520 ("mwifiex: support for creation of AP interface") Signed-off-by: Sascha Hauer Reviewed-by: Francesco Dolcini Acked-by: Brian Norris Signed-off-by: Kalle Valo Link: https://patch.msgid.link/20240809-mwifiex-duplicate-static-structs-v1-1-6837b903b1a4@pengutronix.de Signed-off-by: Greg Kroah-Hartman commit a177a7accaabf9c4803344b3c3804f2e8baaffd9 Author: Alexander Sverdlin Date: Fri Aug 23 15:15:20 2024 +0200 wifi: wfx: repair open network AP mode commit 6d30bb88f623526197c0e18a366e68a4254a2c83 upstream. RSN IE missing in beacon is normal in open networks. Avoid returning -EINVAL in this case. Steps to reproduce: $ cat /etc/wpa_supplicant.conf network={ ssid="testNet" mode=2 key_mgmt=NONE } $ wpa_supplicant -iwlan0 -c /etc/wpa_supplicant.conf nl80211: Beacon set failed: -22 (Invalid argument) Failed to set beacon parameters Interface initialization failed wlan0: interface state UNINITIALIZED->DISABLED wlan0: AP-DISABLED wlan0: Unable to setup interface. Failed to initialize AP interface After the change: $ wpa_supplicant -iwlan0 -c /etc/wpa_supplicant.conf Successfully initialized wpa_supplicant wlan0: interface state UNINITIALIZED->ENABLED wlan0: AP-ENABLED Cc: stable@vger.kernel.org Fixes: fe0a7776d4d1 ("wifi: wfx: fix possible NULL pointer dereference in wfx_set_mfp_ap()") Signed-off-by: Alexander Sverdlin Reviewed-by: Jérôme Pouiller Signed-off-by: Kalle Valo Link: https://patch.msgid.link/20240823131521.3309073-1-alexander.sverdlin@siemens.com Signed-off-by: Greg Kroah-Hartman commit 4bf612bc3c636687e75137ac76bce5cb65fefb7f Author: David Howells Date: Wed Aug 14 21:38:21 2024 +0100 netfs, ceph: Partially revert "netfs: Replace PG_fscache by setting folio->private and marking dirty" commit 92764e8822d4e7f8efb5ad959fac195a7f8ea0c6 upstream. This partially reverts commit 2ff1e97587f4d398686f52c07afde3faf3da4e5c. In addition to reverting the removal of PG_private_2 wrangling from the buffered read code[1][2], the removal of the waits for PG_private_2 from netfs_release_folio() and netfs_invalidate_folio() need reverting too. It also adds a wait into ceph_evict_inode() to wait for netfs read and copy-to-cache ops to complete. Fixes: 2ff1e97587f4 ("netfs: Replace PG_fscache by setting folio->private and marking dirty") Signed-off-by: David Howells Link: https://lore.kernel.org/r/3575457.1722355300@warthog.procyon.org.uk [1] Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8e5ced7804cb9184c4a23f8054551240562a8eda [2] Link: https://lore.kernel.org/r/20240814203850.2240469-2-dhowells@redhat.com cc: Max Kellermann cc: Ilya Dryomov cc: Xiubo Li cc: Jeff Layton cc: Matthew Wilcox cc: ceph-devel@vger.kernel.org cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org cc: linux-mm@kvack.org Signed-off-by: Christian Brauner Signed-off-by: Greg Kroah-Hartman commit 292151af6add3e5ab11b2e9916cffa5f52859a1f Author: Ma Ke Date: Thu Aug 8 12:13:55 2024 +0800 pinctrl: single: fix potential NULL dereference in pcs_get_function() commit 1c38a62f15e595346a1106025722869e87ffe044 upstream. pinmux_generic_get_function() can return NULL and the pointer 'function' was dereferenced without checking against NULL. Add checking of pointer 'function' in pcs_get_function(). Found by code review. Cc: stable@vger.kernel.org Fixes: 571aec4df5b7 ("pinctrl: single: Use generic pinmux helpers for managing functions") Signed-off-by: Ma Ke Link: https://lore.kernel.org/20240808041355.2766009-1-make24@iscas.ac.cn Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit c3b47777c3caa15660cd77ab762de058ee74437b Author: Huang-Huang Bao Date: Tue Jul 9 18:54:28 2024 +0800 pinctrl: rockchip: correct RK3328 iomux width flag for GPIO2-B pins commit 128f71fe014fc91efa1407ce549f94a9a9f1072c upstream. The base iomux offsets for each GPIO pin line are accumulatively calculated based off iomux width flag in rockchip_pinctrl_get_soc_data. If the iomux width flag is one of IOMUX_WIDTH_4BIT, IOMUX_WIDTH_3BIT or IOMUX_WIDTH_2BIT, the base offset for next pin line would increase by 8 bytes, otherwise it would increase by 4 bytes. Despite most of GPIO2-B iomux have 2-bit data width, which can be fit into 4 bytes space with write mask, it actually take 8 bytes width for whole GPIO2-B line. Commit e8448a6c817c ("pinctrl: rockchip: fix pinmux bits for RK3328 GPIO2-B pins") wrongly set iomux width flag to 0, causing all base iomux offset for line after GPIO2-B to be calculated wrong. Fix the iomux width flag to IOMUX_WIDTH_2BIT so the offset after GPIO2-B is correctly increased by 8, matching the actual width of GPIO2-B iomux. Fixes: e8448a6c817c ("pinctrl: rockchip: fix pinmux bits for RK3328 GPIO2-B pins") Cc: stable@vger.kernel.org Reported-by: Richard Kojedzinszky Closes: https://lore.kernel.org/linux-rockchip/4f29b743202397d60edfb3c725537415@kojedz.in/ Tested-by: Richard Kojedzinszky Signed-off-by: Huang-Huang Bao Reviewed-by: Heiko Stuebner Tested-by: Daniel Golle Tested-by: Trevor Woerner Link: https://lore.kernel.org/20240709105428.1176375-1-i@eh5.me Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit b902fb78ab21299e4dd1775e7e8d251d5c0735bc Author: Stefan Metzmacher Date: Wed Aug 21 17:18:23 2024 +0200 smb/client: avoid dereferencing rdata=NULL in smb2_new_read_req() commit c724b2ab6a46435b4e7d58ad2fbbdb7a318823cf upstream. This happens when called from SMB2_read() while using rdma and reaching the rdma_readwrite_threshold. Cc: stable@vger.kernel.org Fixes: a6559cc1d35d ("cifs: split out smb3_use_rdma_offload() helper") Reviewed-by: David Howells Signed-off-by: Stefan Metzmacher Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit ccedb44fc80006ea1380b032f64dcb77a5508657 Author: Josef Bacik Date: Wed Aug 21 15:53:18 2024 -0400 btrfs: run delayed iputs when flushing delalloc commit 2d3447261031503b181dacc549fe65ffe2d93d65 upstream. We have transient failures with btrfs/301, specifically in the part where we do for i in $(seq 0 10); do write 50m to file rm -f file done Sometimes this will result in a transient quota error, and it's because sometimes we start writeback on the file which results in a delayed iput, and thus the rm doesn't actually clean the file up. When we're flushing the quota space we need to run the delayed iputs to make sure all the unlinks that we think have completed have actually completed. This removes the small window where we could fail to find enough space in our quota. CC: stable@vger.kernel.org # 5.15+ Reviewed-by: Qu Wenruo Signed-off-by: Josef Bacik Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 4a3b9e1a8e6cd1a8d427a905e159de58d38941cc Author: Qu Wenruo Date: Sat Aug 17 18:34:30 2024 +0930 btrfs: fix a use-after-free when hitting errors inside btrfs_submit_chunk() commit 10d9d8c3512f16cad47b2ff81ec6fc4b27d8ee10 upstream. [BUG] There is an internal report that KASAN is reporting use-after-free, with the following backtrace: BUG: KASAN: slab-use-after-free in btrfs_check_read_bio+0xa68/0xb70 [btrfs] Read of size 4 at addr ffff8881117cec28 by task kworker/u16:2/45 CPU: 1 UID: 0 PID: 45 Comm: kworker/u16:2 Not tainted 6.11.0-rc2-next-20240805-default+ #76 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014 Workqueue: btrfs-endio btrfs_end_bio_work [btrfs] Call Trace: dump_stack_lvl+0x61/0x80 print_address_description.constprop.0+0x5e/0x2f0 print_report+0x118/0x216 kasan_report+0x11d/0x1f0 btrfs_check_read_bio+0xa68/0xb70 [btrfs] process_one_work+0xce0/0x12a0 worker_thread+0x717/0x1250 kthread+0x2e3/0x3c0 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x11/0x20 Allocated by task 20917: kasan_save_stack+0x37/0x60 kasan_save_track+0x10/0x30 __kasan_slab_alloc+0x7d/0x80 kmem_cache_alloc_noprof+0x16e/0x3e0 mempool_alloc_noprof+0x12e/0x310 bio_alloc_bioset+0x3f0/0x7a0 btrfs_bio_alloc+0x2e/0x50 [btrfs] submit_extent_page+0x4d1/0xdb0 [btrfs] btrfs_do_readpage+0x8b4/0x12a0 [btrfs] btrfs_readahead+0x29a/0x430 [btrfs] read_pages+0x1a7/0xc60 page_cache_ra_unbounded+0x2ad/0x560 filemap_get_pages+0x629/0xa20 filemap_read+0x335/0xbf0 vfs_read+0x790/0xcb0 ksys_read+0xfd/0x1d0 do_syscall_64+0x6d/0x140 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Freed by task 20917: kasan_save_stack+0x37/0x60 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x50 __kasan_slab_free+0x4b/0x60 kmem_cache_free+0x214/0x5d0 bio_free+0xed/0x180 end_bbio_data_read+0x1cc/0x580 [btrfs] btrfs_submit_chunk+0x98d/0x1880 [btrfs] btrfs_submit_bio+0x33/0x70 [btrfs] submit_one_bio+0xd4/0x130 [btrfs] submit_extent_page+0x3ea/0xdb0 [btrfs] btrfs_do_readpage+0x8b4/0x12a0 [btrfs] btrfs_readahead+0x29a/0x430 [btrfs] read_pages+0x1a7/0xc60 page_cache_ra_unbounded+0x2ad/0x560 filemap_get_pages+0x629/0xa20 filemap_read+0x335/0xbf0 vfs_read+0x790/0xcb0 ksys_read+0xfd/0x1d0 do_syscall_64+0x6d/0x140 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [CAUSE] Although I cannot reproduce the error, the report itself is good enough to pin down the cause. The call trace is the regular endio workqueue context, but the free-by-task trace is showing that during btrfs_submit_chunk() we already hit a critical error, and is calling btrfs_bio_end_io() to error out. And the original endio function called bio_put() to free the whole bio. This means a double freeing thus causing use-after-free, e.g.: 1. Enter btrfs_submit_bio() with a read bio The read bio length is 128K, crossing two 64K stripes. 2. The first run of btrfs_submit_chunk() 2.1 Call btrfs_map_block(), which returns 64K 2.2 Call btrfs_split_bio() Now there are two bios, one referring to the first 64K, the other referring to the second 64K. 2.3 The first half is submitted. 3. The second run of btrfs_submit_chunk() 3.1 Call btrfs_map_block(), which by somehow failed Now we call btrfs_bio_end_io() to handle the error 3.2 btrfs_bio_end_io() calls the original endio function Which is end_bbio_data_read(), and it calls bio_put() for the original bio. Now the original bio is freed. 4. The submitted first 64K bio finished Now we call into btrfs_check_read_bio() and tries to advance the bio iter. But since the original bio (thus its iter) is already freed, we trigger the above use-after free. And even if the memory is not poisoned/corrupted, we will later call the original endio function, causing a double freeing. [FIX] Instead of calling btrfs_bio_end_io(), call btrfs_orig_bbio_end_io(), which has the extra check on split bios and do the proper refcounting for cloned bios. Furthermore there is already one extra btrfs_cleanup_bio() call, but that is duplicated to btrfs_orig_bbio_end_io() call, so remove that label completely. Reported-by: David Sterba Fixes: 852eee62d31a ("btrfs: allow btrfs_submit_bio to split bios") CC: stable@vger.kernel.org # 6.6+ 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 408ed08408e72d2a5b57968de67600a55be63802 Author: Stefan Berger Date: Mon Jul 29 09:29:34 2024 -0400 tpm: ibmvtpm: Call tpm2_sessions_init() to initialize session support commit 08d08e2e9f0ad1af0044e4747723f66677c35ee9 upstream. Commit d2add27cf2b8 ("tpm: Add NULL primary creation") introduced CONFIG_TCG_TPM2_HMAC. When this option is enabled on ppc64 then the following message appears in the kernel log due to a missing call to tpm2_sessions_init(). [ 2.654549] tpm tpm0: auth session is not active Add the missing call to tpm2_session_init() to the ibmvtpm driver to resolve this issue. Cc: stable@vger.kernel.org # v6.10+ Fixes: d2add27cf2b8 ("tpm: Add NULL primary creation") Signed-off-by: Stefan Berger Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit dd0533b7e151eb5af51a9a9a76cc51e9ebdee3bf Author: Tiezhu Yang Date: Mon Aug 26 23:11:32 2024 +0800 LoongArch: Add ifdefs to fix LSX and LASX related warnings commit 80376323e2b6a4559f86b2b4d864848ac25cb054 upstream. There exist some warnings when building kernel if CONFIG_CPU_HAS_LBT is set but CONFIG_CPU_HAS_LSX and CONFIG_CPU_HAS_LASX are not set. In this case, there are no definitions of _restore_lsx & _restore_lasx and there are also no definitions of kvm_restore_lsx & kvm_restore_lasx in fpu.S and switch.S respectively, just add some ifdefs to fix these warnings. AS arch/loongarch/kernel/fpu.o arch/loongarch/kernel/fpu.o: warning: objtool: unexpected relocation symbol type in .rela.discard.func_stack_frame_non_standard: 0 arch/loongarch/kernel/fpu.o: warning: objtool: unexpected relocation symbol type in .rela.discard.func_stack_frame_non_standard: 0 AS [M] arch/loongarch/kvm/switch.o arch/loongarch/kvm/switch.o: warning: objtool: unexpected relocation symbol type in .rela.discard.func_stack_frame_non_standard: 0 arch/loongarch/kvm/switch.o: warning: objtool: unexpected relocation symbol type in .rela.discard.func_stack_frame_non_standard: 0 MODPOST Module.symvers ERROR: modpost: "kvm_restore_lsx" [arch/loongarch/kvm/kvm.ko] undefined! ERROR: modpost: "kvm_restore_lasx" [arch/loongarch/kvm/kvm.ko] undefined! Cc: stable@vger.kernel.org # 6.9+ Fixes: cb8a2ef0848c ("LoongArch: Add ORC stack unwinder support") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202408120955.qls5oNQY-lkp@intel.com/ Signed-off-by: Tiezhu Yang Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit d844655a8210e893c41990538db53fcbb99a6627 Author: Miao Wang Date: Sun Aug 25 22:17:39 2024 +0800 LoongArch: Remove the unused dma-direct.h commit 58aec91efb93338d1cc7acc0a93242613a2a4e5f upstream. dma-direct.h is introduced in commit d4b6f1562a3c3284 ("LoongArch: Add Non-Uniform Memory Access (NUMA) support"). In commit c78c43fe7d42524c ("LoongArch: Use acpi_arch_dma_setup() and remove ARCH_HAS_PHYS_TO_DMA"), ARCH_HAS_PHYS_TO_DMA was deselected and the coresponding phys_to_dma()/ dma_to_phys() functions were removed. However, the unused dma-direct.h was left behind, which is removed by this patch. Cc: Fixes: c78c43fe7d42 ("LoongArch: Use acpi_arch_dma_setup() and remove ARCH_HAS_PHYS_TO_DMA") Signed-off-by: Miao Wang Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit abcc6503bb4e2f2ea43645f77f04f2f734f2cf67 Author: Hendrik Borghorst Date: Sun Aug 25 19:43:47 2024 +0200 ALSA: hda/realtek: support HP Pavilion Aero 13-bg0xxx Mute LED commit 2dc43c5e212036458ed7c5586fb82ee183fee504 upstream. This patch adds the HP Pavilion Aero 13 (13-bg0xxx) (year 2024) to list of quirks for keyboard LED mute indication. The laptop has two LEDs (one for speaker and one for mic mute). The pre-existing quirk ALC245_FIXUP_HP_X360_MUTE_LEDS chains both the quirk for mic and speaker mute. Tested on 6.11.0-rc4 with the aforementioned laptop. Signed-off-by: Hendrik Borghorst Cc: Link: https://patch.msgid.link/20240825174351.5687-1-hendrikborghorst@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit a914183edea06284394548b8977ebdac00ddfec2 Author: John Sweeney Date: Sun Aug 18 11:30:15 2024 -0400 ALSA: hda/realtek: Enable mute/micmute LEDs on HP Laptop 14-ey0xxx commit 56314c0d78d6f5a60c8804c517167991a879e14a upstream. HP Pavilion Plus 14-ey0xxx needs existing quirk ALC245_FIXUP_HP_X360_MUTE_LEDS to enable its mute/micmute LEDs. Signed-off-by: John Sweeney Cc: Link: https://patch.msgid.link/E1sfhrD-0007TA-HC@rmmprod05.runbox Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 9b87ef20e4fc7972d2831b656a9dc9f7a36a03e9 Author: Takashi Iwai Date: Mon Aug 19 10:41:53 2024 +0200 ALSA: seq: Skip event type filtering for UMP events commit 32108c22ac619c32dd6db594319e259b63bfb387 upstream. UMP events don't use the event type field, hence it's invalid to apply the filter, which may drop the events unexpectedly. Skip the event filtering for UMP events, instead. Fixes: 46397622a3fa ("ALSA: seq: Add UMP support") Cc: Link: https://patch.msgid.link/20240819084156.10286-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 49c0e081998008cde0c872c0ff9affa1ece4b878 Author: Gao Xiang Date: Tue Aug 20 16:56:19 2024 +0800 erofs: fix out-of-bound access when z_erofs_gbuf_growsize() partially fails commit 0005e01e1e875c5e27130c5e2ed0189749d1e08a upstream. If z_erofs_gbuf_growsize() partially fails on a global buffer due to memory allocation failure or fault injection (as reported by syzbot [1]), new pages need to be freed by comparing to the existing pages to avoid memory leaks. However, the old gbuf->pages[] array may not be large enough, which can lead to null-ptr-deref or out-of-bound access. Fix this by checking against gbuf->nrpages in advance. [1] https://lore.kernel.org/r/000000000000f7b96e062018c6e3@google.com Reported-by: syzbot+242ee56aaa9585553766@syzkaller.appspotmail.com Fixes: d6db47e571dc ("erofs: do not use pagepool in z_erofs_gbuf_growsize()") Cc: # 6.10+ Reviewed-by: Chunhai Guo Reviewed-by: Sandeep Dhavale Signed-off-by: Gao Xiang Link: https://lore.kernel.org/r/20240820085619.1375963-1-hsiangkao@linux.alibaba.com Signed-off-by: Greg Kroah-Hartman commit ed37550d7c516017c3b0324bdf144e2fa563ffb0 Author: Jack Xiao Date: Thu Jul 18 16:38:50 2024 +0800 drm/amdgpu/mes: fix mes ring buffer overflow commit 11752c013f562a1124088a35bd314aa0e9f0e88f upstream. wait memory room until enough before writing mes packets to avoid ring buffer overflow. v2: squash in sched_hw_submission fix Fixes: de3246254156 ("drm/amdgpu: cleanup MES11 command submission") Fixes: fffe347e1478 ("drm/amdgpu: cleanup MES12 command submission") Signed-off-by: Jack Xiao Acked-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit 34e087e8920e635c62e2ed6a758b0cd27f836d13) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman